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:
snip
>
>>> 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? They're higher, but that's somewhat
irrelevant.
>
>> This workaround, that you also propose, would be the least bad of all bad
>> solutions.
>
> Seems pretty bad to me, mixing up things which aren't directly related.
>
I'm not sure I follow. Dither by definition is about relating the input bpc to
the output bpc.
Harry
>
