FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 04-23-2012, 10:16 AM
Samuli Suominen
 
Default 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.
 
Old 04-23-2012, 10:43 AM
Ulrich Mueller
 
Default 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
 
Old 04-23-2012, 11:22 AM
Samuli Suominen
 
Default 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.
 
Old 04-23-2012, 11:58 AM
Richard Yao
 
Default 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?
 
Old 04-23-2012, 12:10 PM
Matt Turner
 
Default 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.)
 
Old 04-23-2012, 12:28 PM
Duncan
 
Default 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
 
Old 04-23-2012, 12:42 PM
Samuli Suominen
 
Default 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.
 
Old 04-23-2012, 02:17 PM
Mike Gilbert
 
Default 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)
 
Old 04-23-2012, 05:49 PM
Pacho Ramos
 
Default 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.
 
Old 04-23-2012, 05:55 PM
Zac Medico
 
Default 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
 

Thread Tools




All times are GMT. The time now is 11:47 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org