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@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