Re: Libraries with NEON backends

-- Matt Sealey matt@genesi-usa.com Product Development Analyst, Genesi USA, Inc. On Wed, Mar 30, 2011 at 11:38 AM, Matt Sealey matt@genesi-usa.com wrote: > Konstantinos is right with regards to the package naming, we discussed > this with the zlib developers at the time. > > It is easily solved with a packaging solution though, Provides: as he > said. You will have the same problems with > something libjpegturbo if it forces NEON, or libmatrix shipped with > the GLES test utilities we've seen in our bug > reports (btw that is a prime target for some NEON optimization, > Konstantinos can you throw some code in there) > or in fact any library that has NEON code which is not properly > inserted/overridden at runtime based on NEON > hwcaps (the concern here is i.MX515 TO2, Marvell and nVidia chips > which have broken NEON or no NEON at all). > > Shipping a libturboz.deb would not be a huge imposition. Given that > Genesi provides system images and installers > for Ubuntu we can install it by default (TO2 support for installation > is going away with Natty). For Debian main, and other > distributions which need to figure on supporting more platforms than > ours, and for Ubuntu in the future if they ever > get their act together on supporting real consumer products instead of > just dev boards (looking at you too, Linaro!) > then it will have to be a user installable option, but this might not > be any more difficult than supplying a metapackage > for the platform (like omap-extra) with some Recommends: line, which > can only be resolved using an external > repository (partner, or so) which is not enabled by default. As soon > as someone enables that repo they will have > the option at next update to "upgrade" their system to these new libraries. > > Unfortunately doing it from a distribution point of view takes away > all the easiest potential for performance optimization, > but I think the benefit of having it "standardized" is worth it. > > Speaking of standardization, we have had a LOT of customer complaints > about xscreensaver-gl being installed > by default on ARM platforms. In what world does the common ARM SoC > ship with a full OpenGL implementation > bolted on? Users are clicking some random 3D screensaver and > complaining there is no acceleration - users do not > understand the difference here between GL and GLES. As well as making > new packages (libturboz in some other > repo), it will have to be automated or automatically educating users > to understand why they need this package and > why, in fact in some cases, they may not actually need it. > > -- > Matt Sealey matt@genesi-usa.com > Product Development Analyst, Genesi USA, Inc. > > > > On Tue, Mar 29, 2011 at 3:07 AM, Konstantinos Margaritis > markos@genesi-usa.com wrote: >> On 29 March 2011 10:53, Steve Langasek steve.langasek@linaro.org wrote: >>> Hi Konstantinos, >> >>> There must be some misunderstanding here; no license that prohibited >>> distribution of binaries built from modified source would be considered a >>> Free Software license, and zlib is certainly considered free. :) >> >> Yes, you're right, the problem is that a modified zlib would have to be clearly >> marked as different -ie the package name would have to be different. This >> would be easily solved by means of a Provides: field, but I'm unsure if the >> differentiation also should include the libz.so filename. I was probably wrong >> in my license interpretation in 2005, but I seem to remember it was something >> like that that basically made me stop my work in vectorizing zlib :) >> >> I'd love to be corrected if it meant having a NEON-optimized zlib in 2011 :) >> >>> The only relevant requirements in the license (according to >>> /usr/share/doc/zlib1g/copyright) are: >>> >>>  1. The origin of this software must not be misrepresented; you must not >>>     claim that you wrote the original software. If you use this software >>>     in a product, an acknowledgment in the product documentation would be >>>     appreciated but is not required. >>>  2. Altered source versions must be plainly marked as such, and must not be >>>     misrepresented as being the original software. >> >> Yes, 2 is the problem, I think this was interpreted as having to rename >> the package and possibly the .so name. >> >>> Are you looking at a different zlib license than this one? >> >> No, it's the same. >> >> Konstantinos >> >> _______________________________________________ >> linaro-dev mailing list >> linaro-dev@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-dev >> >