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