On 12/31/2017 05:53 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.
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.
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.
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.
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 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.
-- 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.
Bedtime here, more later.
-mario
Cheers,
-ilia
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
