[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 at 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 at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> 
>