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