The only times you'll ever want to use software vertex processing are A) if you need to use a vertex shader model specification higher than what the card currently supports, or B) you're using debug tools that require it. Otherwise, use hardware processing and on top of that prefer 'pure' hardware vertex processing for a performance boost. This does come with a slight programming effort cost, as I think you lose the ability to query some related device state IIRC, but in general it's worth this loss.

Hi there,

Can someone tell me when is better to use Software vertex processing instead Hardware vertex processing?

Thank you,

Michelle.

The software processing will allow you to run directx 11 on a directx 9 compatible card. because all the actually work is offloaded to the CPU.
Hardware processing is where all the work is done on the GPU.

software processing is VERY VERY SLOW and is never really used, except if you want to test a feature that is not supported by your current video card.

software processing is VERY VERY SLOW and is never really used, except if you want to test a feature that is not supported by your current video card.

Not quite true, I think you may be confusing it with software emulation of the entire graphics pipeline (which is indeed extremely slow and should not be used unless for testing as mentioned).

The big difference is that software VP is performed by your CPU whereas hardware VP is performed by your graphics card.

There are some key - and subtle - differences in behaviour between software and hardware vertex processing. For one, hardware vertex processing can be fussy. Because the per-vertex stages of the pipeline are where your program initially "connects" to your graphics hardware (not really, but it suffices for this discussion), you're suddenly exposed to a lot of limits that just don't exist with software vertex processing. Limits like: do you support 32-but indexes? What's the maximum number of indexes you can use in a single draw call? What's the maximum number of vertexes you can use in a single draw call? How many vertex shader instructions can you use? And so on. On modern hardware this doesn't matter so much (you can be reasonably confident that it will support whatever you throw at it) but if you need to support downlevel hardware - or the dreaded Intels - then these are all limits that you'll need to test and make sure you don't exceed.

In other cases, hardware vertex processing can be more lenient. It's perfectly permissible to throw some invalid parameters into DrawIndexedPrimitive, for example (not that you should, but bear with me) and hadware vertex processing won't even bat an eyelid, but software will complain - sometimes quite dramatically.

If you're just developing some stuff for your own use, you can use whichever your prefer but generally you'll want hardware, and when creating a new device one standard procedure is to attempt to create a hardware one first, test the HRESULT from your CreateDevice call, and if it fails then create software. If you're developing something for public release I'd actually recommend that you test with both hardware and software VP, as it can be a great way of uncovering (or helping to uncover) some subtle bugs and bad behaviours.

As has been mentioned, there are still some Intel Integrateds around (primarily the 945 and earlier) that only support software vertex processing, but the procedure I outlined above will work with them.

Finally, the performance difference. For lightweight stuff you probably won't notice anything; vertex processing is highly unlikely to be your bottleneck. For more complex rendering it varies, but you can count on a performance loss of up to maybe 50% by using software vertex processing. That may or may not be a big deal if your program is already fast enough (and if you have an older GPU and need some increased limits in the vertex pipeline).