The VS is going to be a little bit of a problem too. There's no straight compatibility between VS and PS, in other words, assuming that a graphics card that supports VS also supports PS is not a slam dunk, and by PS we could mean anything from ps.1.0, p.s.1.2, p.s.1.3, p.s.1.4 etc. The code and syntax is different so, you have to figure that out, and I still maintain that programming a VS is no mean feat.

Another interesting point is that at Meltdown, confirming what some of you may already know, there was some discussion about how you can do VS calculations (read T&L as well) on the host CPU and it would be just as fast as offloading it to the GPU. So, this implies two things: fast CPUs are really fast and have those nice 3Dnow!, SSE, extensions; it takes work to sweat out full performance optimization by balancing the load between the CPU and GPU (kind of like parallel processing. Hmmm.).

With a VS you deal with one vertex at a time. You put your vertex in unlit and untransformed and get it out lit and transformed. I got this email last night, and I will keep the gentleman's name confidential because, his views are his own and not his companys. He had a few points to make about VS and PS, and these are two interesting ones, quoted verbatim, that relate to this discussion:

"4) Lighting is hellish. You need a different vertex shader for every possible lighting environment, which is really not very nice. For dynamic environments you might have spots, points, a directional light from above, ambient, and now you have to support every combination of lighting yourself without any help from the driver. This doesn't cut down development time this increases it."

"5) Imagine writing a vertex shader that uses 100 instructions, now it'll link with most combinations of lighting fine. But when you have 3 spots and a directional light you exceed the maximum instruction count. What do you do? Add fallbacks to the lighting code? Try to split up the original 100 instructions so that you can dump a few? Yuck. Yuck."