Re: Issue 161828 in chromium: Investigate JSGameBench performance

[chro...@googlecode.com]

Updates:
Cc: wiltz...@chromium.org ju...@chromium.org bsalo...@chromium.org
senorbla...@chromium.org al...@chromium.org

Comment #1 on issue 161828 by wiltz...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

GPU eng shouldn't worry about this until the android perf code yellow is
over, but we should definitely revisit. We looked at JSGameBench quite a
bit when enabling accelerated canvas in the beginning of this year. We got
to the point where we were within spitting distance of FF and IE, although
not beating them handily. I'm actually really surprised that IE is losing
in the Tom's benchmark, as they used to own at this. Keep in mind that was
all Win7 testing, but the results seem to show inferiority at Win7 too.

I'm going to rerun locally for curiosity.

[chro...@googlecode.com]

Updates:
Cc: vang...@chromium.org

Comment #2 on issue 161828 by wiltz...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #3 on issue 161828 by ju...@google.com: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

Tom: Chrome 23 shipped with deferred 2d canvas enabled by default. If you
re-run locally, make sure to check it out with and without deferred canvas.

[chro...@googlecode.com]

Comment #4 on issue 161828 by esei...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

For those following along at home. I downloaded and ran jsgamebench on
both Chrome and Safari (built from TOT) and 90+% of the time is spent in
gpu/drawing code. I was curious to make sure that WebKit wasn't doing
anything stupid on these benchmarks. I don't know enough about the
compositing/gpu side of things yet to be of much further use, unfortunately.

QuartzDebug
(http://developer.apple.com/library/mac/#qa/qa1236/_index.html) "flash on
screen updates" shows us redrawing the entire screen for every frame, which
may be caused by the "gameui" absolutely positioned <div> in the upper-left
corner. It's also possible that QuartzDebug is just confused by Chrome's
drawing model.

[chro...@googlecode.com]

Comment #6 on issue 161828 by wiltz...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

I recently re-ran JSGameBench on Windows. I don't get findings that really
accord with the Toms Hardware ones. Chrome dev 25.0.1337.0 gets around 1700
on this machine, and drops to 1400 or so when I disable deferred canvas.
IE9 gets around 2000. IE10 does terribly, scoring <100... something's
clearly wrong there.

IE10 aside, these results are consistent with what we saw months ago after
enabling accelerated Canvas. I'm not sure how Toms Hardware got such
different numbers. I'll need to test on Win8 still, but don't anticipate
huge differences there.

[chro...@googlecode.com]

Updates:
Cc: robertph...@chromium.org

Comment #7 on issue 161828 by ju...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

These are interesting numbers. This benchmark draws a series of sprites
from a sprite set. Two things come to mind:

1. Is the texture domain feature kicking in ganesh? I don't think it need
to be in this case, so if it is, we should investigate and find a way to
optimize it out.
2. Are we missing out on rectangle batching opportunities in GrContext?
Consecutive draws are using different sprites. I have not checked whether
the sprites are packed into the same texture or not, but if they are, it
should be straightforward to draw them as a batch.

[chro...@googlecode.com]

Comment #8 on issue 161828 by to...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

THG has also tested JSGameBench on Android and we are an order of magnitude
behind the pack there.
http://www.tomshardware.com/reviews/android-web-browser-recommendation,3316-7.html

[chro...@googlecode.com]

Comment #9 on issue 161828 by wiltz...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

I can have a goat running JSGameBench on a phone. Note that since Chrome
for Android is M18-based it barely got the first version of accelerated
canvas, much less the improvements since then like deferred Canvas. It'll
be interesting to see how much better (or worse :p) we get on an M25 build.

[chro...@googlecode.com]

Comment #12 on issue 161828 by wiltz...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

What's the best way to run on a real device? Are there instructions
somewhere for how to turn off power saving, etc?

[chro...@googlecode.com]

Comment #13 on issue 161828 by rcr...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

The documentation that we have so far is here:
https://sites.google.com/a/chromium.org/dev/developers/telemetry

The documentation is still very much a work in progress, ping again if this
is not sufficient :)

[chro...@googlecode.com]

Comment #14 on issue 161828 by to...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

Since the benchmark isn't hosted anywhere permanent, the best way to run is
to use Telemetry:
$ tools/perf/run_multipage_benchmarks --browser=android-content-shell
jsgamebench tools/perf/page_sets/jsgamebench.json
or --browser=android-chrome

To disable power saving:
$ adb shell "echo performance >
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor"

There's a patch up now to have Telemetry disable the power saving for you.

[chro...@googlecode.com]

Comment #15 on issue 161828 by wiltz...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Ah, yes that power saving command is what I was looking for, thanks! Will
give that a go.

[chro...@googlecode.com]

Comment #17 on issue 161828 by klo...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

Tony, can you update the number for m25 on Transformer?

As N10 is 130 while Prime is 2, something is fishy. Possible we hit some
glitch of the driver. It will be interesting to see whether virtual context
can help this for Prime.

[chro...@googlecode.com]

Updates:
Cc: klo...@chromium.org

Comment #18 on issue 161828 by klo...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

[chro...@googlecode.com]

Updates:
Cc: aber...@chromium.org

Comment #19 on issue 161828 by aber...@chromium.org: Investigate

[chro...@googlecode.com]

Updates:
Status: Assigned
Owner: skyos...@chromium.org
Cc: tomhud...@chromium.org

Comment #20 on issue 161828 by tomhud...@chromium.org: Investigate

[chro...@googlecode.com]

Comment #22 on issue 161828 by aber...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

According to https://github.com/facebook/jsgamebench the test is measuring
the number of sprites that can be drawn at 30 fps. Watching the fps score
on the screen (you need good eyes to see this) it looks as if it is, most
of the time, only achieving around 17 to 25 fps. This is still true even
when only the background is drawn.

As such, for most of the test, the score will be 0, hence giving a low
overall score.

The question is, of course, why drawing the background is so slow.

[chro...@googlecode.com]

Comment #23 on issue 161828 by aber...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

I think I understand, at a very superficial level, why the results of this
test appear so amazingly bad on Prime. The results are, under some
circumstances, not linear with graphics performance.

According to https://github.com/facebook/jsgamebench the test is measuring
the number of sprites that can be drawn at 30 fps. Watching the fps score
on the screen (you need good eyes to see this) it looks as if it is, most
of the time, only achieving around 17 to 25 fps. This is still true even

when only the background is drawn, and the number of sprites seems to make
little difference to the frame rate.

[chro...@googlecode.com]

Comment #24 on issue 161828 by skyos...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Some numbers with --enable-virtual-gl-contexts:

Nexus 10: 193 (205 with --disable-deferred-canvas)
Nexus 7: 67 (26)
Nexus 4: 119 (116)
Galaxy Nexus: 1 (1)

Neither --enable-virtual-gl-contexts nor --disable-deferred-2d-canvas seem
to make any difference to the GN result.

I captured a trace during the canvas portion of the benchmark and we seem
to be spending 50 ms every frame decoding PNGs. Could this be some kind of
side effect of the spriting the benchmark is doing?

Attachments:
jsgamebench-canvas.trace.gz 815 KB

[chro...@googlecode.com]

Comment #28 on issue 161828 by klo...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

I believe that is true for the canvas2D. Daniel mentioned that he can make
one line change to let canvas2D, the offscreen case, also use virtual
context.

[chro...@googlecode.com]

Comment #33 on issue 161828 by skyos...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

The Asus Transformer TF300T has the same amount of RAM as the Galaxy Nexus,
so we're probably also trashing the image decoding cache there.

Is there a bug for the ashmem cache?

[chro...@googlecode.com]

Comment #34 on issue 161828 by klo...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

Min is working on ashmem support for async image decoding case. It will be
used with impl-side painting.

Both Galaxy Nexus and TF300T are 1G device. But the system carved out some,
so the reported physical memory is less than 1G. This makes Chrome for
Android uses smaller cache. As Chrome for Android only has very limited
number of the render process, we should be more aggressive in the cache
size.

I just run the test with 32M for Galaxy Nexus. I got score as 54 and I
didn't see the instability. Sami, do you still see OOM crash issue with
higher cache size?

[chro...@googlecode.com]

Comment #35 on issue 161828 by skyos...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

I've just re-tested on Galaxy Nexus with ToT and 32 MB and the instability
seems to be gone. The JSGameBench score on this device is 94-100 -- not
sure why it is higher than yours. It looks like we might be able to
increase the cache size after all.

As far as I can tell the cache size is shared by the renderers, so I think
the fact that Android limits the total number of renderers isn't really a
reason to make the cache any bigger.

On Galaxy Nexus the system reports 694 MB of RAM. I don't have a TF300T to
test with, but a TF700T shows 969 MB The threshold for a 32 MB cache in
web_cache_manager.cc:GetDefaultCacheSize() is 1000 MB, so both devices get
lumped to the 512 MB category.

One way to fix this would be to add a new 24 MB cache size for devices
between 512 MB and 1024 MB. I've tested that this gives the same
JSGameBench score on Galaxy Nexus. However, since 969 MB is so close to 1
GB, I'm also tempted to tweak the numbers so that the TF700T gets a
seemingly more appropriate 32 MB cache.

[chro...@googlecode.com]

Comment #36 on issue 161828 by skyos...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

I also tried making the cache always be 1/32th of the RAM size, which gives
20 MB for Galaxy Nexus, but it doesn't look like enough for the benchmark.

[chro...@googlecode.com]

Comment #37 on issue 161828 by klo...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

The cache size is to control WebCore::MemoryCache. It should be per render
process. The default number is shared by all the renderers.

I don't think there are desktop/laptop using less than 1G memory nowasdays.
So Chrome for Android may be the only one affected by this. We can just
change it after confirming.

[chro...@googlecode.com]

Comment #38 on issue 161828 by wiltz...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

I think that's a reasonable assumption (that desktops/laptops with <1G RAM
are rare beasts). I will try to confirm with UMA stats.

[chro...@googlecode.com]

Comment #41 on issue 161828 by nd...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

Erm, dumb question --- is this the image cache? We dont use the webkit
image cache when impl side painting turns on...

[chro...@googlecode.com]

Comment #42 on issue 161828 by klo...@google.com: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

Yes. This is the WebKit MemoryCache. In impl side painting case, the JPEG
won't use this pool. But I believe gif/png still go through this.

For ashmem, we will first turn it on for async decoding with impl side
painting. If necessary, we will look into turn it on for webkit decoding
case.

The tweak in the CL is only affecting low end devices, avail mem less than
1G. So it should not affect desktop.

[chro...@googlecode.com]

Comment #43 on issue 161828 by nd...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

Are you sure of it? I'd check with hclam or use the benchmark.

[chro...@googlecode.com]

Comment #44 on issue 161828 by nd...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

er, s/use the benchmark/verify with deferred image decoding turned on/

typing fail

[chro...@googlecode.com]

Updates:
Owner: skyos...@chromium.org
Cc: hc...@chromium.org

Comment #45 on issue 161828 by skyos...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

[+hclam]

I'll see what the effect of impl side painting and/or deferred image
decoding is on this.

[chro...@googlecode.com]

Comment #46 on issue 161828 by wiltz...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

This may or may not be relevant pending the outcome of later discussion,
but following up on a previous comment about memory; approximately 7% of
Windows users of Chrome have <1G of RAM according to UMA stats (which tends
to bias towards slightly better hardware). Therefore I'd be a little wary
of assuming that most people have >1G of RAM. Perhaps we could check, or
use a heuristic like Sami proposed to use 1/32 of RAM or something.

[chro...@googlecode.com]

Comment #47 on issue 161828 by skyos...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Here are some more numbers on Galaxy Nexus:

Default cache size
------------------
Baseline: 22
--enable-deferred-image-decoding: 94
--enable-impl-side-painting: 1
--enable-impl-side-painting --enable-deferred-image-decoding: 1

With larger cache
-----------------
Baseline: 87
--enable-deferred-image-decoding: 86
--enable-impl-side-painting: 1
--enable-impl-side-painting --enable-deferred-image-decoding: 1

It seems like deferred image decoding gives more or less the same benefit
as increasing the cache size. From comment 46 it seems like deferred image
decoding may be the safer choice -- if it's stable enough to be flipped on.
Anyone know its status?

OTOH impl side painting isn't working that well yet. I'll take some traces
to see what is going wrong.

[chro...@googlecode.com]

Comment #48 on issue 161828 by klo...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

The current deferred image caching doesn't use ashmem yet. But it used a
separate pool to manage the threshold, which is 32M no matter the size of
the physical memory. So it makes sense that we see the similar result
comparing just raise the cache size. I believe the plan is to
turn "enable-deferred-image-decoding" on with impl-side painting. I think
it is ok to turn it on earlier if needed.

Impl-side painting is still in early state, especially for canvas. So it is
not too surprise the performance is not there yet.

[chro...@googlecode.com]

Comment #49 on issue 161828 by skyos...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Ok, it sounds like we should block this bug on ashmem-enabled deferred
image decoding. Agreed?

[chro...@googlecode.com]

Comment #50 on issue 161828 by hc...@google.com: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

Min is working on adding ashmem support to deferred image decoding. I
expect you'll have improvements on sites with a lot of images.

[chro...@googlecode.com]

Comment #54 on issue 161828 by klo...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

FYI, the original bug is about desktop Chrome vs Firefox. We hijacked it
for Chrome for Android. So I think we should leave the bug open as I doubt
the desktop is memory issue.

Sami, can you get a score of Dolphin Jetpack on Galaxy Nexus for comparison?

[chro...@googlecode.com]

Comment #56 on issue 161828 by klo...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

Good to see the big jump. In the Tom's hardware test, it was 82 vs. 2 on
TF300T. Now with a simple memory bump, we are 31 vs. 100 on Galaxy Nexus.
Hope this will be reflected in the external testing.

Sami, now Chrome for Android is fine. But the original bug is about desktop
Chrome vs. Firefox, feel free to change it to available.

[chro...@googlecode.com]

Updates:
Status: Available
Owner: ---

Comment #57 on issue 161828 by skyos...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Sure.

FWIW, --enable-webgl is another way to improve this benchmark. On Nexus 4
the canvas part hovers around 300 while the WebGL one is at 750. However,
the final composite score doesn't reflect this improvement. I'm not sure
how exactly it is calculated.

Furthermore, with --enable-webgl the benchmark looks broken on Galaxy
Nexus: https://crbug.com/169444.

[chro...@googlecode.com]

Updates:
Status: Assigned
Owner: srika...@chromium.org

Comment #59 on issue 161828 by ke...@google.com: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

[chro...@googlecode.com]

Comment #60 on issue 161828 by srika...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Holding this till we make the call on impl-side painting.

[chro...@googlecode.com]

Updates:
Owner: skyos...@chromium.org

Comment #61 on issue 161828 by srika...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

This may need some more digging. With impl-side painting on now on trunk,
not seeing the benchmark move in the right direction.

GN is still hovering between 0-2
http://build.chromium.org/f/chromium/perf/android-gn/jsgamebench/report.html?history=50&rev=-1

N4 & N10 both showed a drop
http://build.chromium.org/f/chromium/perf/android-nexus4/jsgamebench/report.html?history=50&rev=-1
http://build.chromium.org/f/chromium/perf/android-nexus10/jsgamebench/report.html?history=50&rev=-1

Sami - apologies for pulling you back into this but can you see if any
important patches need to still make its way on trunk (and subsequently to
M25 via the mega patch)?

[chro...@googlecode.com]

Comment #62 on issue 161828 by skyos...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Sure, I think this needs another pass anyway now that impl side painting is
shaping up. AFAIK we don't yet have ashmem for image decoding, but deferred
image decoding should be turned on along with impl-side painting. I'll
verify.

[chro...@googlecode.com]

Comment #63 on issue 161828 by skyos...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

It doesn't look like this is image decoding related. Here's a trace from
the canvas portion of the benchmark on a Nexus 4. I'm not sure why, but it
seems like the main thread commit is getting spread over 3 vsync ticks on
the impl side, so we never reach the 30 fps the benchmark is targeting.

Attachments:
jsgamebench-trace.html.gz 1.1 MB

[chro...@googlecode.com]

Comment #64 on issue 161828 by ju...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

In that trace, I see Async texture uploads that are happening about two
thirds of the way into a commit. Between the beginning of the commit and
the async uploads, GPU is keeping busy the whole time. Looks like this is
at least partially GPU-bound.

[chro...@googlecode.com]

Comment #68 on issue 161828 by skyos...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

For comparison, the M18 score on Nexus 4 with fps counter off is 8.

[chro...@googlecode.com]

Comment #69 on issue 161828 by skyos...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Dolphin Browser 9.2.0 w/ Jetpack 1.0.3 gets 211, so we're not quite #1 even
with raster time out of the picture.

[chro...@googlecode.com]

Comment #70 on issue 161828 by klo...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

Thanks Sami for the update. The bot doesn't have fps counter. Wondering why
it also showed lower number with impl-side painting.

[chro...@googlecode.com]

Comment #71 on issue 161828 by skyos...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

By fps counter I mean the div on the jsgamebench page itself. It gets
updated every frame and causes us to re-rasterize and upload its tiles. If
I hide the div, the only thing changing on the page is the canvas and the
workload is greatly reduced.

I tried Nat's idea to immediately rasterize tiles if there are only a few
of them (https://codereview.chromium.org/12088110), and it made the raster
stage much more compact. However, we're still doing async texture uploads
so the pipeline is still long. Trace attached.

Attachments:
jsgamebench-trace-raster-immed.html.gz 1.1 MB

[chro...@googlecode.com]

Comment #72 on issue 161828 by klo...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

That (in page fps counter) makes sense.

Wondering what fps we get if we turn off async upload.

In user gesture, scroll or fling, case, we want to use the current active
tree in 60fps mode and de-prioritize the activation of the pending tree.

In the content, or JavaScript driven case, we should try to activate the
pending tree sooner.

Maybe we only enable async upload if we are in scrolling or flinging.

[chro...@googlecode.com]

Updates:
Blockedon: chromium:173426

Comment #74 on issue 161828 by srika...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

[chro...@googlecode.com]

Comment #75 on issue 161828 by nd...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

Brian is available to work on the upload/raster latency stuff. @skyostil,
the more you can do to set up Brian for success, and get him access to a
shippable isCheapTile, the better.

[chro...@googlecode.com]

Updates:
Cc: briander...@chromium.org

Comment #76 on issue 161828 by briander...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

[chro...@googlecode.com]

Comment #78 on issue 161828 by nd...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

Lets set a bar for completing this bar.

Proposal:
1. fast good uploads
2. immediate raster

File a followup bug; "additional jsgamebench optimizations" and mark m27.
Commit related issues can go in that. But I really want to foucs in on
getting #1 and #2 LANDED, and I need *your* help to do it.

[chro...@googlecode.com]

Updates:
Labels: -Mstone-25 Mstone-26

Comment #79 on issue 161828 by srika...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Per standup this morning, 173426 (or even parts of it) will likely not make
it by tonite and even with that there is more to be done here. Too late to
pick this up for M25 - we will continue post.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Comment #80 on issue 161828 by skyos...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Here's a work-in-progress patch to flush a small number of pending uploads
directly and wait for them to complete on the GPU thread:
https://codereview.chromium.org/12321053. It reduces the chance of an
individual late upload dropping us below 30 fps on JSGameBench.

[chro...@googlecode.com]

Updates:
Blockedon: chromium:178441

Comment #83 on issue 161828 by skyos...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #84 on issue 161828 by skyos...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Unfortunately even with the changes from comment #82, our score on S3 is a
measly ~10. Some more work is still needed.

[chro...@googlecode.com]

Comment #85 on issue 161828 by skyos...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

We noticed that performance on m25 is better than on m27 (80 vs. 50 points
on Nexus 10). I'm not sure what is causing the difference, but looking at
the distribution of frame times (measured from rAF, ~3000 frames), m25
peaks slightly below 33.33 ms whereas m27 is slightly over it:
http://www.plotshare.com/index.ws/plot/208000202. I think this slight bias
may be enough to lower the score on the benchmark.

The average fps counter raster times for m25 also seem to be shorter than
for m27 (1.5 ms vs. 0.5 ms).

Attachments:
m25-vs-m27.png 5.2 KB

[chro...@googlecode.com]

Comment #86 on issue 161828 by skyos...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Had a closer look at the paint times with Tom; looks like we're rasterizing
13 pictures per frame on m25 but only 7 on m27. Rasterizing one picture
takes more time on m27, but the overall raster task completion time is the
same. Looks like a red herring.

[chro...@googlecode.com]

Comment #87 on issue 161828 by tomhud...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

A red herring as far as overall performance goes, but it's a bit of the
system that is too opaque for my taste: why are we rasterizing fewer
pictures now, and why are the pictures being rasterized taking twice as
long?

(Not dependent on layer size; if there's a tile-size difference 2x seems
surprising.)

But then I still don't understand why this tile is being re-rasterized at
low AND high resolution on every frame? Low res often turns out to be not
much faster than high here.

[chro...@googlecode.com]

Updates:
Blockedon: chromium:178634

Comment #88 on issue 161828 by skyos...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #89 on issue 161828 by skyos...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Patches for issues from comment #82:

2. Shallow flush of async uploads:
https://bugs.webkit.org/show_bug.cgi?id=110987,
https://codereview.chromium.org/12210129/,
https://codereview.chromium.org/12321053/

3. Check for completed tasks sooner:
https://codereview.chromium.org/12321140/

[chro...@googlecode.com]

Updates:
Cc: dan...@chromium.org

Comment #90 on issue 161828 by dan...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #91 on issue 161828 by skyos...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Can someone comment whether rasterizing both a low and high res version of
the updated page region every frame is WAI? The low res texture never ends
up getting used.

[chro...@googlecode.com]

Updates:
Cc: en...@chromium.org

Comment #92 on issue 161828 by klo...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

enne@ can confirm. I believe it is as expected with the current
architecture.

[chro...@googlecode.com]

Comment #93 on issue 161828 by en...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

At the moment this is working as expected, although there's been plenty of
discussion about how to reprioritize high res vs. low res in different
contexts.

[chro...@googlecode.com]

Comment #94 on issue 161828 by bugdro...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828#c94

The following revision refers to this bug:
http://src.chromium.org/viewvc/chrome?view=rev&revision=186190

------------------------------------------------------------------------
r186190 | epe...@chromium.org | 2013-03-05T17:02:16.534032Z

Changed paths:
M
http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/client/gles2_cmd_helper_autogen.h?r1=186190&r2=186189&pathrev=186190
M
http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/client/gles2_trace_implementation_autogen.h?r1=186190&r2=186189&pathrev=186190
M
http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/client/gles2_c_lib_autogen.h?r1=186190&r2=186189&pathrev=186190
M
http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/build_gles2_cmd_buffer.py?r1=186190&r2=186189&pathrev=186190
M
http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/common/gles2_cmd_ids_autogen.h?r1=186190&r2=186189&pathrev=186190
M
http://src.chromium.org/viewvc/chrome/trunk/src/content/common/gpu/client/webgraphicscontext3d_command_buffer_impl.cc?r1=186190&r2=186189&pathrev=186190
M
http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/client/gles2_interface_stub_impl_autogen.h?r1=186190&r2=186189&pathrev=186190
M
http://src.chromium.org/viewvc/chrome/trunk/src/content/common/gpu/client/webgraphicscontext3d_command_buffer_impl.h?r1=186190&r2=186189&pathrev=186190
M
http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/cmd_buffer_functions.txt?r1=186190&r2=186189&pathrev=186190
M
http://src.chromium.org/viewvc/chrome/trunk/src/gpu/GLES2/gl2chromium_autogen.h?r1=186190&r2=186189&pathrev=186190
M
http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/client/gles2_trace_implementation_impl_autogen.h?r1=186190&r2=186189&pathrev=186190
M
http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/common/gles2_cmd_format_test_autogen.h?r1=186190&r2=186189&pathrev=186190
M
http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/service/gles2_cmd_decoder_unittest.cc?r1=186190&r2=186189&pathrev=186190
M
http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/client/gles2_implementation_autogen.h?r1=186190&r2=186189&pathrev=186190
M
http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/common/gles2_cmd_format_autogen.h?r1=186190&r2=186189&pathrev=186190
M
http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/service/gles2_cmd_decoder.cc?r1=186190&r2=186189&pathrev=186190
M
http://src.chromium.org/viewvc/chrome/trunk/src/ui/gl/async_pixel_transfer_delegate_stub.cc?r1=186190&r2=186189&pathrev=186190
M
http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/service/async_pixel_transfer_delegate_mock.h?r1=186190&r2=186189&pathrev=186190
M
http://src.chromium.org/viewvc/chrome/trunk/src/ui/gl/async_pixel_transfer_delegate_stub.h?r1=186190&r2=186189&pathrev=186190
M
http://src.chromium.org/viewvc/chrome/trunk/src/ui/gl/async_pixel_transfer_delegate_android.cc?r1=186190&r2=186189&pathrev=186190
M
http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/service/gles2_cmd_decoder_unittest_3_autogen.h?r1=186190&r2=186189&pathrev=186190
M
http://src.chromium.org/viewvc/chrome/trunk/src/ui/gl/async_pixel_transfer_delegate.h?r1=186190&r2=186189&pathrev=186190
M
http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/client/gles2_interface_stub_autogen.h?r1=186190&r2=186189&pathrev=186190
M
http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/client/gles2_interface_autogen.h?r1=186190&r2=186189&pathrev=186190
M
http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/client/gles2_implementation.cc?r1=186190&r2=186189&pathrev=186190

gpu: Add the ability to wait on upload completion.

Patch originally by Eric Penner <epe...@chromium.org>.

We currently have high latency if need to wait for uploads
in the renderer client. If we can do a shallow client side
wait it will be much better. This is effectively the
same as doing synchronous uploads, but exposes less driver
bug surface area then mixing uploads across threads.

BUG=161828, 178634


Review URL: https://chromiumcodereview.appspot.com/12210129
------------------------------------------------------------------------

[chro...@googlecode.com]

Comment #98 on issue 161828 by vange...@google.com: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

Some new data from Tom's Hardware:
http://www.tomshardware.com/reviews/web-browser-chrome-25-firefox-19,3459-8.html

[chro...@googlecode.com]

Comment #99 on issue 161828 by srika...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

The latest THG update (in #98) seems to be more desktop browsers?

[chro...@googlecode.com]

Updates:
Labels: -M-26 M-27 MovedFrom-M26

Comment #103 on issue 161828 by srika...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Lots of good changes have landed but unlikely we will be able to bring them
over to M26 at this point. Lets continue work on trunk towards bringing
these together for M27.

[chro...@googlecode.com]

Updates:
Blockedon: chromium:222695 chromium:222700

Comment #104 on issue 161828 by srika...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

(No comment was entered for this change.)

[chro...@googlecode.com]

Issue 161828: Investigate JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

This issue is now blocking issue chromium:176625.
See http://code.google.com/p/chromium/issues/detail?id=176625

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[chro...@googlecode.com]

Updates:
Owner: tomhud...@chromium.org

Comment #108 on issue 161828 by skyos...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Put up some patches up for discussion let us complete pending frames
quicker. These seem to improve the score a lot, especially on the S3.

1. Keep vsync enabled while there is a pending requestAnimationFrame:
https://codereview.chromium.org/14195025/
2. Retry tree activation if raster tasks finish during first half of vsync
interval: https://codereview.chromium.org/13947038/

--

[chro...@googlecode.com]

Updates:
Labels: -M-28 MovedFrom-28 M-29
Blockedon: chromium:223726

Comment #109 on issue 161828 by srika...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Now targeting M29 given the broader plan on how to address this across
platforms. CLs above give temporary relief but were deemed to be not
generic enough.

In addition to the benchmark, would be great to understand if the work done
here helps web apps such as news that are expecting better performance
(Issue 223726 is tracking incorporating it into the perf harness).

[chro...@googlecode.com]

Updates:
Owner: skyos...@chromium.org

Comment #110 on issue 161828 by tomhud...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

I shouldn't own this until the team working on the broader plan comes up
with concrete goals that I can actually implement; right now I have no idea
when that's going to happen. Handing it back to Sami, who's working on that
doc.

[chro...@googlecode.com]

Updates:
Blockedon: chromium:236648

Comment #111 on issue 161828 by skyos...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Blocking this on the tree activation bug which is part of the low latency
improvements.

[chro...@googlecode.com]

Updates:
Owner: brian...@chromium.org

Comment #112 on issue 161828 by klo...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Brian, this is another case where the new scheduler can address. Move to
your plate for now so that we can verify when it is in place. Thanks.

[chro...@googlecode.com]

Comment #113 on issue 161828 by srika...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

FYI - looks like there has been a recent regression on JSGameBench across
N4/N10 (more evident on the former).

https://chromeperf.appspot.com/report?masters=ChromiumPerf&bots=android-nexus10%2Candroid-nexus4&tests=jsgamebench%2FScore

Expected?

[chro...@googlecode.com]

Comment #114 on issue 161828 by klo...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

It seems popping back around 202086-202113 on N10. N4 hasn't caught up yet.
Let us see whether it is recovered too.

[chro...@googlecode.com]

Comment #115 on issue 161828 by srika...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Yep - lets look across N4/GN as they move forward beyond 202xxx
https://chromeperf.appspot.com/report?masters=ChromiumPerf&bots=android-gn%2Candroid-nexus10%2Candroid-nexus4&tests=jsgamebench%2FScore

[chro...@googlecode.com]

Comment #116 on issue 161828 by skyos...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

I opened https://code.google.com/p/chromium/issues/detail?id=243327 about
the regression earlier. It does look like Nexus 10 is recovering, but
nothing in the changelogs jumps out as the cause.

[chro...@googlecode.com]

Updates:
Blockedon: chromium:243327

Comment #117 on issue 161828 by srika...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

(No comment was entered for this change.)

[chro...@googlecode.com]

Issue 161828: Investigate JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

This issue is now blocking issue chromium:245354.
See http://code.google.com/p/chromium/issues/detail?id=245354

--

[chro...@googlecode.com]

Updates:
Cc: aprigo...@google.com

Comment #119 on issue 161828 by wiltz...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

(No comment was entered for this change.)

--

[chro...@googlecode.com]

Updates:
Labels: -M-29 MovedFrom-29 M-30

Comment #120 on issue 161828 by srika...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Scheduler changes did not land for M29 branch point and looks like Issue
236648 is now tracking to M30 as well. So this one moves with it as well.

[chro...@googlecode.com]

Comment #121 on issue 161828 by to...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

What's the current status of this? The latest THG grand prix reports that
FF22 is still about 40% better than Chrome27.

http://www.tomshardware.com/reviews/chrome-27-firefox-21-opera-next,3534-8.html

[chro...@googlecode.com]

Updates:
Cc: rev...@chromium.org

Comment #126 on issue 161828 by klo...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

The current scheduler (30.0.1562.0) seems compositing more frames than
necessary which caused JS reported fps lower.

The attached trace is grabbed when running the test on Galaxy Nexus. As you
can see, the main thread only commits 17 frames while the cc thread draws
67 times.

+David, as I am not sure whether this is scheduler bug or activation bug.

Attachments:
m30.html 7.2 MB

[chro...@googlecode.com]

Comment #127 on issue 161828 by brian...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Re#126: The compositor is drawing multiple times after activation and
before the next commit, which is strange. I couldn't tell from the trace
what's causing the extra draws. Can you try running with the following in
the for loop of Scheduler::ProcessScheduledActions?

TRACE_EVENT1("cc", "SchedulerStateMachine", "state",
state_machine_.ToString());

[chro...@googlecode.com]

Comment #128 on issue 161828 by klo...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Ok. Here you are.

Attachments:
trace.html 6.8 MB

[chro...@googlecode.com]

Comment #130 on issue 161828 by aj...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

Yes, in the trace, LayerTreeHostImpl::AnimateLayers is calling
SetNeedsRedrawOnImplThread every frame, and this only happens when an
animation is running.

[chro...@googlecode.com]

Updates:
Blockedon: chromium:264437

Comment #131 on issue 161828 by wiltz...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #133 on issue 161828 by tomhud...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Ping - what's our state here? We're P1, have slipped repeatedly, and no
updates in nearly 3 weeks.

[chro...@googlecode.com]

Comment #134 on issue 161828 by skyos...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Re: animations, the test is using requestAnimationFrame() which causes the
impl thread to think there's an ongoing animation. Could this be the reason
we're drawing more than we're committing?

[chro...@googlecode.com]

Comment #135 on issue 161828 by aj...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

No, LayerTreeHostImpl::AnimateLayers calls SetNeedsRedrawOnImplThread only
for accelerated animations. And, indeed, looking at the jsgamebench source
(specifically,
https://github.com/facebook/jsgamebench/blob/master/perf/css/perf.css),
they have accelerated animations that repeat infinitely (that is, they
effectively have infinite duration).

[chro...@googlecode.com]

Comment #136 on issue 161828 by ju...@chromium.org: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

@134: There was previously a bug where accelerated 2d canvases were only
committing gpu draw calls every two frames. That was fixed in Blink
r153900. The part of that patch that fixes the two frame per commit is the
call to flush() in Canvas2DLayerBridge::prepareMailbox(). The fix was also
merged to the m29 branch.

[chro...@googlecode.com]

Updates:
Cc: epen...@chromium.org

Comment #137 on issue 161828 by klo...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

I think we saw the mixed rAF and css animation issue in the other places,
like cubeslam.com (pong game).

Essentially css animation has the high priority in the cc thread. This
caused main webkit thread and raster thread starving of the cpu cycles.
https://code.google.com/p/chromium/issues/detail?id=251990 addressed the
upload issue. But should we also consider to change the thread priority for
webkit and raster when rAF is on?
https://code.google.com/p/chromium/issues/detail?id=264477 may address part
of this.

[chro...@googlecode.com]

Comment #138 on issue 161828 by epen...@google.com: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

#137, It wouldn't only starve CPU, but also block activation (essentially
block webkit frames in favor of CC frames). I think for this reason we
should rename 'prefer smoothness' to 'in accelerated gesture', as it makes
it more clear.

Even after the patch, there is still lurking priority difference in this
case. The CC thread has a priority of -6 while webkit bounces between 10
and 0. If user events are going to webkit while a CSS animation is
occurring, webkit might not get enough CPU time to commit it's frames. The
CSS animation might actually be less important (as in the case of CubeSlam
where JS is processing user input)

Perhaps we should consider bumping webkit thread priority as well when it
recieves a user input? Unfortunately we might prioritize an ugly webkit
action like GC or layout, but we do need to get through that to get user
actions onto the screen.

[chro...@googlecode.com]

Comment #139 on issue 161828 by klo...@chromium.org: Investigate
JSGameBench performance
http://code.google.com/p/chromium/issues/detail?id=161828

Eric, I think you mean that the raster thread is bouncing between 10 and 0.

And for jsgamebenchmark, there is no user input. But there is rAF, I think
we should consider change the thread priority for both webkit and raster
during rAF.

[chro...@googlecode.com]

Comment #141 on issue 161828 by epen...@google.com: Investigate JSGameBench
performance
http://code.google.com/p/chromium/issues/detail?id=161828

Oh, so bumping webkit to -6 could be during RAF or when handling input
events like you suggest in #138. We might not want to keep it there all the
time (aka for CSS animations)