Threading tilesort

<snip>

> 
>>This was one of the reasons I've been pushing for a threaded tilesortSPU 
>>and a threaded/non-blocking network layer.  The later should just about 
>>double current SDP performance.  Alas, this is a non-trivial thing to do 
>>and will cause large changes to the core of Chromium.
>>
> 
> What sort of scheme do you have in mind for tilesort ?

Tilesort is going to be really tricky to thread, which is why I said 
it's non-trivial.  It's amazing how fast we become CPU limited with the 
current tilesort code, even on GigE networks.  Higher speed networks 
just exacerbate the problem.

Some of it can probably be optimized (faster frustum/bounding box 
checking, crPackCanHoldOpcode, etc), but better overlapping with the 
network layer and app will probably help.  For example, can we give 
control back to the application after a swap buffers faster by handling 
the application calls in one thread and the packing and network calls in 
another?  Can we thread the bounding box/frustum checks for each 
display?  Can we run the state tracker in a thread which handles updates 
and queries? etc.

Most people have dual processor systems and folks are starting to build 
quad boxes, so why not try to better use all of the compute resources. 
Obviously the best performance will come from a distributed application 
running tilesort in an n to m configuration, but most of the "big" apps 
are not setup for that just yet.

-Mike


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com