> -Original Message-
> From: Mitch Curtis
> Sent: keskiviikko 5. helmikuuta 2020 15.40
> To: Jani Heikkinen ; Lars Knoll ;
> Yulong Bai
> Cc: Volker Hilsheimer ; Qt development mailing list
> ; releas...@qt-project.org
> Subject: RE: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature
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
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,
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.
> -Original Message-
> From: Development On Behalf Of
> Thiago Macieira
>
> On Wednesday, 5 February 2020 09:41:58 PST Alexander Akulich wrote:
> > On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira
> >
> > wrote:
> > > The correct signal for an error situation is errorOccurred, like in
>
> 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
On Thu, Feb 6, 2020 at 4:52 PM Alex Blasche wrote:
>
> Considering that our naming convention for error() signals is inconsistent
> anyway, I favour an approach that highlights API changes early.
The convention can not be inconsistent. It can either do not exist
("we have no convention, so
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
> 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,
> -Original Message-
> From: Alexander Akulich
> On Thu, Feb 6, 2020 at 4:52 PM Alex Blasche wrote:
> >
> > Considering that our naming convention for error() signals is inconsistent
> anyway, I favour an approach that highlights API changes early.
>
> The convention can not be
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
Are we going to provide some Qt5 → Qt6 migration tool? It is trivial
to grep the sources for "SIGNAL(error(QAbstractSocket::SocketError))"
and print a warning about the dangerous Qt4-style connection.
___
Development mailing list
Wait, what?? When did that decision was made?
I am tired fixing performance bugs induced be the replacement QList with
QList>, can we please get rid of the QList class finally?
> 6 февр. 2020 г., в 20:14, Matthew Woehlke
> написал(а):
> I thought we decided *not* to
> do that!)
>
On 03/02/2020 16.25, Giuseppe D'Angelo via Development wrote:
> Other people are free disagree with this. (For instance, in Qt 6 the
> decision (which I disagree with) was to introduce similar gratuitous and
> very hidden source-incompatible changes, e.g. with QList and QHash both
> breaking
On Thu, Feb 06, 2020 at 01:51:17PM +, Alex Blasche wrote:
>
> > -Original Message- From: Development
> > On Behalf Of Thiago Macieira
> >
> > On Wednesday, 5 February 2020 09:41:58 PST Alexander Akulich wrote:
> > > On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira
> > >
> > > wrote:
Den tors 6 feb. 2020 kl 20:36 skrev André Pönitz :
>
> On Thu, Feb 06, 2020 at 01:51:17PM +, Alex Blasche wrote:
> >
> > > -Original Message- From: Development
> > > On Behalf Of Thiago Macieira
> > >
> > > On Wednesday, 5 February 2020 09:41:58 PST Alexander Akulich wrote:
> > > > On
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
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
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
Alexander Akulich (6 February 2020 16:33) asked:
> Are we going to provide some Qt5 → Qt6 migration tool?
https://codereview.qt-project.org/c/qt/qtrepotools/+/289121
> It is trivial to grep the sources for
> "SIGNAL(error(QAbstractSocket::SocketError))" and print a warning
> about the dangerous
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
22 matches
Mail list logo
