intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Mario Kleiner <mario.kleiner.de@gmail.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>,
	Nischal Varide <nischal.varide@intel.com>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 18/18] drm/i915/display13: Enabling dithering after the CC1 pipe
Date: Fri, 19 Feb 2021 04:22:09 +0100	[thread overview]
Message-ID: <CAEsyxyh9CTJvbMCoD5pOZMfT5fgLc7xjJqk_vm64TNmK71sjNA@mail.gmail.com> (raw)
In-Reply-To: <YCUjM1QwEexccF2x@intel.com>


[-- Attachment #1.1: Type: text/plain, Size: 7847 bytes --]

On Thu, Feb 11, 2021 at 1:29 PM Ville Syrjälä <ville.syrjala@linux.intel.com>
wrote:

> On Thu, Jan 28, 2021 at 11:24:13AM -0800, Matt Roper wrote:
> > From: Nischal Varide <nischal.varide@intel.com>
> >
> > If the panel is 12bpc then Dithering is not enabled in the Legacy
> > dithering block , instead its Enabled after the C1 CC1 pipe post
> > color space conversion.For a 6bpc pannel Dithering is enabled in
> > Legacy block.
>
> Dithering is probably going to require a whole uapi bikeshed.
> Not sure we can just enable it unilaterally.
>
> Ccing dri-devel, and Mario who had issues with dithering in the
> past...
>
> Thanks for the cc Ville!

The problem with dithering on Intel is that various tested Intel gpu's
(Ironlake, IvyBridge, Haswell, Skylake iirc.) are dithering when they
shouldn't. If one has a standard 8 bpc framebuffer feeding into a standard
(legacy) 256 slots, 8 bit wide lut which was loaded with an identity
mapping, feeding into a standard 8 bpc video output (DVI/HDMI/DP), the
expected result is that pixels rendered into the framebuffer show up
unmodified at the video output. What happens instead is that some dithering
is needlessly applied. This is bad for various neuroscience/medical
research equipment that requires pixels to pass unmodified in a pure 8 bpc
configuration, e.g., because some digital info is color-encoded in-band in
the rendered image to control research hardware, a la "if rgb pixel (123,
12, 23) is detected in the digital video stream, emit some trigger signal,
or timestamp that moment with a hw clock, or start or stop some scientific
recording equipment". Also there exist specialized visual stimulators to
drive special displays with more than 12 bpc, e.g., 16 bpc, and so they
encode the 8MSB of 16 bpc color values in pixels in even columns, and the
8LSB in the odd columns of the framebuffer. Unexpected dithering makes such
equipment completely unusable. By now I must have spent months of my life,
just trying to deal with dithering induced problems on different gpu's due
to hw quirks or bugs somewhere in the graphics stack.

Atm. the intel kms driver disables dithering for anything with >= 8 bpc as
a fix for this harmful hardware quirk.

Ideally we'd have uapi that makes dithering controllable per connector
(on/off/auto, selectable depth), also in a way that those controls are
exposed as RandR output properties, easily controllable by X clients. And
some safe default in case the client can't access the properties (like I'd
expect to happen with the dozens of Wayland compositors under the sun).
Various drivers had this over time, e.g., AMD classic kms path (if i don't
misremember) and nouveau, but some of it also got lost in the new atomic
kms variants, and Intel never exposed this.

Or maybe some method that checks the values actually stored in the hw
lut's, CTM etc. and if the values suggest no dithering should be needed,
disable the dithering. E.g., if output depth is 8 bpc, one only needs
dithering if the slots in the final active hw lut do have any meaningful
values in the lower bits below the top 8 MSB, ie. if the content is
actually > 8 bpc net bit depth.

-mario

>
> > Cc: Uma Shankar <uma.shankar@intel.com>
> > Signed-off-by: Nischal Varide <nischal.varide@intel.com>
> > Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com>
> > Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> > ---
> >  drivers/gpu/drm/i915/display/intel_color.c   | 16 ++++++++++++++++
> >  drivers/gpu/drm/i915/display/intel_display.c |  9 ++++++++-
> >  drivers/gpu/drm/i915/i915_reg.h              |  3 ++-
> >  3 files changed, 26 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> > index ff7dcb7088bf..9a0572bbc5db 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -1604,6 +1604,20 @@ static u32 icl_csc_mode(const struct
> intel_crtc_state *crtc_state)
> >       return csc_mode;
> >  }
> >
> > +static u32 dither_after_cc1_12bpc(const struct intel_crtc_state
> *crtc_state)
> > +{
> > +     u32 gamma_mode = crtc_state->gamma_mode;
> > +     struct drm_i915_private *i915 =
> to_i915(crtc_state->uapi.crtc->dev);
> > +
> > +     if (HAS_DISPLAY13(i915)) {
> > +             if (!crtc_state->dither_force_disable &&
> > +                 (crtc_state->pipe_bpp == 36))
> > +                     gamma_mode |= GAMMA_MODE_DITHER_AFTER_CC1;
> > +     }
> > +
> > +     return gamma_mode;
> > +}
> > +
> >  static int icl_color_check(struct intel_crtc_state *crtc_state)
> >  {
> >       int ret;
> > @@ -1614,6 +1628,8 @@ static int icl_color_check(struct intel_crtc_state
> *crtc_state)
> >
> >       crtc_state->gamma_mode = icl_gamma_mode(crtc_state);
> >
> > +     crtc_state->gamma_mode = dither_after_cc1_12bpc(crtc_state);
> > +
> >       crtc_state->csc_mode = icl_csc_mode(crtc_state);
> >
> >       crtc_state->preload_luts = intel_can_preload_luts(crtc_state);
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> > index 4dc4b1be0809..e3dbcd956fc6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -8098,9 +8098,15 @@ static void bdw_set_pipemisc(const struct
> intel_crtc_state *crtc_state)
> >               break;
> >       }
> >
> > -     if (crtc_state->dither)
> > +     /*
> > +      * If 12bpc panel then, Enables dithering after the CC1 pipe
> > +      * post color space conversion and not here
> > +      */
> > +
> > +     if (crtc_state->dither && (crtc_state->pipe_bpp != 36))
> >               val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
> >
> > +
> >       if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
> >           crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444)
> >               val |= PIPEMISC_OUTPUT_COLORSPACE_YUV;
> > @@ -10760,6 +10766,7 @@ intel_modeset_pipe_config(struct
> intel_atomic_state *state,
> >        */
> >       pipe_config->dither = (pipe_config->pipe_bpp == 6*3) &&
> >               !pipe_config->dither_force_disable;
> > +
> >       drm_dbg_kms(&i915->drm,
> >                   "hw max bpp: %i, pipe bpp: %i, dithering: %i\n",
> >                   base_bpp, pipe_config->pipe_bpp, pipe_config->dither);
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> > index 128b835c0adb..27f25214a839 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -6132,7 +6132,7 @@ enum {
> >  #define   PIPEMISC_DITHER_8_BPC              (0 << 5)
> >  #define   PIPEMISC_DITHER_10_BPC     (1 << 5)
> >  #define   PIPEMISC_DITHER_6_BPC              (2 << 5)
> > -#define   PIPEMISC_DITHER_12_BPC     (3 << 5)
> > +#define   PIPEMISC_DITHER_12_BPC     (4 << 5)
> >  #define   PIPEMISC_DITHER_ENABLE     (1 << 4)
> >  #define   PIPEMISC_DITHER_TYPE_MASK  (3 << 2)
> >  #define   PIPEMISC_DITHER_TYPE_SP    (0 << 2)
> > @@ -7668,6 +7668,7 @@ enum {
> >  #define  GAMMA_MODE_MODE_12BIT       (2 << 0)
> >  #define  GAMMA_MODE_MODE_SPLIT       (3 << 0) /* ivb-bdw */
> >  #define  GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED       (3 << 0) /* icl +
> */
> > +#define  GAMMA_MODE_DITHER_AFTER_CC1 (1 << 26)
> >
> >  /* DMC/CSR */
> >  #define CSR_PROGRAM(i)               _MMIO(0x80000 + (i) * 4)
> > --
> > 2.25.4
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel
>

[-- Attachment #1.2: Type: text/html, Size: 9964 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2021-02-19  3:22 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-28 19:23 [Intel-gfx] [PATCH 00/18] Preliminary Display13 support Matt Roper
2021-01-28 19:23 ` [Intel-gfx] [PATCH 01/18] drm/i915/display13: add Display13 characteristics Matt Roper
2021-02-11  0:03   ` Lucas De Marchi
2021-01-28 19:23 ` [Intel-gfx] [PATCH 02/18] drm/i915/display13: Handle proper AUX interrupt bits Matt Roper
2021-02-11  0:10   ` Lucas De Marchi
2021-01-28 19:23 ` [Intel-gfx] [PATCH 03/18] drm/i915/display13: Enhanced pipe underrun reporting Matt Roper
2021-02-11  0:31   ` Lucas De Marchi
2021-02-11 12:25   ` Ville Syrjälä
2021-01-28 19:23 ` [Intel-gfx] [PATCH 04/18] drm/i915/display13: Define plane capabilities Matt Roper
2021-02-11  1:05   ` Lucas De Marchi
2021-01-28 19:24 ` [Intel-gfx] [PATCH 05/18] drm/i915/display13: Support 128k plane stride Matt Roper
2021-02-11  1:17   ` Lucas De Marchi
2021-01-28 19:24 ` [Intel-gfx] [PATCH 06/18] drm/i915/display13: Only enable legacy gamma for now Matt Roper
2021-02-11  1:19   ` Lucas De Marchi
2021-01-28 19:24 ` [Intel-gfx] [PATCH 07/18] drm/i915/display13: Add Display13 power wells Matt Roper
2021-02-11  1:33   ` Lucas De Marchi
2021-01-28 19:24 ` [Intel-gfx] [PATCH 08/18] drm/i915/display13: Handle LPSP for Display 13 Matt Roper
2021-02-11  1:36   ` Lucas De Marchi
2021-01-28 19:24 ` [Intel-gfx] [PATCH 09/18] drm/i915/display13: Handle new location of outputs D and E Matt Roper
2021-01-28 19:24 ` [Intel-gfx] [PATCH 10/18] drm/i915/display13: Increase maximum watermark lines to 255 Matt Roper
2021-01-28 19:24 ` [Intel-gfx] [PATCH 11/18] drm/i915/display13: Required bandwidth increases when VT-d is active Matt Roper
2021-01-28 19:24 ` [Intel-gfx] [PATCH 12/18] drm/i915/display13: Add Wa_14011503030:d13 Matt Roper
2021-01-28 19:24 ` [Intel-gfx] [PATCH 13/18] drm/i915/display/dsc: Refactor intel_dp_dsc_compute_bpp Matt Roper
2021-01-28 19:24 ` [Intel-gfx] [PATCH 14/18] drm/i915/display13: Support DP1.4 compression BPPs Matt Roper
2021-01-28 19:24 ` [Intel-gfx] [PATCH 15/18] drm/i915/display13: Get slice height before computing rc params Matt Roper
2021-01-28 19:24 ` [Intel-gfx] [PATCH 16/18] drm/i915/display13: Calculate VDSC RC parameters Matt Roper
2021-01-28 19:24 ` [Intel-gfx] [PATCH 17/18] drm/i915/display13: Add rc_qp_table for rcparams calculation Matt Roper
2021-01-29 11:12   ` Jani Nikula
2021-01-29 11:15     ` Chris Wilson
2021-01-29 12:01       ` Jani Nikula
2021-02-10 22:24         ` Lucas De Marchi
2021-01-28 19:24 ` [Intel-gfx] [PATCH 18/18] drm/i915/display13: Enabling dithering after the CC1 pipe Matt Roper
2021-02-11 12:29   ` Ville Syrjälä
2021-02-19  3:22     ` Mario Kleiner [this message]
2021-02-19  5:44       ` Mario Kleiner
2021-03-01  4:57         ` Varide, Nischal
2021-03-01  5:43           ` Ilia Mirkin
2021-01-28 19:25 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Preliminary Display13 support Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAEsyxyh9CTJvbMCoD5pOZMfT5fgLc7xjJqk_vm64TNmK71sjNA@mail.gmail.com \
    --to=mario.kleiner.de@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=nischal.varide@intel.com \
    --cc=ville.syrjala@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).