On 08/07/2015 12:12 AM, Daniel Vetter wrote:
On Thu, Aug 6, 2015 at 11:56 PM, Mario Kleiner
<mario.kleiner.de@xxxxxxxxx> 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
