On Tue, 2017-02-28 at 19:23 -0800, Alex Goins wrote: > > FYI - it's only the texture_from_pixmap texture target attributes that they > base > off of the root window, e.g. GLX_TEXTURE_2D_EXT, GLX_TEXTURE_RECTANGLE_EXT, > GLX_TEXTURE_FORMAT_RBGA_EXT. They get the fbconfig from the X pixmap's depth, > along with a few other static attributes, which is still a problem for us > since > with HDR we'll need more info than just depth. The texture target derivation > is > still wrong behavior, however, as it should be done using FBConfig attributes. > If they want to avoid looking up FBconfig attributes every time a window is > mapped, a better implementation suggested internally would be to cache > FBconfig > capabilities in a hash map or something based on the visual ID, due to the > variability of texture format attributes between different visuals/fbconfigs.
It's on window creation, not map, right? You don't get to change the fbconfig bound to a GLXWindow without destroying the GLXWindow. (And even then, if you only have one fbconfig matching that visual ID the map is static, which happens to be the case for Xorg atm.) > The glXQueryDrawable() method of finding the fbconfig could be a problem with > our driver, and possibly others per the spec. glXCreateWindow() doesn't > guarantee that the GLX window and X window are the same, despite being > associated, e.g.: > > glXWin = glXCreateWindow(xWin); > assert(glXWin == xWin); > glXQueryDrawable(xWin); > > will work in Mesa, but with our driver the assert will fail, and > glXQueryDrawable() should too; it certainly can per the spec. > > If glXWin != xWin, the composite manager can't rely on glXQueryDrawable(xWin) > when it discovers a redirected window xWin. So, if we're going to use > glXQueryDrawable(), we'd want a more reliable way to ascertain the GLX window > XID from the native X window. This is a really hard set of grafs to respond to because I'm not really sure what you're getting at. (This thread in general is getting a bit hard to follow; it might help to start over and restate the current proposal/theory.) First: glXCreateWindow _does_ create a new XID, even for Mesa; the assert will fail. I don't think this matters for HDR-aware compositors, because the compositor does not create a GLXWindow for the app. It has only the Window, it only needs to get from the Window to _something_ describing the HDR format. Second (lemma): Xorg is not presently as strict as the GLX spec arguably demands. We will let you create multiple GLXWindows pointed at the same Window as long as the fbconfig matches (for fairly loose definitions of the word "match" that's not really important here). The spec says if there is already an fbconfig associated with the window then glXCreateWindow should throw BadAlloc; Xorg would need to learn how to map from Window to GLXWindow to discover this. Not hard, merely not done yet. Third: glXQueryDrawable does have a special case for Window XIDs, because the GLXDrawable type is a union of the three novel GLX drawable types and the core Window type. Since Xorg does not have a map from Window to GLXWindow (supra), when we are asked for the drawable attributes of a Window, we can only return data that we can compute from core X11 state, meaning we don't return an fbconfig. So, indeed, glXQueryDrawable on the Window would not be sufficient right now, on Xorg's GLX. Fourth: I think the model I was envisioning was that the compositor would call glXQueryDrawable on the Pixmap (that it got from CompositeNameWindowPixmap). But obviously this doesn't work, you need to operate on a GLXDrawable, and a Pixmap isn't one, and you can't create a GLXPixmap unless you know the fbconfig you want to use with it. So the question is still how to map from the Window to the GLX drawable state, but I think we can do it with existing queries and merely new attributes. If the server's GLX has at most one GLXWindow per Window - true I believe of NVIDIA, easy to make true of Xorg, probably what the spec implies - then we can make QueryDrawable implicitly operate on the GLXWindow if there is one. In which case, either you _can_ find an attribute describing the HDR format (because the client is doing HDR rendering to it and has set it), or you can't (because the client is not HDR, or because there is no GLXWindow at all). That's still not awesome. There's the corner case where the app posts its first frame of damage and later starts doing HDR GL to the window, to catch that transition you'd need to glXQueryDrawable on SDR windows on every update. There's also the problem that the HDR window might be a child of the redirected window, the cm would need to redirect the HDR subwindow too. Hmm. > If we make format data a property of the native X window, compositors should > have no issues querying it from the redirected window, and we could piggyback > off of it to do the transformation to unorm8 based on the specified format if > we > have a known transformation for it. > > If it's also a property of native X pixmaps such that composite window-pixmaps > share the attributes of their corresponding redirected windows, it would be > ideal if drivers had a way of intercepting that data before any application > can > attempt to bind those pixmaps as textures. That way, EGL binding a native X > pixmap would work like binding any EGL image target, in that format > information > is implied by the target. I think it makes sense that window-pixmaps would inherit these properties from their associated window, yes. > Encoding can impact storage format. With scRGB, there are two encodings: 16 > bpc > linear, and 12 bpc nonlinear. To confirm, we're not planning on exposing any > of > that information via X visuals, only using X visuals to interpret the > resulting > pixel data after converting to unorm8, correct? Correct, for now anyway. Eventually we need to actually implement the thing and see if that works. > Automatic redirection would have to imply the properties of the underlying > storage from the colorspace/encoding, which may not be ideal. Maybe we could > expose extended X visual properties as well, for reading the raw HDR pixel > data > before transforming it based on the colorspace/encoding information garnered > from the drawable properties. Yeah, I'm starting to think we're going to want non-GLX X extensions for some of this state. Composite might be the most sensible place to put it? - ajax _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel