[Mesa-dev] [PATCH 13/30] i965/miptree: Add an explicit format parameter to create_for_dri_image

[Jason Ekstrand]

On Wed, Jun 28, 2017 at 10:59 AM, Daniel Stone <daniel at fooishbar.org> wrote:

> Hi,
>
> On 28 June 2017 at 16:35, Jason Ekstrand <jason at jlekstrand.net> wrote:
> > On Wed, Jun 28, 2017 at 4:06 AM, Daniel Stone <daniel at fooishbar.org>
> wrote:
> >> On 28 June 2017 at 02:05, Jason Ekstrand <jason at jlekstrand.net> wrote:
> >> > The long answer is that the DRI formats do not specify a colorspace.
> >>
> >> Also, strictly speaking, the DRI_IMAGE_FORMAT_* tokens don't specify a
> >> colourspace, nor do the DRM FourCC tokens. DRI_IMAGE_FOURCC_* is
> >> equivalent to the latter, bar the addition of a special and unique
> >> SARGB8 token, i.e. ARGB8888 with the sRGB transfer function (and
> >> presumably primaries?). The rest are presumed UNORM.
> >
> > Wha?  What's the difference between SARGB8 and ARGB8888 then?  My
> > understanding was that scanout basically treats everything as sRGB
> anyway.
> > Clearly, my sRGB knowledge is imperfect.
>
> GBM_FORMAT_ARGB8888 (aka DRI_IMAGE_FOURCC_ARGB8888), gets mapped to
> DRI_IMAGE_FORMAT_ARGB8888, which gets mapped to
> MESA_FORMAT_B8G8R8X8_UNORM (dri_util.c). Only
> DRI_IMAGE_{FORMAT,FOURCC}_SARGB8 (no defined GBM token, but you can
> pass it through the GBM API and it'll work sometimes) gets mapped to a
> MESA_FORMAT_*_SRGB. So AFAICT, to get an sRGB scanout buffer from
> Mesa/GBM, you'd need to allocate UNORM and do inverse-gamma in your
> frag shader.
>
> Wayland similarly never maps anything to sRGB.
>
> X11 always imports EGLImages as UNORM, so blending would be broken in
> a composited environment if we were actually allocating sRGB.
>

Blending *is* broken.  I had a long chat with Owen Taylor about this some
time ago.  Everything comes into X11 sRGB encoded and scanout treats it's
buffer as sRGB.  X11 then stomps everything to UNORM and blends in the
wrong colorspace.


> i965 tries pretty hard to allocate sRGB images in the pre-DRIImage,
> DRI2 (as in the X11 protocol named 'DRI2') codepath, but this isn't
> used by Wayland, GBM, or DRI3.
>

Except that whether you get an sRGB renderbuffer or not is governed by GLX
and EGL and not Wayland/DRI2/DRI3.  In one of them (I think it's ES), the
default is to get an sRGB renderbuffer but either is possible with both
independent of how the image comes in.  We *do* see it on DRI3 and Wayland
which is why this patch exists in the first place.


> So no, not for pretty much any externally-visible images AFAICT. Even
> if it were true for scanout, the client would need to tell KMS, so KMS
> could send a HDMI infoframe telling the display.
>

But scanout always does sRGB.  If you want real UNORM, then you'll have to
add kernel API.


> Colourspaces \_o_/
>
> > As for enums, sure, that can probably happen.  GL and ISL both have enums
> > for colorspace that we could re-use.
>
> Yes, having too few format tokens is not a problem we have. We seem to
> have about as many of those as we have things called 'DRI2'.
>

Heh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170628/ef9cb2cc/attachment.html>