Thursday, June 18, 2009

Implementing a fixed pipeline path

Yesterday I started on implementing the fixed pipeline path in DirectQ. The good news is that - so far as I can gather - Direct3D is very forgiving in terms of attempting to call programmable pipeline functions where it's not supported, and that the behaviour is to silently fail rather than kick and scream. This means that I can reuse a lot of the codebase without modification, in particular the major part I was concerned about, which is the Effect loader and compiler.

However, it's looking as though I may need to restructure some of the code in order to get it done without creating a mess along the way. So the next few releases will likely contain successive evolutions of the fixed pipeline code, but it won't be operational, and will in fact be hard-disabled.

One aspect I'm not too happy about here is that I had expected some significant speed gains running through the fixed path, especially with respect to the Intel chip I'm testing on. However, while there was a gain, it was quite small (a coupla frames) and may be down to transient conditions arising elsewhere. On the bright side however it means that my previous intention of providing an option to switch to fixed if you wanted to (say if you have a card that supports pixel shaders but runs them poorly) need not be followed through on. This makes things a lot easier for me.

So far I have most of the world and alias models implemented, but I need to go back to the 1.0 code and see how I'd set up the texture blends there. The fixed pipeline in Direct3D is a very complex beast, with a lot of options available, and even the simple ones requiring considerable setup. It is however much more flexible that OpenGL.

The vertex handling will remain in the programmable; it's just so much more simple than using fixed, and Direct3D will handle it very well in software emulation, with approximately equal performance (it may even be faster than fixed).

0 comments: