Intel-kms in Linux-4.2rc causes regression due to dithering always on.

[Daniel Vetter]

On Fri, Aug 07, 2015 at 12:45:52AM +0200, Mario Kleiner wrote:
> On 08/07/2015 12:12 AM, Daniel Vetter wrote:
> >On Thu, Aug 6, 2015 at 11:56 PM, Mario Kleiner
> ><mario.kleiner.de at gmail.com> wrote:
> >>Hi Daniel and all,
> >>
> >>since Linux 4.2 (tested with rc4), i think this commit
> >>d328c9d78d64ca11e744fe227096990430a88477
> >>"drm/i915: Select starting pipe bpp irrespective or the primary plane"
> >>
> >>causes trouble for me and my users, as tested on Intel HD Ironlake and Ivy
> >>Bridge with MiniDP->Singlelink-DVI adapter -> Measurement device.
> >>
> >>Afaics it causes dithering to always be enabled on a regular 8bpc
> >>framebuffer, even when outputting to a 8 bpc DVI-D output, and that
> >>dithering causes my display measurement equipment and other special display
> >>devices used for neuro-science and medical applications to fail. This
> >>equipment requires an identity passthrough of 8 bpc framebuffer pixels to
> >>the digital outputs, iow. dithering off.
> >>
> >>Log output on Linux 4.1 (good):
> >>
> >>Aug  1 06:39:26 twisty kernel: [  154.175394]
> >>[drm:connected_sink_compute_bpp] [CONNECTOR:35:HDMI-A-1] checking for sink
> >>bpp constrains
> >>Aug  1 06:39:26 twisty kernel: [  154.175396]
> >>[drm:intel_hdmi_compute_config] picking bpc to 8 for HDMI output
> >>Aug  1 06:39:26 twisty kernel: [  154.175397]
> >>[drm:intel_hdmi_compute_config] forcing pipe bpc to 24 for HDMI
> >>Aug  1 06:39:26 twisty kernel: [  154.175400] [drm:ironlake_check_fdi_lanes]
> >>checking fdi config on pipe A, lanes 1
> >>Aug  1 06:39:26 twisty kernel: [  154.175402]
> >>[drm:intel_modeset_pipe_config] plane bpp: 24, pipe bpp: 24, dithering: 0
> >>Aug  1 06:39:26 twisty kernel: [  154.175403] [drm:intel_dump_pipe_config]
> >>[CRTC:20][modeset] config for pipe A
> >>Aug  1 06:39:26 twisty kernel: [  154.175404] [drm:intel_dump_pipe_config]
> >>cpu_transcoder: A
> >>Aug  1 06:39:26 twisty kernel: [  154.175405] [drm:intel_dump_pipe_config]
> >>pipe bpp: 24, dithering: 0
> >>
> >>Log output on Linux 4.2-rc4 (bad):
> >>
> >>Aug  1 06:21:31 twisty kernel: [  200.924831]
> >>[drm:connected_sink_compute_bpp] [CONNECTOR:36:HDMI-A-1] checking for sink
> >>bpp constrains
> >>Aug  1 06:21:31 twisty kernel: [  200.924832]
> >>[drm:connected_sink_compute_bpp] clamping display bpp (was 36) to default
> >>limit of 24
> >>Aug  1 06:21:31 twisty kernel: [  200.924834]
> >>[drm:intel_hdmi_compute_config] picking bpc to 8 for HDMI output
> >>Aug  1 06:21:31 twisty kernel: [  200.924835]
> >>[drm:intel_hdmi_compute_config] forcing pipe bpc to 24 for HDMI
> >>Aug  1 06:21:31 twisty kernel: [  200.924838] [drm:ironlake_check_fdi_lanes]
> >>checking fdi config on pipe A, lanes 1
> >>Aug  1 06:21:31 twisty kernel: [  200.924840]
> >>[drm:intel_modeset_pipe_config] plane bpp: 36, pipe bpp: 24, dithering: 1
> >>Aug  1 06:21:31 twisty kernel: [  200.924841] [drm:intel_dump_pipe_config]
> >>[CRTC:21][modeset] config ffff880131a5c800 for pipe A
> >>Aug  1 06:21:31 twisty kernel: [  200.924842] [drm:intel_dump_pipe_config]
> >>cpu_transcoder: A
> >>Aug  1 06:21:31 twisty kernel: [  200.924843] [drm:intel_dump_pipe_config]
> >>pipe bpp: 24, dithering: 1
> >>
> >>Ideas what to do about this?
> >
> >Well I somehow assumed the dither bit would be sane and not wreak
> >havoc with the lower bits when they would fit into the final bpc pipe
> >mode ... Can you confirm with your equipment that we seem to be doing
> >8bpc->6bpc dithering on the 8bpc sink?
> >
> 
> It will need a bit of work to find this out when i'm back in the lab. So far
> i just know something bad is happening to the signal and i assume it's the
> dithering, because the visual error pattern of messiness looks like that
> caused by dithering. E.g., on a static framebuffer i see some repeating
> pattern over the screen, but the pattern changes with every OpenGL
> bufferswap, even if i swap to the same fb content, as if the swap triggers
> some change of the spatial dither pattern (assuming PIPECONF_DITHER_TYPE_SP
> = spatial dithering?)
> 
> >If that's the case we simply limit to only ever dither when the sink
> >is 6bpc, and not in any other case.
> >-Daniel
> >
> 
> That would be an improvement for my immediate problem if that works. But
> assuming we have 10 bpc framebuffers at some point, dithering 10 bpc -> 8
> bpc would also have some practical use.
> 
> Probably some dynamic check would be good, a la if there is a mismatch
> between the max(bpc) over all active planes and the supported depth of the
> sink then dither?
> 
> It's not clear to me where the dithering happens on intel hw. I'd expected
> that with a 24 bpp framebuffer feeding into a 24 bpp pipe, dithering simply
> wouldn't do anything even if enabled.

Yeah my assumption was that if you run the pipe at a given bpc it will
just pass through anything that fits and only dither the additional bits.
But obviously that's not how the hardware works ...

The problem with adaptive schemes is that we have multiple planes nowadays
and they might all run at different depths. And dither seems to be
happening at the pipe/overall level (at least there's only one bit). Of
course this wouldn't be a problem if the thing wouldn't mangle bits which
should pass!

Anyway if we can confirm this I think dithering for only 6bpc should be
ok.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch