From: Arnd Bergmann <[email protected]>
As the DRM_AMD_DC_DCN3_0 code was x86-only and fails to build on
arm64, merging it into DRM_AMD_DC means that the top-level symbol
is now x86-only as well.
Compilation fails on arm64 with clang-12 with
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3641:6: error: stack frame size of 2416 bytes in function 'dml30_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than=]
void dml30_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
I tried to see if the stack usage can be reduced, but this is code
that is described as "This file is gcc-parsable HW gospel, coming
straight from HW engineers." and is written in a way that is inherently
nonportable and not meant to be understood by humans.
There are probably no non-x86 users of this code, so simplify
the dependency list accordingly.
Fixes: 20f2ffe50472 ("drm/amdgpu: fold CONFIG_DRM_AMD_DC_DCN3* into CONFIG_DRM_AMD_DC_DCN (v3)")
Signed-off-by: Arnd Bergmann <[email protected]>
---
drivers/gpu/drm/amd/display/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/Kconfig b/drivers/gpu/drm/amd/display/Kconfig
index 797b5d4b43e5..54aa50d4deba 100644
--- a/drivers/gpu/drm/amd/display/Kconfig
+++ b/drivers/gpu/drm/amd/display/Kconfig
@@ -6,7 +6,7 @@ config DRM_AMD_DC
bool "AMD DC - Enable new display engine"
default y
select SND_HDA_COMPONENT if SND_HDA_CORE
- select DRM_AMD_DC_DCN if (X86 || PPC64 || (ARM64 && KERNEL_MODE_NEON)) && !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS)
+ select DRM_AMD_DC_DCN if X86 && !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS)
help
Choose this option if you want to use the new display engine
support for AMDGPU. This adds required support for Vega and
--
2.27.0
On Fri, Dec 4, 2020 at 3:13 AM Arnd Bergmann <[email protected]> wrote:
>
> From: Arnd Bergmann <[email protected]>
>
> As the DRM_AMD_DC_DCN3_0 code was x86-only and fails to build on
> arm64, merging it into DRM_AMD_DC means that the top-level symbol
> is now x86-only as well.
>
> Compilation fails on arm64 with clang-12 with
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3641:6: error: stack frame size of 2416 bytes in function 'dml30_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than=]
> void dml30_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
>
> I tried to see if the stack usage can be reduced, but this is code
> that is described as "This file is gcc-parsable HW gospel, coming
> straight from HW engineers." and is written in a way that is inherently
> nonportable and not meant to be understood by humans.
>
> There are probably no non-x86 users of this code, so simplify
> the dependency list accordingly.
+ Daniel, Timothy
Others contributed code to enable this on PPC64 and ARM64.
Unfortunately, we don't have these platforms to test with within AMD.
Does PPC64 have the same stack limitations as ARM64? Harry, Leo, can
you take a look at fixing the stack usage?
Thanks,
Alex
>
> Fixes: 20f2ffe50472 ("drm/amdgpu: fold CONFIG_DRM_AMD_DC_DCN3* into CONFIG_DRM_AMD_DC_DCN (v3)")
> Signed-off-by: Arnd Bergmann <[email protected]>
> ---
> drivers/gpu/drm/amd/display/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/Kconfig b/drivers/gpu/drm/amd/display/Kconfig
> index 797b5d4b43e5..54aa50d4deba 100644
> --- a/drivers/gpu/drm/amd/display/Kconfig
> +++ b/drivers/gpu/drm/amd/display/Kconfig
> @@ -6,7 +6,7 @@ config DRM_AMD_DC
> bool "AMD DC - Enable new display engine"
> default y
> select SND_HDA_COMPONENT if SND_HDA_CORE
> - select DRM_AMD_DC_DCN if (X86 || PPC64 || (ARM64 && KERNEL_MODE_NEON)) && !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS)
> + select DRM_AMD_DC_DCN if X86 && !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS)
> help
> Choose this option if you want to use the new display engine
> support for AMDGPU. This adds required support for Vega and
> --
> 2.27.0
>
> _______________________________________________
> amd-gfx mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Am 07.12.20 um 21:47 schrieb Alex Deucher:
> On Fri, Dec 4, 2020 at 3:13 AM Arnd Bergmann <[email protected]> wrote:
>> From: Arnd Bergmann <[email protected]>
>>
>> As the DRM_AMD_DC_DCN3_0 code was x86-only and fails to build on
>> arm64, merging it into DRM_AMD_DC means that the top-level symbol
>> is now x86-only as well.
>>
>> Compilation fails on arm64 with clang-12 with
>>
>> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3641:6: error: stack frame size of 2416 bytes in function 'dml30_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than=]
>> void dml30_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
>>
>> I tried to see if the stack usage can be reduced, but this is code
>> that is described as "This file is gcc-parsable HW gospel, coming
>> straight from HW engineers." and is written in a way that is inherently
>> nonportable and not meant to be understood by humans.
>>
>> There are probably no non-x86 users of this code, so simplify
>> the dependency list accordingly.
> + Daniel, Timothy
>
> Others contributed code to enable this on PPC64 and ARM64.
> Unfortunately, we don't have these platforms to test with within AMD.
> Does PPC64 have the same stack limitations as ARM64? Harry, Leo, can
> you take a look at fixing the stack usage?
This reminds me that I wanted to reply on this.
2416 is even to much on x86 if you add -Werror :)
So this needs to be fixed anyway.
Christian.
>
> Thanks,
>
> Alex
>
>> Fixes: 20f2ffe50472 ("drm/amdgpu: fold CONFIG_DRM_AMD_DC_DCN3* into CONFIG_DRM_AMD_DC_DCN (v3)")
>> Signed-off-by: Arnd Bergmann <[email protected]>
>> ---
>> drivers/gpu/drm/amd/display/Kconfig | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/Kconfig b/drivers/gpu/drm/amd/display/Kconfig
>> index 797b5d4b43e5..54aa50d4deba 100644
>> --- a/drivers/gpu/drm/amd/display/Kconfig
>> +++ b/drivers/gpu/drm/amd/display/Kconfig
>> @@ -6,7 +6,7 @@ config DRM_AMD_DC
>> bool "AMD DC - Enable new display engine"
>> default y
>> select SND_HDA_COMPONENT if SND_HDA_CORE
>> - select DRM_AMD_DC_DCN if (X86 || PPC64 || (ARM64 && KERNEL_MODE_NEON)) && !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS)
>> + select DRM_AMD_DC_DCN if X86 && !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS)
>> help
>> Choose this option if you want to use the new display engine
>> support for AMDGPU. This adds required support for Vega and
>> --
>> 2.27.0
>>
>> _______________________________________________
>> amd-gfx mailing list
>> [email protected]
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Cchristian.koenig%40amd.com%7Cba72f82a98a4443b0dd108d89af15c1e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C1%7C637429708726258711%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=EU1LuB3uxSCrtAw%2BgwD%2FFWsYpZMp1FbffZvkerQ7WVs%3D&reserved=0
On Mon, Dec 7, 2020 at 9:50 PM Christian König <[email protected]> wrote:
> Am 07.12.20 um 21:47 schrieb Alex Deucher:
> > On Fri, Dec 4, 2020 at 3:13 AM Arnd Bergmann <[email protected]> wrote:
> >> From: Arnd Bergmann <[email protected]>
> >>
> >> As the DRM_AMD_DC_DCN3_0 code was x86-only and fails to build on
> >> arm64, merging it into DRM_AMD_DC means that the top-level symbol
> >> is now x86-only as well.
> >>
> >> Compilation fails on arm64 with clang-12 with
> >>
> >> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3641:6: error: stack frame size of 2416 bytes in function 'dml30_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than=]
> >> void dml30_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
> >>
> >> I tried to see if the stack usage can be reduced, but this is code
> >> that is described as "This file is gcc-parsable HW gospel, coming
> >> straight from HW engineers." and is written in a way that is inherently
> >> nonportable and not meant to be understood by humans.
> >>
> >> There are probably no non-x86 users of this code, so simplify
> >> the dependency list accordingly.
> > + Daniel, Timothy
> >
> > Others contributed code to enable this on PPC64 and ARM64.
> > Unfortunately, we don't have these platforms to test with within AMD.
> > Does PPC64 have the same stack limitations as ARM64? Harry, Leo, can
> > you take a look at fixing the stack usage?
>
> This reminds me that I wanted to reply on this.
>
> 2416 is even to much on x86 if you add -Werror :)
>
> So this needs to be fixed anyway.
Right, looking at my latest randconfig logs, I see the same problem on x86
builds with clang as well, though I'm not entirely sure which other
configuration
options are needed to trigger it.
So my patch can be disregarded, but I agree this needs a better fix,
either in clang or in the dcn driver.
Arnd
On Mon, Dec 7, 2020 at 11:08 PM 'Nick Desaulniers' via Clang Built
Linux <[email protected]> wrote:
>
> On Mon, Dec 7, 2020 at 1:57 PM Arnd Bergmann <[email protected]> wrote:
> >
> > Right, looking at my latest randconfig logs, I see the same problem on x86
> > builds with clang as well, though I'm not entirely sure which other
> > configuration
> > options are needed to trigger it.
> >
> > So my patch can be disregarded, but I agree this needs a better fix,
> > either in clang or in the dcn driver.
>
> If you could give https://github.com/ClangBuiltLinux/frame-larger-than
> a spin again, I would appreciate any feedback.
I've already tried it, but the tool doesn't seem to like me, I never
get the information out of it that I want. This time it failed because
it could not parse the .o file correctly.
Arnd
On Mon, Dec 7, 2020 at 2:17 PM Arnd Bergmann <[email protected]> wrote:
>
> On Mon, Dec 7, 2020 at 11:08 PM 'Nick Desaulniers' via Clang Built
> Linux <[email protected]> wrote:
> >
> > On Mon, Dec 7, 2020 at 1:57 PM Arnd Bergmann <[email protected]> wrote:
>
> > >
> > > Right, looking at my latest randconfig logs, I see the same problem on x86
> > > builds with clang as well, though I'm not entirely sure which other
> > > configuration
> > > options are needed to trigger it.
> > >
> > > So my patch can be disregarded, but I agree this needs a better fix,
> > > either in clang or in the dcn driver.
> >
> > If you could give https://github.com/ClangBuiltLinux/frame-larger-than
> > a spin again, I would appreciate any feedback.
>
> I've already tried it, but the tool doesn't seem to like me, I never
> get the information out of it that I want. This time it failed because
> it could not parse the .o file correctly.
Can you send me a config to reproduce the .o file?
--
Thanks,
~Nick Desaulniers
On Mon, Dec 7, 2020 at 1:57 PM Arnd Bergmann <[email protected]> wrote:
>
> On Mon, Dec 7, 2020 at 9:50 PM Christian König <[email protected]> wrote:
> > Am 07.12.20 um 21:47 schrieb Alex Deucher:
> > > On Fri, Dec 4, 2020 at 3:13 AM Arnd Bergmann <[email protected]> wrote:
> > >> From: Arnd Bergmann <[email protected]>
> > >>
> > >> As the DRM_AMD_DC_DCN3_0 code was x86-only and fails to build on
> > >> arm64, merging it into DRM_AMD_DC means that the top-level symbol
> > >> is now x86-only as well.
> > >>
> > >> Compilation fails on arm64 with clang-12 with
> > >>
> > >> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3641:6: error: stack frame size of 2416 bytes in function 'dml30_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than=]
> > >> void dml30_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
> > >>
> > >> I tried to see if the stack usage can be reduced, but this is code
> > >> that is described as "This file is gcc-parsable HW gospel, coming
> > >> straight from HW engineers." and is written in a way that is inherently
> > >> nonportable and not meant to be understood by humans.
> > >>
> > >> There are probably no non-x86 users of this code, so simplify
> > >> the dependency list accordingly.
> > > + Daniel, Timothy
> > >
> > > Others contributed code to enable this on PPC64 and ARM64.
> > > Unfortunately, we don't have these platforms to test with within AMD.
> > > Does PPC64 have the same stack limitations as ARM64? Harry, Leo, can
> > > you take a look at fixing the stack usage?
> >
> > This reminds me that I wanted to reply on this.
> >
> > 2416 is even to much on x86 if you add -Werror :)
> >
> > So this needs to be fixed anyway.
>
> Right, looking at my latest randconfig logs, I see the same problem on x86
> builds with clang as well, though I'm not entirely sure which other
> configuration
> options are needed to trigger it.
>
> So my patch can be disregarded, but I agree this needs a better fix,
> either in clang or in the dcn driver.
If you could give https://github.com/ClangBuiltLinux/frame-larger-than
a spin again, I would appreciate any feedback.
--
Thanks,
~Nick Desaulniers
On Tue, Dec 8, 2020 at 6:26 AM Arnd Bergmann <[email protected]> wrote:
>
> On Mon, Dec 7, 2020 at 11:28 PM 'Nick Desaulniers' via Clang Built
> Linux <[email protected]> wrote:
> >
> > On Mon, Dec 7, 2020 at 2:17 PM Arnd Bergmann <[email protected]> wrote:
> > >
> > > On Mon, Dec 7, 2020 at 11:08 PM 'Nick Desaulniers' via Clang Built
> > > Linux <[email protected]> wrote:
> > > >
> > > > On Mon, Dec 7, 2020 at 1:57 PM Arnd Bergmann <[email protected]> wrote:
> > >
> > > > >
> > > > > Right, looking at my latest randconfig logs, I see the same problem on x86
> > > > > builds with clang as well, though I'm not entirely sure which other
> > > > > configuration
> > > > > options are needed to trigger it.
> > > > >
> > > > > So my patch can be disregarded, but I agree this needs a better fix,
> > > > > either in clang or in the dcn driver.
> > > >
> > > > If you could give https://github.com/ClangBuiltLinux/frame-larger-than
> > > > a spin again, I would appreciate any feedback.
> > >
> > > I've already tried it, but the tool doesn't seem to like me, I never
> > > get the information out of it that I want. This time it failed because
> > > it could not parse the .o file correctly.
The tool has a dependency on a python library for parsing ELF; I've
been having to teach it about various relocation types for non-x86_64
architectures; I'm sure the failure from that scenario is...gnarly. I
don't know if my latest aarch64 fixes have been deployed (and it
depends on how the library is distributed).
> >
> > Can you send me a config to reproduce the .o file?
>
> The one attached here should reproduce it on x86.
Hmm...no warnings for me with that config on next-20201208:
$ make LLVM=1 -j71 olddefconfig
$ make LLVM=1 -j71
...
$ clang --version
clang version 12.0.0 ([email protected]:llvm/llvm-project.git
1c98f984105e552daa83ed8e92c61fba0e401410)
(ie. near ToT LLVM)
I see CONFIG_KASAN=y in the .config, so that's a recurring theme with
clang; excessive stack usage. It does seem a shame to disable a
driver for a bunch of archs just due to KASAN stack usage.
$ grep KASAN=y 0x9077925C_defconfig
CONFIG_HAVE_ARCH_KASAN=y
CONFIG_KASAN=y
Is there a different branch of a different tree that I should be
testing on instead? Otherwise, can you send the object file?
--
Thanks,
~Nick Desaulniers
On Mon, Dec 7, 2020 at 11:28 PM 'Nick Desaulniers' via Clang Built
Linux <[email protected]> wrote:
>
> On Mon, Dec 7, 2020 at 2:17 PM Arnd Bergmann <[email protected]> wrote:
> >
> > On Mon, Dec 7, 2020 at 11:08 PM 'Nick Desaulniers' via Clang Built
> > Linux <[email protected]> wrote:
> > >
> > > On Mon, Dec 7, 2020 at 1:57 PM Arnd Bergmann <[email protected]> wrote:
> >
> > > >
> > > > Right, looking at my latest randconfig logs, I see the same problem on x86
> > > > builds with clang as well, though I'm not entirely sure which other
> > > > configuration
> > > > options are needed to trigger it.
> > > >
> > > > So my patch can be disregarded, but I agree this needs a better fix,
> > > > either in clang or in the dcn driver.
> > >
> > > If you could give https://github.com/ClangBuiltLinux/frame-larger-than
> > > a spin again, I would appreciate any feedback.
> >
> > I've already tried it, but the tool doesn't seem to like me, I never
> > get the information out of it that I want. This time it failed because
> > it could not parse the .o file correctly.
>
> Can you send me a config to reproduce the .o file?
The one attached here should reproduce it on x86.
Arnd
On Tue, Dec 8, 2020 at 7:21 PM 'Nick Desaulniers' via Clang Built
Linux <[email protected]> wrote:
>
> On Tue, Dec 8, 2020 at 6:26 AM Arnd Bergmann <[email protected]> wrote:
> >
> > On Mon, Dec 7, 2020 at 11:28 PM 'Nick Desaulniers' via Clang Built
> > Linux <[email protected]> wrote:
> Hmm...no warnings for me with that config on next-20201208:
> $ make LLVM=1 -j71 olddefconfig
> $ make LLVM=1 -j71
> ...
> $ clang --version
> clang version 12.0.0 ([email protected]:llvm/llvm-project.git
> 1c98f984105e552daa83ed8e92c61fba0e401410)
> (ie. near ToT LLVM)
>
> I see CONFIG_KASAN=y in the .config, so that's a recurring theme with
> clang; excessive stack usage. It does seem a shame to disable a
> driver for a bunch of archs just due to KASAN stack usage.
> $ grep KASAN=y 0x9077925C_defconfig
> CONFIG_HAVE_ARCH_KASAN=y
> CONFIG_KASAN=y
>
> Is there a different branch of a different tree that I should be
> testing on instead? Otherwise, can you send the object file?
I was on a slightly older linux-next, and the latest version contains
the patch "ubsan: enable for all*config builds" in linux-next,
which enables CONFIG_UBSAN_SANITIZE_ALL. It took me
an hour to figure out, but after turning that option off, the warning
is back.
I'll send you the object for reference in a private mail, it's kind
of large.
Arnd
On Tue, Dec 8, 2020 at 2:18 PM Arnd Bergmann <[email protected]> wrote:
>
> On Tue, Dec 8, 2020 at 7:21 PM 'Nick Desaulniers' via Clang Built
> Linux <[email protected]> wrote:
> >
> > On Tue, Dec 8, 2020 at 6:26 AM Arnd Bergmann <[email protected]> wrote:
> > >
> > > On Mon, Dec 7, 2020 at 11:28 PM 'Nick Desaulniers' via Clang Built
> > > Linux <[email protected]> wrote:
> > Hmm...no warnings for me with that config on next-20201208:
> > $ make LLVM=1 -j71 olddefconfig
> > $ make LLVM=1 -j71
> > ...
> > $ clang --version
> > clang version 12.0.0 ([email protected]:llvm/llvm-project.git
> > 1c98f984105e552daa83ed8e92c61fba0e401410)
> > (ie. near ToT LLVM)
> >
> > I see CONFIG_KASAN=y in the .config, so that's a recurring theme with
> > clang; excessive stack usage. It does seem a shame to disable a
> > driver for a bunch of archs just due to KASAN stack usage.
> > $ grep KASAN=y 0x9077925C_defconfig
> > CONFIG_HAVE_ARCH_KASAN=y
> > CONFIG_KASAN=y
> >
> > Is there a different branch of a different tree that I should be
> > testing on instead? Otherwise, can you send the object file?
>
> I was on a slightly older linux-next, and the latest version contains
> the patch "ubsan: enable for all*config builds" in linux-next,
> which enables CONFIG_UBSAN_SANITIZE_ALL. It took me
> an hour to figure out, but after turning that option off, the warning
> is back.
>
> I'll send you the object for reference in a private mail, it's kind
> of large.
Got it, thanks.
$ llvm-objdump -Dr
--disassemble-symbols=dml30_ModeSupportAndSystemConfigurationFull
display_mode_vba_30.o
...
1584f: 48 81 ec a0 08 00 00 subq $2208, %rsp
...
$ python3 /android0/frame-larger-than/frame_larger_than.py
display_mode_vba_30.o dml30_ModeSupportAndSystemConfigurationFull
No dwarf info found in display_mode_vba_30.o
$ llvm-readelf -S display_mode_vba_30.o | grep debug_info
$ echo $?
1
Can you rebuild+resend with CONFIG_DEBUG_INFO enabled?
frame_larger_than.py relies on the DWARF debug info to know what local
variables occupy how much stack space.
--
Thanks,
~Nick Desaulniers