Saturday, February 12, 2011

DirectQ Update - 12th February 2011

Just spent a few hours between yesterday and today tracking down a nasty shader compiler crash bug. It turned out to be a combination of my own stupidity and a documentation omission. If you're passing preprocessor definitions to the effect compiler you need to use a NULL-terminated array (rather than just an array); this is only documented in the D3DXCreateEffectFromFile functions (which I don't use), it's completely omitted from the other D3DXCreateEffect function documentation.

I say my own stupidity here because I should have been aware that the array needed to be NULL-terminated; there's no length parameter for it so how else is the shader compiler going to detect it's end? It still doesn't excuse the documentation though; having an important fact only documented in a function that someone might never even use seems a mite dangerous to me.

This one has been present since fog reappeared in DirectQ, but it wasn't a crash bug until now as I had some other variable declarations following my D3DXMACRO, which soaked up the abuse and eventually got NULLs into the right places. It was only after my recent code reworking that it started blowing up.

I've been doing some experiments with hardware geometry instancing, and this is another area where documentation is quite obtuse and confusing. It doesn't help that instead of saying straight up what the various methods and parameters actually do it instead veers off into giving some fairly foggy (and simplistic) examples and leaves you to figure out what the hell is going on for yourself.

But all's well that ends well and I've implemented it on particles, which are a good candidate for this rendering technique. I've been able to reduce the particle vertex submission overhead by a factor of over 4, and have also offloaded a lot of the billboarding calculations to my vertex shader. It had always annoyed me that D3D9 didn't get geometry shaders, but this is a good compromise and helps to reduce one bottleneck. It also removes one of the reasons for eventually porting to D3D11.

This type of instancing is only available on SM3 or higher hardware, but I've left the old codepath in for lowlier devices.

2 comments:

MichealS said...

So, does that leave out the ageing GMA 950? It apparently has software support for VS-SM3, but is that enough for this new setup?

mhquake said...

It'll fall back to the old code, no worries.