From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-wr0-x22d.google.com ([2a00:1450:400c:c0c::22d]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1eltoJ-0001N2-PU for ptxdist@pengutronix.de; Wed, 14 Feb 2018 10:57:08 +0100 Received: by mail-wr0-x22d.google.com with SMTP id s5so21520050wra.0 for ; Wed, 14 Feb 2018 01:57:07 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20180213153742.iljambtbf7g2v6fd@pengutronix.de> <20180214074917.ev6rodzevanduzix@pengutronix.de> From: Guillermo Rodriguez Garcia Date: Wed, 14 Feb 2018 10:57:06 +0100 Message-ID: Subject: Re: [ptxdist] libjpeg-turbo and libjpeg List-Id: PTXdist Development Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: ptxdist@pengutronix.de Content-Type: multipart/mixed; boundary="===============1097980024==" Errors-To: ptxdist-bounces@pengutronix.de Sender: "ptxdist" To: ptxdist@pengutronix.de --===============1097980024== Content-Type: multipart/alternative; boundary="f403045f51b845ce40056529223f" --f403045f51b845ce40056529223f Content-Type: text/plain; charset="UTF-8" 2018-02-14 10:22 GMT+01:00 Guillermo Rodriguez Garcia < guille.rodriguez@gmail.com>: > Hi Michael, > > 2018-02-14 8:49 GMT+01:00 Michael Olbrich : > >> On Tue, Feb 13, 2018 at 05:12:14PM +0100, Guillermo Rodriguez Garcia >> wrote: >> > 2018-02-13 16:37 GMT+01:00 Michael Olbrich : >> > > 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 > BTW one more comment: If --with-jpeg8 is specified, --with-jpeg7 has no effect. See configure.ac: if test "x${with_jpeg8}" = "xyes"; then JPEG_LIB_VERSION=80 else if test "x${with_jpeg7}" = "xyes"; then JPEG_LIB_VERSION=70 else JPEG_LIB_VERSION=62 fi fi So you may want to remove --with-jpeg7 from the .make file. Best, Guillermo Rodriguez Garcia guille.rodriguez@gmail.com --f403045f51b845ce40056529223f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= 2018-02-14 10:22 GMT+01:00 Guillermo Rodriguez Garcia <= ;guille.rod= riguez@gmail.com>:
Hi Michael,

2018-02-14 8:49 GMT+01:0= 0 Michael Olbrich <m.olbrich@pengutronix.de>:
On Tue, Feb 13, 2018 at 05:12:14PM +0100, Guillermo Ro= driguez 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 speci= fic
> > > libjpeg-turbo extensions that are not available in the stand= ard (IJG's)
> > > libjpeg library. So I started to create a set of ptxdist rul= es for
> > > libjpeg-turbo.
> > >
> > > libjpeg-turbo is supposed to provide a drop-in replacement f= or the
> > standard
> > > IJG's libjpeg, and in fact many Linux distributions have= already switched
> > > to it. So most packages that currently depend on LIBJPEG sho= uld be able
> > to
> > > use libjpeg-turbo as well without any changes.
> > >
> > > Example: gst-plugins-good1.in currently does the follo= wing:
> > >
> > > select LIBJPEG if GST_PLUGINS_GOOD1_JPEG
> > >
> > > However, gst-plugins-good1 should work just fine with libjpe= g-turbo as
> > > well. In fact the upstream gst-plugins already switched to l= ibjpeg-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-tur= bo 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 li= bjpeg would
> > not
> > > be able to benefit from the performance improvements in libj= peg-turbo.
> > Also
> > > I am not sure whether these two libraries (libjpeg and libjp= eg-turbo) can
> > > actually coexist in the same system.
> >
> > No.
> >
> > > 2. Modify the LIBJPEG rules to provide an option to select b= etween the
> > > standard (IJG) libjpeg, or libjpeg-turbo. This would be simi= lar to what
> > is
> > > done in alsa.in/alsa.make to select between the "ful= l" and "light"
> > versions
> > > of the library.
> >
> > Either this ...
> >
> > > 3. Other?
> >
> > ... or change the libjpeg rule to always build libjpeg-turbo inst= ead.
> >
> > 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<= br> > distros, I'd say that if we had to choose one, libjpeg-turbo may a= ctually
> be the "safe" choice.
>
>
> >
> > I have some libjpeg-turbo stuff lying around here somewhere. It w= as 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 d= o
> have an app that explicitly needs libjpeg-turbo and doesn't work w= ith 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 confir= m that both gst-plugins-good1 (with the jpeg plugin) and imagemagick both w= ork fine with libjpeg-turbo on my target platform.

Some comments:

- According to the documentation (= https://github.com/libjpeg-turbo/libjpeg-tur= bo/blob/master/BUILDING.md),=C2=A0NASM or YASM are required if bui= lding 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 th= at this can't be checked in the .in file?)

- F= or ARM targets, --with-simd requires NEON support. Perhaps the .make file s= hould do something like this:

# For ARM, enable SI= MD extensions only if NEON is available
ifdef PTXCONF_ARCH_AR= M_NEON
LIBJPEG_CONF_OPT +=3D --with-simd
endif
# For architectures other than ARM, enable SIMD extensions unconditio= nally
ifndef PTXCONF_ARCH_ARM
LIBJPEG_CONF_OPT= +=3D --with-simd
endif

BTW one more comment:

If = --with-jpeg8 is specified, --with-jpeg7 has no effect. See configure.ac:

=C2=A0 if t= est "x${with_jpeg8}" =3D "xyes"; then
=C2=A0 = =C2=A0 JPEG_LIB_VERSION=3D80
=C2=A0 else
=C2=A0 =C2=A0 = if test "x${with_jpeg7}" =3D "xyes"; then
=C2= =A0 =C2=A0 =C2=A0 JPEG_LIB_VERSION=3D70
=C2=A0 =C2=A0 else
<= div>=C2=A0 =C2=A0 =C2=A0 JPEG_LIB_VERSION=3D62
=C2=A0 =C2=A0 fi
=C2=A0 fi

So you may want to remove= --with-jpeg7 from the .make file.

Best,

Guillermo Rodriguez Garcia
guille.rodriguez@gmail.com
--f403045f51b845ce40056529223f-- --===============1097980024== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcHR4ZGlzdCBt YWlsaW5nIGxpc3QKcHR4ZGlzdEBwZW5ndXRyb25peC5kZQ== --===============1097980024==--