Hi, > I think that should be dependant on whether the device was created > with D3DCREATE_MULTITHREADED or not. I'm not sure how much can be > gained by moving shader compilation into it's own thread, but I > suppose it's worth some tests. Correct.
I wrote a quick and dirty patch to do vertex fixups in their own thread, and it gained nothing. It was just as fast as fixing everything up directly in the rendering thread, and slower than using drawStridedSlow for dynamic vertex data. This was on my single-cpu laptop. My patch deadlocked on my dual core machine, so I guess the thread sychronisation didn't work as intended, so I couldn't test there. But Multi-core systems will very likely have cards with shaders too, so I think a fixed pipeline replacement is the way to go :-) Attached is the patch if anyone wants to look at it, I personally will move the idea to /dev/null too
0005-Async-vertex-fixups.txt.bz2
Description: BZip2 compressed data
pgpvYe71Bv7GY.pgp
Description: PGP signature
