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

Fri Nov 24 07:13:23 UTC 2017

On 11/23/2017 08:31 PM, Mario Kleiner 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 have gone through i965 bits and everything looks good to me. The 
reason I haven't gone forward with review is that KDE Plasma desktop is 
currently broken due to my patch exposing SRGB visuals and I wanted to 
try to solve that first.

However looks like that is going to take longer than expected so FWIW I 
have tested KDE with your patches rebased on top (all but wayland ones) 
and I did not see any 'extra issues' happening with KDE Plasma, just the 
ones that exist already.

> 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.
> 
> -mario
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev