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

[Matt Turner]

On Tue, Jul 29, 2014 at 5:02 PM, Emil Velikov <emil.l.velikov at 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.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.

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.