On 3/31/26 21:51, Harry Wentland wrote: > On 2026-03-31 03:16, Michel Dänzer wrote: >> On 3/30/26 19:36, Harry Wentland wrote: >>> On 2026-03-30 12:20, Michel Dänzer wrote: >>>> On 3/24/26 20:20, Mario Kleiner wrote: >>>>> On Sun, Mar 22, 2026 at 7:11 PM Kovac, Krunoslav <[email protected] >>>>> <mailto:[email protected]>> wrote: >>> >>>>>> I believe we don't have surface info in that code, but one way to >>>>>> work around it would be to use spatial dithering for FP16/ARGB16 and >>>>>> rounding for 10 bits. But if we just switch to spatial, some of the >>>>>> earlier complaints about 10-bit output having one-off bit errors will be >>>>>> coming back. >>>>> >>>>> Looking at all callers of resource_build_bit_depth_reduction_params(), >>>>> they all have access to the associated "struct pipe_ctx", which should >>>>> give access to pipe_ctx ->plane_state->format of an associated display >>>>> plane. I could prepare a patch that passes the pipe_ctx from each caller >>>>> into resource_build_bit_depth_reduction_params() and that function could >>>>> check if a 16 bpc framebuffer is in use and switch to spatial dithering >>>>> down-to-10-bpc in this case, and leave the rounding/truncation to 10 bpc >>>>> otherwise. >>>> >>>> That doesn't really make sense, the output of the display HW colour >>>> pipeline has more than 10 bpc regardless of framebuffer format. >>>> >>> >>> The output will be determined by the link bandwidth, display-advertised >>> supported bpc, and userspace-selected "max bpc" on a drm_connector. This >>> could very well be 10 bpc, 8 bpc, even 6 bpc. Or are you referring to the >>> internal DCN HW representation of the values? >> >> I am indeed. >> >>> They're higher, but that's somewhat irrelevant. >> >> How so? Surely dithering is applied to those values, not to the original >> values sampled from the framebuffer. >> > > True, but if, for example, the input is 8bpc then the intermediate > representation won't be able to add additional precision.
Why not? (See below) > I guess if there are color operations on top of the 8bpc content > then the values might be shifted in such a way that outputting > or dithered 8pbc will be a better representation than 8bpc rounded > values. Exactly. The colour pipeline can produce arbitrary output values up to the precision limits of the KMS API / HW internal pipeline, independent from the framebuffer formats. I.e. the output values can have more significant bits than the framebuffer formats. Therefore, basing the dithering on/off decision on the framebuffer format makes no sense. A less bad solution would be to disable dithering if the output bpc is >= (or ==) 10. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
