On Wed, Feb 10, 2021 at 10:36 PM Alex Deucher <alexdeucher@xxxxxxxxx> wrote:
On Wed, Feb 10, 2021 at 4:08 PM Mario Kleiner
<mario.kleiner.de@xxxxxxxxx> 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?
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.
-mario
Alex
> Thanks,
> -mario
>
> On Mon, Jan 25, 2021 at 3:56 AM Mario Kleiner <mario.kleiner.de@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
