[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 11:09 AM, Jason Ekstrand <jason at jlekstrand.net>
wrote:

> 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.
>

Inserting some asserts and running through CI confirms this.  There are
piles of times when we take a nominally UNORM DRI format and interpret it
as sRGB.


> 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/20170629/610a892e/attachment-0001.html>