New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 784938 link

Starred by 1 user
Status: WontFix
Owner:
ccameron@chromium.org
Closed: Nov 2017
Cc:
█ p...@myitcv.org.uk
ericrk@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

Blocking:
issue 773705



Sign in to add a comment

Use of IOSurfaces/zero-copy is significantly slower than one-copy on Discrete NVidia GPUs

Project Member Reported by ericrk@chromium.org, Nov 14 2017 
Not sure if this is a general issue or one specific to 10.13, but a user has reported that running Chrome with in software raster mode with:

--disable-native-gpu-memory-buffers --disable-zero-copy --disable-gpu-memory-buffer-video-frames

Results in a significant speed up vs running software raster with no flags. This is a bit unexpected (maybe due to reallocation of GMBs? could this be slower on NVidia?), so it seemed worth taking a look at. See comment #135 of  crbug.com/773705 

ccameron@, can you think of any reasons why this might be the case - especially when switching tabs?

Comment 1 by p...@myitcv.org.uk, Nov 14 2017 

Following up on #143 from  crbug.com/773705 

ericrk@: current stable (Version 62.0.3202.94) seems faster than current Canary (Version 64.0.3265.0), both without flags. 

But neither are as anywhere near as fast as current Canary with "--disable-native-gpu-memory-buffers --disable-zero-copy --disable-gpu-memory-buffer-video-frames" flags.

Maybe of interest; when running current Canary without flags and switching between tabs as I described before, the spindump process starts grabbing >100% of CPU (multi core); my machine is definitely struggling in this configuration. 

Running current stable it is also as struggling, but spindump is not the culprit, Chrome itself seems to be consuming ~2x the CPU as it does when running current Canary with flags.

Comment 2 by ccameron@chromium.org, Nov 14 2017

Status: WontFix (was: Assigned)
IOSurface allocation is more expensive than GL texture allocation.

The display path using IOSurfaces is lower power and higher performance than using GL.

This is a conscious trade-off, and the correct trade-off, and will not be changed.

Comment 3 by p...@myitcv.org.uk, Nov 14 2017 

ericrk@ - as you're aware, I'm simply reporting back what I've seen in response to your request to run with these flags; I'm not advocating a change one way or the other, just reporting back.

So what would you suggest now, given #1 in this thread?

Comment 4 by p...@myitcv.org.uk, Nov 16 2017 

Any thoughts @ericrk? 

I'm still seeing the slowness in tab switching without these flags in Version 64.0.3269.3. 

Along with messages on stdout/stderr like:

Connection InterfaceProviderSpec prevented service: content_renderer from binding interface: blink::mojom::ReportingServiceProxy exposed by: content_browser

With the flags Chrome performs almost perfectly (this is obviously subjective and hard to measure, hence the use of "almost")

Comment 5 by p...@myitcv.org.uk, Nov 17 2017 

ericrk@ - just to confirm I'm still experiencing these issues on beta 4 (which just came out): 10.13.2 Beta (17C79a)
►

Sign in to add a comment