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

From: "Christian König" <deathsimple-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
To: Harry Wentland <harry.wentland-5C7GfCeVMHo@public.gmane.org>,
	Dave Airlie <airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "Michel Dänzer" <michel.daenzer-5C7GfCeVMHo@public.gmane.org>,
	"amd-gfx mailing list"
	<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	"Dmytro Laktyushkin"
	<Dmytro.Laktyushkin-5C7GfCeVMHo@public.gmane.org>,
	"Alex Deucher" <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>,
	"Tony Cheng" <Tony.Cheng-5C7GfCeVMHo@public.gmane.org>,
	"Christian König" <christian.koenig-5C7GfCeVMHo@public.gmane.org>
Subject: Re: [PATCH] drm/amd/display: Limit DCN to x86 arch
Date: Sat, 20 May 2017 10:13:33 +0200	[thread overview]
Message-ID: <013f44e3-1734-43f8-4cd7-e950ffb014f0@vodafone.de> (raw)
In-Reply-To: <4e0c342b-d18e-5f7a-bd30-9becd0e97e3c-5C7GfCeVMHo@public.gmane.org>

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