[RFC] Visual Class for On-Screen HDR Drawables

[Adam Jackson]

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