Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 38 users
Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature


Sign in to add a comment
Ganesh on all gpu-accelerated Chrome
Project Member Reported by danakj@chromium.org, Oct 1 2014 Back to list
We'd like to have ganesh everywhere we use the GPU. Metabug for all of the platforms. We should pick a platform to go after first. Is is Android 100%? Mac? ChromeOS? Some combination?
 
Labels: Cr-Internals-Compositing-Rasterization
Cc: siev...@chromium.org
Comment 3 Deleted
It appears that approx 70% of page views on android are rendered with ganesh today. Does that mean anything to the decision to go after android 100% or a desktop platform first?
For Android and Windows, a "100%" goal implies we'd also add workarounds for any and all driver issues we encounter.  It's truly laborious to guess why an opaque driver binary might be behaving a particular way, and that engineering time isn't worth investing for older/small market share devices.  And in some cases, the only available workaround that maintains correctness might turn out to be rastering in software and uploading.  So I think a more reasonable goal for those platforms is ~90% coverage, with case-by-case decisions weighing marketshare versus driver bugginess.

For ChromeOS and Mac, the device variety is small enough that Ganesh everywhere may indeed be feasible.  Although I suspect that even there, we'll prefer to blacklist some ancient devices when they come up as problem cases.
If we can blacklist to software compositing for bad drivers instead of maintaining a half-gpu-sorta path with all the texture upload machinery, I think that'd be nice in the long term. Maybe that's not something we can do for android tho, so it may be moot.
Re #4: the numbers we have from the UMA indicate that from the current devices that have Ganesh enabled (about 35% of total) only about 18% of page loads have the appropriate Ganesh trigger (viewport meta tag):

https://uma.googleplex.com/p/chrome/histograms/?dayCount=1&endDate=10-02-2014&version=M37-A&histograms=Renderer4.GpuRasterizationTriggered&otherVersions=true&filters

Ooh okay, thanks. I wasn't clear what triggers it clearly :)
#6: right, unfortunately software compositing is nonviable even as a fallback on Android, we would see <10fps thanks to the combination of weak CPUs and high-dpi.  Unfortunately, I think we have to maintain all three modes until we stop supporting Android devices <L (we expect to be able to ship Ganesh everywhere on L thanks to Chrome and WebView unconditionally enabling it already if on L, thus forcing OEMs to fix their drivers before they ship L devices).

Anyway, I think we should focus on widening Android first because it's the main beneficiary, and desktop platforms probably in order of ease of deployment and testing.  I wonder if for example we should enable it on some subset of desktop Linux so that Chromium developers get Ganesh by default.
>  I wonder if for example we should enable it on some subset of desktop Linux so that Chromium developers get Ganesh by default.

No one has been brave enough to suggest linux first here, hehe. But I think that's a really cool idea.
Vangelis, do you remember why we disabled c2d on Linux? I remember it caused some problem with the X server locking up.
Re #11: The X server hangs was  issue 145600  related to GLX windows and memory management in the NVIDIA driver. It made us very reluctant triggering GPU compositing on lots of pages and was one of the reasons that we didn't want to turn on accelerated canvas. But thankfully these days are gone.

The second reason was an inherent mistrust of Linux GPU drivers in the wild and as a matter of focus we decided to only worry about windows and mac. 

If we experiment with Ganesh on Linux we should probably start with Ubuntu + NVIDIA since this is closest to the configuration most of us are on.


Blockedon: chromium:419950
Duplicate of Issue 426530?
Blockedon: chromium:426530
Not quite. This would include more use on android as well I guess. 
Labels: -Cr-Internals-Compositing -Cr-Internals-Skia-Compositing -Cr-Internals-Compositing-Rasterization -SlowRaster Cr-Internals-GPU-Rasterization Cr-Internals-Skia
Blockedon: chromium:463323
Cc: -ernstm@chromium.org ccameron@chromium.org
Owner: vmi...@chromium.org
Status: Assigned
Labels: Hotlist-GPU-Fixit
Comment 19 by hcm@chromium.org, Aug 11 2015
Cc: hcm@chromium.org
Labels: -Type-Bug -Hotlist-GPU-Fixit Type-Feature
This issue should be categorized as Feature vs Bug (which also removes it from candidacy for the GPU fixit), adjusting...
Blockedon: chromium:574606
Blocking: chromium:574606
Blockedon: 656618
Sign in to add a comment