[Mesa-dev] llvmpipe broken on Skylake Pentium (LP_NATIVE_VECTOR_WIDTH=128)

[Roland Scheidegger]

Am 12.10.2015 um 22:47 schrieb Adam Jackson:
> On Mon, 2015-10-12 at 21:57 +0200, Roland Scheidegger wrote:
> 
>> Note that the vector width doesn't really control if avx is used or not,
>> since that's a decision which llvm does on its own (we do set it
>> manually if we detect avx on our own, but llvm will use avx anyway even
>> if we don't if it thinks the cpu supports it with newer llvm versions),
>> albeit it would be possible to override this (but this changed
>> significantly between llvm versions).
> 
> I don't care about AVX working, really.  It might be nice to have but
> the performance benefit isn't all that impressive for gnome-shell-like
> workloads, and a non-functional desktop is a framerate of 0 so
> literally anything would be an improvement.
> 
> I patched X86.td in llvm to clamp Skylake at SSE4.2 [1], but it doesn't
> help.  More to the point the instructions I'm dying on here aren't AVX
> to begin with, the intrinsics we're emitting are SSE4.1 and I would
> have hoped llvm could break v4i32 apart on its own.  
> 
>> You could give lp_build_create_jit_compiler_for_module() a look, in
>> particular builder.setMCPU(MCPU) and related stuff. I believe if you've
>> got a core i5 haswell there or something similar (by
>> llvm::sys::getHostCPUName()), it will then try to use avx, regardless if
>> the avx flag is present or not. This means that theoretically we should
>> probably mask off the not supported bits manually somehow, so they
>> aren't automatically derived from the cpu type set there (or set a
>> different cpu name, but we'd need to bend over backwards to derive the
>> correct type). The mechanism to do so seems kind of "meh" for jit code...
> 
> I don't think getHostCPUName is the droid I'm looking for:
> 
> Breakpoint 1, llvm::sys::getHostCPUName () at Host.cpp:218
> 218	StringRef sys::getHostCPUName() {
> (gdb) finish
> Run till exit from #0  llvm::sys::getHostCPUName () at Host.cpp:218
> 0x00007ffff260e193 in lp_build_create_jit_compiler_for_module (OutJIT=OutJIT at entry=0x8defe8, 
>     OutCode=OutCode at entry=0x8df018, M=<optimized out>, CMM=0x8d52c0, OptLevel=<optimized out>, 
>     useMCJIT=useMCJIT at entry=1, OutError=OutError at entry=0x7fffffffd300) at gallivm/lp_bld_misc.cpp:480
> 480	   StringRef MCPU = llvm::sys::getHostCPUName();
> Value returned is $1 = {static npos = 18446744073709551615, Data = 0x7ffff16ab9f8 "x86-64", Length = 6}
> 
> [1] - https://urldefense.proofpoint.com/v2/url?u=https-3A__ajax.fedorapeople.org_llvm-2D3.6.2-2Dnerf-2Dskylake.patch&d=BQICaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=mjLjvWAlk0sncHrrendtvN-UMPLGuEItVZeH-JvVZEE&s=9kW7THjmJXnhAaMTgXRf5tPYJsJ06MEkoifHL_XrbJo&e= 
> 
> - ajax
> 

I don't know that looks like a generic string you're getting back.
x86-64 IIRC implies sse2 in llvm, but not the other sseX flags (and if
we detected sse41 we're going to use intrinsics for these, which then
may not be available in llvm _potentially_ (I'm really not sure here as
this code changed, and mesa generally is only adapted to such changes
once it breaks..., but the string here will be something less generic
like "ivybridge" usually on real hw).

Roland