Tim Sweeney on the twilight of the GPU

I don't think this is what is holding back Linux games. Many game companies already design their games to not rely on DirectX -- none of the games on the PS3, Wii, Mac, or various portables require DirectX.

But they will only port to platforms where they think they can make money. Linux's low gamer population doesn't help, nor does the "everything's free" user expectation.

Actually, even with hand rolled C you'd have a hard time getting real time rendering performance out of a network of computers. 10-100 white boxes have fearsome throughput, but their latency will probably never be suitable for real time use.

The first painful problem is the processing power of a GPU versus a CPU. A general rule of thumb is that a GPU (or in general, a many core, stream processor) will have more than 10x the peak FLOPS per transistor. The QX9775 versus the 8800 Ultra according to Wikipedia is 51 gflops versus 576 - and note that the 8800 Ultra cost significantly less when released!

Then there's the suitability of the two processor types for rendering. Graphics cards have the benefit of specialised instructions (think SSE) to help with things like antialiasing, I believe Larrabbee will have quite a few of these not found on x86. Then there's the cache model - stream processors are designed for the data to stream through the processor (hence the name), not for random access. This is exactly what you want for rendering, and I think you'd probably find you'd get more cache misses on a modern Intel CPU because you can't precache from memory into cache. Let's call it a 3x penalty between these two problems. I have no idea what it really is.

So we're at requiring 30 QX9775s for each 8800 Ultra, which would probably be 30 skulltrail (2xQX9775) versus an 8800 SLI setup.

Now, rendering at 60 fps you've got to render in 16ms. This actually turns out to not be much time in a networked environment.

First, you've got to push out all of the data that you would have pushed onto the graphics card over PCI-X. 32x runs at 8gb/s, which is 8 times faster than Gig-E, but you have to distribute the information to 30 computers. The fastest way to do this is to stream the information to one other machine, which in turn starts streaming to another, and so on - so you're transfering at 500mbps (or 1gbps, I think, if in full duplex?). This is far less efficient than just using PCI-X, though! If you've got to send a lot of data, you're probably screwed. 16ms at 500mbps is 1 megabyte - that is enough to stream new rotation/positions for preloaded geometry, but it's not a lot of triangles (considering the processing power of your setup), and it's nothing in terms of textures. And that's if just the streaming out portion eats up your whole 16ms - you'll probably want to keep it down in the 1-2ms range, which means a few hundred kb, at the theoretical throughput of the network!

Now, each of the machines render their rectangle. Note that this doesn't scale linearly. Imagine rendering just one pixel - you've still got to process all of the geometry that can potentially modify that pixel. So each of your 30 machines are only going to be rendering 1/30 of the game, but they'll be far less than 30x faster. Amdahl's law sometimes pops up in graphics, too!

Now, you've got to send the already rendered frame buffer back to machine that's rendering. You'd probably do this as 32 bit frame (you want at least one bit for the alpha, because you've got to have some way to mask, and picking a colour for the mask means running through the whole image to find a colour you've not used - there will always be one in 24 bit for <4096x4096).

Now, depending on how you're splitting the rendering up, this is going to add up to 9 megabytes at 1920x1200 and... oops, I should have checked this before I even started, because that's too big to send back. You can only send those at 10fps on GigE uncompressed, and there's no way you'll be able to do anything except RLE in 16ms - which, in general 3D rendering, won't do much.

Note that PCI-X doesn't require this send - since the graphics card runs the display - but even on an SLI setup, they use a special interconnect for communication between the cards since PCI-X itself isn't fast enough.

Wow, that was fun to write, but I doubt anyone is going to read it! Readers digest version:

* 10x more FLOPS on a graphics card

* 3x the throughput per FLOP due to graphics specific optimisation (this is a wild guess)

* 30x the machine requirements, except that even 3D rendering does not scale linearly

* 60fps requires 16ms rendering, which allows for just 1mb of network traffic at GigE (or 2mb full duplex)

* You're sending back a 9mb frame buffer rendering a 1920x1200 image

* Fail.

Now, the picture would probably change if you used 10gbps ethernet, and put 4x larrabee cards in each of a smaller number of boxes...