From: Arnd Bergmann arnd@arndb.de
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 arnd@arndb.de --- 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
On Fri, Dec 4, 2020 at 3:13 AM Arnd Bergmann arnd@kernel.org wrote:
From: Arnd Bergmann arnd@arndb.de
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 arnd@arndb.de
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 amd-gfx@lists.freedesktop.org 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 arnd@kernel.org wrote:
From: Arnd Bergmann arnd@arndb.de
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 arnd@arndb.de
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 amd-gfx@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.free...
On Mon, Dec 7, 2020 at 9:50 PM Christian König christian.koenig@amd.com wrote:
Am 07.12.20 um 21:47 schrieb Alex Deucher:
On Fri, Dec 4, 2020 at 3:13 AM Arnd Bergmann arnd@kernel.org wrote:
From: Arnd Bergmann arnd@arndb.de
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 1:57 PM Arnd Bergmann arnd@kernel.org wrote:
On Mon, Dec 7, 2020 at 9:50 PM Christian König christian.koenig@amd.com wrote:
Am 07.12.20 um 21:47 schrieb Alex Deucher:
On Fri, Dec 4, 2020 at 3:13 AM Arnd Bergmann arnd@kernel.org wrote:
From: Arnd Bergmann arnd@arndb.de
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.
On Mon, Dec 7, 2020 at 11:08 PM 'Nick Desaulniers' via Clang Built Linux clang-built-linux@googlegroups.com wrote:
On Mon, Dec 7, 2020 at 1:57 PM Arnd Bergmann arnd@kernel.org 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 arnd@kernel.org wrote:
On Mon, Dec 7, 2020 at 11:08 PM 'Nick Desaulniers' via Clang Built Linux clang-built-linux@googlegroups.com wrote:
On Mon, Dec 7, 2020 at 1:57 PM Arnd Bergmann arnd@kernel.org 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?
On Mon, Dec 7, 2020 at 11:28 PM 'Nick Desaulniers' via Clang Built Linux clang-built-linux@googlegroups.com wrote:
On Mon, Dec 7, 2020 at 2:17 PM Arnd Bergmann arnd@kernel.org wrote:
On Mon, Dec 7, 2020 at 11:08 PM 'Nick Desaulniers' via Clang Built Linux clang-built-linux@googlegroups.com wrote:
On Mon, Dec 7, 2020 at 1:57 PM Arnd Bergmann arnd@kernel.org 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 6:26 AM Arnd Bergmann arnd@kernel.org wrote:
On Mon, Dec 7, 2020 at 11:28 PM 'Nick Desaulniers' via Clang Built Linux clang-built-linux@googlegroups.com wrote:
On Mon, Dec 7, 2020 at 2:17 PM Arnd Bergmann arnd@kernel.org wrote:
On Mon, Dec 7, 2020 at 11:08 PM 'Nick Desaulniers' via Clang Built Linux clang-built-linux@googlegroups.com wrote:
On Mon, Dec 7, 2020 at 1:57 PM Arnd Bergmann arnd@kernel.org 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 (git@github.com: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?
On Tue, Dec 8, 2020 at 7:21 PM 'Nick Desaulniers' via Clang Built Linux clang-built-linux@googlegroups.com wrote:
On Tue, Dec 8, 2020 at 6:26 AM Arnd Bergmann arnd@kernel.org wrote:
On Mon, Dec 7, 2020 at 11:28 PM 'Nick Desaulniers' via Clang Built Linux clang-built-linux@googlegroups.com 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 (git@github.com: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 arnd@kernel.org wrote:
On Tue, Dec 8, 2020 at 7:21 PM 'Nick Desaulniers' via Clang Built Linux clang-built-linux@googlegroups.com wrote:
On Tue, Dec 8, 2020 at 6:26 AM Arnd Bergmann arnd@kernel.org wrote:
On Mon, Dec 7, 2020 at 11:28 PM 'Nick Desaulniers' via Clang Built Linux clang-built-linux@googlegroups.com 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 (git@github.com: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.
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Arnd Bergmann -
Christian König -
Nick Desaulniers