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?
thanks, -mario
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?
If that's the case we simply limit to only ever dither when the sink is 6bpc, and not in any other case. -Daniel
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.
-mario
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
On 08/07/2015 09:14 AM, Daniel Vetter wrote:
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
Ok, did some testing and the results are weird. The procedure was to render a fullscreen constant color image via OpenGL - set constant color framebuffer via glClearColor + glClear + bufferswap, using pageflips through unredirected fullscreen windows. Gamma tables were set to identity mapping. I stepped through all 256 R = G = B = Ref. values and my equipment captured the actual single-link DVI-D video input signal of the topmost scanline. The table below shows the actual value in the framebuffer vs. the readback 8 bpc values of the red channel for the first 10 pixels in the scanline, green and blue channels have same result:
On Linux 4.2-rc5, Intel HD Ironlake, 24 bpp fb,pipeconf etc. via DVI-D.
Ref 0: 0 0 0 0 0 0 0 0 0 0 Ref 1: 1 0 1 0 1 0 1 0 1 0 Ref 2: 2 1 2 1 2 1 2 1 2 1 Ref 3: 3 2 3 2 3 2 3 2 3 2 Ref 4: 4 3 4 3 4 3 4 3 4 3 Ref 5: 5 4 5 4 5 4 5 4 5 4 Ref 6: 6 5 6 5 6 5 6 5 6 5 Ref 7: 7 6 7 6 7 6 7 6 7 6 Ref 8: 8 7 8 7 8 7 8 7 8 7 Ref 9: 9 8 9 8 9 8 9 8 9 8 Ref 10: 10 9 10 9 10 9 10 9 10 9 Ref 11: 11 10 11 10 11 10 11 10 11 10 Ref 12: 12 11 12 11 12 11 12 11 12 11 Ref 13: 13 12 13 12 13 12 13 12 13 12 Ref 14: 14 13 14 13 14 13 14 13 14 13 Ref 15: 15 14 15 14 15 14 15 14 15 14 Ref 16: 16 15 16 15 16 15 16 15 16 15 Ref 17: 17 16 17 16 17 16 17 16 17 16 Ref 18: 18 17 18 17 18 17 18 17 18 17 Ref 19: 19 18 19 18 19 18 19 18 19 18 Ref 20: 20 19 20 19 20 19 20 19 20 19 Ref 21: 21 20 21 20 21 20 21 20 21 20 Ref 22: 22 21 22 21 22 21 22 21 22 21 Ref 23: 23 22 23 22 23 22 23 22 23 22 Ref 24: 24 23 24 23 24 23 24 23 24 23 Ref 25: 25 24 25 24 25 24 25 24 25 24 Ref 26: 26 25 26 25 26 25 26 25 26 25 Ref 27: 27 26 27 26 27 26 27 26 27 26 Ref 28: 28 27 28 27 28 27 28 27 28 27 Ref 29: 29 28 29 28 29 28 29 28 29 28 Ref 30: 30 29 30 29 30 29 30 29 30 29 Ref 31: 31 30 31 30 31 30 31 30 31 30 Ref 32: 32 31 32 31 32 31 32 31 32 31 Ref 33: 33 32 33 32 33 32 33 32 33 32 Ref 34: 34 33 34 33 34 33 34 33 34 33 Ref 35: 35 34 35 34 35 34 35 34 35 34 Ref 36: 36 35 36 35 36 35 36 35 36 35 Ref 37: 37 36 37 36 37 36 37 36 37 36 Ref 38: 38 37 38 37 38 37 38 37 38 37 Ref 39: 39 38 39 38 39 38 39 38 39 38 Ref 40: 40 39 40 39 40 39 40 39 40 39 Ref 41: 41 40 41 40 41 40 41 40 41 40 Ref 42: 42 41 42 41 42 41 42 41 42 41 Ref 43: 43 42 43 42 43 42 43 42 43 42 Ref 44: 44 43 44 43 44 43 44 43 44 43 Ref 45: 45 44 45 44 45 44 45 44 45 44 Ref 46: 46 45 46 45 46 45 46 45 46 45 Ref 47: 47 46 47 46 47 46 47 46 47 46 Ref 48: 48 47 48 47 48 47 48 47 48 47 Ref 49: 49 48 49 48 49 48 49 48 49 48 Ref 50: 50 49 50 49 50 49 50 49 50 49 Ref 51: 51 50 51 50 51 50 51 50 51 50 Ref 52: 52 51 52 51 52 51 52 51 52 51 Ref 53: 53 52 53 52 53 52 53 52 53 52 Ref 54: 54 53 54 53 54 53 54 53 54 53 Ref 55: 55 54 55 54 55 54 55 54 55 54 Ref 56: 56 55 56 55 56 55 56 55 56 55 Ref 57: 57 56 57 56 57 56 57 56 57 56 Ref 58: 58 57 58 57 58 57 58 57 58 57 Ref 59: 59 58 59 58 59 58 59 58 59 58 Ref 60: 60 59 60 59 60 59 60 59 60 59 Ref 61: 61 60 61 60 61 60 61 60 61 60 Ref 62: 62 61 62 61 62 61 62 61 62 61 Ref 63: 63 62 63 62 63 62 63 62 63 62 Ref 64: 64 63 64 63 64 63 64 63 64 63 Ref 65: 65 64 65 64 65 64 65 64 65 64 Ref 66: 66 65 66 65 66 65 66 65 66 65 Ref 67: 67 66 67 66 67 66 67 66 67 66 Ref 68: 68 67 68 67 68 67 68 67 68 67 Ref 69: 69 68 69 68 69 68 69 68 69 68 Ref 70: 70 69 70 69 70 69 70 69 70 69 Ref 71: 71 70 71 70 71 70 71 70 71 70 Ref 72: 72 71 72 71 72 71 72 71 72 71 Ref 73: 73 72 73 72 73 72 73 72 73 72 Ref 74: 74 73 74 73 74 73 74 73 74 73 Ref 75: 75 74 75 74 75 74 75 74 75 74 Ref 76: 76 75 76 75 76 75 76 75 76 75 Ref 77: 77 76 77 76 77 76 77 76 77 76 Ref 78: 78 77 78 77 78 77 78 77 78 77 Ref 79: 79 78 79 78 79 78 79 78 79 78 Ref 80: 80 79 80 79 80 79 80 79 80 79 Ref 81: 81 80 81 80 81 80 81 80 81 80 Ref 82: 82 81 82 81 82 81 82 81 82 81 Ref 83: 83 82 83 82 83 82 83 82 83 82 Ref 84: 84 83 84 83 84 83 84 83 84 83 Ref 85: 85 84 85 84 85 84 85 84 85 84 Ref 86: 86 85 86 85 86 85 86 85 86 85 Ref 87: 87 86 87 86 87 86 87 86 87 86 Ref 88: 88 87 88 87 88 87 88 87 88 87 Ref 89: 89 88 89 88 89 88 89 88 89 88 Ref 90: 90 89 90 89 90 89 90 89 90 89 Ref 91: 91 90 91 90 91 90 91 90 91 90 Ref 92: 92 91 92 91 92 91 92 91 92 91 Ref 93: 93 92 93 92 93 92 93 92 93 92 Ref 94: 94 93 94 93 94 93 94 93 94 93 Ref 95: 95 94 95 94 95 94 95 94 95 94 Ref 96: 96 95 96 95 96 95 96 95 96 95 Ref 97: 97 96 97 96 97 96 97 96 97 96 Ref 98: 98 97 98 97 98 97 98 97 98 97 Ref 99: 99 98 99 98 99 98 99 98 99 98 Ref 100: 100 99 100 99 100 99 100 99 100 99 Ref 101: 101 100 101 100 101 100 101 100 101 100 Ref 102: 102 101 102 101 102 101 102 101 102 101 Ref 103: 103 102 103 102 103 102 103 102 103 102 Ref 104: 104 103 104 103 104 103 104 103 104 103 Ref 105: 105 104 105 104 105 104 105 104 105 104 Ref 106: 106 105 106 105 106 105 106 105 106 105 Ref 107: 107 106 107 106 107 106 107 106 107 106 Ref 108: 108 107 108 107 108 107 108 107 108 107 Ref 109: 109 108 109 108 109 108 109 108 109 108 Ref 110: 110 109 110 109 110 109 110 109 110 109 Ref 111: 111 110 111 110 111 110 111 110 111 110 Ref 112: 112 111 112 111 112 111 112 111 112 111 Ref 113: 113 112 113 112 113 112 113 112 113 112 Ref 114: 114 113 114 113 114 113 114 113 114 113 Ref 115: 115 114 115 114 115 114 115 114 115 114 Ref 116: 116 115 116 115 116 115 116 115 116 115 Ref 117: 117 116 117 116 117 116 117 116 117 116 Ref 118: 118 117 118 117 118 117 118 117 118 117 Ref 119: 119 118 119 118 119 118 119 118 119 118 Ref 120: 120 119 120 119 120 119 120 119 120 119 Ref 121: 121 120 121 120 121 120 121 120 121 120 Ref 122: 122 121 122 121 122 121 122 121 122 121 Ref 123: 123 122 123 122 123 122 123 122 123 122 Ref 124: 124 123 124 123 124 123 124 123 124 123 Ref 125: 125 124 125 124 125 124 125 124 125 124 Ref 126: 126 125 126 125 126 125 126 125 126 125 Ref 127: 127 126 127 126 127 126 127 126 127 126 Ref 128: 127 128 127 128 127 128 127 128 127 128 Ref 129: 128 129 128 129 128 129 128 129 128 129 Ref 130: 129 130 129 130 129 130 129 130 129 130 Ref 131: 130 131 130 131 130 131 130 131 130 131 Ref 132: 131 132 131 132 131 132 131 132 131 132 Ref 133: 132 133 132 133 132 133 132 133 132 133 Ref 134: 133 134 133 134 133 134 133 134 133 134 Ref 135: 134 135 134 135 134 135 134 135 134 135 Ref 136: 135 136 135 136 135 136 135 136 135 136 Ref 137: 136 137 136 137 136 137 136 137 136 137 Ref 138: 137 138 137 138 137 138 137 138 137 138 Ref 139: 138 139 138 139 138 139 138 139 138 139 Ref 140: 139 140 139 140 139 140 139 140 139 140 Ref 141: 140 141 140 141 140 141 140 141 140 141 Ref 142: 141 142 141 142 141 142 141 142 141 142 Ref 143: 142 143 142 143 142 143 142 143 142 143 Ref 144: 143 144 143 144 143 144 143 144 143 144 Ref 145: 144 145 144 145 144 145 144 145 144 145 Ref 146: 145 146 145 146 145 146 145 146 145 146 Ref 147: 146 147 146 147 146 147 146 147 146 147 Ref 148: 147 148 147 148 147 148 147 148 147 148 Ref 149: 148 149 148 149 148 149 148 149 148 149 Ref 150: 149 150 149 150 149 150 149 150 149 150 Ref 151: 150 151 150 151 150 151 150 151 150 151 Ref 152: 151 152 151 152 151 152 151 152 151 152 Ref 153: 152 153 152 153 152 153 152 153 152 153 Ref 154: 153 154 153 154 153 154 153 154 153 154 Ref 155: 154 155 154 155 154 155 154 155 154 155 Ref 156: 155 156 155 156 155 156 155 156 155 156 Ref 157: 156 157 156 157 156 157 156 157 156 157 Ref 158: 157 158 157 158 157 158 157 158 157 158 Ref 159: 158 159 158 159 158 159 158 159 158 159 Ref 160: 159 160 159 160 159 160 159 160 159 160 Ref 161: 160 161 160 161 160 161 160 161 160 161 Ref 162: 161 162 161 162 161 162 161 162 161 162 Ref 163: 162 163 162 163 162 163 162 163 162 163 Ref 164: 163 164 163 164 163 164 163 164 163 164 Ref 165: 164 165 164 165 164 165 164 165 164 165 Ref 166: 165 166 165 166 165 166 165 166 165 166 Ref 167: 166 167 166 167 166 167 166 167 166 167 Ref 168: 167 168 167 168 167 168 167 168 167 168 Ref 169: 168 169 168 169 168 169 168 169 168 169 Ref 170: 169 170 169 170 169 170 169 170 169 170 Ref 171: 170 171 170 171 170 171 170 171 170 171 Ref 172: 171 172 171 172 171 172 171 172 171 172 Ref 173: 172 173 172 173 172 173 172 173 172 173 Ref 174: 173 174 173 174 173 174 173 174 173 174 Ref 175: 174 175 174 175 174 175 174 175 174 175 Ref 176: 175 176 175 176 175 176 175 176 175 176 Ref 177: 176 177 176 177 176 177 176 177 176 177 Ref 178: 177 178 177 178 177 178 177 178 177 178 Ref 179: 178 179 178 179 178 179 178 179 178 179 Ref 180: 179 180 179 180 179 180 179 180 179 180 Ref 181: 180 181 180 181 180 181 180 181 180 181 Ref 182: 181 182 181 182 181 182 181 182 181 182 Ref 183: 182 183 182 183 182 183 182 183 182 183 Ref 184: 183 184 183 184 183 184 183 184 183 184 Ref 185: 184 185 184 185 184 185 184 185 184 185 Ref 186: 185 186 185 186 185 186 185 186 185 186 Ref 187: 186 187 186 187 186 187 186 187 186 187 Ref 188: 187 188 187 188 187 188 187 188 187 188 Ref 189: 188 189 188 189 188 189 188 189 188 189 Ref 190: 189 190 189 190 189 190 189 190 189 190 Ref 191: 190 191 190 191 190 191 190 191 190 191 Ref 192: 192 192 192 192 192 192 192 192 192 192 Ref 193: 193 193 193 193 193 193 193 193 193 193 Ref 194: 194 194 194 194 194 194 194 194 194 194 Ref 195: 195 195 195 195 195 195 195 195 195 195 Ref 196: 196 196 196 196 196 196 196 196 196 196 Ref 197: 197 197 197 197 197 197 197 197 197 197 Ref 198: 198 198 198 198 198 198 198 198 198 198 Ref 199: 199 199 199 199 199 199 199 199 199 199 Ref 200: 200 200 200 200 200 200 200 200 200 200 Ref 201: 201 201 201 201 201 201 201 201 201 201 Ref 202: 202 202 202 202 202 202 202 202 202 202 Ref 203: 203 203 203 203 203 203 203 203 203 203 Ref 204: 204 204 204 204 204 204 204 204 204 204 Ref 205: 205 205 205 205 205 205 205 205 205 205 Ref 206: 206 206 206 206 206 206 206 206 206 206 Ref 207: 207 207 207 207 207 207 207 207 207 207 Ref 208: 208 208 208 208 208 208 208 208 208 208 Ref 209: 209 209 209 209 209 209 209 209 209 209 Ref 210: 210 210 210 210 210 210 210 210 210 210 Ref 211: 211 211 211 211 211 211 211 211 211 211 Ref 212: 212 212 212 212 212 212 212 212 212 212 Ref 213: 213 213 213 213 213 213 213 213 213 213 Ref 214: 214 214 214 214 214 214 214 214 214 214 Ref 215: 215 215 215 215 215 215 215 215 215 215 Ref 216: 216 216 216 216 216 216 216 216 216 216 Ref 217: 217 217 217 217 217 217 217 217 217 217 Ref 218: 218 218 218 218 218 218 218 218 218 218 Ref 219: 219 219 219 219 219 219 219 219 219 219 Ref 220: 220 220 220 220 220 220 220 220 220 220 Ref 221: 221 221 221 221 221 221 221 221 221 221 Ref 222: 222 222 222 222 222 222 222 222 222 222 Ref 223: 223 223 223 223 223 223 223 223 223 223 Ref 224: 224 224 224 224 224 224 224 224 224 224 Ref 225: 225 225 225 225 225 225 225 225 225 225 Ref 226: 226 226 226 226 226 226 226 226 226 226 Ref 227: 227 227 227 227 227 227 227 227 227 227 Ref 228: 228 228 228 228 228 228 228 228 228 228 Ref 229: 229 229 229 229 229 229 229 229 229 229 Ref 230: 230 230 230 230 230 230 230 230 230 230 Ref 231: 231 231 231 231 231 231 231 231 231 231 Ref 232: 232 232 232 232 232 232 232 232 232 232 Ref 233: 233 233 233 233 233 233 233 233 233 233 Ref 234: 234 234 234 234 234 234 234 234 234 234 Ref 235: 235 235 235 235 235 235 235 235 235 235 Ref 236: 236 236 236 236 236 236 236 236 236 236 Ref 237: 237 237 237 237 237 237 237 237 237 237 Ref 238: 238 238 238 238 238 238 238 238 238 238 Ref 239: 239 239 239 239 239 239 239 239 239 239 Ref 240: 240 240 240 240 240 240 240 240 240 240 Ref 241: 241 241 241 241 241 241 241 241 241 241 Ref 242: 242 242 242 242 242 242 242 242 242 242 Ref 243: 243 243 243 243 243 243 243 243 243 243 Ref 244: 244 244 244 244 244 244 244 244 244 244 Ref 245: 245 245 245 245 245 245 245 245 245 245 Ref 246: 246 246 246 246 246 246 246 246 246 246 Ref 247: 247 247 247 247 247 247 247 247 247 247 Ref 248: 248 248 248 248 248 248 248 248 248 248 Ref 249: 249 249 249 249 249 249 249 249 249 249 Ref 250: 250 250 250 250 250 250 250 250 250 250 Ref 251: 251 251 251 251 251 251 251 251 251 251 Ref 252: 252 252 252 252 252 252 252 252 252 252 Ref 253: 253 253 253 253 253 253 253 253 253 253 Ref 254: 254 254 254 254 254 254 254 254 254 254 Ref 255: 255 255 255 255 255 255 255 255 255 255
I get the same result on Ironlake and IvyBridge. So it's not dithering the 8 bpc fb on the 8 bpc pipe to 6 bpc output, as all 256 values are in the output, but it is somehow screwing with the 8 bpc signal for no reason. Values >= 192 are unaffected, values between 0 and 127 get treated slightly different wrong than between 128 and 191.
On Linux <= 4.1 the output is as expected. If i apply this patch to force dithering off, then the problem is fixed on 4.2-rc:
--- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8622,8 +8622,10 @@ static void ironlake_set_pipeconf(struct drm_crtc *crtc) BUG(); }
- if (intel_crtc->config->dither) - val |= (PIPECONF_DITHER_EN | PIPECONF_DITHER_TYPE_SP); + if (intel_crtc->config->dither) { + DRM_INFO("Ironlake wants dithering, but skipping dither enable!\n"); + /* val |= (PIPECONF_DITHER_EN | PIPECONF_DITHER_TYPE_SP); */ + }
if (intel_crtc->config->base.adjusted_mode.flags & DRM_MODE_FLAG_INTERLACE) val |= PIPECONF_INTERLACED_ILK;
So the weirdness is triggered by dither enable on a 24 bpp fb feeding into the 24 bpp pipe, at least on the ironlake code path. Don't have a haswell part atm. to test that.
-mario
dri-devel@lists.freedesktop.org