Re: Asynchronous Direct3D rendering design sugeestion

[H. Verbeet]

On 20/07/06, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
> for us. The reason why it doesn't are apparently drawStridedSlow and the
> brute force setting of gl states. The debugging facilies seem to have really
> bad effects on performance too.
> Well, that should be fixed anyway, of course.
> Yet I think some things should be done, like having vertex and pixel format
> fixups in a seperate thread, or shader perhaps compilation. The D3D objects
> have to be protected with critical sections too.
> 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.

Asynchronous Direct3D rendering design sugeestion

[Stefan Dösinger]

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