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

[Ilia Mirkin]

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

(Hm, looking at the code, it actually looks like it's modetest that's
fubar for rgb10 formats. So there's hope!)

  -ilia