On Tue, Jul 29, 2014 at 5:02 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 30/07/14 00:24, Matt Turner wrote: >> On Tue, Jul 29, 2014 at 3:54 PM, Emil Velikov <emil.l.veli...@gmail.com> >> wrote: >>> If the user/builder has a setup capable of using sse4.1 it's their >>> responsibility to enable it. >>> >>> Let's unconditionally include main/streaming-load-memcpy.c, as it >>> already features a ifdef __SSE4_1__ check and add a stub implementation >>> for people that don't have -msse4.1 enabled at compile-time. >>> >>> This resolves undefined references to _mesa_streaming_load_memcpy for >>> the Android build and compilers not capable of sse4.1 optimizations. >>> >>> Note: if your compiler is capable of -msse4.1 and you are interested >>> in using such optimisations, enable them explicitly. >> >> The reason we build this file with -msse4.1 explicitly is because >> distributions build things for the lowest common denominator but we >> still want this code to be enabled (via a runtime check for SSE 4.1). >> >> If we do this, distributions building with typical CFLAGS won't get >> this optimization. That's not what we want. >> >> What's the problem with the current solution -- that the Android build >> system doesn't let you build this file with -msse4.1? >> > IMHO going behind the back of someone like that and toggling compiler > optimisations is a slight nuisance, but I would not feel to strong about this > either way.
This is a really common thing that a lot of projects do. How else can you offer runtime-enabled fast paths? I don't think you're fully appreciating the problem. > The problem: > Server/buildbot builds without -msse4.1 while the user's machine is capable. > As such we'll end up calling _mesa_streaming_load_memcpy which is undefined > and... How about we unconditionally include the file(s) so that the function > becomes a no-op, rather than blowing up ? Right, okay. This looks like a problem for autotools builds too, if your compiler is old enough to not support -msse4.1. pixman, for instance, uses AC_DEFINE to define macros like USE_X86_MMX, and then the code that calls the MMX code is wrapped in an #ifdef USE_X86_MMX. I suppose that's what we should do, and then wrap the functions in intel_mipmap_tree.c so we can't have undefined references. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
