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. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
