Why no spatial dithering to 10 bit depth on DCE?

Mario Kleiner mario.kleiner.de at gmail.com
Wed Feb 10 21:07:56 UTC 2021


Resending this one as well, in the hope of some clarification or background
information.

Thanks,
-mario

On Mon, Jan 25, 2021 at 3:56 AM Mario Kleiner <mario.kleiner.de at gmail.com>
wrote:

> Hi Harry and Nicholas,
>
> I'm still on an extended quest to squeeze as much HDR out of Linux + your
> hw as possible, although the paid contract with Vesa has officially ended
> by now, and stumbled over this little conundrum:
>
> DC's set_spatial_dither() function (see link below) has this particular
> comment:
> "/* no 10bpc on DCE11*/" followed by code that skips dithering setup if
> the target output depth is 10 bpc:
>
>
> https://elixir.bootlin.com/linux/v5.11-rc4/source/drivers/gpu/drm/amd/display/dc/dce/dce_opp.c#L219
>
> I couldn't find any hint in the commit messages towards the reason, so why
> is that?
>
> This gets in the way if one has a HDR-10 monitor with 10 bit native output
> depth connected and wants to output a fp16 framebuffer and retain some of
> the > 10 bit linear precision by use of spatial dithering down to 10 bit.
> One only gets the same precision as a 10 bpc unorm fb. Also the routine is
> called for all DCE's, not only DCE11, so it affects all of them.
>
> The same restrictions don't exist in the old kms code for amdgpu-kms and
> radeon-kms. I added a mmio hack to Psychtoolbox to go behind the drivers
> back and hack the FMT_BIT_DEPTH_CONTROL register to use spatial dithering
> down to 10 bpc anyway to circumvent this limitation. My photometer
> measurements on fp16 framebuffers feeding into 10 bit output show that I
> get a nice looking response consistent with dithering to 10 bpc properly
> working on DCE. Also i don't see any visual artifacts in displayed
> pictures, so the hw seems to be just fine. This on DCE-11.2, and more
> lightly tested on DCE-8.3.
>
> So i wonder if this is some leftover from some hw bringup, or if there is
> a good reason for it being there? Maybe it could be removed or made more
> specific to some problematic asic?
>
> Thanks for any insights you could provide. Stay safe,
> -mario
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20210210/0340682f/attachment.htm>


More information about the amd-gfx mailing list