| Message ID | CA+pfegELseWchx5hbbChKKi-=xtQMO9CWTyKBEV+6RpRQVEqBA@mail.gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
Hello, Le Sun, 3 Jun 2012 05:57:46 +0300, Murat Demirten <mdemirten@yh.com.tr> a écrit : > --- /dev/null > +++ b/package/jpeg-turbo/Config.in > @@ -0,0 +1,26 @@ > +config BR2_PACKAGE_JPEG_TURBO > + bool "jpeg-turbo" Indentation should be one tab. > + help Here as well. > + It is a derivative of libjpeg that uses SIMD instructions > + (MMX, SSE2, NEON) to accelerate baseline JPEG compression > + and decompression on x86, x86-64, and ARM systems. > + > + http://libjpeg-turbo.virtualgl.org Indentation should be one tab + two spaces (for the help text) > +choice > + prompt "libjpeg api version" Fix indentation everywhere :) > --- /dev/null > +ifeq ($(BR2_PACKAGE_JPEG_TURBO_APIVERSION_62),y) > + JPEG_TURBO_CONF_ENV += JPEG_LIB_VERSION=62 > +endif > + > +$(eval $(call AUTOTARGETS)) > +$(eval $(call AUTOTARGETS,host)) There's no need to have a host variant of this package I think. Also, your patch is line-wrapped, so it cannot easily be applied. Could you fix your e-mail client, or better, use git send-email to send your patch? Thanks a lot for your contribution! Thomas
Hi, You're right, host package not important even if you're trying to build a filesystem for x86 platform because of the one-to-one compatibility of jpeg-turbo with libjpeg, I'll remove it. When I start to prepare .mk for jpeg-turbo, I see that there is a need for new dependency management option like "Provides: jpeg" in professional package management formats. Suppose that we built the jpeg-turbo and later we want to build tiff package. In this case, jpeg turbo will build and it replace jpeg-turbo's libjpeg.soXX files. For this reason, we have to build jpeg-turbo again to replace the libraries with correct ones. Is there any plan to address this issue in future? We just see that jpeg-turbo a lot faster than libjpeg especially on embedded environments. (I will send a patch with git send-email, previous one is the result of a firewall which blocking outgoing smtp and webmail client) 2012/6/3 Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > Hello, > > Le Sun, 3 Jun 2012 05:57:46 +0300, > Murat Demirten <mdemirten@yh.com.tr> a écrit : > > > --- /dev/null > > +++ b/package/jpeg-turbo/Config.in > > @@ -0,0 +1,26 @@ > > +config BR2_PACKAGE_JPEG_TURBO > > + bool "jpeg-turbo" > > Indentation should be one tab. > > > + help > > Here as well. > > > + It is a derivative of libjpeg that uses SIMD instructions > > + (MMX, SSE2, NEON) to accelerate baseline JPEG compression > > + and decompression on x86, x86-64, and ARM systems. > > + > > + http://libjpeg-turbo.virtualgl.org > > Indentation should be one tab + two spaces (for the help text) > > > +choice > > + prompt "libjpeg api version" > > Fix indentation everywhere :) > > > --- /dev/null > > +ifeq ($(BR2_PACKAGE_JPEG_TURBO_APIVERSION_62),y) > > + JPEG_TURBO_CONF_ENV += JPEG_LIB_VERSION=62 > > +endif > > + > > +$(eval $(call AUTOTARGETS)) > > +$(eval $(call AUTOTARGETS,host)) > > There's no need to have a host variant of this package I think. > > Also, your patch is line-wrapped, so it cannot easily be applied. Could > you fix your e-mail client, or better, use git send-email to send your > patch? > > Thanks a lot for your contribution! > > Thomas > -- > Thomas Petazzoni, Free Electrons > Kernel, drivers, real-time and embedded Linux > development, consulting, training and support. > http://free-electrons.com > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
Hi Murat, all, 2012/6/3 Murat Demirten <mdemirten@yh.com.tr> > > Hi, > > You're right, host package not important even if you're trying to build a filesystem for x86 platform because of the one-to-one compatibility of jpeg-turbo with libjpeg, I'll remove it. > > When I start to prepare .mk for jpeg-turbo, I see that there is a need for new dependency management option like "Provides: jpeg" in professional package management formats. You're right about that, I've just noticed that testing your patch. AFAIK, there is no such infrastructure in place in BR to handle this. Some other distro like gentoo has a virtual package mechanism. I think such a thing can be quite easily handle in BR: at the Config.in level: config BR2_PACKAGE_VIRTUAL_JPEG bool "jpeg support" if BR2_PACKAGE_VIRTUAL_JPEG choice ... config BR2_PACKAGE_VIRTUAL_JPEG_LIBJPEG bool "libjpeg" select config BR2_PACKAGE_VIRTUAL_JPEG_JPEG_TURBO bool "jpeg-turbo" ... endchoice endif if BR2_PACKAGE_VIRTUAL_JPEG_LIBJPEG source package/jpeg/Config.in endif if BR2_PACKAGE_VIRTUAL_JPEG_JPEG_TURBO source package/jpeg-turbo/Config.in endif at the *.mk level: virtual-jpeg.mk: # standard gentarget should do the job, no need for source/version/site variables VIRTUAL_JPEG_DEPENDENCY = \ $(if $(BR2_PACKAGE_LIBJPEG),libjpeg) \ $(if $(BR2_PACKAGE_JPEG_TURBO),jpeg-turbo)\ $(eval $(call GENTARGETS)) then all packages depending on jpeg should be ajdust to depends on virtual-jpeg. BTW, this has just popped up out my mind and need more careful thoughts I don't know which solution is the best between a virtual package mechanism or a "PROVIDE" variable mechanism. > > Suppose that we built the jpeg-turbo and later we want to build tiff package. In this case, jpeg turbo will build and it replace jpeg-turbo's libjpeg.soXX files. For this reason, we have to build jpeg-turbo again to replace the libraries with correct ones. > > Is there any plan to address this issue in future? We just see that jpeg-turbo a lot faster than libjpeg especially on embedded environments. Do you have any bench? I'd like to see that ;-) > > > (I will send a patch with git send-email, previous one is the result of a firewall which blocking outgoing smtp and webmail client) > > Again, thx for contributing to BR, Cheers, -- Sam
Hi, Your solution will work. Adding a PROVIDES mechanism need more work (like the what is provides-default of jpeg?). I'm not changing anything in patch now. I'm not sure about that to add a generic PROVIDES mechanism because it will increase the buildroot complexity if only used by jpeg-turbo. When we see that there are more packages like this, we have to add generic PROVIDES mechanism. jpeg-turbo's performance gain depends to type of images you're working on too. We tested it on mips and arm platform (yes, it make difference on mips too) and it is %30-%50 times faster than libjpeg (I don't have the exact results now). It is a big difference when you have to make lots of jpeg decompression in your program. I sent the same patch again with correct formatting. 2012/6/3 Samuel Martin <s.martin49@gmail.com> > Hi Murat, all, > > 2012/6/3 Murat Demirten <mdemirten@yh.com.tr> > > > > Hi, > > > > You're right, host package not important even if you're trying to build > a filesystem for x86 platform because of the one-to-one compatibility of > jpeg-turbo with libjpeg, I'll remove it. > > > > When I start to prepare .mk for jpeg-turbo, I see that there is a need > for new dependency management option like "Provides: jpeg" in professional > package management formats. > > You're right about that, I've just noticed that testing your patch. > > AFAIK, there is no such infrastructure in place in BR to handle this. > Some other distro like gentoo has a virtual package mechanism. > > I think such a thing can be quite easily handle in BR: > > at the Config.in level: > > config BR2_PACKAGE_VIRTUAL_JPEG > bool "jpeg support" > if BR2_PACKAGE_VIRTUAL_JPEG > choice > ... > config BR2_PACKAGE_VIRTUAL_JPEG_LIBJPEG > bool "libjpeg" > select > config BR2_PACKAGE_VIRTUAL_JPEG_JPEG_TURBO > bool "jpeg-turbo" > ... > endchoice > endif > > if BR2_PACKAGE_VIRTUAL_JPEG_LIBJPEG > source package/jpeg/Config.in > endif > > if BR2_PACKAGE_VIRTUAL_JPEG_JPEG_TURBO > source package/jpeg-turbo/Config.in > endif > > > at the *.mk level: > > virtual-jpeg.mk: > # standard gentarget should do the job, no need for > source/version/site variables > VIRTUAL_JPEG_DEPENDENCY = \ > $(if $(BR2_PACKAGE_LIBJPEG),libjpeg) \ > $(if $(BR2_PACKAGE_JPEG_TURBO),jpeg-turbo)\ > > $(eval $(call GENTARGETS)) > > then all packages depending on jpeg should be ajdust to depends on > virtual-jpeg. > > > BTW, this has just popped up out my mind and need more careful thoughts > > > I don't know which solution is the best between a virtual package > mechanism or a "PROVIDE" variable mechanism. > > > > > > Suppose that we built the jpeg-turbo and later we want to build tiff > package. In this case, jpeg turbo will build and it replace jpeg-turbo's > libjpeg.soXX files. For this reason, we have to build jpeg-turbo again to > replace the libraries with correct ones. > > > > Is there any plan to address this issue in future? We just see that > jpeg-turbo a lot faster than libjpeg especially on embedded environments. > > Do you have any bench? > I'd like to see that ;-) > > > > > > > (I will send a patch with git send-email, previous one is the result of > a firewall which blocking outgoing smtp and webmail client) > > > > > Again, thx for contributing to BR, > > > Cheers, > > > -- > Sam >
>>>>> "Murat" == Murat Demirten <mdemirten@yh.com.tr> writes:
Murat> Hi,
Murat> Your solution will work. Adding a PROVIDES mechanism need more
Murat> work (like the what is provides-default of jpeg?). I'm not
Murat> changing anything in patch now. I'm not sure about that to add a
Murat> generic PROVIDES mechanism because it will increase the
Murat> buildroot complexity if only used by jpeg-turbo. When we see
Murat> that there are more packages like this, we have to add generic
Murat> PROVIDES mechanism.
Murat> jpeg-turbo's performance gain depends to type of images you're
Murat> working on too. We tested it on mips and arm platform (yes, it
Murat> make difference on mips too) and it is %30-%50 times faster than
Murat> libjpeg (I don't have the exact results now). It is a big
Murat> difference when you have to make lots of jpeg decompression in
Murat> your program.
Is there any reason to NOT use jpeg-turbo? Isn't it source level
compatible with the "normal" libjpeg?
Yes, jpeg-turbo is source compatible with libjpeg and some distributions (including Ubuntu, Fedora, Gentoo) start to ship it for the default libjpeg. Please note that, jpeg-turbo and TurboJPEG-IPP is not the same, TurboJPEG has some disadvantages on new 64 bit systems and it's development stopped. 2012/6/4 Peter Korsgaard <jacmet@uclibc.org> > >>>>> "Murat" == Murat Demirten <mdemirten@yh.com.tr> writes: > > Murat> Hi, > > Murat> Your solution will work. Adding a PROVIDES mechanism need more > Murat> work (like the what is provides-default of jpeg?). I'm not > Murat> changing anything in patch now. I'm not sure about that to add a > Murat> generic PROVIDES mechanism because it will increase the > Murat> buildroot complexity if only used by jpeg-turbo. When we see > Murat> that there are more packages like this, we have to add generic > Murat> PROVIDES mechanism. > > Murat> jpeg-turbo's performance gain depends to type of images you're > Murat> working on too. We tested it on mips and arm platform (yes, it > Murat> make difference on mips too) and it is %30-%50 times faster than > Murat> libjpeg (I don't have the exact results now). It is a big > Murat> difference when you have to make lots of jpeg decompression in > Murat> your program. > > Is there any reason to NOT use jpeg-turbo? Isn't it source level > compatible with the "normal" libjpeg? > > -- > Bye, Peter Korsgaard >
diff --git a/package/Config.in b/package/Config.in index ca8fc96..5a23f66 100644 --- a/package/Config.in +++ b/package/Config.in @@ -336,6 +336,7 @@ source "package/gtk2-engines/Config.in" source "package/gtk2-themes/Config.in" source "package/imlib2/Config.in" source "package/jpeg/Config.in" +source "package/jpeg-turbo/Config.in" source "package/libart/Config.in" source "package/libdmtx/Config.in" source "package/libdrm/Config.in" diff --git a/package/jpeg-turbo/Config.in b/package/jpeg-turbo/Config.in new file mode 100644 index 0000000..a398079 --- /dev/null +++ b/package/jpeg-turbo/Config.in @@ -0,0 +1,26 @@ +config BR2_PACKAGE_JPEG_TURBO + bool "jpeg-turbo" + help + It is a derivative of libjpeg that uses SIMD instructions + (MMX, SSE2, NEON) to accelerate baseline JPEG compression + and decompression on x86, x86-64, and ARM systems. + + http://libjpeg-turbo.virtualgl.org + +choice + prompt "libjpeg api version" + default BR2_PACKAGE_JPEG_TURBO_APIVERSION_80 + depends on BR2_PACKAGE_JPEG_TURBO + help + Selects libjpeg compatible api version. + +config BR2_PACKAGE_JPEG_TURBO_APIVERSION_62 + bool "62" + +config BR2_PACKAGE_JPEG_TURBO_APIVERSION_70 + bool "70" + +config BR2_PACKAGE_JPEG_TURBO_APIVERSION_80 + bool "80" + +endchoice diff --git a/package/jpeg-turbo/jpeg-turbo.mk b/package/jpeg-turbo/ jpeg-turbo.mk new file mode 100644 index 0000000..7cfd8c1 --- /dev/null +++ b/package/jpeg-turbo/jpeg-turbo.mk @@ -0,0 +1,23 @@ +############################################################# +# +# jpeg-turbo +# +############################################################# +JPEG_TURBO_VERSION = 1.2.0 +JPEG_TURBO_SITE = http://$(BR2_SOURCEFORGE_MIRROR). dl.sourceforge.net/sourceforge/libjpeg-turbo +JPEG_TURBO_SOURCE = libjpeg-turbo-$(JPEG_TURBO_VERSION).tar.gz + +ifeq ($(BR2_PACKAGE_JPEG_TURBO_APIVERSION_80),y) + JPEG_TURBO_CONF_ENV += JPEG_LIB_VERSION=80 +endif + +ifeq ($(BR2_PACKAGE_JPEG_TURBO_APIVERSION_70),y) + JPEG_TURBO_CONF_ENV += JPEG_LIB_VERSION=70 +endif + +ifeq ($(BR2_PACKAGE_JPEG_TURBO_APIVERSION_62),y) + JPEG_TURBO_CONF_ENV += JPEG_LIB_VERSION=62 +endif + +$(eval $(call AUTOTARGETS))