Re: [chromium-dev] Does Chrome use GPU to decode jpeg images on Android?

987 views
Skip to first unread message

Alexandre Elias

unread,
Apr 10, 2014, 9:22:28 PM4/10/14
to ducbu...@gmail.com, Chromium-dev
We don't, and don't currently have any plans to do so.  The JPEG format is not very well-suited for GPU decompression.  One part of it is, the YUV -> RGB colorspace conversion, and we might consider doing that on the GPU someday, but there are complications for that as well (e.g. shipping the raw image over to the GPU process).

--
Alex


On Wed, Apr 9, 2014 at 4:48 AM, Duc H. Bui <ducbu...@gmail.com> wrote:
Dear all,
In event traces of Chrome on Android during a page load, jpeg image decoding seems to take place in a CompositorRaterWorker thread. This image decoding takes a lot of CPU time.

I just wonder whether Chrome uses GPU to decode jpeg on Android or not?

The attached file shows the trace when loading apple.com over 3G on my Nexus 4 with Android 4.2.2.

Best regards,
Duc H. Bui

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

Stéphane Marchesin

unread,
Apr 10, 2014, 9:29:54 PM4/10/14
to Alexandre Elias, ducbu...@gmail.com, Chromium-dev
On Thu, Apr 10, 2014 at 6:22 PM, Alexandre Elias <ael...@google.com> wrote:
> We don't, and don't currently have any plans to do so. The JPEG format is
> not very well-suited for GPU decompression.

Actually some GPUs have dedicated JPEG decoding units, so in this case
it would be very well suited. But as you mention, you still need
plumbing and such...

Stéphane

Tom Hudson

unread,
Apr 11, 2014, 7:21:44 AM4/11/14
to ducbu...@gmail.com, Chromium-dev, graphi...@chromium.org
On Wed, Apr 9, 2014 at 12:48 PM, Duc H. Bui <ducbu...@gmail.com> wrote:
Dear all,
In event traces of Chrome on Android during a page load, jpeg image decoding seems to take place in a CompositorRaterWorker thread. This image decoding takes a lot of CPU time.
The attached file shows the trace when loading apple.com over 3G on my Nexus 4 with Android 4.2.2.

It's not *quite* as bad as it looks in that screenshot: the raster worker thread runs at a low priority, and during the two really slow decodes (>> 40ms) the thread is getting repeatedly suspended.

But there are only 5 large jpegs on that homepage; seeing more than 5 decodes suggests that our image cache is once again not keeping up with the load?

Tom

Jimmy Milleson

unread,
Apr 11, 2014, 9:04:36 AM4/11/14
to chromi...@chromium.org, ducbu...@gmail.com, graphi...@chromium.org
Hi,

We at Opera have a working implementation for the YUV -> RGB on the GPU. There are still some things
to work out (getting it to work in hybrid ganesh properly and more testing). We only do the upscaling and
transformation on the GPU, but are exploring doing the IDCT on the GPU as well. There are some research
papers decribing differrent ways of doing this, the hard parts would get it to fit with chromium nicely.

Erik Möller

unread,
Apr 11, 2014, 10:54:02 AM4/11/14
to Jimmy Milleson, chromi...@chromium.org, ducbu...@gmail.com, graphi...@chromium.org
Our plan is to give a bit of an update on this and our texture
compression work at BlinkOn2 in May.

//Erik
> To unsubscribe from this group and stop receiving emails from it, send an
> email to graphics-dev...@chromium.org.



--
Erik Moller
Team Manager Android
Opera Software

Alexandre Elias

unread,
Apr 11, 2014, 3:39:00 PM4/11/14
to Erik Möller, Jimmy Milleson, Chromium-dev, Duc H. Bui, graphi...@chromium.org
OK, we'll be interested to hear about it, thanks!

This may actually be a good synergy with hybrid ganesh, which requires shipping image data to the GPU process anyway.  Shipping over partially compressed data would reduce the burden of that (although this will have to be weighed against shader capacity which is also more valuable in a ganesh world -- I'll be interested to see how the tradeoff shakes out).

Patrick Meenan

unread,
Apr 25, 2014, 3:20:10 PM4/25/14
to graphi...@chromium.org, Erik Möller, Jimmy Milleson, Chromium-dev, Duc H. Bui
Have we experimented at all with using the dedicated ASICs on phones?  Most (all?) of them have hardware dedicated to JPEG decoding for dealing with photos.  It looks like TI provided Skia support for their OMAP chips in Android back in 2009.  If it's a memory bus issue then it won't help a lot because you'd still be moving the raw decoded pixels to the GPU instead of the smaller YUV data but it could be a net win if you could completely offload the decode to the already-present hardware (presumably would use less power too).

Brian Salomon

unread,
Apr 25, 2014, 3:30:14 PM4/25/14
to Jimmy Milleson, Chromium-dev, ducbu...@gmail.com, graphi...@chromium.org
Jimmy, Feel free to contact myself or others on the Skia team if you'd like to coordinate your efforts with us. We've had this on our mind for some time but haven't committed any resources to it yet.

Brian
Reply all
Reply to author
Forward
0 new messages