<div dir="ltr"><div dir="ltr">On Wed, Feb 10, 2021 at 10:36 PM Alex Deucher <<a href="mailto:alexdeucher@gmail.com">alexdeucher@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Feb 10, 2021 at 4:08 PM Mario Kleiner<br>
<<a href="mailto:mario.kleiner.de@gmail.com" target="_blank">mario.kleiner.de@gmail.com</a>> wrote:<br>
><br>
> Resending this one as well, in the hope of some clarification or background information.<br>
><br>
<br></blockquote><div><br></div><div>Thanks Alex.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I suspect this may have been a limitation from DCE11.0 (E.g.,<br>
carrizo/stoney APUs).  They had some bandwidth limitations with<br>
respect to high bit depth IIRC.  I suspect it should be fine on the<br>
relevant dGPUs.  The code was probably originally added for the APUs<br>
</blockquote><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">and just never updated or the changes were accidentally lost when we<br>
consolidated the DCE code.  Unfortunately, there are not a lot of apps<br>
that work properly in Linux with >8 bits per channel.<br>
<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>-mario</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Alex<br>
<br>
<br>
> Thanks,<br>
> -mario<br>
><br>
> On Mon, Jan 25, 2021 at 3:56 AM Mario Kleiner <<a href="mailto:mario.kleiner.de@gmail.com" target="_blank">mario.kleiner.de@gmail.com</a>> wrote:<br>
>><br>
>> Hi Harry and Nicholas,<br>
>><br>
>> 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:<br>
>><br>
>> DC's set_spatial_dither() function (see link below) has this particular comment:<br>
>> "/* no 10bpc on DCE11*/" followed by code that skips dithering setup if the target output depth is 10 bpc:<br>
>><br>
>> <a href="https://elixir.bootlin.com/linux/v5.11-rc4/source/drivers/gpu/drm/amd/display/dc/dce/dce_opp.c#L219" rel="noreferrer" target="_blank">https://elixir.bootlin.com/linux/v5.11-rc4/source/drivers/gpu/drm/amd/display/dc/dce/dce_opp.c#L219</a><br>
>><br>
>> I couldn't find any hint in the commit messages towards the reason, so why is that?<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> 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?<br>
>><br>
>> Thanks for any insights you could provide. Stay safe,<br>
>> -mario<br>
>><br>
> _______________________________________________<br>
> amd-gfx mailing list<br>
> <a href="mailto:amd-gfx@lists.freedesktop.org" target="_blank">amd-gfx@lists.freedesktop.org</a><br>
> <a href="https://lists.freedesktop.org/mailman/listinfo/amd-gfx" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/amd-gfx</a><br>
</blockquote></div></div>