Re: [Mesa-dev] [PATCH 1/4] meson: Enable SSE4.1 optimizations

[Emil Velikov]

On 20 November 2017 at 18:02, Matt Turner  wrote:
> On Mon, Nov 20, 2017 at 3:47 AM, Emil Velikov  
> wrote:
>> On 17 November 2017 at 20:46, Matt Turner  wrote:
>>> On Fri, Nov 17, 2017 at 12:34 PM, Dylan Baker  wrote:
 Quoting Emil Velikov (2017-11-17 03:11:50)
> On 16 November 2017 at 22:21, Dylan Baker  wrote:
> > Quoting Emil Velikov (2017-11-16 03:35:17)
> >> Hi Dylan,
> >>
> >> On 16 November 2017 at 01:10, Dylan Baker  wrote:
> >> > This patch checks for an and then enables sse4.1 optimizations if the
> >> > host machine will be x86/x86_64.
> >> >
> >> Hell yeah, SSE is coming to town :-)
> >>
> >> Will this work if the user disables SSE4.1, say via CFLAGS=-mno-sse4.1
> >> meson ...?
> >> My meson is still bit rough, so I could not quite grok ^^ by reading
> >> through the patch.
> >>
> >> Thanks
> >> Emil
> >
> > It'll explode horribly. Id didn't see any special handling of that in 
> > autotools
> > build though either, did I miss something?
> >
> In autotools it's handled before the normal ld invocation.
>
> Namely: configure.ac does:
>  - construct a program using sse4.1 intrinsicts
> Note: return _mm_...() is required otherwise the whole program will be
> optimised away
>  - the -msse is passed first and then the user flags (-mno-sse and/or
> anything else)
>  - the user -mno-sse takes precedence, hence the test program fails to 
> build
>  - set see_supported=false and don't build the SSE optimised static 
> library
>
> HTH
> Emil

 That's an interesting question. So arguments passed via CFLAGS and friends 
 will
 be passed to tests, but the arguments passed explicitly to those tests are
 appended, so -msse4.1 will take precedence. I'm also pretty sure there 
 isn't a
 way to check the arguments passed via -Dc_args or CFLAGS (they're treated 
 as
 default arguments, like the c_std in the project() argument). I asked on
 #mesonbuild, but I haven't gotten an answer yet (Fridays are pretty slow
 everywhere).

 I think currently the only way to control this would be to have a meson 
 option
 to turn off optimizations, and I really don't like that.
>>>
>>> The original bug report of "Mesa doesn't build with -mno-sse4.1" was
>>> in Gentoo's bugzilla; https://bugs.gentoo.org/503828
>>>
>>> There's no compelling reason to support that configuration because
>>> since the -msseX flags are off by default... in order for the
>>> -mno-sseX flag to do anything the user must be enabling them somehow
>>> (likely via -march=...). Using -march=... only to disable particular
>>> instruction sets seems pretty idiotic.
>>>
>> I'm confused - it isn't the user but Mesa's build system which enables
>> -msseX, right?
>> Using -msseX is a good thing, but if the binary produced causes bugs
>> the builder/user has no way to disable it.
>
> There are two cases: code enabled at compile-time and code enabled at runtime.
>
> At compile-time we choose either the SSE2 or SSSE3 paths in
> src/mesa/drivers/dri/i965/intel_tiled_memcpy.c, based only on whether
> the compiler is enabled to use those instruction sets. If -mssse3 or
> some -march=... value is specified that enables SSSE3, then the SSSE3
> code will be enabled. Otherwise the SSE2 code is enabled (even on
> 32-bit systems since we always add -msse2 to CFLAGS in i965's
> Makefile.am).
>
> At runtime, we choose whether to execute
> src/mesa/main/streaming-load-memcpy.c based on whether the CPU
> supports the SSE 4.1 instruction set. It's safe (and good!) to always
> build the code. It won't be executed unless supported.
>
> The problem is that in order to build it, we have to tell the compiler
> it's okay to use SSE 4.1 instructions. Think of Debian for instance.
> They want to ship builds that will run on the oldest AMD64 system
> (without SSE 4.1) but would also like the code to exist and be
> executed where possible. As a result we need to build just that source
> file with -msse4.1. Again, this is safe because we have code that
> checks the CPU's capabilities at runtime and decides whether its safe
> to execute it.
>
In case I wasn't clear earlier - I fully support adding optimised hot paths.


> Now, a clever user specifies -mno-sse4.1. This throws a wrench into
> the system. Depending on the order the CFLAGS appear, the check of
> "does my compiler support emitting SSE 4.1 instructions" will succeed
> or fail.
>
> The reasons users in the bug [1] seem to be using -mno-sse4.1 are (1)
> no reason, using *all* the CFLAGS; (2) building packages on a system
> with SSE 4.1 for a system without (i.e., using the wrong -march= value
> and trying to compensate); (3) using -march=native with distcc, which
> cannot work. All of these are 

Re: [Mesa-dev] [PATCH 1/4] meson: Enable SSE4.1 optimizations

[Matt Turner]

On Mon, Nov 20, 2017 at 3:47 AM, Emil Velikov  wrote:
> On 17 November 2017 at 20:46, Matt Turner  wrote:
>> On Fri, Nov 17, 2017 at 12:34 PM, Dylan Baker  wrote:
>>> Quoting Emil Velikov (2017-11-17 03:11:50)
 On 16 November 2017 at 22:21, Dylan Baker  wrote:
 > Quoting Emil Velikov (2017-11-16 03:35:17)
 >> Hi Dylan,
 >>
 >> On 16 November 2017 at 01:10, Dylan Baker  wrote:
 >> > This patch checks for an and then enables sse4.1 optimizations if the
 >> > host machine will be x86/x86_64.
 >> >
 >> Hell yeah, SSE is coming to town :-)
 >>
 >> Will this work if the user disables SSE4.1, say via CFLAGS=-mno-sse4.1
 >> meson ...?
 >> My meson is still bit rough, so I could not quite grok ^^ by reading
 >> through the patch.
 >>
 >> Thanks
 >> Emil
 >
 > It'll explode horribly. Id didn't see any special handling of that in 
 > autotools
 > build though either, did I miss something?
 >
 In autotools it's handled before the normal ld invocation.

 Namely: configure.ac does:
  - construct a program using sse4.1 intrinsicts
 Note: return _mm_...() is required otherwise the whole program will be
 optimised away
  - the -msse is passed first and then the user flags (-mno-sse and/or
 anything else)
  - the user -mno-sse takes precedence, hence the test program fails to 
 build
  - set see_supported=false and don't build the SSE optimised static library

 HTH
 Emil
>>>
>>> That's an interesting question. So arguments passed via CFLAGS and friends 
>>> will
>>> be passed to tests, but the arguments passed explicitly to those tests are
>>> appended, so -msse4.1 will take precedence. I'm also pretty sure there 
>>> isn't a
>>> way to check the arguments passed via -Dc_args or CFLAGS (they're treated as
>>> default arguments, like the c_std in the project() argument). I asked on
>>> #mesonbuild, but I haven't gotten an answer yet (Fridays are pretty slow
>>> everywhere).
>>>
>>> I think currently the only way to control this would be to have a meson 
>>> option
>>> to turn off optimizations, and I really don't like that.
>>
>> The original bug report of "Mesa doesn't build with -mno-sse4.1" was
>> in Gentoo's bugzilla; https://bugs.gentoo.org/503828
>>
>> There's no compelling reason to support that configuration because
>> since the -msseX flags are off by default... in order for the
>> -mno-sseX flag to do anything the user must be enabling them somehow
>> (likely via -march=...). Using -march=... only to disable particular
>> instruction sets seems pretty idiotic.
>>
> I'm confused - it isn't the user but Mesa's build system which enables
> -msseX, right?
> Using -msseX is a good thing, but if the binary produced causes bugs
> the builder/user has no way to disable it.

There are two cases: code enabled at compile-time and code enabled at runtime.

At compile-time we choose either the SSE2 or SSSE3 paths in
src/mesa/drivers/dri/i965/intel_tiled_memcpy.c, based only on whether
the compiler is enabled to use those instruction sets. If -mssse3 or
some -march=... value is specified that enables SSSE3, then the SSSE3
code will be enabled. Otherwise the SSE2 code is enabled (even on
32-bit systems since we always add -msse2 to CFLAGS in i965's
Makefile.am).

At runtime, we choose whether to execute
src/mesa/main/streaming-load-memcpy.c based on whether the CPU
supports the SSE 4.1 instruction set. It's safe (and good!) to always
build the code. It won't be executed unless supported.

The problem is that in order to build it, we have to tell the compiler
it's okay to use SSE 4.1 instructions. Think of Debian for instance.
They want to ship builds that will run on the oldest AMD64 system
(without SSE 4.1) but would also like the code to exist and be
executed where possible. As a result we need to build just that source
file with -msse4.1. Again, this is safe because we have code that
checks the CPU's capabilities at runtime and decides whether its safe
to execute it.

Now, a clever user specifies -mno-sse4.1. This throws a wrench into
the system. Depending on the order the CFLAGS appear, the check of
"does my compiler support emitting SSE 4.1 instructions" will succeed
or fail.

The reasons users in the bug [1] seem to be using -mno-sse4.1 are (1)
no reason, using *all* the CFLAGS; (2) building packages on a system
with SSE 4.1 for a system without (i.e., using the wrong -march= value
and trying to compensate); (3) using -march=native with distcc, which
cannot work. All of these are misuses.

To your question of "what if users need a way to disable the code
because of bugs?": Sorry, that's absurd. CFLAGS aren't a solution to
bugs. Also, the code just had its fourth birthday and the only bugs
have been build system madness (like [1]).

[1] https://bugs.gentoo.org/503828

Re: [Mesa-dev] [PATCH 1/4] meson: Enable SSE4.1 optimizations

[Emil Velikov]

On 17 November 2017 at 20:46, Matt Turner  wrote:
> On Fri, Nov 17, 2017 at 12:34 PM, Dylan Baker  wrote:
>> Quoting Emil Velikov (2017-11-17 03:11:50)
>>> On 16 November 2017 at 22:21, Dylan Baker  wrote:
>>> > Quoting Emil Velikov (2017-11-16 03:35:17)
>>> >> Hi Dylan,
>>> >>
>>> >> On 16 November 2017 at 01:10, Dylan Baker  wrote:
>>> >> > This patch checks for an and then enables sse4.1 optimizations if the
>>> >> > host machine will be x86/x86_64.
>>> >> >
>>> >> Hell yeah, SSE is coming to town :-)
>>> >>
>>> >> Will this work if the user disables SSE4.1, say via CFLAGS=-mno-sse4.1
>>> >> meson ...?
>>> >> My meson is still bit rough, so I could not quite grok ^^ by reading
>>> >> through the patch.
>>> >>
>>> >> Thanks
>>> >> Emil
>>> >
>>> > It'll explode horribly. Id didn't see any special handling of that in 
>>> > autotools
>>> > build though either, did I miss something?
>>> >
>>> In autotools it's handled before the normal ld invocation.
>>>
>>> Namely: configure.ac does:
>>>  - construct a program using sse4.1 intrinsicts
>>> Note: return _mm_...() is required otherwise the whole program will be
>>> optimised away
>>>  - the -msse is passed first and then the user flags (-mno-sse and/or
>>> anything else)
>>>  - the user -mno-sse takes precedence, hence the test program fails to build
>>>  - set see_supported=false and don't build the SSE optimised static library
>>>
>>> HTH
>>> Emil
>>
>> That's an interesting question. So arguments passed via CFLAGS and friends 
>> will
>> be passed to tests, but the arguments passed explicitly to those tests are
>> appended, so -msse4.1 will take precedence. I'm also pretty sure there isn't 
>> a
>> way to check the arguments passed via -Dc_args or CFLAGS (they're treated as
>> default arguments, like the c_std in the project() argument). I asked on
>> #mesonbuild, but I haven't gotten an answer yet (Fridays are pretty slow
>> everywhere).
>>
>> I think currently the only way to control this would be to have a meson 
>> option
>> to turn off optimizations, and I really don't like that.
>
> The original bug report of "Mesa doesn't build with -mno-sse4.1" was
> in Gentoo's bugzilla; https://bugs.gentoo.org/503828
>
> There's no compelling reason to support that configuration because
> since the -msseX flags are off by default... in order for the
> -mno-sseX flag to do anything the user must be enabling them somehow
> (likely via -march=...). Using -march=... only to disable particular
> instruction sets seems pretty idiotic.
>
I'm confused - it isn't the user but Mesa's build system which enables
-msseX, right?
Using -msseX is a good thing, but if the binary produced causes bugs
the builder/user has no way to disable it.

Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] meson: Enable SSE4.1 optimizations

[Eric Engestrom]

On Friday, 2017-11-17 12:34:12 -0800, Dylan Baker wrote:
> Quoting Emil Velikov (2017-11-17 03:11:50)
> > On 16 November 2017 at 22:21, Dylan Baker  wrote:
> > > Quoting Emil Velikov (2017-11-16 03:35:17)
> > >> Hi Dylan,
> > >>
> > >> On 16 November 2017 at 01:10, Dylan Baker  wrote:
> > >> > This patch checks for an and then enables sse4.1 optimizations if the
> > >> > host machine will be x86/x86_64.
> > >> >
> > >> Hell yeah, SSE is coming to town :-)
> > >>
> > >> Will this work if the user disables SSE4.1, say via CFLAGS=-mno-sse4.1
> > >> meson ...?
> > >> My meson is still bit rough, so I could not quite grok ^^ by reading
> > >> through the patch.
> > >>
> > >> Thanks
> > >> Emil
> > >
> > > It'll explode horribly. Id didn't see any special handling of that in 
> > > autotools
> > > build though either, did I miss something?
> > >
> > In autotools it's handled before the normal ld invocation.
> > 
> > Namely: configure.ac does:
> >  - construct a program using sse4.1 intrinsicts
> > Note: return _mm_...() is required otherwise the whole program will be
> > optimised away
> >  - the -msse is passed first and then the user flags (-mno-sse and/or
> > anything else)
> >  - the user -mno-sse takes precedence, hence the test program fails to build
> >  - set see_supported=false and don't build the SSE optimised static library
> > 
> > HTH
> > Emil
> 
> That's an interesting question. So arguments passed via CFLAGS and friends 
> will
> be passed to tests, but the arguments passed explicitly to those tests are
> appended, so -msse4.1 will take precedence. I'm also pretty sure there isn't a
> way to check the arguments passed via -Dc_args or CFLAGS (they're treated as
> default arguments, like the c_std in the project() argument). I asked on
> #mesonbuild, but I haven't gotten an answer yet (Fridays are pretty slow
> everywhere).

I asked that already a little while ago, about if there was a way to get
any -O passed in in any of the cflags inputs, and the answer was that
no, you can't and you shouldn't have behaviour based on cflags set at
any time, so I don't expect they will ever add this functionality.

One thing they might do though, is parse all the cflags and print
a warning if both `-foo` and `-nofoo` are present, so that might be
something to suggest.

> 
> I think currently the only way to control this would be to have a meson option
> to turn off optimizations, and I really don't like that.
> 
> Dylan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] meson: Enable SSE4.1 optimizations

[Dylan Baker]

Quoting Matt Turner (2017-11-17 12:46:03)
> On Fri, Nov 17, 2017 at 12:34 PM, Dylan Baker  wrote:
> > Quoting Emil Velikov (2017-11-17 03:11:50)
> >> On 16 November 2017 at 22:21, Dylan Baker  wrote:
> >> > Quoting Emil Velikov (2017-11-16 03:35:17)
> >> >> Hi Dylan,
> >> >>
> >> >> On 16 November 2017 at 01:10, Dylan Baker  wrote:
> >> >> > This patch checks for an and then enables sse4.1 optimizations if the
> >> >> > host machine will be x86/x86_64.
> >> >> >
> >> >> Hell yeah, SSE is coming to town :-)
> >> >>
> >> >> Will this work if the user disables SSE4.1, say via CFLAGS=-mno-sse4.1
> >> >> meson ...?
> >> >> My meson is still bit rough, so I could not quite grok ^^ by reading
> >> >> through the patch.
> >> >>
> >> >> Thanks
> >> >> Emil
> >> >
> >> > It'll explode horribly. Id didn't see any special handling of that in 
> >> > autotools
> >> > build though either, did I miss something?
> >> >
> >> In autotools it's handled before the normal ld invocation.
> >>
> >> Namely: configure.ac does:
> >>  - construct a program using sse4.1 intrinsicts
> >> Note: return _mm_...() is required otherwise the whole program will be
> >> optimised away
> >>  - the -msse is passed first and then the user flags (-mno-sse and/or
> >> anything else)
> >>  - the user -mno-sse takes precedence, hence the test program fails to 
> >> build
> >>  - set see_supported=false and don't build the SSE optimised static library
> >>
> >> HTH
> >> Emil
> >
> > That's an interesting question. So arguments passed via CFLAGS and friends 
> > will
> > be passed to tests, but the arguments passed explicitly to those tests are
> > appended, so -msse4.1 will take precedence. I'm also pretty sure there 
> > isn't a
> > way to check the arguments passed via -Dc_args or CFLAGS (they're treated as
> > default arguments, like the c_std in the project() argument). I asked on
> > #mesonbuild, but I haven't gotten an answer yet (Fridays are pretty slow
> > everywhere).
> >
> > I think currently the only way to control this would be to have a meson 
> > option
> > to turn off optimizations, and I really don't like that.
> 
> The original bug report of "Mesa doesn't build with -mno-sse4.1" was
> in Gentoo's bugzilla; https://bugs.gentoo.org/503828
> 
> There's no compelling reason to support that configuration because
> since the -msseX flags are off by default... in order for the
> -mno-sseX flag to do anything the user must be enabling them somehow
> (likely via -march=...). Using -march=... only to disable particular
> instruction sets seems pretty idiotic.
> 
> I can push back harder on such stupidity in the future if we can't
> handle this case, but it would be nice to solve so I never have to
> hear about it again.

Hmmm, yeah. I'd also like to be able to provide an error in that case too,
because I agree it's pretty idiotic. I'll bring it up in the meson bug tracker.


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] meson: Enable SSE4.1 optimizations

[Matt Turner]

On Fri, Nov 17, 2017 at 12:34 PM, Dylan Baker  wrote:
> Quoting Emil Velikov (2017-11-17 03:11:50)
>> On 16 November 2017 at 22:21, Dylan Baker  wrote:
>> > Quoting Emil Velikov (2017-11-16 03:35:17)
>> >> Hi Dylan,
>> >>
>> >> On 16 November 2017 at 01:10, Dylan Baker  wrote:
>> >> > This patch checks for an and then enables sse4.1 optimizations if the
>> >> > host machine will be x86/x86_64.
>> >> >
>> >> Hell yeah, SSE is coming to town :-)
>> >>
>> >> Will this work if the user disables SSE4.1, say via CFLAGS=-mno-sse4.1
>> >> meson ...?
>> >> My meson is still bit rough, so I could not quite grok ^^ by reading
>> >> through the patch.
>> >>
>> >> Thanks
>> >> Emil
>> >
>> > It'll explode horribly. Id didn't see any special handling of that in 
>> > autotools
>> > build though either, did I miss something?
>> >
>> In autotools it's handled before the normal ld invocation.
>>
>> Namely: configure.ac does:
>>  - construct a program using sse4.1 intrinsicts
>> Note: return _mm_...() is required otherwise the whole program will be
>> optimised away
>>  - the -msse is passed first and then the user flags (-mno-sse and/or
>> anything else)
>>  - the user -mno-sse takes precedence, hence the test program fails to build
>>  - set see_supported=false and don't build the SSE optimised static library
>>
>> HTH
>> Emil
>
> That's an interesting question. So arguments passed via CFLAGS and friends 
> will
> be passed to tests, but the arguments passed explicitly to those tests are
> appended, so -msse4.1 will take precedence. I'm also pretty sure there isn't a
> way to check the arguments passed via -Dc_args or CFLAGS (they're treated as
> default arguments, like the c_std in the project() argument). I asked on
> #mesonbuild, but I haven't gotten an answer yet (Fridays are pretty slow
> everywhere).
>
> I think currently the only way to control this would be to have a meson option
> to turn off optimizations, and I really don't like that.

The original bug report of "Mesa doesn't build with -mno-sse4.1" was
in Gentoo's bugzilla; https://bugs.gentoo.org/503828

There's no compelling reason to support that configuration because
since the -msseX flags are off by default... in order for the
-mno-sseX flag to do anything the user must be enabling them somehow
(likely via -march=...). Using -march=... only to disable particular
instruction sets seems pretty idiotic.

I can push back harder on such stupidity in the future if we can't
handle this case, but it would be nice to solve so I never have to
hear about it again.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] meson: Enable SSE4.1 optimizations

[Dylan Baker]

Quoting Emil Velikov (2017-11-17 03:11:50)
> On 16 November 2017 at 22:21, Dylan Baker  wrote:
> > Quoting Emil Velikov (2017-11-16 03:35:17)
> >> Hi Dylan,
> >>
> >> On 16 November 2017 at 01:10, Dylan Baker  wrote:
> >> > This patch checks for an and then enables sse4.1 optimizations if the
> >> > host machine will be x86/x86_64.
> >> >
> >> Hell yeah, SSE is coming to town :-)
> >>
> >> Will this work if the user disables SSE4.1, say via CFLAGS=-mno-sse4.1
> >> meson ...?
> >> My meson is still bit rough, so I could not quite grok ^^ by reading
> >> through the patch.
> >>
> >> Thanks
> >> Emil
> >
> > It'll explode horribly. Id didn't see any special handling of that in 
> > autotools
> > build though either, did I miss something?
> >
> In autotools it's handled before the normal ld invocation.
> 
> Namely: configure.ac does:
>  - construct a program using sse4.1 intrinsicts
> Note: return _mm_...() is required otherwise the whole program will be
> optimised away
>  - the -msse is passed first and then the user flags (-mno-sse and/or
> anything else)
>  - the user -mno-sse takes precedence, hence the test program fails to build
>  - set see_supported=false and don't build the SSE optimised static library
> 
> HTH
> Emil

That's an interesting question. So arguments passed via CFLAGS and friends will
be passed to tests, but the arguments passed explicitly to those tests are
appended, so -msse4.1 will take precedence. I'm also pretty sure there isn't a
way to check the arguments passed via -Dc_args or CFLAGS (they're treated as
default arguments, like the c_std in the project() argument). I asked on
#mesonbuild, but I haven't gotten an answer yet (Fridays are pretty slow
everywhere).

I think currently the only way to control this would be to have a meson option
to turn off optimizations, and I really don't like that.

Dylan


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] meson: Enable SSE4.1 optimizations

[Emil Velikov]

On 16 November 2017 at 22:21, Dylan Baker  wrote:
> Quoting Emil Velikov (2017-11-16 03:35:17)
>> Hi Dylan,
>>
>> On 16 November 2017 at 01:10, Dylan Baker  wrote:
>> > This patch checks for an and then enables sse4.1 optimizations if the
>> > host machine will be x86/x86_64.
>> >
>> Hell yeah, SSE is coming to town :-)
>>
>> Will this work if the user disables SSE4.1, say via CFLAGS=-mno-sse4.1
>> meson ...?
>> My meson is still bit rough, so I could not quite grok ^^ by reading
>> through the patch.
>>
>> Thanks
>> Emil
>
> It'll explode horribly. Id didn't see any special handling of that in 
> autotools
> build though either, did I miss something?
>
In autotools it's handled before the normal ld invocation.

Namely: configure.ac does:
 - construct a program using sse4.1 intrinsicts
Note: return _mm_...() is required otherwise the whole program will be
optimised away
 - the -msse is passed first and then the user flags (-mno-sse and/or
anything else)
 - the user -mno-sse takes precedence, hence the test program fails to build
 - set see_supported=false and don't build the SSE optimised static library

HTH
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] meson: Enable SSE4.1 optimizations

[Matt Turner]

On Thu, Nov 16, 2017 at 2:19 PM, Dylan Baker  wrote:
> Quoting Matt Turner (2017-11-15 21:57:37)
>> On Wed, Nov 15, 2017 at 5:10 PM, Dylan Baker  wrote:
>> > This patch checks for an and then enables sse4.1 optimizations if the
>> > host machine will be x86/x86_64.
>>
>> There's some stack realignment stuff that probably needs to stay, but
>> depending on what gcc version we require we can just always enable SSE
>> 4.1. It's existed since GCC 4.3 (March 2008).
>
> Well, since we require 4.6 in the meson build unconditionally, I think that
> we can just set the stackalignment variable.
>
> So, we can just drop the whole compile check altogether in that case, correct?

Exactly.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] meson: Enable SSE4.1 optimizations

[Dylan Baker]

Quoting Emil Velikov (2017-11-16 03:35:17)
> Hi Dylan,
> 
> On 16 November 2017 at 01:10, Dylan Baker  wrote:
> > This patch checks for an and then enables sse4.1 optimizations if the
> > host machine will be x86/x86_64.
> >
> Hell yeah, SSE is coming to town :-)
> 
> Will this work if the user disables SSE4.1, say via CFLAGS=-mno-sse4.1
> meson ...?
> My meson is still bit rough, so I could not quite grok ^^ by reading
> through the patch.
> 
> Thanks
> Emil

It'll explode horribly. Id didn't see any special handling of that in autotools
build though either, did I miss something?

Dylan


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] meson: Enable SSE4.1 optimizations

[Dylan Baker]

Quoting Matt Turner (2017-11-15 21:57:37)
> On Wed, Nov 15, 2017 at 5:10 PM, Dylan Baker  wrote:
> > This patch checks for an and then enables sse4.1 optimizations if the
> > host machine will be x86/x86_64.
> 
> There's some stack realignment stuff that probably needs to stay, but
> depending on what gcc version we require we can just always enable SSE
> 4.1. It's existed since GCC 4.3 (March 2008).

Well, since we require 4.6 in the meson build unconditionally, I think that
we can just set the stackalignment variable.

So, we can just drop the whole compile check altogether in that case, correct?

Dylan


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] meson: Enable SSE4.1 optimizations

[Eric Engestrom]

On Wednesday, 2017-11-15 17:10:59 -0800, Dylan Baker wrote:
> This patch checks for an and then enables sse4.1 optimizations if the
> host machine will be x86/x86_64.
> 
> Signed-off-by: Dylan Baker 
> ---
>  meson.build  | 27 ++-
>  src/mesa/meson.build | 14 +++---
>  2 files changed, 37 insertions(+), 4 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index 1c4200705f3..0d201c711a0 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -502,7 +502,32 @@ foreach a : ['-Wno-override-init', 
> '-Wno-initializer-overrides']
>endif
>  endforeach
>  
> -# TODO: SSE41 (which is only required for core mesa)
> +with_sse41 = false
> +if host_machine.cpu_family().startswith('x86')
> +  sse41_args = ['-msse4.1']

Nit: newline here

Patches 1, 3 & 4 are:
Reviewed-by: Eric Engestrom 

> +  # GCC on x86 (not 64) with -msse* assumes a 16 byte aligned stack, but 
> that's
> +  # not guaranteed
> +  if host_machine.cpu_family() == 'x86'
> +sse41_args += '-mstackrealign'
> +  endif
> +
> +  _code = '''
> +  #include 
> +  int param;
> +  int main () {
> +  __m128i a = _mm_set1_epi32 (param), b = _mm_set1_epi32 (param + 1), c;
> +  c = _mm_max_epu32(a, b);
> +  return _mm_cvtsi128_si32(c);
> +  }
> +  '''
> +
> +  if cc.compiles(_code, args : sse41_args, name : 'SSE4.1')
> +pre_args += '-DHAVE_SSE41'
> +with_sse41 = true
> +  endif
> +else
> +  sse41_args = []
> +endif
>  
>  # Check for GCC style atomics
>  if cc.compiles('int main() { int n; return __atomic_load_n(, 
> __ATOMIC_ACQUIRE); }',
> diff --git a/src/mesa/meson.build b/src/mesa/meson.build
> index b839fd02981..05a3a9ac55d 100644
> --- a/src/mesa/meson.build
> +++ b/src/mesa/meson.build
> @@ -592,9 +592,6 @@ files_libmesa_gallium = files(
>'state_tracker/st_vdpau.h',
>  )
>  
> -# TODO: sse41
> -libmesa_sse41 = []
> -
>  matypes_h = []
>  if with_asm_arch == 'x86' or with_asm_arch == 'x86_64'
>gen_matypes = executable(
> @@ -692,6 +689,17 @@ files_libmesa_common += [
>sha1_h,
>  ]
>  
> +if with_sse41
> +  libmesa_sse41 = static_library(
> +'mesa_sse41',
> +files('main/streaming-load-memcpy.c', 'main/sse_minmax.c'),
> +c_args : [c_vis_args, c_msvc_compat_args, sse41_args],
> +include_directories : inc_common,
> +  )
> +else
> +  libmesa_sse41 = []
> +endif
> +
>  libmesa_classic = static_library(
>'mesa_classic',
>[files_libmesa_common, files_libmesa_classic],
> -- 
> 2.15.0
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] meson: Enable SSE4.1 optimizations

[Emil Velikov]

Hi Dylan,

On 16 November 2017 at 01:10, Dylan Baker  wrote:
> This patch checks for an and then enables sse4.1 optimizations if the
> host machine will be x86/x86_64.
>
Hell yeah, SSE is coming to town :-)

Will this work if the user disables SSE4.1, say via CFLAGS=-mno-sse4.1
meson ...?
My meson is still bit rough, so I could not quite grok ^^ by reading
through the patch.

Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] meson: Enable SSE4.1 optimizations

[Matt Turner]

On Wed, Nov 15, 2017 at 5:10 PM, Dylan Baker  wrote:
> This patch checks for an and then enables sse4.1 optimizations if the
> host machine will be x86/x86_64.

There's some stack realignment stuff that probably needs to stay, but
depending on what gcc version we require we can just always enable SSE
4.1. It's existed since GCC 4.3 (March 2008).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/4] meson: Enable SSE4.1 optimizations

[Dylan Baker]

This patch checks for an and then enables sse4.1 optimizations if the
host machine will be x86/x86_64.

Signed-off-by: Dylan Baker 
---
 meson.build  | 27 ++-
 src/mesa/meson.build | 14 +++---
 2 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/meson.build b/meson.build
index 1c4200705f3..0d201c711a0 100644
--- a/meson.build
+++ b/meson.build
@@ -502,7 +502,32 @@ foreach a : ['-Wno-override-init', 
'-Wno-initializer-overrides']
   endif
 endforeach
 
-# TODO: SSE41 (which is only required for core mesa)
+with_sse41 = false
+if host_machine.cpu_family().startswith('x86')
+  sse41_args = ['-msse4.1']
+  # GCC on x86 (not 64) with -msse* assumes a 16 byte aligned stack, but that's
+  # not guaranteed
+  if host_machine.cpu_family() == 'x86'
+sse41_args += '-mstackrealign'
+  endif
+
+  _code = '''
+  #include 
+  int param;
+  int main () {
+  __m128i a = _mm_set1_epi32 (param), b = _mm_set1_epi32 (param + 1), c;
+  c = _mm_max_epu32(a, b);
+  return _mm_cvtsi128_si32(c);
+  }
+  '''
+
+  if cc.compiles(_code, args : sse41_args, name : 'SSE4.1')
+pre_args += '-DHAVE_SSE41'
+with_sse41 = true
+  endif
+else
+  sse41_args = []
+endif
 
 # Check for GCC style atomics
 if cc.compiles('int main() { int n; return __atomic_load_n(, 
__ATOMIC_ACQUIRE); }',
diff --git a/src/mesa/meson.build b/src/mesa/meson.build
index b839fd02981..05a3a9ac55d 100644
--- a/src/mesa/meson.build
+++ b/src/mesa/meson.build
@@ -592,9 +592,6 @@ files_libmesa_gallium = files(
   'state_tracker/st_vdpau.h',
 )
 
-# TODO: sse41
-libmesa_sse41 = []
-
 matypes_h = []
 if with_asm_arch == 'x86' or with_asm_arch == 'x86_64'
   gen_matypes = executable(
@@ -692,6 +689,17 @@ files_libmesa_common += [
   sha1_h,
 ]
 
+if with_sse41
+  libmesa_sse41 = static_library(
+'mesa_sse41',
+files('main/streaming-load-memcpy.c', 'main/sse_minmax.c'),
+c_args : [c_vis_args, c_msvc_compat_args, sse41_args],
+include_directories : inc_common,
+  )
+else
+  libmesa_sse41 = []
+endif
+
 libmesa_classic = static_library(
   'mesa_classic',
   [files_libmesa_common, files_libmesa_classic],
-- 
2.15.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev