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.
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.
Harry
>
