Am 04.11.2016 um 04:24 schrieb Rowley, Timothy O:
>
>> On Nov 3, 2016, at 7:09 PM, Roland Scheidegger <srol...@vmware.com> wrote:
>>
>> I'm a bit worried by this.
>> We've had some (a lot actually) unpleasant surprises in the past with
>> llvm choosing to use instruction sets not appropriate for a given cpu...
>> Hence only setting flags we checked ourselves being available, and
>> disabling everything else. Not sure if this actually still works though
>> given we set the host cpu name…
>
> I’ve experienced the fragility of just using the host cpu name in llvm,
> though I thought it usually fails in the conservative direction. Doing a
> little googling I see there was recently a bit of a hiccup with skylake
> accidentally using evex encoding.
Well that's not the first one for sure.
Based on experience, there is roughly a 100% probability (I think maybe
slightly more than that even...) that we'll hit some bug again with some
future llvm version and some future cpus... I don't trust llvm one bit
there, sorry. (Albeit we've lost there in any case, since we can't
disable features we don't know about.)
>> We do not want llvm to use evex encoded instructions (with any bit
>> width) for llvmpipe at this point on "ordinary" x86 cpus (I'm
>> specifically thinking about normal, albeit future, xeons, like
>> skylake-ep), as that would be a completely untested path (albeit, as I
>> said, I'm not even sure the current code actually really prevents
>> that...) - well I suppose you tested it with KNL, which is good to know.
>> Enabling it on KNL is fair enough I suppose, but I'm not sure if you can
>> detect such cpus easily based on feature, do they lack something which
>> the normal cpus have? I guess though since it's otherwise only mattering
>> for not yet released cpus we could still fix it up later if necessary…
>
> KNL could be detected by looking for the processor family, but that would
> prevent future avx512 processors from just working. What would you think of
> replacing the manually maintained list of mattr overrides for x86 with some
> code that just uses what getHostCPUFeatures (based on cpuid) returns?
> Something like this:
>
> #if defined(PIPE_ARCH_X86) || defined(PIPE_ARCH_X86_64)
> llvm::StringMap<bool> features;
> llvm::sys::getHostCPUFeatures(features);
>
> for (StringMapIterator<bool> f = features.begin(); f != features.end();
> ++f) {
> MAttrs.push_back(((*f).second ? "+" : "-") + (*f).first().str());
> }
> #endif
Doesn't sound too bad. I still don't like the idea of enabling evex
encoding if we're only going to use 256bit vectors without some real
testing, though...
But I don't really have a much better idea, if you restrict the above to
3.9+... Can always introduce some env disabling it I suppose if needed
later...
Roland
> -Tim
>
>> Roland
>>
>> Am 03.11.2016 um 22:29 schrieb Tim Rowley:
>>> ---
>>> src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
>>> b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
>>> index bd4d4d3..bff2198 100644
>>> --- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
>>> +++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
>>> @@ -583,6 +583,8 @@
>>> lp_build_create_jit_compiler_for_module(LLVMExecutionEngineRef *OutJIT,
>>> MAttrs.push_back("-fma");
>>> }
>>> MAttrs.push_back(util_cpu_caps.has_avx2 ? "+avx2" : "-avx2");
>>> +
>>> +#if HAVE_LLVM <= 0x0308
>>> /* disable avx512 and all subvariants */
>>> #if HAVE_LLVM >= 0x0304
>>> MAttrs.push_back("-avx512cd");
>>> @@ -596,6 +598,7 @@
>>> lp_build_create_jit_compiler_for_module(LLVMExecutionEngineRef *OutJIT,
>>> MAttrs.push_back("-avx512vl");
>>> #endif
>>> #endif
>>> +#endif
>>>
>>> #if defined(PIPE_ARCH_PPC)
>>> MAttrs.push_back(util_cpu_caps.has_altivec ? "+altivec" : "-altivec");
>>>
>>
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
