070930 / Porting to SM3.0

previous | next

Atom is a technology gamble, will enough people with GeForce 8x00 cards be interested in the game within the first year of release (some time in 2008)? If so, this will be a success, if not, well, I'd rather not go there.

BTW, this is an OpenGL based game, so there is NO need to goto Vista to run this (to get DirectX10), the NVidia drivers for Windows XP have SM4.0 support!

Porting to AMD/ATI HD

Getting Atom to run on the New AMD/ATI HD cards should be easy, only have to replace my TextureArray usage with a large flat 2D texture and multiple drawing passes with glScissor() to mask the regions. Is it worth the change? I will probably wait and see in 2008.

Porting to SM3.0

First, ATI never really had SM3.0 support do to a lack of a vertex texture fetch ability. So all older ATI cards are an instant no go. Vertex texture fetch is an absolute requirement, render to vertex array just isn't going to cut it for Atom.

Looking at the Valve Hardware Survey Summary about 22% have a 7600 or better NVidia card, and only about 6% have a SM4.0 able card.

So could Atom be ported to SM3.0 to get about 3.6 times the possible user base?

The GPU Gems 2 book has a chapter which outlines the 6800 card's hardware. Key points from this are, limited to 4 MRTs, only float FP32 and vec4 FP32 un-filtered texture lookups from the Vertex Shader, only un-filted FP32 texture lookups from the Fragment Shader, no TextureArrays, and no Geometry Shaders. From what I can gather, the 7x00 hardware is the same in this respect, just a faster series of cards.

Getting around the lack of a Geometry Shader is a serious problem, requiring either more work on the CPU or 4 times more work on the Vertex Shader, including a bunch of dependent texture reads (to generate my impostor billboards on the GPU). Either way performance would suffer, but it could be done.

However the real deal breaker might be the lack of a FP32 filtered texture lookup. A little secret, the physics gathering step uses linear filtered texture lookups to filter between particles ... without it, physics effects start grouping particles because a much smaller than screen size buffer (in the x,y dimension) is used to accumulate the velocity vector field (and other physics properties). Manually filtering is not an option. I'm doing 65K mega particles with multiple gathers per particle. The performance just isn't there to manually filter each gather.

Going to FP16 was a possible fix, and would work for a 2D game. Would probably also greatly improve my performance do to 2x better texture caching and filtered lookup performance. Just not enough precision for Z. The X,Y position could be translated into projected screen space, then un-projected back to FP32 knowing the Z. So the first though was to just use impostor drawing order as Z, 65K values fit nicely into a FP16 value. Then could do a dependent texture lookup to find actual Z given the FP16 impostor drawing order.

Might work, but one more problem, my physics scattering pass draws alpha blended motion billboards (of the physics properties per particle) into a layered 2D buffer. It is the alpha blending and actual drawing of the path of the particle, which enables the ultra smooth CFD physics. So if I had my XY velocity vectors in screen space, and my Z position as drawing order, the blending would be wrong. Also storing a Z velocity vector would be a mess. Could save Z velocity divided by particle radius, but would have to save particle radius in projected screen space as well. Doing a non-blended extra FP32 Z only pass could be an option, would double the work at the Vertex Shader level, and removes the Z blending which is important.

Bottom line, it only just might be possible to port to SM3.0, but is it worth it? This is what I am going to ponder while I'm reading GPU Gems 3 on the plane and am off photographing this week in the Sierras.