On Thu, Nov 23, 2017 at 1:31 PM, Mario Kleiner <mario.kleiner...@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 <mar...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
