On Friday, May 5th, 2023 at 15:30, Joshua Ashton <joshua@xxxxxxxxx> wrote: > > > AMD would expose the following objects and properties: > > > > > > Plane 10 > > > ├─ "type": immutable enum {Overlay, Primary, Cursor} = Primary > > > └─ "color_pipeline": enum {0, 42} = 0 > > > Color operation 42 (input CSC) > > > ├─ "type": enum {Bypass, Matrix} = Matrix > > > ├─ "matrix_data": blob > > > └─ "next": immutable color operation ID = 43 > > > Color operation 43 > > > ├─ "type": enum {Scaling} = Scaling > > > └─ "next": immutable color operation ID = 44 > > > Color operation 44 (DeGamma) > > > ├─ "type": enum {Bypass, 1D curve} = 1D curve > > > ├─ "1d_curve_type": enum {sRGB, PQ, …} = sRGB > > > └─ "next": immutable color operation ID = 45 > > Some vendors have per-tap degamma and some have a degamma after the sample. > How do we distinguish that behaviour? > It is important to know. Can you elaborate? What is "per-tap" and "sample"? Is the "Scaling" color operation above not enough to indicate where in the pipeline the hw performs scaling? > > > Color operation 45 (gamut remap) > > > ├─ "type": enum {Bypass, Matrix} = Matrix > > > ├─ "matrix_data": blob > > > └─ "next": immutable color operation ID = 46 > > > Color operation 46 (shaper LUT RAM) > > > ├─ "type": enum {Bypass, 1D curve} = 1D curve > > > ├─ "1d_curve_type": enum {LUT} = LUT > > > ├─ "lut_size": immutable range = 4096 > > > ├─ "lut_data": blob > > > └─ "next": immutable color operation ID = 47 > > > Color operation 47 (3D LUT RAM) > > > ├─ "type": enum {Bypass, 3D LUT} = 3D LUT > > > ├─ "lut_size": immutable range = 17 > > > ├─ "lut_data": blob > > > └─ "next": immutable color operation ID = 48 > > > Color operation 48 (blend gamma) > > > ├─ "type": enum {Bypass, 1D curve} = 1D curve > > > ├─ "1d_curve_type": enum {LUT, sRGB, PQ, …} = LUT > > > ├─ "lut_size": immutable range = 4096 > > > ├─ "lut_data": blob > > > └─ "next": immutable color operation ID = 0 > > > > > > To configure the pipeline for an HDR10 PQ plane (path at the top) and a HDR > > > display, gamescope would perform an atomic commit with the following property > > > values: > > > > > > Plane 10 > > > └─ "color_pipeline" = 42 > > > Color operation 42 (input CSC) > > > └─ "matrix_data" = PQ → scRGB (TF) > > ^ > Not sure what this is. > We don't use an input CSC before degamma. > > > > Color operation 44 (DeGamma) > > > └─ "type" = Bypass > > ^ > If we did PQ, this would be PQ -> Linear / 80 > If this was sRGB, it'd be sRGB -> Linear > If this was scRGB this would be just treating it as it is. So... Linear / 80. > > > > Color operation 45 (gamut remap) > > > └─ "matrix_data" = scRGB (TF) → PQ > > ^ > This is wrong, we just use this to do scRGB primaries (709) to 2020. > > We then go from scRGB -> PQ to go into our shaper + 3D LUT. > > > > Color operation 46 (shaper LUT RAM) > > > └─ "lut_data" = PQ → Display native > > ^ > "Display native" is just the response curve of the display. > In HDR10, this would just be PQ -> PQ > If we were doing HDR10 on SDR, this would be PQ -> Gamma 2.2 (mapped > from 0 to display native luminance) [with a potential bit of headroom > for tonemapping in the 3D LUT] > For SDR on HDR10 this would be Gamma 2.2 -> PQ (Not intending to start > an sRGB vs G2.2 argument here! :P) > > > > Color operation 47 (3D LUT RAM) > > > └─ "lut_data" = Gamut mapping + tone mapping + night mode > > > Color operation 48 (blend gamma) > > > └─ "1d_curve_type" = PQ > > ^ > This is wrong, this should be Display Native -> Linearized Display Referred In the HDR case, isn't this the inverse of PQ? > > You cannot do a TF with a matrix, and a gamut remap with a matrix on > > electrical values is certainly surprising, so the example here is a > > bit odd, but I don't think that hurts the intention of demonstration. > > I have done some corrections inline. > > You can see our fully correct color pipeline here: > https://raw.githubusercontent.com/ValveSoftware/gamescope/master/src/docs/Steam%20Deck%20Display%20Pipeline.png > > Please let me know if you have any more questions about our color pipeline. As expected, I got the gamescope part wrong. I'm pretty confident that the proposed API would still work since the AMD vendor-specific props would just be exposed as color operation objects. Can you confirm we can make the gamescope pipeline work with the AMD color pipeline outlined above?