Re: Qt5 switching qreal from float to double on arm*
On Thu, Nov 07, 2013 at 02:46:27PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: - If we decide to do the change in Qt5, it will be *without* soname bump. Yes, I know many of you will think of this as **ugly**, but so far means 3 binNMUs per arch. Now if this is not acceptable, then no change will be made, because I won't change Qt5's SONAME. What is your plan to support partial upgrades? BinNMUs can require new Qt versions to be installed, but Qt can be upgraded independently to the newer version, causing the rdepends to crash. This can potentially be solved by Breaks, but it still breaks assumptions of people using Debian in that such ABI breaks will be communicated through SONAME bumps. And the old lib will not even be coinstallable. (Of course a good time to do such changes are in fact SONAME bumps, but I realize that this won't happen for Qt for quite some time.) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Qt5 switching qreal from float to double on arm*
On Sat, Nov 02, 2013, Lisandro Damián Nicanor Pérez Meyer wrote: Hi! Starting from Qt 5.2.0 (most probably from rc1 and definitely not from beta1 currently in experimental) Qt5 will switch qreal from float to double on arm*. We have the option to keep some archs in float by passing a compilation parameter. I've done so for armel and sh4, so only armhf will switch to double. Of course we are still on time to discuss this, and this is the reason of this mail. What do you think WRT the above changes? First, thanks a lot for the heads up on this. qreal being float instead of double on ARM was the source of a bunch of work for ARM porters in the past; now I have these worries/questions: * switching it back might imply some new porting work (in the case where the patches were something #if ARM use float #else use double); this might be particularly painful if armel and armhf have different definitions. Maybe there's a nice define #QREAL_IS_FLOAT or something to help with this. * what about arm64? sounds like this one should be double from the start; not sure what it is right now * when you say you've changed armel and sh4 to keep using float, is this Debian-specific? Not sure we want a delta with upstream on this kind of stuff. Would it not work at all to use double, or would it just be slow? I'd rather have it slow for people using big software on slow arches rather than keeping a delta; it sounds like we do a SONAME transition no matter what anyway * what's the point in qreal anyway? can't we just switch everything to float or double? sounds like software should know what kind of level of precision it needs in the first place; e.g. if it's a scale in some UI, then either float or double is enough, but it's not an arch specific decision Thanks again for raising this! -- Loïc Minier -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131107171818.gb12...@bee.dooz.org
Re: Qt5 switching qreal from float to double on arm*
On Thursday 07 November 2013 18:18:18 you wrote: On Sat, Nov 02, 2013, Lisandro Damián Nicanor Pérez Meyer wrote: Hi! Starting from Qt 5.2.0 (most probably from rc1 and definitely not from beta1 currently in experimental) Qt5 will switch qreal from float to double on arm*. We have the option to keep some archs in float by passing a compilation parameter. I've done so for armel and sh4, so only armhf will switch to double. Of course we are still on time to discuss this, and this is the reason of this mail. What do you think WRT the above changes? First, thanks a lot for the heads up on this. Thank you too for replying :) qreal being float instead of double on ARM was the source of a bunch of work for ARM porters in the past; now I have these worries/questions: * switching it back might imply some new porting work (in the case where the patches were something #if ARM use float #else use double); this might be particularly painful if armel and armhf have different definitions. Maybe there's a nice define #QREAL_IS_FLOAT or something to help with this. Don't forget we are talking about *just* Qt5 here, *not* Qt4. We only have 3 apps building against Qt5 right now. If apps switch to Qt5 they will surely find some bumps, so this can be managed. * what about arm64? sounds like this one should be double from the start; not sure what it is right now I have not added any provisions to arm64, so with the next 5.2.0 [rc/final] upload it will switch to double. We are still on time if something needs a fix here. * when you say you've changed armel and sh4 to keep using float, is this Debian-specific? Not sure we want a delta with upstream on this kind of stuff. Would it not work at all to use double, or would it just be slow? I'd rather have it slow for people using big software on slow arches rather than keeping a delta; it sounds like we do a SONAME transition no matter what anyway Now this *will* be messy. I have asked upstream [0] and so far haven't got any explicit reply from other distro's maintainers. [0] http://lists.qt-project.org/pipermail/development/2013-November/014017.html But, according to [1]: I should also point out that this option now allows selecting qreal to be float on other platforms, besides ARM. That's why I'm still spamming debian-ports ;) [1] http://lists.qt-project.org/pipermail/development/2013-November/014017.html So: - We don't know yet what other distros are going to do. - If we decide to do the change in Qt5, it will be *without* soname bump. Yes, I know many of you will think of this as **ugly**, but so far means 3 binNMUs per arch. Now if this is not acceptable, then no change will be made, because I won't change Qt5's SONAME. * what's the point in qreal anyway? can't we just switch everything to float or double? sounds like software should know what kind of level of precision it needs in the first place; e.g. if it's a scale in some UI, then either float or double is enough, but it's not an arch specific decision I really don't know, it was already there when I started using Qt back in Qt3's final days ;-) But I *do* know that if people want it gone, they will need to wait until Qt6 and provide the necessary patches :-/ Hope that helps, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Qt5 switching qreal from float to double on arm*
On Thursday 07 November 2013 18:55:31 Loïc Minier wrote: On Thu, Nov 07, 2013, Lisandro Damián Nicanor Pérez Meyer wrote: - We don't know yet what other distros are going to do. IMO we shouldn't have distro-specific patching for this kind of stuff; it seems to commonly impact apps (which should be using qreal instead of assuming qreal is double) way too commonly, and we want binaries to be compatible between distros, so diverging from upstream seems a really bad idea. The problem is the can of worms it has been opened: now we have the *chance* to choose, so ideally we need maintainers from most distros cooperating to keep SONAME and ABI the same. Let's hope maintainers from other distros stand up. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Qt5 switching qreal from float to double on arm*
On Thu, Nov 07, 2013, Lisandro Damián Nicanor Pérez Meyer wrote: - We don't know yet what other distros are going to do. IMO we shouldn't have distro-specific patching for this kind of stuff; it seems to commonly impact apps (which should be using qreal instead of assuming qreal is double) way too commonly, and we want binaries to be compatible between distros, so diverging from upstream seems a really bad idea. - If we decide to do the change in Qt5, it will be *without* soname bump. Yes, I know many of you will think of this as **ugly**, but so far means 3 binNMUs per arch. Now if this is not acceptable, then no change will be made, because I won't change Qt5's SONAME. Well, it's kind of ugly but we could take this hit once and go through a binary transition with a package name change, or some kind of other transition trick. Not pretty and breaks compat between binaries built against old lib and new lib, but things in Debian will be ok. Also, as you note, not too many things are using Qt5 yet; might be a good time to get this right. Likely something the release team would be able to advise on, I would guess. I really don't know, it was already there when I started using Qt back in Qt3's final days ;-) Eh ok; if you get the chance to ask, that would be helpful to know when porting apps; perhaps it's something to bring up upstream in issues faced by distros kind of chatters :-) -- Loïc Minier -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131107175531.ga25...@bee.dooz.org
Re: Qt5 switching qreal from float to double on arm*
In data sabato 2 novembre 2013 15:29:05, Lisandro Damián Nicanor Pérez Meyer ha scritto: Hi! Starting from Qt 5.2.0 (most probably from rc1 and definitely not from beta1 currently in experimental) Qt5 will switch qreal from float to double on arm*. Did upstream bump the SONAME of QtCore5 and any other qt5 library because of this? Of course we are still on time to discuss this, and this is the reason of this mail. What do you think WRT the above changes? This will basically break the ABI of basically all the Qt5 libraries on those architectures. Unless upstream already managed the SONAME bump already, it would imply that Debian has to maintain it on its own... are you sure these changes are worth the pain they cause? On the other hand, if the above change is kept, symbols for Qt5 on armhf managed with pkg-kde-tools' symbolshelper will need an explicit double for armhf instead of using qreal's subst. This is because on Qt4 qreal will be kept as float. This is another issue, i.e. pkgkde-symbolshelper not being able to distinguish version of qt for substitutions. We have the option to keep some archs in float by passing a compilation parameter. I've done so for armel and sh4, so only armhf will switch to double. My option goes on keeping the status quo of qreal as it was, on architectures that managed to build qtbase-opensource-src already. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: Qt5 switching qreal from float to double on arm*
Note: readding p-k-t@ and debian-ports@... On Tuesday 05 November 2013 19:22:30 peter green wrote: Lisandro Damián Nicanor Pérez Meyer wrote: I really don't understand where Canonical gets in here. If qreal is float on armhf and key software fails in that configuration then canonical have to fix it (ubuntu are usually either very close to or ahead of debian on key software) Afaict neither armel or sh4 has anything like the level of corporate support that armhf gets from canonical. Ah, you mean that armhf hardware has more support from the Ubuntu side. Anyway, we need to make this decision within Debian. I also don't understand what you mean with ports that stick with qreal. qreal is a typedef which type is defined at compile time. Did you meant float? Sorry I meant ports that stick with defining qreal as float. I see, in this case only those ports will have to deal with that (as it has been with Qt4) I have not participated in any way in upstream's decision nor I have the power to overcome them. Anyway, we are giving the choice of a compile-time parameter to better suit our needs on purpose. The problem is this is going to have a massive affect on ABI which implies: 1: changing the descision later would mean a soname change The reason why I took the time to create this thread is because this is the time to take that decision, and we Qt maintainers will not change it later because that would mean a soname change. 2: if debian make a different descision from other distros we will be binary incompatible. Sune just made me rmember LSB. Yes, indeed, we need to try and coordinate with other distros. How this is normally done? Kinds regards, Lisandro. -- Un viejo proverbio de El.Machi dice que la memoria es como las papas fritas... ¡nunca sobran! Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Qt5 switching qreal from float to double on arm*
On Sat, 02 Nov 2013 15:29:05 -0300 Lisandro Damián Nicanor Pérez Meyer perezme...@gmail.com wrote: Hi! Starting from Qt 5.2.0 (most probably from rc1 and definitely not from beta1 currently in experimental) Qt5 will switch qreal from float to double on arm*. We have the option to keep some archs in float by passing a compilation parameter. I've done so for armel and sh4, so only armhf will switch to double. Of course we are still on time to discuss this, and this is the reason of this mail. What do you think WRT the above changes? FWIW, I was a bit sceptical about switching qreal to double. True this would minimise the patches some packages would need on armhf, but OTOH, I don't know what would happen to packages that use both GL graphics and Qt at the same time. All armhf platforms support only OpenGLES and not full OpenGL stack which supports *only* 32-bit floats. However Lissandro just told me on IRC that GL-stuff on Qt5 switched to float for exactly that reason). So apart from speed I don't see a reason for not going that route. If anything, FPU in recent armv7-a systems has become increasingly better so this will be better in a couple of years (it will still suck on a Cortex-A8, but will be less apparent on a Cortex-A15 or better). FTR, I don't think many apps would mind that much. Most apps that would actually care for speed/accuracy would use float/double directly and not qreal, for most it would save us the burden of patching (eg. scribus, qgis). So unless, we find some particular strong cases for *not* switching to double, I'd vote in favour of that. Regards Konstantinos pgpY4LJPGsrhH.pgp Description: PGP signature
Re: Qt5 switching qreal from float to double on arm*
On Saturday 02 November 2013 15:29:05 Lisandro Damián Nicanor Pérez Meyer wrote: [snip] We have the option to keep some archs in float by passing a compilation parameter. I've done so for armel and sh4, so only armhf will switch to double. Just for the record, I din't considered the switch for armel and sh4 because I think that may slow down those archs a lot, but please understand that I do not have a solid background for stating this, so feel free to correct me here. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Qt5 switching qreal from float to double on arm*
Note: adding back debian-arm@..., please tell me if it's not necessary. On Saturday 02 November 2013 23:25:57 peter green wrote: Lisandro Damián Nicanor Pérez Meyer wrote: Any feedback will be kindly appreciated. I've always thought there is something fundamentally wrong. What is qreal supposed to be used for? If it's supposed to be used for things where float would be adequate then shouldn't it be float on all platforms? If it's supposed to be used for things where float is inadequate then why isn't it double on all platforms? The current situation leads to people who develop on i386 and amd64 (which is most developers) assuming that qreal is equivilent to double. Then we try and build it on arm* and float gets used. Sometimes this is ok because there was really no reason for the developer to be using double precision in the first place and there were no incorrect conversion assumptions. Sometimes this causes build failures which can be difficult to resolve* and I bet in some cases it causes more subtule bugs. It also goes against the principle of offering to the greatest extent possible the same functionality on all platforms. Peter: I'm not in the position of changing qreal's existence, so I'm not here to argue if qreal is a good idea or not. The important thing is that qreal has been in Qt since at least Qt3, and, as far as I remember, has always been defined to be double on archs that natively support it and float on those that didn't. Making qreal double on armhf but leaving it as float on armel will mean that canonical are no longer forced for fix bugs surrounding it. I'm sure canonical would like that but I also suspect it may cause severe degredation in the maintainance of QT software on those ports that stick with qreal. I really don't understand where Canonical gets in here. I don't work for Canonical nor I am an Ubuntu maintainer .Qt5's change comes from Lars Knoll, the current main/lead architect of the project. And we are still left with the possibility to define what value will qreal take (see below). I also don't understand what you mean with ports that stick with qreal. qreal is a typedef which type is defined at compile time. Did you meant float? On the other hand presumablly there would be a performance hit from switching from float to double, especially on platforms which use software floating point (I presume that was why whoever controlled qt at the time made qreal float on arm in the first place). That's why they added an option to bypass this at compile time (see my previous mail) and also the main reason that I left armel as float. Of course, it might be that some armhf's hardware isn't capable of doing double, which is not what I currently understand, but feel free to correct me. But the most important thing here is that if the porters decide that we better stick to float for qreal, I have no problem in doing so. I found some older upstream discussion on what to do about float at https://groups.google.com/forum/#!topic/qt-project-list-development/dPcP3NAS Y1k I also found some discussion at http://comments.gmane.org/gmane.comp.lib.qt.qt5-feedback/700 saying that on coretex A8 double was significantly slower than float. Finally has there been any discussion with other linux distros. This is obviously something that impacts the ABI in a big way so ideally it's not something where we want different distros doing different things. I have not participated in any way in upstream's decision nor I have the power to overcome them. Anyway, we are giving the choice of a compile-time parameter to better suit our needs on purpose. Kinds regards, Lisandro. -- 18: Como se pueden evitar los problemas de alimentacion electrica * No coma cerca de un enchufe Damian Nadales http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Qt5 switching qreal from float to double on arm*
Hi! Starting from Qt 5.2.0 (most probably from rc1 and definitely not from beta1 currently in experimental) Qt5 will switch qreal from float to double on arm*. We have the option to keep some archs in float by passing a compilation parameter. I've done so for armel and sh4, so only armhf will switch to double. Of course we are still on time to discuss this, and this is the reason of this mail. What do you think WRT the above changes? On the other hand, if the above change is kept, symbols for Qt5 on armhf managed with pkg-kde-tools' symbolshelper will need an explicit double for armhf instead of using qreal's subst. This is because on Qt4 qreal will be kept as float. Any feedback will be kindly appreciated. Kinds regards, Lisandro. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Qt5 switching qreal from float to double on arm*
On Saturday 02 November 2013 15:29:05 Lisandro Damián Nicanor Pérez Meyer wrote: Hi! Starting from Qt 5.2.0 (most probably from rc1 and definitely not from beta1 currently in experimental) Qt5 will switch qreal from float to double on arm*. I forgot to mention: please keep pkg-kde-talk at l.a.d.o CCed :) -- Dadme voto electrónico y con una terminal os haré presidente. el.machi Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Qt5 switching qreal from float to double on arm*
Lisandro Damián Nicanor Pérez Meyer wrote: Any feedback will be kindly appreciated. I've always thought there is something fundamentally wrong. What is qreal supposed to be used for? If it's supposed to be used for things where float would be adequate then shouldn't it be float on all platforms? If it's supposed to be used for things where float is inadequate then why isn't it double on all platforms? The current situation leads to people who develop on i386 and amd64 (which is most developers) assuming that qreal is equivilent to double. Then we try and build it on arm* and float gets used. Sometimes this is ok because there was really no reason for the developer to be using double precision in the first place and there were no incorrect conversion assumptions. Sometimes this causes build failures which can be difficult to resolve* and I bet in some cases it causes more subtule bugs. It also goes against the principle of offering to the greatest extent possible the same functionality on all platforms. Making qreal double on armhf but leaving it as float on armel will mean that canonical are no longer forced for fix bugs surrounding it. I'm sure canonical would like that but I also suspect it may cause severe degredation in the maintainance of QT software on those ports that stick with qreal. On the other hand presumablly there would be a performance hit from switching from float to double, especially on platforms which use software floating point (I presume that was why whoever controlled qt at the time made qreal float on arm in the first place). I found some older upstream discussion on what to do about float at https://groups.google.com/forum/#!topic/qt-project-list-development/dPcP3NASY1k I also found some discussion at http://comments.gmane.org/gmane.comp.lib.qt.qt5-feedback/700 saying that on coretex A8 double was significantly slower than float. Finally has there been any discussion with other linux distros. This is obviously something that impacts the ABI in a big way so ideally it's not something where we want different distros doing different things. * See scribus for an especially nasty example. -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52758a05.9090...@p10link.net
