On Mon, 2014-11-03 at 20:39 +1100, Timothy Arceri wrote: > On Fri, 2014-10-31 at 17:24 +0000, Jose Fonseca wrote: > > On 31/10/14 17:01, Matt Turner wrote: > > > On Fri, Oct 31, 2014 at 4:12 AM, Jose Fonseca <jfons...@vmware.com> wrote: > > >> On 31/10/14 10:13, Juha-Pekka Heikkila wrote: > > >>> > > >>> defined(__SSE2__) && defined(__GNUC__) > > >> > > >> > > >> Instead of duplicate this expression everywhere lets create a > > >> "HAVE_SSE2_INTRIN" define. Not only this expression is complex, it will > > >> become even more when we updated it for MSVC. > > > > > > Isn't testing __SSE2__ sufficient? Does MSVC not do this? > > > > > > clang/icc/gcc all implement this and all of the _mm_* intrinsics. > > > > > > > No, __SSE2__ is a GCC-only macro. It's not defined or needed by MSVC > > compilers. And I strongly suspect that Intel compiler probably only > > defines it for GCC compatibility. > > > > > > This is because GCC is quite lame IMO: it can't distinguish between > > "enabling SSE intrinsics" (ie, allow including emmintrin.h and use the > > Intel _mm_* instrincis) and emitting SSE2 opcodes own its own accord. > > That is, when you pass -msse2 to GCC, you're also giving carte blache > > for GCC to emit SSE2 opcodes for any C code! Which makes it _very_ hard > > to have special code paths for SSE1/2/3/4/etc and no SSE. Since you > > basically need to compile each path in a different C module, passing > > different -msse* flags to each. > > So does anyone have a suggestion how this can be better organised? As in > should there be an SSE folder somewhere? > > Currently streaming-load-memcpy.c is in mesa/main even though its only > used by the intel driver, also my patch adds another file there and I've > also noticed this [1] which should be made to use a runtime switch too. > > Dumping everything in Mesa main would obviously get messy fast. > > [1] > http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/i965/intel_tex_subimage.c#n199
Hi, FWIW, my opinion is that maybe we should move this kind of code to utils/sse or something like that. After all, this is some utility code that could be used anywhere. - Bruno > > > > > > Whereas on MSVC, you can #include emmintrin any time, any where, and > > only the code that uses the intrinsics will generate those opcodes. So > > you can have a awesomeFuncionC(), awesomeFunctionSSE2(), > > awesomeFunctionAVX() all next to each other, and a switch table to jump > > into them. > > > > > > In other words, on MSVC, instead of > > > > #if defined(__SSE2__) && defined(__GNUC__) > > > > all you need is > > > > #if 1 > > > > or > > > > #if defined(_M_IX86) || defined(_M_X64) > > > > if you want the code not to cause problems when targetting non-x86 > > architectures. > > > > > > > > Of course there's some merit in GCC emiting SSE instructions for plain C > > code, but let's face it: virtually all the code that can benefit from > > SIMD is too complex to be auto-vectorized by compilers, and need humans > > writing code with SSE intrincs. So GCC is effectively tailored to make > > the rare thing easy, at the expense of making the common thing hard... > > > > > > I believe recent GCC versions have better support for having specialized > > SSE code side-by-side. But from what I remember of it, is all pretty > > non-standard and GCC specific, so still pretty useless for portable code. > > > > > > Jose > > _______________________________________________ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
