On Tue, Jan 2, 2018 at 11:51 PM, Mario Kleiner <[email protected]> wrote: > On 12/31/2017 05:53 PM, Ilia Mirkin wrote: >> I went through and added support for xbgr2101010 throughout (and >> hacked the kernel to assume that 30bpp == that). >> > > Cool! > >> Your (I hope latest) patches + my mesa patches are available at >> https://github.com/imirkin/mesa/commits/30bpp . It all seems to not be > > > Yes, those are the latest patches. It would be great if somebody could push > them to master now if there aren't any objections, given that they are all > tested, and reviewed by Marek and Tapani, and as far as i'm concerned > finished at least for intel and amd. Having a new baseline to work off > without rebasing and manually resolving frequent merge conflicts would be > nice.
Please try to get Marek to merge it. I wouldn't feel comfortable doing it until it was all worked out on NVIDIA, and I think you're much closer on other hardware. > >> totally broken, at least glxgears colors are right with X -depth 30. >> And rendercheck seems not extremely unhappy either (with >> xf86-video-nouveau at least). DRI3 seems broken for some reason that I >> haven't determined yet (client stops sending stuff at the protocol >> level after the Open call, but I'm weak on what the protocol _should_ >> be), but DRI2 is totally fine. (And DRI3 is apparently >> broken-by-design anyways on all EXA drivers I guess, so I'm not going >> to loose too much sleep over it.) >> > > I'll give them a try when i get back to my machines and colorimeter sometime > within the next couple of days. > >> Like you said, Kepler+ supports ARGB, but Tesla and Fermi are stuck >> with ABGR. If possible (which in this case it seems to be), I'd rather >> maximise the amount of hardware this can all work with. >> > > Having it working on older gpu's would be nice - most of mine are still > tesla. I assume the downside is Prime renderoffload with intel + nvidia > won't automagically work anymore? Unless we can do a format conversion xbgr > -> xrgb during the blitImage op that converts from tiled renderoffload gpu > format to the linear scanout format of the display gpu? Or make the exported > format dependent on what the display gpu prefers. I hadn't considered PRIME offload. I was so happy when the spinning gears had the correct colors... In theory, the NVIDIA gpu will happily render to either ABGR or ARGB. It can only scan out one of those, but assuming that my fiddling with flags doesn't mess up the infra's ability to allocate a properly-formatted buffer to pass in for rendering, it should all be fine. > >> If you do decide to play with it, on top of the hack to make 30bpp == >> xbgr, if you want to use GF119+, you also need to apply >> https://lists.freedesktop.org/archives/nouveau/2017-December/029408.html > > > Do i understand that patch correctly, that the current code for gf119+ > enabled a 1024 slot lut, but only initialized the first 256 slots? And then More like every 4th slot, which worked just fine for 8bpc buffers. > a 8 bpc fb would only index the properly initialized slots, but the 10 bpc > fb also indexed into the 768 uninitialized slots? And your patch switches > back to pure 256 slot lut? That would explain the kind of corruption i've > seen on maxwell and pascal which made things untestable on those cards. Correct. Ideally we'd want to use a 1024-position LUT, but legacy API / software sadness prevents it for now. There must be a clean way out of all this, but it'll be more involved -- I took the quick way initially, esp since it's no worse than what we're doing today. > >> -- I'm going to send out an email about the whole LUT situation, but >> the backwards-compatibility makes it all rather annoying. I suspect >> that without either disabling the LUT (which would be easy to hack >> nv50_display.c to do), or using a 1024-entry LUT, you won't get actual >> 10bpp per channel, still just 8bpp. But can't really tell from just >> looking at the SMPTE pattern on my fading LCD monitor :) The >> 1024-entry LUT is only available on GF119+, so I'm curious whether >> earlier chips can output 10bpp at all, or if it all gets chopped down >> to 8bpp "on the wire" even if LUT is disabled. Perhaps you can >> experiment with a colorimeter and known-good display if you get some >> time. > > > I enabled the spatial dithering to 8 bpc via xrandr props, outputting to two > different 8 bpc panels via DVI and HDMI iirc and measuring that i got 10 bpc > on GeForce 9600 and 330M, so that worked fine enough to at least convince > the colorimeter and my eyes. Years ago i also measured native VGA out to a > CRT via DVI-I with the builtin 10 bit dacs of a GeForce 8800 with the > proprietary driver. > > I could misremember, with my poor memory and all the testing i did lately on > different gpu's, but i think what happened on nvidia with the nouveau > programmed lut's (also under linux 4.4 with the old lut setup code) was that > the lut's at least on those tesla cards got bypassed for a 10 bpc fb. I have > a test that cycles the lut's for some old-style clut animation, and the > picture stayed static in 10 bpc mode. I will check again when i'm back at > the machines. Well, if it just auto-skips the LUT, I can test that -- just invert the LUT and that should be pretty obvious even to the naked eye on a fading monitor :) But if it doesn't, then we could also make it skip by explicitly disabling the LUT. Or allow some way for userspace to indicate that it should skip. From some follow-on discussions with Dave Airlie, 10bpc with DVI requires hacks since it natively only supports 8bpc -- you have to stick the extra bits "somewhere else", which requires an implicit convention between the monitor and the display image producer. With HDMI 1.1 / DP, you can have InfoFrames which specify 10bpc, although I don't think that nouveau takes advantage of this. So you won't get true 10bpc for now. By the way, if you have any advice for how I can test the "trueness" of the 10bpc with the naked eye, I do have a "deep color" TV with HDMI inputs. I'm guessing some kind of fine gradient which will show banding at 8bpp? Cheers, -ilia _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
