Much more efficient (some 0.x watts) and faster - but not very easy to develop and even harder to deploy :)

and you will get in trouble with the amount of code(needed gates) for porting nowerdays doom

No it will not outperform your GPU for rendering, that is already a specialized hardware

It honestly depends on what you are rendering. If your application is just pong, it is feasible to implement a rendering pipeline that is virtually instantaneous. GPUs have overhead for even the most trivial application. With flip-flops or other analog circuitry, you are talking about frame latency in terms that are similar to the propagation speed of an electron through arbitrary copper wires or semiconductors. If you insist on digital output, some buffering will be required, but in the analog output case you are probably looking at a handful of microseconds of latency between input and output.

It’s specialized for a very general problem though. If he made his own graphics logic in there too he could maybe make it faster too

The available fpga hardware is just not able to compete with the sheer hardware power (ghz,ram,gates) of a todays gpu - but i would agree on smaller problems

FPGAs can achieve very compelling performance when programmed properly, but usually not for compute bound workloads. Most interesting problems are memory bound these days, and that's where FPGAs shine, since you can design your hardware to be as wide as your problem. Or alternatively if you have many parallel sub-problems, you can make your hardware as narrow as the sub-problems and replicate it many times.

You can usually move data on and off chip very quickly also, since high end modern FPGAs have many hundreds of pins. Generally these get connected in to hard-logic like fiber networking or PCIe.

An FPGA soft core is never going to beat an ASIC if both were designed well. But they can beat general purpose ASICs (e.g. GPUs) for certain classes of problems, mostly those where you can exploit the massive memory bandwidth of the FPGA.

I think that for rendering computer graphics, you really just want a big fat pile of FPUs. FPGAs will usually have a number of hard logic DSP blocks on-die, but nowhere near as many as a GPU. If rendering 3D graphics is the problem you want to solve, you probably really want a GPU.

Further down the author says it runs at 60fps, without much headroom. So quite some way behind modern GPUs - the latest doom game can run at 200+ FPS and is vastly more complicated.

That, combined with the cost of the hardware in comparison to a digital copy makes me think this is unlikely to be particularly useful to the games industry. It's incredibly impressive though!

(Author here) Thanks - and I agree. That being said this is running 100 MHz on (what I believe is) a relatively low end FPGA? Also my implementation remains simplistic, many things to optimize. But this is a very good and deep question: how can we compare these things? What is the right metric? (FLOPS per watt? err, no, no floating point involved ;) ). I am wondering and this seems quite a difficult/subtle question.

I love GPUs, I spent many year working with them (still do!) and these are beautiful pieces of hardware and engineering (as modern CPUs are). They have evolved beyond our craziest dreams since the NVidia register combiners (https://www.khronos.org/registry/OpenGL/extensions/NV/NV_reg...). The performance we get nowadays is absolutely mind-boggling (I often think we don't fully realize how powerful they actually are).

Can we dream of some sort of mixed platform, where we could 'burn-in' very specific functions into FPGA type hardware that would seamlessly interact with our modern GPUs/CPUs? Is it already happening?

One could probably go for something like the product of the number of gates involved and the clock frequency to quantify the efficiency of an implementation. Then you can either have a very simple processor with only a few gates but running at a high clock frequency to get all the computations done or you can have a very large parallel implementation with many gates but requiring only a lower clock frequency.

One must obviously only count the actually used gates, for example if floating point units in a processor are not used, and account for idle time if a frame is completed faster than the frame time. Also counting gates might be somewhat tricky, for example in a FPGA where multiplexers and memory are used to build look-up tables to then implement gates, so one could either count the actual gates in the FPGA because those are the gates that are actually used but one could also want to count the gates in the design as if the design was implemented in an ASIC. On the other hand the difference is probably just a small constant factor and it might not really matter that much.

In the end power consumption should capture this pretty well as it scales with the number of actually switching transistors and clock frequency. One would still have to account for the differences in technology and especially supply voltage which goes quadratically into the power consumption.

That's way more expensive than the margins they're used to for distribution.

And the xbone not getting hacked in it's lifetime proved that they can have their cake and eat it too.