Re: Threading tilesort

On Fri, 2004-06-25 at 13:59, Mike Houston wrote:
> <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.
> 
Hmm. Most of my profiling results indicate that the majority of the time
in the tilesorter is spent in the state tracking code.
 crStateCurrentRecover is a major bottleneck. The texture state tracking
code is another one as well since it always seems to be iterating over
maxTextureUnits over and over again. 

Having a threaded non-blocking network layer would help but without any
real hard numbers to go by it's difficult to say how much faster we
could go (now I'm starting to sound like a carpenter .. "measure twice
.. cut once"  :) ).

> 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
-- 
Alan Matsuoka
Global Professional Services
Red Hat Canada, Ltd
mailto:[email protected]



-------------------------------------------------------
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