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