Xgl/Xegl future?

[Michel Dänzer]

On Mon, 2005-08-22 at 10:37 +1000, Dave Airlie wrote:
> > Actually, I think the problem there is that we rely on the process
> > scheduler to sort out who gets the lock after contention. AFAICT it
> > would be possible to share the lock in a perfect round robin manner
> > between processes. The drawback of that might be excessive context
> > restoring overhead though.
> > 
> > Also, Xgl per se will have zero impact on this specific case with direct
> > rendering. And even indirect rendering won't guarantee that the GLX
> > requests are processed evenly between clients, will it?
> 
> If everything goes via Render via Xegl then you don't have GLX
> requests in the common case, the X server just draws things in
> whatever order it sees fit, I don't really like the idea of all my
> individual applications being direct or indirect rendering clients,
> the 2D apps should take the standard route and the X server should
> decide how to draw them,

The above addressed your specific example of two glxgears (or two GL
apps in general) only. I wasn't implying anything about other cases.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer