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