[sldev] Avatar Rending Speed

[Dzonatas]

Dave Parks wrote:
> Dzonatas wrote:
>>
>> The vertex shaders help, but I still would like to see multiprocessor 
>> rendering threads.
>
> Really for GL you want one rendering thread since the machine is 
> thread context sensitive.

I read OpenGL requires a bit of tuning to get it to work well under 
multiple threads.

The SSE issues I ran into with the viewer exploits the context issues.

> Putting avatar animations on their own thread would help a lot.  So 
> would using worker threads for processing network updates.  I've got a 
> design for cutting the time spent updating flexi's in half, too, but 
> they could probably go on a thread as well.
>


One thing we tried for a speed up is to change the VBOs  vector size 
from 3 floats to 4 floats in size. The last float is a pad. Then, we 
used SSE 128bit aligned movs from the worker task to the VBO. I reached 
100% speed improvement on my machine, but the pad in the VBO didn't seem 
to work on all machines (some jira issue around here with vectors in 
weird places). It worked awesome on mine. For cost, that particular code 
was dropped and no further work done to track down why the weird vectors 
occurred on some machines.

Later, I wrote a routine to write the normal llvector3 sized VBO with a 
mix of aligned and unaligned SSE movs. The code work well, also.  
However, that was when I found by many tests that the viewers 50+ 
context switches on a single CPU were the real problem to slowdown.  In 
an isolated VBO test code, I saw up to 10x speed improvements, but when 
the same code was ran in the viewer... it maxed around 30-40% 
performance gain.  I ran VTune on it, and discovered the 50+ context 
switches and wait-state hotspots.  SSE context switches can make any 
speed improvement look like nada when the cache-lines are hit hard.

The avatar rendering speed time isn't the true bog on the frame time. 
Fastimers can't detect the hotspots that VTune does.

So ya, I'm for worker threads.