Enhancements for Render composite request

[Michel Dänzer]

On Tue, 2009-08-25 at 11:56 -0700, Keith Packard wrote: 
> On Tue, 2009-08-25 at 20:33 +0200, Michel Dänzer wrote:
> 
> > The way this is currently done with DRI2 is an implementation detail and
> > clearly sub-optimal in some cases.
> 
> I haven't heard of any substantive issues with the DRI2 implementation,
> if you have concerns about how it works, now would be an excellent time
> to raise them.

I raised them a long time ago... What's happened with DRI2 is that most
of the GLX synchronization functionality available with DRI1 has been
ignored, and instead there's an implicit ad-hoc implementation detail.


> > It's a bad idea to encode these semantics in a rendering API.
> 
> OpenGL encodes these semantics in its rendering API, so at least we'd be
> in good company.

No, there's a difference between OpenGL and GLX.


> > An extension which deals with synchronization, as opposed to rendering.
> 
> The operation we're interested in here is a copy from a back buffer to a
> front buffer.

Which would naturally be CopyArea (just like the DRI2 implementations
you keep bringing up), not a RENDER operation.

> Would you rather we add swapping controls to the render extension or
> rendering operations to the sync extension?

Strawman.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer