* [PATCH] drm/amd/display: Limit DCN to x86 arch @ 2017-05-19 14:01 Harry Wentland [not found] ` <20170519140121.14296-1-harry.wentland-5C7GfCeVMHo@public.gmane.org> 0 siblings, 1 reply; 10+ messages in thread From: Harry Wentland @ 2017-05-19 14:01 UTC (permalink / raw) To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW Cc: Harry Wentland, Michel Dänzer, Dmytro Laktyushkin, Alex Deucher, Tony Cheng, Christian König DCN bw calcs currently rely on the following gcc options: -mhard-float -msse -mpreferred-stack-boundary=4 We probably shouldn't allow building this on architectures other than x86. CC: Alex Deucher <Alexander.Deucher@amd.com> CC: Christian König <christian.koenig@amd.com> CC: Michel Dänzer <michel.daenzer@amd.com> CC: Tony Cheng <Tony.Cheng@amd.com> CC: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> --- Tested this change by running make menuconfig and make modules with ARCH=arm. Harry drivers/gpu/drm/amd/display/Kconfig | 2 +- drivers/gpu/drm/amd/display/dc/calcs/Makefile | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/Kconfig b/drivers/gpu/drm/amd/display/Kconfig index 2b8d77cebe03..62ea9f600374 100644 --- a/drivers/gpu/drm/amd/display/Kconfig +++ b/drivers/gpu/drm/amd/display/Kconfig @@ -11,7 +11,7 @@ config DRM_AMD_DC config DRM_AMD_DC_DCN1_0 bool "DCN 1.0 Raven family" - depends on DRM_AMD_DC + depends on DRM_AMD_DC && X86 help Choose this option if you want to have RV family for display engine diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile b/drivers/gpu/drm/amd/display/dc/calcs/Makefile index a095472bf4b5..2e4ce0918c02 100644 --- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile +++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile @@ -3,9 +3,11 @@ # It calculates Bandwidth and Watermarks values for HW programming # +ifeq ($(ARCH),x86) CFLAGS_dcn_calcs.o := -mhard-float -msse -mpreferred-stack-boundary=4 CFLAGS_dcn_calc_auto.o := -mhard-float -msse -mpreferred-stack-boundary=4 CFLAGS_dcn_calc_math.o := -mhard-float -msse -mpreferred-stack-boundary=4 +endif BW_CALCS = dce_calcs.o bw_fixed.o custom_float.o -- 2.11.0 _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply related [flat|nested] 10+ messages in thread
[parent not found: <20170519140121.14296-1-harry.wentland-5C7GfCeVMHo@public.gmane.org>]
* RE: [PATCH] drm/amd/display: Limit DCN to x86 arch [not found] ` <20170519140121.14296-1-harry.wentland-5C7GfCeVMHo@public.gmane.org> @ 2017-05-19 14:54 ` Lazare, Jordan 2017-05-19 15:02 ` Christian König 1 sibling, 0 replies; 10+ messages in thread From: Lazare, Jordan @ 2017-05-19 14:54 UTC (permalink / raw) To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW Cc: Wentland, Harry, Daenzer, Michel, Laktyushkin, Dmytro, Deucher, Alexander, Cheng, Tony, Koenig, Christian Acked-by: Jordan Lazare <Jordan.Lazare@amd.com> -----Original Message----- From: amd-gfx [mailto:amd-gfx-bounces@lists.freedesktop.org] On Behalf Of Harry Wentland Sent: Friday, May 19, 2017 10:01 AM To: amd-gfx@lists.freedesktop.org Cc: Wentland, Harry <Harry.Wentland@amd.com>; Daenzer, Michel <Michel.Daenzer@amd.com>; Laktyushkin, Dmytro <Dmytro.Laktyushkin@amd.com>; Deucher, Alexander <Alexander.Deucher@amd.com>; Cheng, Tony <Tony.Cheng@amd.com>; Koenig, Christian <Christian.Koenig@amd.com> Subject: [PATCH] drm/amd/display: Limit DCN to x86 arch DCN bw calcs currently rely on the following gcc options: -mhard-float -msse -mpreferred-stack-boundary=4 We probably shouldn't allow building this on architectures other than x86. CC: Alex Deucher <Alexander.Deucher@amd.com> CC: Christian König <christian.koenig@amd.com> CC: Michel Dänzer <michel.daenzer@amd.com> CC: Tony Cheng <Tony.Cheng@amd.com> CC: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> --- Tested this change by running make menuconfig and make modules with ARCH=arm. Harry drivers/gpu/drm/amd/display/Kconfig | 2 +- drivers/gpu/drm/amd/display/dc/calcs/Makefile | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/Kconfig b/drivers/gpu/drm/amd/display/Kconfig index 2b8d77cebe03..62ea9f600374 100644 --- a/drivers/gpu/drm/amd/display/Kconfig +++ b/drivers/gpu/drm/amd/display/Kconfig @@ -11,7 +11,7 @@ config DRM_AMD_DC config DRM_AMD_DC_DCN1_0 bool "DCN 1.0 Raven family" - depends on DRM_AMD_DC + depends on DRM_AMD_DC && X86 help Choose this option if you want to have RV family for display engine diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile b/drivers/gpu/drm/amd/display/dc/calcs/Makefile index a095472bf4b5..2e4ce0918c02 100644 --- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile +++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile @@ -3,9 +3,11 @@ # It calculates Bandwidth and Watermarks values for HW programming # +ifeq ($(ARCH),x86) CFLAGS_dcn_calcs.o := -mhard-float -msse -mpreferred-stack-boundary=4 CFLAGS_dcn_calc_auto.o := -mhard-float -msse -mpreferred-stack-boundary=4 CFLAGS_dcn_calc_math.o := -mhard-float -msse -mpreferred-stack-boundary=4 +endif BW_CALCS = dce_calcs.o bw_fixed.o custom_float.o -- 2.11.0 _______________________________________________ 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 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] drm/amd/display: Limit DCN to x86 arch [not found] ` <20170519140121.14296-1-harry.wentland-5C7GfCeVMHo@public.gmane.org> 2017-05-19 14:54 ` Lazare, Jordan @ 2017-05-19 15:02 ` Christian König [not found] ` <f84c51b6-06f1-b4d2-c472-89265ebb26cb-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org> 1 sibling, 1 reply; 10+ messages in thread From: Christian König @ 2017-05-19 15:02 UTC (permalink / raw) To: Harry Wentland, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW Cc: Alex Deucher, Tony Cheng, Dmytro Laktyushkin, Michel Dänzer, Christian König Am 19.05.2017 um 16:01 schrieb Harry Wentland: > DCN bw calcs currently rely on the following gcc options: > -mhard-float -msse -mpreferred-stack-boundary=4 Mhm, price question: Why does DCN rely on the gcc options? That is something very unusual for drivers. We occasionally have something like enabling additional warnings, but things like "-mhard-float" is clearly raising an eyebrow here. Christian. > > We probably shouldn't allow building this on architectures > other than x86. > > CC: Alex Deucher <Alexander.Deucher@amd.com> > CC: Christian König <christian.koenig@amd.com> > CC: Michel Dänzer <michel.daenzer@amd.com> > CC: Tony Cheng <Tony.Cheng@amd.com> > CC: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> > Signed-off-by: Harry Wentland <harry.wentland@amd.com> > --- > > Tested this change by running make menuconfig and make modules with > ARCH=arm. > > Harry > > drivers/gpu/drm/amd/display/Kconfig | 2 +- > drivers/gpu/drm/amd/display/dc/calcs/Makefile | 2 ++ > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/display/Kconfig b/drivers/gpu/drm/amd/display/Kconfig > index 2b8d77cebe03..62ea9f600374 100644 > --- a/drivers/gpu/drm/amd/display/Kconfig > +++ b/drivers/gpu/drm/amd/display/Kconfig > @@ -11,7 +11,7 @@ config DRM_AMD_DC > > config DRM_AMD_DC_DCN1_0 > bool "DCN 1.0 Raven family" > - depends on DRM_AMD_DC > + depends on DRM_AMD_DC && X86 > help > Choose this option if you want to have > RV family for display engine > diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile b/drivers/gpu/drm/amd/display/dc/calcs/Makefile > index a095472bf4b5..2e4ce0918c02 100644 > --- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile > +++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile > @@ -3,9 +3,11 @@ > # It calculates Bandwidth and Watermarks values for HW programming > # > > +ifeq ($(ARCH),x86) > CFLAGS_dcn_calcs.o := -mhard-float -msse -mpreferred-stack-boundary=4 > CFLAGS_dcn_calc_auto.o := -mhard-float -msse -mpreferred-stack-boundary=4 > CFLAGS_dcn_calc_math.o := -mhard-float -msse -mpreferred-stack-boundary=4 > +endif > > BW_CALCS = dce_calcs.o bw_fixed.o custom_float.o > _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <f84c51b6-06f1-b4d2-c472-89265ebb26cb-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>]
* Re: [PATCH] drm/amd/display: Limit DCN to x86 arch [not found] ` <f84c51b6-06f1-b4d2-c472-89265ebb26cb-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org> @ 2017-05-19 19:36 ` Harry Wentland [not found] ` <7a8b84af-38f7-33d2-5bbb-473f2ea35bb2-5C7GfCeVMHo@public.gmane.org> 0 siblings, 1 reply; 10+ messages in thread From: Harry Wentland @ 2017-05-19 19:36 UTC (permalink / raw) To: Christian König, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW Cc: Alex Deucher, Tony Cheng, Dmytro Laktyushkin, Michel Dänzer, Christian König On 2017-05-19 11:02 AM, Christian König wrote: > Am 19.05.2017 um 16:01 schrieb Harry Wentland: >> DCN bw calcs currently rely on the following gcc options: >> -mhard-float -msse -mpreferred-stack-boundary=4 > > Mhm, price question: Why does DCN rely on the gcc options? > Tony and Dmytro can probably provide more info here but my understanding is that DCN bandwidth calcs requires floating point support. This code comes pretty much straight from hardware teams with a guarantee that the output is good. If we were to rewrite bandwidth calculations that guarantee would basically fly out the window, which means when there's a bandwidth bug we cannot easily get HW support unless we can prove that our calculations yield the exact same results in all cases as HWs formula. Covering all scenarios that bandwidth calcs covers would be quite an extensive undertaking and I'm sure we'd miss important cases. Bandwidth issues can be very hard to pin down and changes in the calculations can have significant impact on our power efficiency. > That is something very unusual for drivers. We occasionally have > something like enabling additional warnings, but things like > "-mhard-float" is clearly raising an eyebrow here. > Absolutely, and I'd love to hear more opinions on this. Harry > Christian. > >> >> We probably shouldn't allow building this on architectures >> other than x86. >> >> CC: Alex Deucher <Alexander.Deucher@amd.com> >> CC: Christian König <christian.koenig@amd.com> >> CC: Michel Dänzer <michel.daenzer@amd.com> >> CC: Tony Cheng <Tony.Cheng@amd.com> >> CC: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> >> Signed-off-by: Harry Wentland <harry.wentland@amd.com> >> --- >> >> Tested this change by running make menuconfig and make modules with >> ARCH=arm. >> >> Harry >> >> drivers/gpu/drm/amd/display/Kconfig | 2 +- >> drivers/gpu/drm/amd/display/dc/calcs/Makefile | 2 ++ >> 2 files changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/amd/display/Kconfig >> b/drivers/gpu/drm/amd/display/Kconfig >> index 2b8d77cebe03..62ea9f600374 100644 >> --- a/drivers/gpu/drm/amd/display/Kconfig >> +++ b/drivers/gpu/drm/amd/display/Kconfig >> @@ -11,7 +11,7 @@ config DRM_AMD_DC >> config DRM_AMD_DC_DCN1_0 >> bool "DCN 1.0 Raven family" >> - depends on DRM_AMD_DC >> + depends on DRM_AMD_DC && X86 >> help >> Choose this option if you want to have >> RV family for display engine >> diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile >> b/drivers/gpu/drm/amd/display/dc/calcs/Makefile >> index a095472bf4b5..2e4ce0918c02 100644 >> --- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile >> +++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile >> @@ -3,9 +3,11 @@ >> # It calculates Bandwidth and Watermarks values for HW programming >> # >> +ifeq ($(ARCH),x86) >> CFLAGS_dcn_calcs.o := -mhard-float -msse -mpreferred-stack-boundary=4 >> CFLAGS_dcn_calc_auto.o := -mhard-float -msse >> -mpreferred-stack-boundary=4 >> CFLAGS_dcn_calc_math.o := -mhard-float -msse >> -mpreferred-stack-boundary=4 >> +endif >> BW_CALCS = dce_calcs.o bw_fixed.o custom_float.o > > _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <7a8b84af-38f7-33d2-5bbb-473f2ea35bb2-5C7GfCeVMHo@public.gmane.org>]
* Re: [PATCH] drm/amd/display: Limit DCN to x86 arch [not found] ` <7a8b84af-38f7-33d2-5bbb-473f2ea35bb2-5C7GfCeVMHo@public.gmane.org> @ 2017-05-19 20:18 ` Dave Airlie [not found] ` <CAPM=9tzcA8t-ji6qNQhycB0cezz2vH6HMixCgvKQ78cY1Y8fsA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 10+ messages in thread From: Dave Airlie @ 2017-05-19 20:18 UTC (permalink / raw) To: Harry Wentland Cc: Michel Dänzer, amd-gfx mailing list, Christian König, Dmytro Laktyushkin, Alex Deucher, Tony Cheng, Christian König On 20 May 2017 at 05:36, Harry Wentland <harry.wentland@amd.com> wrote: > On 2017-05-19 11:02 AM, Christian König wrote: >> >> Am 19.05.2017 um 16:01 schrieb Harry Wentland: >>> >>> DCN bw calcs currently rely on the following gcc options: >>> -mhard-float -msse -mpreferred-stack-boundary=4 >> >> >> Mhm, price question: Why does DCN rely on the gcc options? >> > > Tony and Dmytro can probably provide more info here but my understanding is > that DCN bandwidth calcs requires floating point support. This code comes > pretty much straight from hardware teams with a guarantee that the output is > good. > > If we were to rewrite bandwidth calculations that guarantee would basically > fly out the window, which means when there's a bandwidth bug we cannot > easily get HW support unless we can prove that our calculations yield the > exact same results in all cases as HWs formula. Covering all scenarios that > bandwidth calcs covers would be quite an extensive undertaking and I'm sure > we'd miss important cases. Is this only going to happen for X86 APUs? Using floating point in the kernel requires a lot of care to be taken, are we doing it properly? Really rewriting the calcs in fixed point is the best option, maybe push back on the hardware team to have a fixed point version created. Dave. _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <CAPM=9tzcA8t-ji6qNQhycB0cezz2vH6HMixCgvKQ78cY1Y8fsA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH] drm/amd/display: Limit DCN to x86 arch [not found] ` <CAPM=9tzcA8t-ji6qNQhycB0cezz2vH6HMixCgvKQ78cY1Y8fsA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2017-05-19 20:28 ` Harry Wentland [not found] ` <4e0c342b-d18e-5f7a-bd30-9becd0e97e3c-5C7GfCeVMHo@public.gmane.org> 0 siblings, 1 reply; 10+ messages in thread From: Harry Wentland @ 2017-05-19 20:28 UTC (permalink / raw) To: Dave Airlie Cc: Michel Dänzer, amd-gfx mailing list, Christian König, Dmytro Laktyushkin, Alex Deucher, Tony Cheng, Christian König On 2017-05-19 04:18 PM, Dave Airlie wrote: > On 20 May 2017 at 05:36, Harry Wentland <harry.wentland@amd.com> wrote: >> On 2017-05-19 11:02 AM, Christian König wrote: >>> >>> Am 19.05.2017 um 16:01 schrieb Harry Wentland: >>>> >>>> DCN bw calcs currently rely on the following gcc options: >>>> -mhard-float -msse -mpreferred-stack-boundary=4 >>> >>> >>> Mhm, price question: Why does DCN rely on the gcc options? >>> >> >> Tony and Dmytro can probably provide more info here but my understanding is >> that DCN bandwidth calcs requires floating point support. This code comes >> pretty much straight from hardware teams with a guarantee that the output is >> good. >> >> If we were to rewrite bandwidth calculations that guarantee would basically >> fly out the window, which means when there's a bandwidth bug we cannot >> easily get HW support unless we can prove that our calculations yield the >> exact same results in all cases as HWs formula. Covering all scenarios that >> bandwidth calcs covers would be quite an extensive undertaking and I'm sure >> we'd miss important cases. > > Is this only going to happen for X86 APUs? Using floating point in the > kernel requires > a lot of care to be taken, are we doing it properly? > This case would be only for AMD X86 APUs, although I wouldn't be surprised if we'd see something similar for discrete ASICs in the future. Are you aware of anyone using our GPUs on non-X86 architectures? If so, I never heard of it. I realize this is raising a lot of concern. I was concerned myself when I first saw this. Beside calling kernel_fpu_begin() and kernel_fpu_end() are there other things to watch out for? Harry > Really rewriting the calcs in fixed point is the best option, maybe push back on > the hardware team to have a fixed point version created. > > Dave. > _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <4e0c342b-d18e-5f7a-bd30-9becd0e97e3c-5C7GfCeVMHo@public.gmane.org>]
* Re: [PATCH] drm/amd/display: Limit DCN to x86 arch [not found] ` <4e0c342b-d18e-5f7a-bd30-9becd0e97e3c-5C7GfCeVMHo@public.gmane.org> @ 2017-05-20 8:13 ` Christian König [not found] ` <013f44e3-1734-43f8-4cd7-e950ffb014f0-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org> 0 siblings, 1 reply; 10+ messages in thread From: Christian König @ 2017-05-20 8:13 UTC (permalink / raw) To: Harry Wentland, Dave Airlie Cc: Michel Dänzer, amd-gfx mailing list, Dmytro Laktyushkin, Alex Deucher, Tony Cheng, Christian König Am 19.05.2017 um 22:28 schrieb Harry Wentland: > > > On 2017-05-19 04:18 PM, Dave Airlie wrote: >> On 20 May 2017 at 05:36, Harry Wentland <harry.wentland@amd.com> wrote: >>> On 2017-05-19 11:02 AM, Christian König wrote: >>>> >>>> Am 19.05.2017 um 16:01 schrieb Harry Wentland: >>>>> >>>>> DCN bw calcs currently rely on the following gcc options: >>>>> -mhard-float -msse -mpreferred-stack-boundary=4 >>>> >>>> >>>> Mhm, price question: Why does DCN rely on the gcc options? >>>> >>> >>> Tony and Dmytro can probably provide more info here but my >>> understanding is >>> that DCN bandwidth calcs requires floating point support. This code >>> comes >>> pretty much straight from hardware teams with a guarantee that the >>> output is >>> good. >>> >>> If we were to rewrite bandwidth calculations that guarantee would >>> basically >>> fly out the window, which means when there's a bandwidth bug we cannot >>> easily get HW support unless we can prove that our calculations >>> yield the >>> exact same results in all cases as HWs formula. Covering all >>> scenarios that >>> bandwidth calcs covers would be quite an extensive undertaking and >>> I'm sure >>> we'd miss important cases. >> >> Is this only going to happen for X86 APUs? Using floating point in the >> kernel requires >> a lot of care to be taken, are we doing it properly? >> > > This case would be only for AMD X86 APUs, although I wouldn't be > surprised if we'd see something similar for discrete ASICs in the future. > Ok, that makes at least a bit more sense. On APUs we obviously know exactly what CPU we have. > Are you aware of anyone using our GPUs on non-X86 architectures? If > so, I never heard of it. Yeah, there are actually quite a number of people. That's one of the reasons why we still have a bunch of "#ifdef __BIG_ENDIAN" in the amdgpu source. > I realize this is raising a lot of concern. I was concerned myself > when I first saw this. Beside calling kernel_fpu_begin() and > kernel_fpu_end() are there other things to watch out for? Yeah, especially setting "-msse" is rather questionable. As far as I know on 64bit systems it is the default, but on 32bit systems that could silently break some assumptions. Additional to that as far as I know "-msse" is just for optimization and that isn't performance critical code, so why exactly do we need it? Christian. > > Harry > >> Really rewriting the calcs in fixed point is the best option, maybe >> push back on >> the hardware team to have a fixed point version created. >> >> Dave. >> > _______________________________________________ > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <013f44e3-1734-43f8-4cd7-e950ffb014f0-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>]
* Re: [PATCH] drm/amd/display: Limit DCN to x86 arch [not found] ` <013f44e3-1734-43f8-4cd7-e950ffb014f0-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org> @ 2017-05-23 13:37 ` Harry Wentland [not found] ` <ff8918ec-ee0e-692e-4ada-cd6bd939d902-5C7GfCeVMHo@public.gmane.org> 0 siblings, 1 reply; 10+ messages in thread From: Harry Wentland @ 2017-05-23 13:37 UTC (permalink / raw) To: Christian König, Dave Airlie Cc: Michel Dänzer, amd-gfx mailing list, Dmytro Laktyushkin, Alex Deucher, Tony Cheng, Christian König On 2017-05-20 04:13 AM, Christian König wrote: > Am 19.05.2017 um 22:28 schrieb Harry Wentland: >> >> >> On 2017-05-19 04:18 PM, Dave Airlie wrote: >>> On 20 May 2017 at 05:36, Harry Wentland <harry.wentland@amd.com> wrote: >>>> On 2017-05-19 11:02 AM, Christian König wrote: >>>>> >>>>> Am 19.05.2017 um 16:01 schrieb Harry Wentland: >>>>>> >>>>>> DCN bw calcs currently rely on the following gcc options: >>>>>> -mhard-float -msse -mpreferred-stack-boundary=4 >>>>> >>>>> >>>>> Mhm, price question: Why does DCN rely on the gcc options? >>>>> >>>> >>>> Tony and Dmytro can probably provide more info here but my >>>> understanding is >>>> that DCN bandwidth calcs requires floating point support. This code >>>> comes >>>> pretty much straight from hardware teams with a guarantee that the >>>> output is >>>> good. >>>> >>>> If we were to rewrite bandwidth calculations that guarantee would >>>> basically >>>> fly out the window, which means when there's a bandwidth bug we cannot >>>> easily get HW support unless we can prove that our calculations >>>> yield the >>>> exact same results in all cases as HWs formula. Covering all >>>> scenarios that >>>> bandwidth calcs covers would be quite an extensive undertaking and >>>> I'm sure >>>> we'd miss important cases. >>> >>> Is this only going to happen for X86 APUs? Using floating point in the >>> kernel requires >>> a lot of care to be taken, are we doing it properly? >>> >> >> This case would be only for AMD X86 APUs, although I wouldn't be >> surprised if we'd see something similar for discrete ASICs in the future. >> > > Ok, that makes at least a bit more sense. On APUs we obviously know > exactly what CPU we have. > >> Are you aware of anyone using our GPUs on non-X86 architectures? If >> so, I never heard of it. > > Yeah, there are actually quite a number of people. That's one of the > reasons why we still have a bunch of "#ifdef __BIG_ENDIAN" in the amdgpu > source. > Interesting. I'd love to know more about this, like which platforms, etc, since sadly we've been pretty unaware of this. >> I realize this is raising a lot of concern. I was concerned myself >> when I first saw this. Beside calling kernel_fpu_begin() and >> kernel_fpu_end() are there other things to watch out for? > > Yeah, especially setting "-msse" is rather questionable. As far as I > know on 64bit systems it is the default, but on 32bit systems that could > silently break some assumptions. > > Additional to that as far as I know "-msse" is just for optimization and > that isn't performance critical code, so why exactly do we need it? > Once we enable multi-plane code this code becomes performance critical as I believe it gets executed when resizing an underlay surface, such as a video player. I don't we've tried running without -msse, though. It might be good enough. Harry > Christian. > >> >> Harry >> >>> Really rewriting the calcs in fixed point is the best option, maybe >>> push back on >>> the hardware team to have a fixed point version created. >>> >>> Dave. >>> >> _______________________________________________ >> 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <ff8918ec-ee0e-692e-4ada-cd6bd939d902-5C7GfCeVMHo@public.gmane.org>]
* Re: [PATCH] drm/amd/display: Limit DCN to x86 arch [not found] ` <ff8918ec-ee0e-692e-4ada-cd6bd939d902-5C7GfCeVMHo@public.gmane.org> @ 2017-05-23 14:57 ` Felix Kuehling 2017-05-24 1:09 ` Michel Dänzer 1 sibling, 0 replies; 10+ messages in thread From: Felix Kuehling @ 2017-05-23 14:57 UTC (permalink / raw) To: Harry Wentland, Christian König, Dave Airlie Cc: Michel Dänzer, amd-gfx mailing list, Dmytro Laktyushkin, Alex Deucher, Tony Cheng, Christian König On 17-05-23 09:37 AM, Harry Wentland wrote: > > > On 2017-05-20 04:13 AM, Christian König wrote: >> Are you aware of anyone using our GPUs on non-X86 architectures? If >> so, I never heard of it. >> >> Yeah, there are actually quite a number of people. That's one of the >> reasons why we still have a bunch of "#ifdef __BIG_ENDIAN" in the >> amdgpu source. >> > > Interesting. I'd love to know more about this, like which platforms, > etc, since sadly we've been pretty unaware of this. For ROCm we're working on supporting ARMv8 and Power8. This is for compute, so mostly headless. Not sure if they would care about display in the future. Regards, Felix _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] drm/amd/display: Limit DCN to x86 arch [not found] ` <ff8918ec-ee0e-692e-4ada-cd6bd939d902-5C7GfCeVMHo@public.gmane.org> 2017-05-23 14:57 ` Felix Kuehling @ 2017-05-24 1:09 ` Michel Dänzer 1 sibling, 0 replies; 10+ messages in thread From: Michel Dänzer @ 2017-05-24 1:09 UTC (permalink / raw) To: Harry Wentland, Christian König, Dave Airlie Cc: Michel Dänzer, amd-gfx mailing list, Dmytro Laktyushkin, Alex Deucher, Tony Cheng, Christian König On 23/05/17 10:37 PM, Harry Wentland wrote: > On 2017-05-20 04:13 AM, Christian König wrote: >> Am 19.05.2017 um 22:28 schrieb Harry Wentland: >>> >>> I realize this is raising a lot of concern. I was concerned myself >>> when I first saw this. Beside calling kernel_fpu_begin() and >>> kernel_fpu_end() are there other things to watch out for? >> >> Yeah, especially setting "-msse" is rather questionable. As far as I >> know on 64bit systems it is the default, but on 32bit systems that >> could silently break some assumptions. >> >> Additional to that as far as I know "-msse" is just for optimization >> and that isn't performance critical code, so why exactly do we need it? > > Once we enable multi-plane code this code becomes performance critical > as I believe it gets executed when resizing an underlay surface, such as > a video player. That should still only happen once per frame though, i.e. on the order of 10s to 100s of times per second. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-05-24 1:09 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-05-19 14:01 [PATCH] drm/amd/display: Limit DCN to x86 arch Harry Wentland [not found] ` <20170519140121.14296-1-harry.wentland-5C7GfCeVMHo@public.gmane.org> 2017-05-19 14:54 ` Lazare, Jordan 2017-05-19 15:02 ` Christian König [not found] ` <f84c51b6-06f1-b4d2-c472-89265ebb26cb-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org> 2017-05-19 19:36 ` Harry Wentland [not found] ` <7a8b84af-38f7-33d2-5bbb-473f2ea35bb2-5C7GfCeVMHo@public.gmane.org> 2017-05-19 20:18 ` Dave Airlie [not found] ` <CAPM=9tzcA8t-ji6qNQhycB0cezz2vH6HMixCgvKQ78cY1Y8fsA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2017-05-19 20:28 ` Harry Wentland [not found] ` <4e0c342b-d18e-5f7a-bd30-9becd0e97e3c-5C7GfCeVMHo@public.gmane.org> 2017-05-20 8:13 ` Christian König [not found] ` <013f44e3-1734-43f8-4cd7-e950ffb014f0-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org> 2017-05-23 13:37 ` Harry Wentland [not found] ` <ff8918ec-ee0e-692e-4ada-cd6bd939d902-5C7GfCeVMHo@public.gmane.org> 2017-05-23 14:57 ` Felix Kuehling 2017-05-24 1:09 ` Michel Dänzer
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.