compiz on aiglx

[Kristian Høgsberg]

James Jones wrote:
...

> We plan to provide an X option in our driver that turns off clipping 
> of GLX drawing to the root window.  This will be a workaround for 
> users who wish to experiment with GLX-based composite managers 
> until X servers and composite managers using the composite overlay 
> window are available.

We could probably use the same X option for enabling the 
IncludeInferiors DRI hack I posted, but I think the long term solution 
to this is an FBConfig option.  You could do something like:

   static const int attribs[] = {
     GLX_DRAWABLE_TYPE,         GLX_WINDOW_BIT,
     GLX_RENDER_TYPE,           GLX_RGBA_BIT,
     ...
     GLX_DOUBLEBUFFER,          GL_TRUE,
     GLX_INCLUDE_INFERIORS_EXT, GL_TRUE,
     None
   };

   fbconfig = glXChooseFBConfig(dpy, scrnum, attribs, &num_configs);
   ctx = glXCreateNewContext(dpy, fbconfig[0], renderType, NULL, False);

to get a double buffered, include inferior gl context for the root 
window, without worrying about which visual the root window has been 
assigned.

It sounds like Keith and Deron prefer the magic overlay window approach, 
but I think this approach is simpler and a lot cleaner and it almost 
already works, we just need the GLX_EXT_include_inferiors extension. 
That should be pretty easy, though, as it just defines the 
GLX_INCLUDE_INFERIORS_EXT token.

...
>> Yes, we agreed that GLX_EXT_tfp semantics should be that it binds
>> a copy and it makes sense for being able to completely avoid
>> tearing. I haven't updated compiz and Xgl for that yet. Textures
>> and pixmaps will continue to share the same memory in Xgl so to
>> get copy-on-bind semantics I have to be able to lock a drawable
>> so that no other client can write to it. I don't know how hard
>> that will be but updating compiz to bind before every draw could
>> be done right without breaking anything.
> 
> The copy-on-write wording was thrown around a lot at the dev 
> conference, but I don't think its what was generally desired.  This 
> would require one of the following:
> 
> 1) block all drawing to a drawable while it is bound as a texture.  
> This is just can not be done without extensive changes in the X 
> server.  From what I can see, it would require determining which 
> drawables are affected by incoming operations, then backing out of 
> the operation, putting that client to sleep until the drawable was 
> unbound from the texture, then waking up the client and resuming 
> the operation.
> 
> 2) Doing an implicit copy if the drawable is going to be damaged 
> while it is bound to a texture, then updating the texture to point 
> to the copy.  This might be slightly easier than the above, but it 
> still becomes very involved with direct rendering clients.  Also, 
> it would mostly eliminate the benefit binding drawables directly to 
> textures.  If we need to copy, it removes all the performance 
> benefit.

Yup, it comes down to either blocking drawing to the pixmap or adding a 
copy-on-write mechanism.  Both schemes add overhead in the tfp 
implementation, and the repeated binding and releasing of the pixmap 
adds overhead in the compositing manager.

> I interpreted the discussion we had this way:
> 
> The drawable can not be rendered to, by X, OpenGL, or any other 
> direct rendering client, while it is bound to a texture.  It is the 
> applications job to enforce this.  This can be done with server 
> grabs.  If the application obeys this rule, the BindTexture 
> operation will indeed act as if it were a CopyTexSubImage operation 
> in this case.
> 
> If the application does not want to grab, all bets are off.  The 
> contents of the texture are undefined if it is rendered to while 
> bound.  That said, I suspect this will still work on most 
> implementations, but there may be tearing.  We have all seen it 
> work on Xgl, I'm ensuring it works in our driver, and it sounds 
> like it will work in aiglx since you are doing damage tracking to 
> update the texture.

Even if your compositing manger uses grabs to prevent updates to the 
pixmap while it is used as a texture, you risk half-finished drawing on 
the screen.  Suppose you have an application that starts repainting its 
window and starts submitting a number of drawing requests.  At any time 
during this sequence of requests can the X server or the kernel decide 
to schedule in the compositing manager, which will then lock the server 
and use the half-finished pixmap contents to recomposite the screen. 
Grabbing ensures that the contents of the pixmap doesn't change while 
you texture from it, but there's no guarantee that the contents was 
consistent to begin with.

To get consistent updates working, we need some kind of protocol between 
the compositing manager and the applications, to pass "ownership" of the 
pixmap contents back and forth.  To begin with the application owns the 
pixmap but once it has finished painting into it the application passes 
ownership to the compositing manager.  Once the application has passed 
ownership it can't touch the pixmap contents.  The compositing manager 
now knows that as long as it owns the pixmap, the contents wont change 
and it can use the contents for compositing.  Once that's done it passes 
ownership back to the application, who is now free to draw into the 
pixmap again.

All I'm trying to say, is that I don't think the copy semantics make a 
lot of sense either, but I think we should try to specify the behaviour 
better in the case where the pixmap receives rendering while bound as a 
texture.  As it is now, reverting to solid pink is a valid behaviour, 
but as you say, most implementations will do the right thing, so lets 
try to specify that.

I basically think that the way David uses tfp in compiz currently is the 
most reasonable semantics (alias-sematics), and the bind-as-copy 
semantics compromise the usability of the extension without ensuring 
consitent updates anyway.

Kristian