Re: [ptxdist] libjpeg-turbo and libjpeg

[Guillermo Rodriguez Garcia <guille.rodriguez@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4327 bytes --]

Hi Michael,

2018-02-14 8:49 GMT+01:00 Michael Olbrich <m.olbrich@pengutronix.de>:

> On Tue, Feb 13, 2018 at 05:12:14PM +0100, Guillermo Rodriguez Garcia wrote:
> > 2018-02-13 16:37 GMT+01:00 Michael Olbrich <m.olbrich@pengutronix.de>:
> > > On Tue, Feb 13, 2018 at 10:23:09AM +0100, Guillermo Rodriguez Garcia
> wrote:
> > > > I need to use libjpeg-turbo for some apps that rely on specific
> > > > libjpeg-turbo extensions that are not available in the standard
> (IJG's)
> > > > libjpeg library. So I started to create a set of ptxdist rules for
> > > > libjpeg-turbo.
> > > >
> > > > libjpeg-turbo is supposed to provide a drop-in replacement for the
> > > standard
> > > > IJG's libjpeg, and in fact many Linux distributions have already
> switched
> > > > to it. So most packages that currently depend on LIBJPEG should be
> able
> > > to
> > > > use libjpeg-turbo as well without any changes.
> > > >
> > > > Example: gst-plugins-good1.in currently does the following:
> > > >
> > > > select LIBJPEG if GST_PLUGINS_GOOD1_JPEG
> > > >
> > > > However, gst-plugins-good1 should work just fine with libjpeg-turbo
> as
> > > > well. In fact the upstream gst-plugins already switched to
> libjpeg-turbo
> > > > some time ago (see the Cerbero scripts)
> > > >
> > > > So, what is the recommended way to approach this in ptxdist? I can
> > > imagine
> > > > some options:
> > > >
> > > > 1. Provide a separate set of .in/.make files for libjpeg-turbo and a
> > > > separate LIBJPEG_TURBO package. So new packages that want to use
> > > > libjpeg-turbo would need to explicitly select LIBJPEG_TURBO (instead
> of
> > > > LIBJPEG). But this means that packages that currently use libjpeg
> would
> > > not
> > > > be able to benefit from the performance improvements in
> libjpeg-turbo.
> > > Also
> > > > I am not sure whether these two libraries (libjpeg and
> libjpeg-turbo) can
> > > > actually coexist in the same system.
> > >
> > > No.
> > >
> > > > 2. Modify the LIBJPEG rules to provide an option to select between
> the
> > > > standard (IJG) libjpeg, or libjpeg-turbo. This would be similar to
> what
> > > is
> > > > done in alsa.in/alsa.make to select between the "full" and "light"
> > > versions
> > > > of the library.
> > >
> > > Either this ...
> > >
> > > > 3. Other?
> > >
> > > ... or change the libjpeg rule to always build libjpeg-turbo instead.
> > >
> > > I would prefer to avoid an option. But I'm not sure
> > > 1. if there are use-cases where libjpeg is preferable
> > > 2. if there are packages that fail to build with libjpeg-turbo
> > >
> >
> > Judging from the wide adoption of libjpeg-turbo by many popular Linux
> > distros, I'd say that if we had to choose one, libjpeg-turbo may actually
> > be the "safe" choice.
> >
> >
> > >
> > > I have some libjpeg-turbo stuff lying around here somewhere. It was
> just
> > > never finished. I've just dumped it in my test BSP so see if anythings
> > > fails to build. I'll report the result later.
> > >
> >
> > Let me know if you need help; I am also working on this now (since I do
> > have an app that explicitly needs libjpeg-turbo and doesn't work with the
> > stock libjpeg)
>
> My test build looks good. No failed packages. So I pushed what I have to
> master. Please test it and compare it with what you have so far.
>

No build issues here and I can confirm that both gst-plugins-good1 (with
the jpeg plugin) and imagemagick both work fine with libjpeg-turbo on my
target platform.

Some comments:

- According to the documentation (
https://github.com/libjpeg-turbo/libjpeg-turbo/blob/master/BUILDING.md), NASM
or YASM are required if building x86 or x86-64 SIMD extensions. I have not
verified this ,yself (I'm building for an ARM target) but since we are
enabling SIMD, shouldn't the .in file select HOST_NASM? (ideally for
ARCH_X86 only but it seems that this can't be checked in the .in file?)

- For ARM targets, --with-simd requires NEON support. Perhaps the .make
file should do something like this:

# For ARM, enable SIMD extensions only if NEON is available
ifdef PTXCONF_ARCH_ARM_NEON
LIBJPEG_CONF_OPT += --with-simd
endif
# For architectures other than ARM, enable SIMD extensions unconditionally
ifndef PTXCONF_ARCH_ARM
LIBJPEG_CONF_OPT += --with-simd
endif


Best regards,

Guillermo Rodriguez Garcia
guille.rodriguez@gmail.com

[-- Attachment #1.2: Type: text/html, Size: 6113 bytes --]

[-- Attachment #2: Type: text/plain, Size: 91 bytes --]

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de