[Intel-gfx] [PATCH 04/12] drm: Add structures for querying color capabilities

[Ville Syrjälä]

On Fri, Jul 03, 2015 at 11:28:41AM +0100, Damien Lespiau wrote:
> On Fri, Jul 03, 2015 at 08:41:31AM +0200, Daniel Vetter wrote:
> > > Yeah. My first idea for the gamma stuff was that we'd simply have the
> > > blob property for the data, and then a separate enum property which
> > > decides how we interpret the blob contents. The default for the enum
> > > would be the 8bpc/256 entries thing always, but the other values could
> > > be potentially hardware specific. Obviously this would limit the use of
> > > the fancier modes to the atomic API since you'd need to configure both
> > > the blob and enum at the same time. But I don't see why we shouldn't
> > > be allowed to rely on atomic from now on.
> > 
> > Yeah, enum+blob is what I like too. We can do one gamma table format enum
> > in drm core. And drivers can then create it with just the enum values they
> > actually support, similar to how we have rotation/mirror defines for
> > everything, but the driver doesn't necessarily support it all. And the
> > enum would fully encode everything there is to know about a layout, i.e.
> > including excat precision and stuff like the 1025th/513th additional entry
> > we have in some intel gamma tables.
> 
> I'm assuming you're still talking about 3 separate properties though?
> pre-csc lut, csc, post-csc lut?

For CHV that would seem to fit since the pre and post gamma have
different size and precision. Although I suppose we could stuff it
in one blob if needed. Hmm. Actually I think you can even enable both
GGM and the old gamma unit at the same time, but maybe we should just
decice that it's going too far and not provide the option for that.

And we'd need to consider the CGM CSC vs. VLV wide gamut CSC too.
The pipe looks something like this:
"cgm degamma -> cgm csc -> cgm gamma -> wide gamut CSC -> pipe gamma"
So just pre and post csc gammas aren't going to cut it if we want to
expoe it all. But if we decice to not expose the wide gamut csc, then
we should be able to use either the cgm gamma or the pipe gamma as
the post-csc gamma.

Another thing which is unclear at this point is whether the plane
control register gamma bit can be used to bypass the CGM
gamma/degamma on a per plane basis, or if the bit only affects the
pipe gamma.

VLV is easier since it just has the wide gamut csc and pipe gamma
after it, and older gmch platforms have no csc unit.

For ILK+ we can choose to position the gamma before or after the csc,
or we can do the split gamma on IVB+. So from hardware POV it's
just a single table, but I suppose we could expose it as two blobs to
be a bit more compatible with CHV if we use two blobs there.

I tried to enumerate all the different gamma modes we have and came up
with the following list:
- 0.8 x 256				legacy gamma
- 0.10 and 6bit slope x 128		gen2/3 10bit interpolated gamma
- 0.16 x 128 + 1.16 x 1			gen4/g4x/vlv/chv 10bit interpolated gamma
- 0.14 x 65				chv interpolated gcm degamma
- 0.10 x 257				chv interpolated gcm gamma
- 0.10 x 1024				ilk/snb 10bit gamma
- 0.16 x 512 + 1.16 x 1			ilk/snb 12bit interpolated gamma
- 0.10 x 1024 + 3.16 x 1		ivb+ 10bit gamma
- 0.10 x 512  + 3.16 x 1		ivb+ split gamma before csc
- 0.10 x 512				ivb+ split gamma after csc
- 0.16 x 512 + 1.16 x 1 + 3.16 x 1	ivb+ 12bit interpolated gamma

I hope I didn't forget anyting. Also looks like in the future we'll get
yet another extra entry for the higher precision modes.

So if we have two blobs, would we also want two enums? In that case we'd
also need some kind of "bypass" or "disabled" enum value. But with two
enums coming up with supported combinations might become a bit hairy.
If we'd instead go with a single enum I suppose we'd need to have
pre-csc and post-csc variants of all the non-split modes for ilk+.

-- 
Ville Syrjälä
Intel OTC