[Fwd: Re: CVS Update: xc (branch: trunk)]

[Roland Mainz]

Keith Whitwell wrote:
[snip]
> > Every GL driver can potentially exhibit this behaviour, the fact that
> > none do is because it is such an easy condition to trigger and that even
> > basic usage of a driver brings it to light.  If glxgears causes your
> > driver to become unresponsive, think what quake will do to it.
> >
> > The trouble with your fix is that it covers up a driver bug in one
> > application only, namely glxgears.  It does so by doing something that
> > is quite unusual for GL applications and isn't recommended or normal
> > coding practice.
> >
> > The real problem is that the driver does nothing to throttle the rate it
> > accepts GL commands in relation to the speed of the hardware. Presumably
> > there is a very large buffer somewhere which is being filled up with
> > rendering commands - the simplest way to reduce the problem would be to
> > find and reduce the size of that buffer.  It may be that the items being
> > buffered are GLX protocol requests, or drawing requests internal to the
> > X server or both, or something else entirely.
> 
> Following up on myself, the buffer in question is most likely to be one
> containing the GLX protocol, as glxgears manages to use the
> performance-oriented features of the GLX protocol to do a large amount
> of drawing with very little actual wire traffic.  So a couple of
> kilobytes of buffering can probably contain a few hundred frames worth
> of gears output.
> 
> Changing or amending the GLX protocol isn't ever going to eliminate the
> problem as long as remote connections are allowed, as the foreign libGL
> may not use whatever protocol changes are added to get try and deal with
> this.
> 
> So you're left with dealing with this in the X server.
> 
> I see two ways of doing this:
> 
> 1) Reduce the amount of GLX protocol that is buffered but not rendered
> in the X server, perhaps in response to the rate of consumption of the
> protocol stream by the backend driver.
> 
> 2) Improve the scheduling of the GLX protocol stream in relation to
> other clients to avoid the situation where the indirect renderer locks
> out other clients.

[1] sounds better for me as it may result in a stable consumption rate

BTW: It seems some OpenGL UNIX drivers call |sched_yield()| after a GL
buffer swap, but I am not sure whether this was added to help the main
Xserver thread to do it's job or to help the client or whether there was
an other reason for that.

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)