On 2017-05-19 04:18 PM, Dave Airlie wrote:
On 20 May 2017 at 05:36, Harry Wentland <[email protected]> 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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
