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

[Mario Kleiner]

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.

-mario