On Samstag, 8. Februar 2020 05:00:31 CET Thiago Macieira wrote:
> If we don't need runtime detection, then just #include or a
> wrapper header to deal with MSVC not defining __SSE2__. qfloat16.h does
> that.
>
> We also need to decide whether we want the macro normalisation that
> qsimd_p.h does
On Thursday, 6 February 2020 03:45:51 PST Lars Knoll wrote:
> Hi,
>
> We’ve seen that in a couple of places things like matrix operations are a
> CPU bottleneck. Being able to provide SSE/NEON optimised versions of some
> of those operations could help significantly.
> On x86/x64, we require SS
> On 6 Feb 2020, at 21:54, Allan Sandfeld Jensen wrote:
>
> On Donnerstag, 6. Februar 2020 21:17:02 CET Lars Knoll wrote:
>>> On 6 Feb 2020, at 19:29, Allan Sandfeld Jensen wrote:
>>> making the default SSE4.1 enabled but still offer users (linux distros
>>> really), the option to force it down
On Donnerstag, 6. Februar 2020 21:17:02 CET Lars Knoll wrote:
> > On 6 Feb 2020, at 19:29, Allan Sandfeld Jensen wrote:
> > making the default SSE4.1 enabled but still offer users (linux distros
> > really), the option to force it down to only SSE2.
>
>
> We should at least default to SSE2 as
> On 6 Feb 2020, at 19:29, Allan Sandfeld Jensen wrote:
>
> On Donnerstag, 6. Februar 2020 12:45:51 CET Lars Knoll wrote:
>> One problem is, that we can only get full benefit out of those if we can
>> offer them inline. That would basically imply making our qsimd_p.h header
>> public and includin
On Donnerstag, 6. Februar 2020 12:45:51 CET Lars Knoll wrote:
> One problem is, that we can only get full benefit out of those if we can
> offer them inline. That would basically imply making our qsimd_p.h header
> public and including that one from qvectornd.h and qmatrixnxn.h (so that we
> can im
Hi!
On Thu, 6 Feb 2020 at 14:14, Kevin Kofler wrote:
>
> Lisandro Damián Nicanor Pérez Meyer wrote:
> > At least in Debian we do this for qtbase on i386, and have different
> > versions of corelib and gui (the only ones which where directly affected
> > by this).
>
> FYI, QtWebEngine is pretty mu
Lisandro Damián Nicanor Pérez Meyer wrote:
> At least in Debian we do this for qtbase on i386, and have different
> versions of corelib and gui (the only ones which where directly affected
> by this).
FYI, QtWebEngine is pretty much unfixably screwed on non-SSE2. The last
version that was reasona
Hi,
For *Android*:
- NEON is turned on by default for armv7a starting with NDKr21[0] (for armv8
NEON is mandatory).
- for x86 all up to SSE3 [1]
- for x86_64 all up to SSE4.2 [1]
Cheers,
BogDan.
[0] https://github.com/android/ndk/wiki/Changelog-r21#changes
[1] https://developer.android.com/nd
On 20/02/06 02:00, Lars Knoll wrote:
> > On 6 Feb 2020, at 14:36, Lisandro Damián Nicanor Pérez Meyer
> > wrote:
> >
> > On 20/02/06 11:45, Lars Knoll wrote:
> >> Hi,
> >>
> >> We’ve seen that in a couple of places things like matrix operations are a
> >> CPU bottleneck. Being able to provide
> On 6 Feb 2020, at 14:54, Kevin Kofler wrote:
>
> Lars Knoll wrote:
>> As a side note: SSE 4.1 offers some nice additional instructions that
>> would simplify some of the operations. Should we keep the minimum
>> requirement for SSE at version 2, or can we raise it to 4.1?
>
> SSE2, definitely.
> On 6 Feb 2020, at 14:36, Lisandro Damián Nicanor Pérez Meyer
> wrote:
>
> On 20/02/06 11:45, Lars Knoll wrote:
>> Hi,
>>
>> We’ve seen that in a couple of places things like matrix operations are a
>> CPU bottleneck. Being able to provide SSE/NEON optimised versions of some of
>> those oper
Lars Knoll wrote:
> As a side note: SSE 4.1 offers some nice additional instructions that
> would simplify some of the operations. Should we keep the minimum
> requirement for SSE at version 2, or can we raise it to 4.1?
SSE2, definitely. There is lots of hardware still in use that does not
suppo
On 20/02/06 11:45, Lars Knoll wrote:
> Hi,
>
> We’ve seen that in a couple of places things like matrix operations are a CPU
> bottleneck. Being able to provide SSE/NEON optimised versions of some of
> those operations could help significantly.
>
> On x86/x64, we require SSE2 already anyway, s
On 02/06/20 12:45, Lars Knoll wrote:
As a side note: SSE 4.1 offers some nice additional instructions that would
simplify some of the operations. Should we keep the minimum requirement for SSE
at version 2, or can we raise it to 4.1?
I have a classroom-sized deployment of Intel Centrino Duo b
Hi,
We’ve seen that in a couple of places things like matrix operations are a CPU
bottleneck. Being able to provide SSE/NEON optimised versions of some of those
operations could help significantly.
On x86/x64, we require SSE2 already anyway, so we should be able to use those
unconditionally.
16 matches
Mail list logo
