On 3/31/26 21:57, Kovac, Krunoslav wrote: > On 3/31/2026 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. > > Our internal precision is higher than 12, but since we first "trim" to 12bpc > and then dither to 10bpc, bypass case is actually ok in practice even with > dithering. > > Normally for this case where we want 10bpc to go out as-is we would put HW > color pipeline blocks to bypass. There are some exceptions however, and > unfortunately one of them is not that uncommon. It's the multi-plane case > where linear blending is desired, which is the norm for HDR. In this case, we > do degamma, blend, regamma.
That's not "passthrough" by definition, so maybe the expectation that 10 bpc framebuffer values get through the pipeline unmodified just isn't realistic. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
