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:al...@re...
|
