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.
Degamma+regamma can be set in a way that makes them true inverses at 10bpc
precision for common EOTFs, but not with dithering.
It's pretty hard to notice difference between dithering and rounding at 10bpc
even with a colorimeter, and since we had complaints about 10-bit one-off
errors, we went with rounding. I still think it's a preferred option for 10bpc
surfaces.
