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. I have them enabled all the time :) That is as long as we fix the issue mentioned below.
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 ? -Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
