[Mesa-dev] 10-bit Mesa/Gallium support

[Ilia Mirkin]

On Thu, Nov 23, 2017 at 2:02 PM, Mario Kleiner
<mario.kleiner.de at gmail.com> wrote:
> On 11/23/2017 07:44 PM, Ilia Mirkin wrote:
>>
>> On Thu, Nov 23, 2017 at 1:31 PM, Mario Kleiner
>> <mario.kleiner.de at gmail.com> wrote:
>>>
>>> On 11/23/2017 06:45 PM, Ilia Mirkin wrote:
>>>>
>>>>
>>>> On Thu, Nov 23, 2017 at 12:35 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>>>>
>>>>>
>>>>> Hi everybody,
>>>>>
>>>>> Mario, feel free to push your patches if you haven't yet. (except the
>>>>> workaround)
>>>>>
>>>
>>> Hi,
>>>
>>> just started 10 minutes ago with rebasing my current patchset against
>>> mesa
>>> master. Will need some adjustments and retesting against i965.
>>>
>>> I was also just "sort of done" with a mesa/gallium 10 bit version. I
>>> think
>>> i'll submit rev 3 later today or tomorrow and maybe we'll need to sort
>>> this
>>> out then, what goes where. I'll compare with Mareks branch...
>>>
>>> The current state of my series for AMD here is that radeon-kms + ati-ddx
>>> works nicely under exa (and with a slightly patched weston), but the
>>> ati-ddx
>>> also needed some small patches which i have to send out. On amdgpu-kms i
>>> know it works under my patched weston branch.
>>>
>>> What is completely missing is glamor support, ergo support for at least
>>> amdgpu-ddx and modesetting-ddx -- and xwayland.
>>>
>>>>> For AMD, I applied Mario's patches (except Wayland - that didn't
>>>>> apply) and added initial Gallium support:
>>>>> https://cgit.freedesktop.org/~mareko/mesa/log/?h=10bit
>>>>>
>>>>> What's the status of Glamor?
>>>>>
>>>>> Do we have patches for xf86-video-amdgpu? The closed should have
>>>>> 10-bit support, meaning we should have DDX patches already somewhere,
>>>>> right?
>>>
>>>
>>>
>>> Somewhere there must be some, as the amdgpu-pro driver with the
>>> proprietary
>>> libGL supported depth 30 at least in some version i tested earlier this
>>> year?
>>>
>>>>
>>>> I'd like to test this out with nouveau as well... do I understand
>>>> correctly that I shouldn't need anything special to check if it
>>>> basically works? i.e. I apply the patches, start Xorg in bpp=30 mode,
>>>> and then if glxgears works then I'm done? Is there a good way that I'm
>>>> really in 30bpp mode as far as all the software is concerned? (I don't
>>>> have a colorimeter or whatever fancy hw to *really* tell the
>>>> difference, although I do have a "deep color" TV.) If used with a
>>>> 24bpp display, is the hw supposed to dither somehow?x
>>>>
>>>>     -ilia
>>>>
>>>
>>> nouveau is quite a bit work to do and not so clear how to proceed.
>>>
>>> My current series does do proper xrgb2101010 / argb2101010 rendering
>>> under
>>> gallium on both nv50 and nvc0 (Tested under GeForce 9600 for tesla, GTX
>>> 970
>>> and 1050 for maxwell and pascal). I used PRIME render offload under both
>>> DRI3/Present and Wayland/Weston with both intel and amd as display gpus,
>>> so
>>> i know the drivers work together properly and nouveau-gallium renders
>>> correctly.
>>>
>>> The display side for native scanout on Nvidia is somewhat broken atm.:
>>>
>>> 1. Since Linux 4.10 with the switch of nouveau-kms to atomic modesetting,
>>> using drmAddFB() with depth/bpp 30/32 maps to xrgb2101010 format, but
>>> nouveau-kms doesn't support xrgb2101010, so setting Xorg to depth 30 will
>>> end in a server-abort with modesetting failure. nouveau before Linux 4.10
>>> mapped 30/32 to xbgr2101010 which seems to be supported since nv50. If i
>>> boot with a < 4.10 kernel i get a picture at least on the old GeForce
>>> 9600
>>> and GT330M.
>>>
>>> If i hack nouveau-ddx to use a xrgb2101010 color channel mask (red in
>>> msb's,
>>> blue in lsbs) instead of the correct xbgr2101010 mask, then i can get
>>> nouveau-gallium to render 10 bits, but of course with swapped red and
>>> blue
>>> channels. Switching dithering on via xrandr allows to get rendered 10 bit
>>> images to get to a 8 bpc display, as confirmed via colorimeter. I hope a
>>> deep color TV might work without dithering.
>>>
>>> According to
>>>
>>>
>>> https://github.com/envytools/envytools/blob/master/rnndb/display/nv_evo.xml
>>>
>>> gpu's since kepler gk104 support xrgb2101010 scanout. With a hacked
>>> nouveau-kms i can get the maxwell and pascal cards to accept xrgb2101010,
>>> but the display is beyond weird. So far i couldn't make much sense of the
>>> pixeltrash -- some of it remotely resembles a desktop, but something is
>>> going wrong badly. Also the xbgr2101010 mode doesn't work correct. The
>>> same
>>> is true for Wayland+Weston and even if i run Weston with pixman, keeping
>>> Mesa out of the picture. So nouveau-kms needs some work for all modern
>>> nvidia gpu's. Gamma table handling changed quite a bit, so maybe
>>> something
>>> is wrong there.
>>>
>>> 2. We might also need some work for exa on nvc0+, but it's not clear what
>>> problems are caused by kernel side, and what in exa.
>>>
>>> 3. In principle the clean solution for nouveau would be to upgrade the
>>> ddx
>>> to drmAddFB2 ioctl, and use xbgr2101010 scanout to support everything
>>> back
>>> to nv50+, but everything we have in X or Wayland is meant for xrgb2101010
>>> not xbgr2101010. And we run into ambiguities of what, e.g., a depth 30
>>> pixmap means in some extensions like glx_texture_form_pixmap. And the GLX
>>> extension generally seems to have unresolved problems with ARGB formats
>>> instead of ABGR formats, which is why Mesa doesn't expose ARGB by default
>>> --
>>> only on Android atm.
>
>
> Mistyped, i actually meant BGRA/BGRX is fine, but RGBA/RGBX has confusion
> problems in GLX, so that's only exposed on Android.

Well, the hardware supports what it supports. Not much we can do about
that. I thought the color masks were supposed to avoid confusion, i.e.
if it's 30bpp and red is 0x3ff, then it's one, if red is 0x3ff00000
then it's the other.

>
>>>
>>> So on nouveau everything except the gallium bits is quite a bit messy at
>>> the
>>> moment, but the gallium bits work according to my testing.
>>
>>
>> Sounds like you've gotten moderately far. I wasn't sure if you were
>> interested in working on this for nouveau. I can't seem to even get
>> modetest to show XB30 at all on a G92 nor on a GK208. Either way,
>> probably not relevant discussion for this list.
>>
>
> I'm mostly stuck with nouveau, not sure how much time i'll have to look into
> it atm. The Mesa/Gallium bits seem to work fine, so that's something. Exa
> nvc0 i lack the knowledge, but i guess we'd first need to get the kms driver
> working properly before we know if there is a problem in exa at all.

If you could post your hackpatches, I could take it from there. I
wouldn't be surprised if the EXA callbacks needed a little help to
render to rgb10a2 surfaces (or bgr10a2). There's a lot of hardcoding
in there.

>
>> (Hm, looking at the code, it actually looks like it's modetest that's
>> fubar for rgb10 formats. So there's hope!)
>>
>
> Yes, something looked broken there as well. I side-stepped it with weston +
> pixman 10 bit so far.

I sent a fix for it a few minutes ago. Works fine now (or at least ...
a lot less obviously wrong than "black screen"). I still think that
there are LUT issues since we always go through a 256-based color LUT.
There are options to make that 1024 or higher though. Perhaps the LUT
gets auto-disabled when you do a 10bpp surface but have the 256-sized
LUT size enabled? Needs some experimentation.

  -ilia