Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo Development (http://www.linux-archive.org/gentoo-development/)
-   -   RFC: A tiny news item for migrating to libjpeg-turbo (http://www.linux-archive.org/gentoo-development/658750-rfc-tiny-news-item-migrating-libjpeg-turbo.html)

Samuli Suominen 04-23-2012 10:16 AM

RFC: A tiny news item for migrating to libjpeg-turbo
 
I don't really think this is necessary, but some people seem to.

Looks fine?

- Samuli
Title: The default JPEG implementation is libjpeg-turbo
Author: Samuli Suominen <ssuominen@gentoo.org>
Content-Type: text/plain
Posted: 2012-04-23
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: =media-libs/jpeg-8*

libjpeg-turbo is a derivative of libjpeg that uses MMX, SSE, SSE2, and NEON
SIMD instructions to accelerate baseline JPEG compression/decompression by
about 2-4x on x86, x86-64, and ARM platforms. It is based on libjpeg/SIMD but
has numerous enhancements.

All users are recommended to migrate:

# emerge -C media-libs/jpeg:0
# emerge -1 media-libs/libjpeg-turbo

From here on out media-libs/jpeg:0 is only used as a fallback and at the time
of writing this news item, libjpeg-turbo has no known bugs that would require
using it.

Ulrich Mueller 04-23-2012 10:43 AM

RFC: A tiny news item for migrating to libjpeg-turbo
 
>>>>> On Mon, 23 Apr 2012, Samuli Suominen wrote:

> I don't really think this is necessary, but some people seem to.
> Looks fine?

> Title: The default JPEG implementation is libjpeg-turbo

Too long. GLEP 42 allows a maximum of 44 characters only.

> Author: Samuli Suominen <ssuominen@gentoo.org>
> Content-Type: text/plain
> Posted: 2012-04-23
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: =media-libs/jpeg-8*

> libjpeg-turbo is a derivative of libjpeg that uses MMX, SSE, SSE2, and NEON
> SIMD instructions to accelerate baseline JPEG compression/decompression by
> about 2-4x on x86, x86-64, and ARM platforms. It is based on libjpeg/SIMD but
> has numerous enhancements.

I'd suggest to use our standard names for these architectures, i.e. x86,
amd64, and arm.

> All users are recommended to migrate:

> # emerge -C media-libs/jpeg:0
> # emerge -1 media-libs/libjpeg-turbo

> >From here on out media-libs/jpeg:0 is only used as a fallback and at the time
> of writing this news item, libjpeg-turbo has no known bugs that would require
> using it.

Maybe avoid the word "From" at the beginning of the line. eselect news
will escape it properly, but it looks somewhat ugly.

And please wrap the body text at 72 chars (GLEP 42 says so).

Ulrich

Samuli Suominen 04-23-2012 11:22 AM

RFC: A tiny news item for migrating to libjpeg-turbo
 
On 04/23/2012 01:43 PM, Ulrich Mueller wrote:

On Mon, 23 Apr 2012, Samuli Suominen wrote:



I don't really think this is necessary, but some people seem to.
Looks fine?



Title: The default JPEG implementation is libjpeg-turbo


Too long. GLEP 42 allows a maximum of 44 characters only.


Author: Samuli Suominen<ssuominen@gentoo.org>
Content-Type: text/plain
Posted: 2012-04-23
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: =media-libs/jpeg-8*



libjpeg-turbo is a derivative of libjpeg that uses MMX, SSE, SSE2, and NEON
SIMD instructions to accelerate baseline JPEG compression/decompression by
about 2-4x on x86, x86-64, and ARM platforms. It is based on libjpeg/SIMD but
has numerous enhancements.


I'd suggest to use our standard names for these architectures, i.e. x86,
amd64, and arm.


All users are recommended to migrate:



# emerge -C media-libs/jpeg:0
# emerge -1 media-libs/libjpeg-turbo



> From here on out media-libs/jpeg:0 is only used as a fallback and at the time
of writing this news item, libjpeg-turbo has no known bugs that would require
using it.


Maybe avoid the word "From" at the beginning of the line. eselect news
will escape it properly, but it looks somewhat ugly.

And please wrap the body text at 72 chars (GLEP 42 says so).


Thanks Ulrich. See attachment as draft #2.
Title: The default JPEG implementation
Author: Samuli Suominen <ssuominen@gentoo.org>
Content-Type: text/plain
Posted: 2012-04-23
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: =media-libs/jpeg-8*

libjpeg-turbo is a derivative of libjpeg that uses MMX, SSE, SSE2,
and NEON SIMD instructions to accelerate baseline JPEG
compression/decompression by about 2-4x on amd64, arm and x86
platforms. It is based on libjpeg/SIMD but has numerous enhancements.

All users are recommended to migrate:

# emerge -C media-libs/jpeg:0
# emerge -1 media-libs/libjpeg-turbo

media-libs/jpeg:0 will be left in tree as a fallback implementation
in case libjpeg-turbo will become unmaintained or suffers from issues
caused by, for example, upgrading the toolchain.

Richard Yao 04-23-2012 11:58 AM

RFC: A tiny news item for migrating to libjpeg-turbo
 
On 04/23/12 06:16, Samuli Suominen wrote:
> I don't really think this is necessary, but some people seem to.
>
> Looks fine?
>
> - Samuli

What is the plan for platforms that are not supported by libturbo?

Matt Turner 04-23-2012 12:10 PM

RFC: A tiny news item for migrating to libjpeg-turbo
 
On Mon, Apr 23, 2012 at 7:58 AM, Richard Yao <ryao@cs.stonybrook.edu> wrote:
> What is the plan for platforms that are not supported by libturbo?

It's not that they're not supported, just that libjpeg-turbo doesn't
have optimized routines for them. It'll still run fine. (Check the
keywords, you'll see that it's stabilized.)

Duncan 04-23-2012 12:28 PM

RFC: A tiny news item for migrating to libjpeg-turbo
 
Samuli Suominen posted on Mon, 23 Apr 2012 14:22:53 +0300 as excerpted:

> Title: The default JPEG implementation

[...]

> All users are recommended to migrate:
>
> # emerge -C media-libs/jpeg:0
> # emerge -1 media-libs/libjpeg-turbo

That of course leaves the system without a jpeg library between the jpeg
unmerge and the completion of the libjpeg-turbo merge. If the build
process fails for some reason...

There's no way to use portage's automatic block-resolving ability here to
avoid that, I take it?

I'd suggest warning people that some image processing apps might not work
during the interim, and possibly suggest using qpkg to package up the old
version for quick binpkg remerge, if the build goes bad. And/or
ebuild /path/to/libjpeg-turbo-ebuild package up the new version first, so
it's know to have at least built and binpkged correctly, before unmerging
jpeg.

Since such instructions get a bit detailed for a news item overview,
perhaps a link to a page explaining these sorts of details would be more
appropriate than putting all that detail in the news item.

> media-libs/jpeg:0 will be left in tree as a fallback implementation in
> case libjpeg-turbo will become unmaintained or suffers from issues
> caused by, for example, upgrading the toolchain.

s/will become/becomes/

("Becomes" is more common usage and agrees better with "suffers" as well,
which would otherwise need to be "will suffer" to match, but that's just
a stilted construction all around, then.)

Also possibly: s/in tree/in the tree/
Alternatively: s/in tree/in-tree/

("The" is arguably needed here, unless it's made a single compound word,
in-tree. However, this isn't as odd sounding to me as the "in case ...
will become" syntax and it may just be me being picky. Another opinion
might be helpful.)

Or better yet, the reasons the fallback might be needed don't really need
to be enumerated at all. What about simply omitting that, leaving only:

media-libs/jpeg:0 will be left in the tree as a fallback implementation.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

Samuli Suominen 04-23-2012 12:42 PM

RFC: A tiny news item for migrating to libjpeg-turbo
 
On 04/23/2012 02:58 PM, Richard Yao wrote:

On 04/23/12 06:16, Samuli Suominen wrote:

I don't really think this is necessary, but some people seem to.

Looks fine?

- Samuli


What is the plan for platforms that are not supported by libturbo?



Matt's reply is accurate.

Mike Gilbert 04-23-2012 02:17 PM

RFC: A tiny news item for migrating to libjpeg-turbo
 
On Mon, Apr 23, 2012 at 8:28 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> Samuli Suominen posted on Mon, 23 Apr 2012 14:22:53 +0300 as excerpted:
>
>> Title: The default JPEG implementation
>
> [...]
>
>> All users are recommended to migrate:
>>
>> # emerge -C media-libs/jpeg:0
>> # emerge -1 media-libs/libjpeg-turbo
>
> That of course leaves the system without a jpeg library between the jpeg
> unmerge and the completion of the libjpeg-turbo merge. *If the build
> process fails for some reason...
>
> There's no way to use portage's automatic block-resolving ability here to
> avoid that, I take it?
>

This works for me.

floppym@naomi ~ % emerge -pv1 -j1 libjpeg-turbo

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild N ] media-libs/libjpeg-turbo-1.2.0-r1 USE="-java
-static-libs" 0 kB
[uninstall ] media-libs/jpeg-8d USE="-static-libs"
[blocks b ] media-libs/jpeg:0 ("media-libs/jpeg:0" is blocking
media-libs/libjpeg-turbo-1.2.0-r1)

Pacho Ramos 04-23-2012 05:49 PM

RFC: A tiny news item for migrating to libjpeg-turbo
 
El lun, 23-04-2012 a las 10:17 -0400, Mike Gilbert escribió:
> On Mon, Apr 23, 2012 at 8:28 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> > Samuli Suominen posted on Mon, 23 Apr 2012 14:22:53 +0300 as excerpted:
> >
> >> Title: The default JPEG implementation
> >
> > [...]
> >
> >> All users are recommended to migrate:
> >>
> >> # emerge -C media-libs/jpeg:0
> >> # emerge -1 media-libs/libjpeg-turbo
> >
> > That of course leaves the system without a jpeg library between the jpeg
> > unmerge and the completion of the libjpeg-turbo merge. If the build
> > process fails for some reason...
> >
> > There's no way to use portage's automatic block-resolving ability here to
> > avoid that, I take it?
> >
>
> This works for me.
>
> floppym@naomi ~ % emerge -pv1 -j1 libjpeg-turbo
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
> [ebuild N ] media-libs/libjpeg-turbo-1.2.0-r1 USE="-java
> -static-libs" 0 kB
> [uninstall ] media-libs/jpeg-8d USE="-static-libs"
> [blocks b ] media-libs/jpeg:0 ("media-libs/jpeg:0" is blocking
> media-libs/libjpeg-turbo-1.2.0-r1)
>
>

I guess it will work when jpeg is not in world file... maybe people
should be told to drop it and, then, let emerge do all the work
automatically.

Zac Medico 04-23-2012 05:55 PM

RFC: A tiny news item for migrating to libjpeg-turbo
 
On 04/23/2012 10:49 AM, Pacho Ramos wrote:

El lun, 23-04-2012 a las 10:17 -0400, Mike Gilbert escribió:

On Mon, Apr 23, 2012 at 8:28 AM, Duncan<1i5t5.duncan@cox.net> wrote:

Samuli Suominen posted on Mon, 23 Apr 2012 14:22:53 +0300 as excerpted:


Title: The default JPEG implementation


[...]


All users are recommended to migrate:

# emerge -C media-libs/jpeg:0
# emerge -1 media-libs/libjpeg-turbo


That of course leaves the system without a jpeg library between the jpeg
unmerge and the completion of the libjpeg-turbo merge. If the build
process fails for some reason...

There's no way to use portage's automatic block-resolving ability here to
avoid that, I take it?



This works for me.

floppym@naomi ~ % emerge -pv1 -j1 libjpeg-turbo

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild N ] media-libs/libjpeg-turbo-1.2.0-r1 USE="-java
-static-libs" 0 kB
[uninstall ] media-libs/jpeg-8d USE="-static-libs"
[blocks b ] media-libs/jpeg:0 ("media-libs/jpeg:0" is blocking
media-libs/libjpeg-turbo-1.2.0-r1)




I guess it will work when jpeg is not in world file... maybe people
should be told to drop it and, then, let emerge do all the work
automatically.


This will do the trick:

emerge --deselect media-libs/jpeg
emerge --oneshot media-libs/libjpeg-turbo

--
Thanks,
Zac


All times are GMT. The time now is 01:32 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.