[Intel-gfx] 8-bit vs. 10-bit palette mode, and LVDS dithering

[Adam Jackson]

On Sat, 2010-04-24 at 17:25 +0100, Peter Clifton wrote:

> I noticed an anomaly in the register settings on my GM45, according to
> PIPEBCONF, it is set in 10-bit palette mode, yet the KMS code programs
> the palette registers as if it is in 8-bit mode, and doesn't touch the
> PIPEBGCMAX{RED,GREEN,BLUE} entries for the final interpolation step.
> 
> I've played with it, and I "think" my screen looks nicer with the
> palette reset to 8-bit mode. The KMS driver never touches this register
> normally, and I think it should reset it in intel_display.c's
> intel_crtc_load_lut.

You are almost certainly correct, we should be forcing 8-bit gamma mode.
We're loading the palette as though we are, it's very unlikely to look
right if programmed for 10-bit.

> Ideally, it would be nice to have a higher resolution gamma correction.
> Will it work if I drm_mode_crtc_set_gamma_size(&intel_crtc->base, 129);
> and feed that into the 10-bit linear-interpolated lookup table?

There's a 256-stop assumption hardcoded in a bunch of places, and you
want to be compatible with whatever ramp size userspace passes down.
But, once you fix that, yes, 10-bit linear gamma should work regardless
of the actual pixel depth.  It's definitely something we should fix
though, 30bpp displays won't look any better than 24bpp if we don't do
wider gamma.

Cantiga's 10-bit palette mode is... weird.  It really only works for
TrueColor visuals, and it's a bit counterintuitive that the 129-stop
ramp would be more precise than the 256-stop ramp.  We should probably
only expose it for 30bpp framebuffers (which should then be TrueColor
only in X).

> At what stage is the LVDS dithering involved here.. gamma correction
> probably makes a difference to whether a dither works nicely or not, and
> I'm wondering whether I can tune the dithering process at all.

I suspect gamma applies _after_ truncation and dither, and that dither
doesn't have any knowledge of the gamma ramp and is only trying to
approximate the bits being sourced from the framebuffer.  There's
probably some clever non-monotonic-increasing ramp you could program
that would let one deduce where gamma happens.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20100426/bfff2a48/attachment.sig>