Why no spatial dithering to 10 bit depth on DCE?

[Mario Kleiner]

On Fri, Feb 12, 2021 at 6:32 AM Alex Deucher <alexdeucher at gmail.com> wrote:

> On Thu, Feb 11, 2021 at 4:12 PM Mario Kleiner
> <mario.kleiner.de at gmail.com> wrote:
> >
> > On Wed, Feb 10, 2021 at 10:36 PM Alex Deucher <alexdeucher at gmail.com>
> wrote:
> >>
> >> On Wed, Feb 10, 2021 at 4:08 PM Mario Kleiner
> >> <mario.kleiner.de at gmail.com> wrote:
> >> >
> >> > Resending this one as well, in the hope of some clarification or
> background information.
> >> >
> >>
> >
> > Thanks Alex.
> >
> >> I suspect this may have been a limitation from DCE11.0 (E.g.,
> >> carrizo/stoney APUs).  They had some bandwidth limitations with
> >> respect to high bit depth IIRC.  I suspect it should be fine on the
> >> relevant dGPUs.  The code was probably originally added for the APUs
> >
> >
> > That sounds as if it would make sense for me to try to submit a patch to
> you that restricts this limitation to DCE 11.0 only?
>
> I suspect older DCE 8.x APUs have similar limitations.  Although it
> may only be an issue with multiple monitors or something like that.  I
> don't remember the details.  @Harry Wentland do you remember?
>
> >
>

Fwiw, the tested DCE-8.3 was a mullins APU, at least that one was fine,
although only testable with 10 bpc HDMI + 6 bpc eDP, the only available
outputs.

I just sent out a patch to restrict the dithering restriction to DCE-11.0.
Successfully retested on DCE-11.2 via DP for extra care.

Have a nice weekend,
-mario


> All i can say is during my testing with DCE-8.3 over HDMI and DCE-11.2
> over DP under amdvlk with fp16 mode and ouptut_bpc set to 10 bpc, ie.
> dithering down from 12 bpc to 10 bpc, i didn't notice any problems when
> hacking this out, and photometer measurements showed good improvements of
> luminance reproduction with dithering.
> >
> >> and just never updated or the changes were accidentally lost when we
> >> consolidated the DCE code.  Unfortunately, there are not a lot of apps
> >> that work properly in Linux with >8 bits per channel.
> >>
> >
> > Mine does ;-). As does apparently the Kodi media player. And at least
> Gnome/X11 works now, whereas KDE's Kwin/X11 used to work nicely, but
> regressed. And amdvlk does have fp16 support now since a while ago, so
> that's one way to get high precision without disturbing conventional
> desktop apps. I'll probably look into Mesa's Vulkan/WSI for 10 bpc / fp16
> sometime this year if nobody beats me to it.
> >
>
> Sounds good.
>
> Alex
>
> > -mario
> >
> >
> >> Alex
> >>
> >>
> >> > 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
> >> >>
> >> > _______________________________________________
> >> > amd-gfx mailing list
> >> > amd-gfx at lists.freedesktop.org
> >> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20210212/9feeb8b9/attachment.htm>