Monday, May 3, 2010

HLSL Water Warp Might Go

I really didn't expect to be making this post, but ever since I brought back the non-HLSL water warp I've been optimizing it quite well, and now have it in a state where even with a gl_subdivide_size of 8 it runs faster than the HLSL warp. This was achieved by removing duplicate vertexes from the resulting subdivided surface, so that the cost of submitting vertexes to the renderer has been colossally reduced.

I'm still undecided. The HLSL warp is higher quality as it's per-pixel, but having two code paths for liquid surfaces is currently a little too complex for my liking (and right now the non-HLSL warp would fit better with where I want to go with the renderer in the future). At the same time, the default gl_subdivide_size of 128 does not provide good quality, and I do want to have a default behaviour that is good quality. On the other hand the non-HLSL warp would be a default that works on everything, whereas the HLSL warp isn't.

Surface subdivision also slows down map loading, although I have some memcpy and memset optimizations in that can negate much of that. It does use more memory though, which is another downside.

I think I'm going to be doing some more tests and comparisons before I come to a decision, but as things stand my preference for simpler cleaner code paths needs to be balanced against the need for a sensible default that both looks good and runs well (or well enough). It's a difficult one...

Update: I've done some further testing with this and it appears that in cases where you're not bandwidth limited the optimization is of marginal benefit. It should still be good for the GeForce FX crowd though, as DirectQ's shaders won't run too fast on those cards.

Overall though it's a good thing to have, but the HLSL water warp will be staying nonetheless.

0 comments: