On Friday 04 March 2011 11:43:05 pm Keith Packard wrote: > * PGP Signed by an unknown key > > On Fri, 4 Mar 2011 16:47:45 -0800, James Jones <[email protected]> wrote: > > On 3/1/11 6:56 PM, "James Jones" <[email protected]> wrote: > > > On Tuesday 01 March 2011 08:02:24 Keith Packard wrote: > > > *snip* > > > > > >> Scanout pixmaps get resized automatically when the associated crtc > > >> gets a new mode. This lets a compositing manager deal with the > > >> scanout pixmap creation while separate screen configuration > > >> applications deal with mode setting. Of course, internally, this is > > >> done by creating a new scanout pixmap and pointing the existing XID > > >> at the new object. (Hrm. I wonder if there are implications for > > >> DRI2/GLX/EGL here...) > > > > I looked over the rest of the spec changes, and spent some more time > > thinking about how bad it would be for GLX/EGL to have pixmaps resize. > > It looks pretty heinous. A lot of the badness comes from > > texture_from_pixmap/EGLimage extensions. If the pixmap is bound to a > > texture or EGL image, the size is derived from that pixmap. At least for > > GLX pixmaps, whether you want to use non-power-of-two textures (with > > mipmapping support), normal power of two textures (with mipmapping > > support), or rectangle textures (no mip-mapping, different texel > > coordinate system) depends on the size of the texture as well. The > > texture target is selected at GLX pixmap creation time, so just > > re-binding the pixmap wouldn't be sufficient to update all state. > > Remember that internally (at least at this point), the pixmap *isn't* > getting resized -- a new pixmap is allocated and automagically assigned > to the crtc as a scanout pixmap, and then the pixmap ID is switched from > the old scanout pixmap to the new one. So, if you've created a resource > which references the pixmap inside the server, things should 'just > work'. Any client-side reference which ends up sticking the pixmap ID on > the wire will not work though.
OK, I thought you wanted to completely hide the resize from applications. If the intent is to force GLX clients to re-create their GLX pixmaps when the underlying X pixmap resizes, then the design sounds clean, and should work fine as long as no one goes in and tries to "optimize" the destroy/create out of the server code. Is there some way to bake that into the protocol spec so such an optimization would be non-compliant? It seems a little ugly to require clients to know RandR events can make certain GLX pixmaps no longer refer to the same resource they were created against, but this is admittedly a special case, and one that shouldn't break any existing applications. > > As an alternative to resizing the scannout pixmap, could you organize the > > protocol such that when a randr 1.4 composite manager is running, > > requests to change to a pre-validated resolution are redirected to the > > composite manager, based on something like SubstructureRedirectMask? > > The composite manager would then create a new crtc pixmap if necessary > > and apply the mode. I haven't thought this through in great depth yet, > > or discussed with anyone else at NVIDIA. Error conditions might be hard > > to get right in > > particular. > > I thought about this and it looked really ugly. Essentially, the entire > mode set must be pend waiting for the compositing manager to deal with > it. Which means either doing the whole redirection request, including > packing up the entire mode set operation and handing it to the > compositing manager to re-execute, or blocking the RandR application > inside the server waiting for the compositing manager to reply. > > The former would be a fairly significant change for RandR applications, > requiring that they pend on an event before continuing. The latter > suffers from the usual live-lock adventure if the RandR application has > grabbed a server lock. At least the server lock isn't required any more > as we've got the atomic 'do everything' RandR operation now. Agreed, those problems do sound harder to overcome. I hand-waved myself past error-handling and replies when I thought this suggestion through. > I decided on the pixmap resizing as the least evil of these options, I'd > love to know how to make this work cleanly with GLX pixmaps. I don't know how to improve the interaction, but it sounds acceptable to me within the constraints I mention above. An explicit "pixmap changed" event (I assume these resizes won't generate configure-notify on a pixmap some how...) might make things clearer, but it might be overkill. I think mentioning the issue in the protocol updates would be valuable though, so future GLX/EGL/VDPAU-based composite manager coders don't need to dig up this thread to understand what's going on with their CRTC pixmaps. Thanks, -James _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
