Skip to content

L
linux
Switch branch/tag
  1. 08 Dec, 2022 11 commits
  3. 07 Dec, 2022 7 commits
  5. 30 Nov, 2022 3 commits
  7. 29 Nov, 2022 2 commits
  9. 23 Nov, 2022 11 commits
  11. 22 Nov, 2022 6 commits
    • Ville Syrjälä's avatar
      drm/i915: Add 10bit gamma mode for gen2/3 · 67630bac
      Ville Syrjälä authored 
      Some gen2/gen3 parts have a 10bit gamma mode, on some pipes.
Expose it.

The format is different to the later i965+ style in that we
store a 10bit value and a 6 bit floating point slope for each
entry. Ie. the hardware extrapolates the intermediate steps
from the current LUT entry, instead of interpolating between
the current and next LUT entries. This also means we don't store
the last LUT entry in any register as it is defined by the previous
LUT entry's value+slope.

The slope has limited precision though (2 bit exponent + 4 bit
mantissa), so we'd have to allow for more error in the state checker
for the last entry and we have to make sure userspace doesn't
pass in something where the slope is simply to steep. In theory
we should perhaps check the slope for every interval, but we don't
do that for any other interpolated gamma mode and I suspect they
may also have some internal limit on the slope. I haven't confirmed
that theory though. Anyways, for ease of implementation we shall
just ignore the last entry in the state checker. If all the other
entries match anyway then that seems like a good indication that
the hardware was programmed as expected.

v2: Redo the state checker logic a bit
    Rebase due to other changes
v3: Fix C8 readout
v4: Use REG_FIELD_PREP()
Acked-by: default avatarUma Shankar <uma.shankar@intel.com>
Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221114153732.11773-20-ville.syrjala@linux.intel.com
      67630bac
    • Ville Syrjälä's avatar
      drm/i915: Use gamma LUT for RGB limited range compression · 07fc6a7b
      Ville Syrjälä authored 
      On hsw+ and glk class hardware we current make a mess of
things when we have to both generate limited range output
and use the hw gamma LUT. Since we do the range compression
using the pipe CSC unit (which is situated before the gamma
LUT in the pipe) we are in fact applying the gamma to the
limited range data instead of the full range data as the
user intended.

We can work around this by applying the range compression
via the gamma LUT instead of using the pipe CSC for it.
Fairly easy to do now that we have the internal post_csc_lut
attachment point where we can stick our new cooked LUT.

On hsw+ this only needs to be done when using the split
gamma mode or when the ctm is enabled since otherwise we can
simply reorder the LUT vs. CSC. On glk we need to do this any
time a gamma LUT is used since no reordering is possible.
We do lose a bit of coverage in intel_color_assert_luts(),
but so be it.
Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221114153732.11773-19-ville.syrjala@linux.intel.comReviewed-by: default avatarUma Shankar <uma.shankar@intel.com>
      07fc6a7b
    • Ville Syrjälä's avatar
      drm/i915: Use hw degamma LUT for sw gamma on glk with YCbCr output · 58765e0c
      Ville Syrjälä authored 
      On glk we can no longer reorder the hw LUTS vs. pipe CSC like
we could on earlier platforms, and neither do we have a
separate output CSC like on icl+. That means if we use the
pipe CSC for YCbCr output we are currently applying the gamma
LUT after the RGB->YCbCr conversion, which is just wrong.
The further we go from a linear curve the more distorted the
resulting colors become.

To work around this terrible limitation the best we can do is
repurpose the hw degamma LUT as a poor man's gamma LUT. Now
that we have the internal pre_csc_lut attachment point that
is not particularly hard to do.

What makes this less than ideal however is the fact that the
hw degamma LUT and gamma LUTs have very different capabilities.
The gamma LUT can operate in direct color type modes, whereas
the degamma LUT can't and just always operates in interpolated
mode. Additionally the degamma LUT is just a single 1D LUT, whereas
the gamma LUT is made of three separate 1D LUts (one for each channel).
So in order to make this semi-sensible we must also verify the
user supplied LUT more less matches the hw degamma LUT capabilities.
We still end up losing most of the LUT entries though, so the results
might be a bit crap.

The other option of flat out rejecting the YCbCr+gamma LUT combo
seems extremely likely to just cause a black screen for the user.
Eg. pretty sure Xorg always applies some kind of gamma LUT, and
if the user then plugs in a display that needs YCbCr output we're
toast.
Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221114153732.11773-18-ville.syrjala@linux.intel.comReviewed-by: default avatarUma Shankar <uma.shankar@intel.com>
      58765e0c
    • Ville Syrjälä's avatar
      drm/i915: Rework legacy LUT handling · e0b10f88
      Ville Syrjälä authored 
      Currently crtc_state_is_legacy_gamma() has a very specific set
of conditions, not all of which are actually necessary. Also
when we detect those conditions check_luts() just skips all
the checks. That will no longer work for glk soon when we'll
start to use the hw degamma LUT in place of the hw gamma LUT
for YCbCr output. So let's rework the logic to only really consider
whether the user provided gamma_lut is one that matches the hw
legacy LUT capabilities or not.

We'll need to reject C8+degamma on ivb+ since the presence of
degamma_lut would either mean we have to really use the LUT
for degamma as opposed to C8 palette, or we have to enable
split gamma mode which also can't work as the C8 palette.

Otherwise this will now cause the legacy LUT to go through the
regular lut checks as well. As a side effect we also start to
allow the use of the legacy LUT with CTM, but that is perfectly
fine as far a the hardware is concerned.
Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221114153732.11773-17-ville.syrjala@linux.intel.comReviewed-by: default avatarUma Shankar <uma.shankar@intel.com>
      e0b10f88
    • Ville Syrjälä's avatar
      drm/i915: Finish the LUT state checker · 96ffd0cd
      Ville Syrjälä authored 
      We have full readout now for all platforms (sans the icl+
multi-segment readout hw fail), so hook up the LUT state
checker for everyone.

We add a new vfunc for this since different platforms need
to handle the details a bit differently.

The implementation is rather repetitive in places. Probably
we want to think of a more declarative approach for the
LUT precision/etc. stuff in the future...

Note that we're currently missing readout for c8_planes, so
we'll have to skip the state check in that case.

v2: Fix readout for C8 use cases
v3: Skip C8 entirely due to lack of c8_planes readout
    Add ilk_has_pre_csc_lut() helper and use other such helpers
Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221114153732.11773-16-ville.syrjala@linux.intel.comReviewed-by: default avatarUma Shankar <uma.shankar@intel.com>
      96ffd0cd
    • Ville Syrjälä's avatar
      drm/i915: Make .read_luts() mandatory · bad2383f
      Ville Syrjälä authored 
      Every platform now implements .read_luts(). Make it mandatory.
Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221114153732.11773-15-ville.syrjala@linux.intel.comReviewed-by: default avatarUma Shankar <uma.shankar@intel.com>
      bad2383f
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7