Re: Why no spatial dithering to 10 bit depth on DCE?

Re: Why no spatial dithering to 10 bit depth on DCE?

[Mario Kleiner]

[-- Attachment #1.1: Type: text/plain, Size: 2066 bytes --]

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@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
>
>

[-- Attachment #1.2: Type: text/html, Size: 2768 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Why no spatial dithering to 10 bit depth on DCE?

[Alex Deucher]

On Wed, Feb 10, 2021 at 4:08 PM Mario Kleiner
<mario.kleiner.de@gmail.com> wrote:
>
> Resending this one as well, in the hope of some clarification or background information.
>

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
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.

Alex


> Thanks,
> -mario
>
> On Mon, Jan 25, 2021 at 3:56 AM Mario Kleiner <mario.kleiner.de@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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Why no spatial dithering to 10 bit depth on DCE?

[Mario Kleiner]

[-- Attachment #1.1: Type: text/plain, Size: 3858 bytes --]

On Wed, Feb 10, 2021 at 10:36 PM Alex Deucher <alexdeucher@gmail.com> wrote:

> On Wed, Feb 10, 2021 at 4:08 PM Mario Kleiner
> <mario.kleiner.de@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?

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@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@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>

[-- Attachment #1.2: Type: text/html, Size: 5478 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Why no spatial dithering to 10 bit depth on DCE?

[Alex Deucher]

On Thu, Feb 11, 2021 at 4:12 PM Mario Kleiner
<mario.kleiner.de@gmail.com> wrote:
>
> On Wed, Feb 10, 2021 at 10:36 PM Alex Deucher <alexdeucher@gmail.com> wrote:
>>
>> On Wed, Feb 10, 2021 at 4:08 PM Mario Kleiner
>> <mario.kleiner.de@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?

>
> 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@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@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Why no spatial dithering to 10 bit depth on DCE?

[Mario Kleiner]

[-- Attachment #1.1: Type: text/plain, Size: 4803 bytes --]

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

> On Thu, Feb 11, 2021 at 4:12 PM Mario Kleiner
> <mario.kleiner.de@gmail.com> wrote:
> >
> > On Wed, Feb 10, 2021 at 10:36 PM Alex Deucher <alexdeucher@gmail.com>
> wrote:
> >>
> >> On Wed, Feb 10, 2021 at 4:08 PM Mario Kleiner
> >> <mario.kleiner.de@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@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@lists.freedesktop.org
> >> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>

[-- Attachment #1.2: Type: text/html, Size: 6631 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx