[Mesa-stable] [PATCH 21/29] mesa: stop going behind the user's back wrt sse4.1 optimisations

Emil Velikov emil.l.velikov at gmail.com
Tue Jul 29 17:02:28 PDT 2014


On 30/07/14 00:24, Matt Turner wrote:
> On Tue, Jul 29, 2014 at 3:54 PM, Emil Velikov <emil.l.velikov at 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









More information about the mesa-stable mailing list