On Fri, Feb 12, 2021 at 6:32 AM Alex Deucher <[email protected]> wrote:
> On Thu, Feb 11, 2021 at 4:12 PM Mario Kleiner > <[email protected]> wrote: > > > > On Wed, Feb 10, 2021 at 10:36 PM Alex Deucher <[email protected]> > wrote: > >> > >> On Wed, Feb 10, 2021 at 4:08 PM Mario Kleiner > >> <[email protected]> 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 < > [email protected]> 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 > >> > [email protected] > >> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx >
_______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
