[Intel-gfx] rfc: breaking old userspace gamma for 10-bit support

[Jesse Barnes]

On Tue, 27 Jul 2010 11:03:56 -0400
Adam Jackson <ajax at redhat.com> wrote:

> On Fri, 2010-07-23 at 16:29 -0400, Andrew Lutomirski wrote:
> 
> > Does that include not breaking DirectColor?  If we program the gamma
> > ramp to 129 slots, old userspace submits 256 entries that are not
> > monotonic, and we decimate the gamma ramp, we'll display the wrong
> > thing.  I have no idea if there are any programs *at all* that do
> > that, though.  (If they did, presumably they'd make the entire screen
> > look rather odd.)
> 
> If I'm remembering this right, it's like this:
> 
> GM45 and earlier can only do 10bpc with 10-bit, 129-stop interpolated
> LUT.  There is no way to support DirectColor with this, the hardware
> assumes that each step is monotonically increasing and will do very
> weird things if it's not.  So the DDX driver needs to simply not set up
> any DC visuals when run at 10bpc on this hardware.  That's fine though:
> DC is a pretty rarely-used feature, and it brings with it all the
> colormap-flashing nightmares you remember from pseudocolor.
> 
> Ironlake and later can do 30bpc as either 10-bit 1024-stop, or 12-bit
> 512-stop interpolated.  For the 12-bit ramp you'd need to do the same as
> for the GM45 10-bit ramp: DDX driver doesn't set up DC visuals.
> 
> Once you've done this, the DRM driver can unambiguously determine what
> gamma ramp size to use based on what DDX passes down.  At least in
> current RANDR you only get to pick one ramp size.  You could in
> principle wire up an output property to change this, but I suggest that
> you don't bother.
> 
> There are some places in the server where we assume 256 stops, and some
> other places where we make the weaker assumption that all CRTCs have the
> same ramp size.
> 
> Having done all that you'd need to go out to gnome-color-manager and
> friends and make sure they don't assume they have 2^n stops of gamma for
> an n bpc display.

[Resurrecting this ancient thread now that 30bpp has been posted]

I think we'll also want a kernel getparam flag to indicate whether the
kernel can handle the larger ramp sizes, otherwise a new DDX and old
kernel will silently break horribly.

Current DDX always assumes a 256 entry ramp, and we'd want to preserve
that for old kernels w/o support for other sizes.  For new DDX and new
kernel, we should be able to key the palette load based on the size
passed in to the gamma_set callback.  For some reason that callback
includes a 'start' value, but fortunately the ioctl makes you load the
whole thing everytime, so the start value is always 0.

Sounds like dealing with chipset variations will be a bit of a pain
though, so we'll want per-chipset gamma_set functions at least.

Andrew, do you have anything hacked together for this yet?

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center