| Message ID | 20201204081349.1182302-1-arnd@kernel.org |
|---|---|
| State | New |
| Headers | show |
| Series | drm/amdgpu: make DRM_AMD_DC x86-only again | expand |
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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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.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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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? -- Thanks, ~Nick Desaulniers _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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? -- Thanks, ~Nick Desaulniers _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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. -- Thanks, ~Nick Desaulniers _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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