On Fri, Mar 2, 2018 at 5:16 PM, Mario Kleiner <mario.kleiner...@gmail.com> wrote: > On 03/01/2018 07:21 PM, nouveau-requ...@lists.freedesktop.org wrote: >> >> >> Message: 1 >> Date: Thu, 1 Mar 2018 08:15:55 -0500 >> From: Ilia Mirkin <imir...@alum.mit.edu> >> To: Mario Kleiner <mario.kleiner...@gmail.com> >> Cc: nouveau <email@example.com> >> Subject: Re: [Nouveau] [PATCH] Fix colormap handling at screen depth >> 30. >> Message-ID: >> >> <cakb7uvhnuf6w41vxhpc+q+jvsrognhuxd8czvfoghmysq_x...@mail.gmail.com> >> Content-Type: text/plain; charset="UTF-8" >> >> NVLoadPalette is pretty hard-coded to 256. I haven't looked at what >> all xf86HandleColormaps does, but it seems pretty suspicious. Also > > > It's also pretty dead :). NVLoadPalette is not ever used, because nouveau > hooks up the .gamma_set function in xf86CrtcFuncsRec, so xf86HandleColormaps > ignores the NVLoadPalette pointer. Iow. dead code that can be removed. I'll > send some follow up patch, once this one is in. We have similar dead code in > intel-ddx and modesetting-ddx which only serves to confuse the reader. > >> note that the kernel currently only exposes a 256-sized LUT to >> userspace, even for 10bpc modes. >> > > Yes, but that doesn't matter. In xbgr2101010 mode, the gpu seems to properly > interpolate between the 256 (or 257) hw lut slots, as far as my measurments > go. The X-Server maintains separate color palettes, per-x-screen xf86vidmode > gamma lut's and per-crtc RandR gamma lut's and munches them together to > produce the final 256 slot hw lut for the kernel, up/downsampling if needed.
OK, so even if you're passing 1024 to xf86HandleColormaps, gamma_set still only gets called with a 256-entry LUT? If so, that works nicely here, but is not intuitive :) > So adapting the values for xf86HandleColorMaps() is about properly sizing > those internal palette's and lut's to avoid out-of-bounds segfaults or loss > of precision somewhere in the whole multi-step remapping procedure, because > one of the server internal tables is a bottleneck with too little slots. > > This variant is the one that avoids crashes and also visual artifacts that i > at least observed on tesla gpu's at depth 30. > > One weird thing i still observed though is that in depth 30 xbgr2101010 > scanout mode nouveau used dithering when i tried to output a linear > intensity ramp, despite me disabling dithering via the xrandr property. But > that is an unrelated problem. It's sending 8bpc data out to the screen, unless you're using a DP monitor (and probably would need a Kepler GPU for that anyways). Although setting dither to off should still kill the dithering... probably some experimentation required. I'm pretty sure I could tell that it was dithering for me on Kepler. When I added support for 10bpc dither, the dither effect went away (and it looked no different than the 8bpc gradient). I didn't try explicitly disabling dithering -- I'll try that tonight and see what happens (except I've got a Fermi plugged in now). -ilia _______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau