Libraries with NEON backends
matt at genesi-usa.com
Wed Mar 30 16:42:36 UTC 2011
I forgot btw: the true solution here is adapt zlib so that the
functions are pluggable and the appropriate calls are made at the
appropriate times based on HW capabilities.
Then throw it at mainline, they may accept it.
Matt Sealey <matt at genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
On Wed, Mar 30, 2011 at 11:38 AM, Matt Sealey <matt at 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 at genesi-usa.com>
> Product Development Analyst, Genesi USA, Inc.
> On Tue, Mar 29, 2011 at 3:07 AM, Konstantinos Margaritis
> <markos at genesi-usa.com> wrote:
>> On 29 March 2011 10:53, Steve Langasek <steve.langasek at 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.
>> linaro-dev mailing list
>> linaro-dev at lists.linaro.org
More information about the linaro-dev