Re: [utah-glx-dev] Efficiency Of glx driver

[Robert L. <bo...@ya...>]

On Sunday 11 May 2003 09:31, Philip Brown wrote:
> On Sun, May 11, 2003 at 09:10:10AM +1000, Robert Lunnon wrote:
> > 3. Contrary to my initial reading of the code LibGL does batch up
> > sequences of gl commands into a block, then xfers the block through X.
> > This should be relatively efficient, becoming more so as there is more
> > content per frame.
>
> this is true. However, I think there is a certain amount of cross-platform
> munging of the data, double-checking byte order, etc, etc.
> So you could make a reduced block encoding spec, that might be faster to
> encode and decode if you get to assume you are running on exactly the same
> machine at both ends. That, coupled with using a faster transport like
> shared memory, should be of some benefit.
Yes, but I think there are some more basic opportunities in the indirect 
rendering first.

I will look at this to familiarise myself, but also to modify the drivers to 
support rendering card commands into arbitrary buffers so the hardware 
renderers can be loaded with libGL to do pre-rendering

> Cheating even more, and using in-memory semaphores to signal
> "I'm done with the buffer, send the next one", instead of winding all the
> way through the X server, may yield significant speedups.
>
I'm not so sure, for complex applications we want to try to reduce the 
requirement to one flush per display frame which may just means that we may 
just need to automatically tune the buffer sizes in libGL and delay flushes 
till after a VBI There is absolutely no bemefit in rendering frames faster 
than the display framerate. We can use this to our advantage to keep the 
transaction rate with the X server below 70 hz which should kill the X 
overhead and bring some big savings. Question is how to sync the transfers 
with the VBI and my guess is that most cards should have a "Delay DMA to VBI" 
mode we can use.

> You still have to keep in mind that you need to let the X server process
> some events at times, though ;-)

Could be a problem :-)

>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> utah-glx-dev mailing list
> uta...@li...
> https://lists.sourceforge.net/lists/listinfo/utah-glx-dev