On Thursday, September 13, 2012 07:14:50 AM lars.kn...@nokia.com wrote: > On Sep 13, 2012, at 2:07 AM, ext Romain Pokrzywka <romain.pokrzy...@kdab.com> wrote: > > On Wednesday, September 12, 2012 07:10:52 AM lars.kn...@nokia.com wrote: > >> On Sep 12, 2012, at 12:27 AM, ext André Pönitz > >> <andre.poen...@mathematik.tu-> > > chemnitz.de> wrote: > >>> On Tue, Sep 11, 2012 at 10:34:50PM +0100, Sean Harmer wrote: > >>>> On 11/09/2012 13:34, Thiago Macieira wrote: > >>>>> I propose we revert it. > >>>> > >>>> I propose we (I) fix the affected classes in QtMultimedia > >>>> and Qt3D. I'm away on business this week but I will make a > >>>> start asap. > >>> > >>> I believe I mentioned that before. Anyway: > >>> > >>> I think there are (medium term) only two acceptable solutions, > >>> none of them perfect: > >>> (a) keep everything as it is (or, rather, "was") > >>> (b) have fully functional real/double "verticals" > >> > >> (c) Turn qreal into a double everywhere > >> > >> This was rejected before by some, because it might make things slower on > >> ARM, but would have the advantage that it's fully source compatible with > >> Qt > >> 4, solves the mess and would allow us to introduce floating point types > >> where required later. > >> > >> Only minuses I can see are > >> (c1) the names of QXxxF classes which are double and not float based > >> (c2) possibly slower execution on ARM > >> (c3) Somewhat higher memory consumption on ARM > >> > >> (c1) is not easily fixed. But (c2) seems to be less of an issue these > >> days. > >> At least for the Cortex A9 ARM claims very good double precision support. > >> Older CPUs also have some support through VFPv2/3. (c3) should also > >> become > >> less and less of an issue moving forward. > >> > >> So to bring this up again: How about turning qreal into a typedef for > >> double on all platforms and remove the mess this way? Whereever we need > >> (or want to use) floats, let's use them explicitly. > > > > I think the statements "might make things slower on ARM" and "seems to be > > less of an issue these days" are a little misleading and too optimistic. > > > > From my own experience, using double on ARM has a serious impact on > > performance at many levels: data size, code generation, and even FPU > > options. > > > > Indeed, from what I've read it seems like the Cortex-A9 is significantly > > closing the gap between float and double (although not eliminating it), > > but's it's really the only platform that does. [1] > > True, but more and more embedded systems will start using that platform. My > main proposal is that the default (and supported) build of Qt on ARM uses > doubles for qreal. If we keep the typedef, you could still typedef it to > use float at your own risk :)
True, that would be a good enough solution, e.g. as an option to configure > > Every other platform, Cortex-A8 and previous ARM architectures, and even > > Intel Atom, will suffer badly from switching from floats to doubles, even > > though they have VFP. > > > > This is mainly due to the crappy VFP abilities in those platforms, > > combined > > with the Cortex-A8 allowing use of the NEON co-processor as the FPU, with > > massive performance improvements over VFP, but only available for floats. > > [2] > > > > And it gets even worse when using -mfloat-abi=softfp. [3] > > Yes, but softfp doesn't make sense with Qt Quick 2 anyway. > > > Now, considering that most usage of Qt on embedded platforms is either > > through QGraphicsView or Qt Quick (1 and 2), both of them relying heavily > > on floating point calculations (coordinate systems, painting with AA...), > > this is definitely a decision with a potentially serious impact on most > > embedded platforms. > > One solution here is to explicitly use floats internally in Qt wherever > possible and where it's critical to performance. > > One may still argue that Qt5 should be targeting the latest and future > > platforms instead of legacy and current ones. Fair enough. But I think the > > consequences should be stressed more. Some extensive benchmarking would be > > nice too, before deciding on one solution against the other. > > As said above: It's about the default build that the Qt Project tests and > supports. > > We can keep the option of forcing qreal to float at least for now or until > we've proven that the performance impact is acceptable. Yep, I'm happy with that :) Thx, Romain > > Cheers, > Lars > > > [1] http://www.360doc.com/content/12/0806/14/350555_228637047.shtml > > [2] > > http://processors.wiki.ti.com/index.php/Cortex_A8#Neon_and_VFP_both_suppor > > t_floating_point.2C_which_should_I_use.3F [3] > > http://wiki.debian.org/ArmHardFloatPort/VfpComparison > > > > Regards, > > Romain > > > >> Cheers, > >> Lars > >> > >>> Version (a) means the current mess will go on. but it has the > >>> distict charme of (a.1) not breaking anyones existing code and > >>> (a.2) sticking to feature freeze rules. > >>> > >>> Version (b) is somewhat closer to a proper solution, but fails > >>> (a.1) and (a.2). It has also the disadvantage of requiring real > >>> work, and therefore to tie up resources. > >>> > >>> Even with my usual "let's break feature freeze if the feature is > >>> cool enough" hat on, I am tempted to lean towards (a). We are > >>> late in the game, and there are one or two rather essential > >>> things to be done for Qt 5. Having applications lock up regularly > >>> does not exactly sound like a strong sell to me. And while partial > >>> and/or extremly slow window updates might give that warm and cosy > >>> sense of being back in Qt 2.1 times to some, I have ths nagging > >>> feeling that not everyone out there will appreciate it. > >>> > >>> So, please, make the things that were there work again, and do > >>> not open up new construction sites. And yes, that may mean > >>> postpone stuff to Qt 6 (or maybe convincing the Chief in a year > >>> or two that having a QT_NO_COMPATIBILITY would be a feasible > >>> approach) > >>> > >>> Andre' > >>> _______________________________________________ > >>> Development mailing list > >>> Development@qt-project.org > >>> http://lists.qt-project.org/mailman/listinfo/development > >> > >> _______________________________________________ > >> Development mailing list > >> Development@qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
