Switching to pkg-kde-talk@l.d.o, as it's a better place for this. Hi Peter!
On Thursday 21 April 2016 15:09:53 Peter Green wrote: [snip] > There are two qt source packages in raspbian jessie where we currently > have neon disabled. qt4-x11 and qtbase-opensource-src . I have a couple > of questions. > > 1: are these packages supposed to have runtime neon detection (either in > the packages own code or through ld.so hwcaps). First of all Qt4 is dead upstream, so the best thing to do in this case is keep it as it is. If someone complains hint them to port their apps to Qt5. Sounds harsh, I know, but... With respect to qtbase it seems to be a build time configuration, possibly based on config.tests/arch/arch.cpp. And if I remember correctly the Ubuntu folks used to have a neon-enabled build, but don't take my word on it. It *might* be possible to use ld hwcaps as we do for i386 and SSE2, provided ld has the necessary code. > 2: For each of the packages can anyone suggest a simple benchmark/test > that will hit the neon codepaths which I can use to check that neon > detection is doing it's job (i.e. that the package still works on the > pi1 and there is a performance improvement over the package without neon > on the pi2) Get a Qt graphical-intensive app not using OpenGL, the difference should be noticeable. Maybe the QGraphics's [demos] would be enough. [demos] Provided by qtbase5-examples and installed into /usr/lib/<a-t>/qt5/examples/widgets/graphicsview/ I want to point out that I have never had the chance to check it on Neon- enabled hardware *but* I did test iwmmxt-enabled devices with Qt4. The basic idea behind them is the same: SIMD instructions, which can be really cool when dealing with, for example, graphics without hardware-based OpenGL, so my guess is that it will show there for sure. Now with my maintainer hat on: I don't think we would like to support this on Debian. Some issues I see: - Acording to [wikipedia] all Cortex-A8 devices have the instruction set but on Cortex-A9 they are optional: we can't warrant it will be available everywhere → using it would need ld hwcaps (if applicable) and double builds but... is it worth the effort? Now it *might* really worth it for raspbian. [wikipedia] <https://en.wikipedia.org/wiki/ARM_architecture#Advanced_SIMD_.28NEON.29> - As I wrote above it will require double builds like we do on i386 thus increasing build time and possibly requiring more maintainership work. On i386 we do it because we have no other choice... and that's not the case here :-/ - It will require that all ARM buildds (or maybe just the compilers in them?) support NEON to get it properly detected. That being said if I where maintaining stuff for raspbian I would certainly consider doing this (again, as long as ld hwcaps can deal with it). Tip: not everything should be rebuilt, just check what we rebuild for i386 with SSE2. With those libraries covered the impact should be visible. Hope it helps, Lisandro. -- 20:57 * m4rgin4l patento el proceso de invencion 20:57 < m4rgin4l> de aqui en mas cualquier inventor me tiene que pagar regalias por inventar algo 20:57 * m4rgin4l tiene la patente pendiente del metodo cientifico 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.
-- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
