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

[Mario Kleiner]

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.

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

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

As far as i'm concerned it would be good to get all the Mesa bits and 
then glamor and ddx'es ready asap, so maybe we have something somewhat 
workable for XOrg 1.20, and then deal with kernel stuff.

-mario