[PATCH] drm/amd/display: Limit DCN to x86 arch

[PATCH] drm/amd/display: Limit DCN to x86 arch

[Harry Wentland]

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

RE: [PATCH] drm/amd/display: Limit DCN to x86 arch

[Lazare, Jordan]

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

Re: [PATCH] drm/amd/display: Limit DCN to x86 arch

[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

Re: [PATCH] drm/amd/display: Limit DCN to x86 arch

[Harry Wentland]

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

Re: [PATCH] drm/amd/display: Limit DCN to x86 arch

[Dave Airlie]

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

Re: [PATCH] drm/amd/display: Limit DCN to x86 arch

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

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

Re: [PATCH] drm/amd/display: Limit DCN to x86 arch

[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

Re: [PATCH] drm/amd/display: Limit DCN to x86 arch

[Harry Wentland]

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

Re: [PATCH] drm/amd/display: Limit DCN to x86 arch

[Felix Kuehling]

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

Re: [PATCH] drm/amd/display: Limit DCN to x86 arch

[Michel Dänzer]

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