Here are some numbers to illustrate the cost. This is for about 10-12 seconds of 1080p h.264 playback:
GPU process total - 19,024 samples
GpuCommandBufferStub::OnMessageReceived - 6,328 samples
ChromeContentClient::SetActiveUrl - 564 samples

Yeah, I tried to comment out FastSetActiveURL, but unfortunately that didn't seem to help at all with power. The code to save the crash keys seems to be doing a lot of unnecessary sprintfs and memory allocations, so it should be easy to optimize if we feel that it's worth it.

What does this code do? I had no idea we even set active urls during playback?

This code stores a URL associated with the currently executing GL context to a crash key, so we can determine what web page a person was visiting when the GPU process crashes.

Hmm, I don't think that's even all that useful. Many of the crashes I see in the GPU process for video are stuff like chrome://gpu/RenderThreadImpl::CreateOffscreenContext3d -- since the crash is rarely at the time of call.

Yeah, it used to be more useful when we had a separate context for each compositor (and no browser compositor). It's still nice for webgl and pepper, though. And it's a bit useful to see what type of context it is that crashed.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I'll take this and investigate if this is still an issue. I remember seeing some changes in that area.

I suggest we remove the code that sets active URL in the GPU code.

I did another round of testing. It looks like there is a difference in power usage although it isn't large - about 0.02 - 0.025 Wt.

Here are some concrete numbers, which I've got using jbauman's python script when running 1080p MP4 video in a small window (to minimize variability of power usage).

With SetActiveURL call in place: 2.71, 2.68, 2.58, 2.65, 2.68, 2.67
Without SetActiveURL call:       2.63, 2.64, 2.65, 2.55, 2.64, 2.65

Considering this Active URL isn't actually a page URL I think it is of a limited use for debugging.
The possible values are:
- chrome://gpu/MusContextFactory
- chrome://gpu/RenderThreadImpl::CreateOffscreenContext/" +
           ui::command_buffer_metrics::ContextTypeToString(type))
- "chrome://gpu/GpuProcessTransportFactory::CreateContextCommon"

+1, that thing is completely useless AFAIK, per c#6. +Internals>GPU, +kbr in case they have different opinions.

The URLs are useful for WebGL crashes, where they are valid. See for example crash ID d64a5184eede4443 . Please don't simply remove the mechanism. Instead let's optimize it.

For the record, here's a crash database query which filters out most of the non-WebGL crashes for the current Stable channel on Windows:

product.name='Chrome' AND product.version='61.0.3163.100' AND custom_data.ChromeCrashProto.channel='' AND custom_data.ChromeCrashProto.ptype='gpu-process' AND custom_data.ChromeCrashProto.url.raw!='chrome://gpu/RenderThreadImpl::CreateOffscreenContext/Media' AND custom_data.ChromeCrashProto.url.raw!='chrome://gpu/GpuProcessTransportFactory::CreateContextCommon' AND custom_data.ChromeCrashProto.url.raw!='chrome://gpu/RenderThreadImpl::CreateOffscreenContext/RenderWorker' AND custom_data.ChromeCrashProto.url.raw!='chrome://gpu/RenderThreadImpl::CreateOffscreenContext/Offscreen-MainThread'

Good point! I guess if we just make all the special URLs empty the optimization in FastSetActiveURL should take care of skipping the actual work most of the time for most users.

It looks like one more special URL to exclude is chrome://gpu/RenderViewImpl::CreateGraphicsContext3D.

Here is the query that shows only crashes with a useful URL:
https://crash.corp.google.com/dremel_query_ui?q=SELECT%20Product.Version%20AS%20Version%2C%20custom_data.ChromeCrashProto.url.raw%20as%20URL%2C%20ReportID%20FROM%20crash.prod.latest%20WHERE%20Product.Name%3D%27Chrome%27%20AND%20custom_data.ChromeCrashProto.ptype%3D%27gpu-process%27%20AND%0Acustom_data.ChromeCrashProto.url.raw!%3D%27%27%20AND%20custom_data.ChromeCrashProto.url.raw!%3D%27chrome%3A%2F%2Fgpu%2FRenderThreadImpl%3A%3ACreateOffscreenContext%2FMedia%27%20AND%20custom_data.ChromeCrashProto.url.raw!%3D%27chrome%3A%2F%2Fgpu%2FGpuProcessTransportFactory%3A%3ACreateContextCommon%27%20AND%20custom_data.ChromeCrashProto.url.raw!%3D%27chrome%3A%2F%2Fgpu%2FRenderThreadImpl%3A%3ACreateOffscreenContext%2FRenderWorker%27%20AND%20custom_data.ChromeCrashProto.url.raw!%3D%27chrome%3A%2F%2Fgpu%2FRenderThreadImpl%3A%3ACreateOffscreenContext%2FOffscreen-MainThread%27%20AND%20custom_data.ChromeCrashProto.url.raw!%3D%27chrome%3A%2F%2Fgpu%2FRenderViewImpl%3A%3ACreateGraphicsContext3D%27%20ORDER%20BY%20Version%20DESC%20LIMIT%20100&sql_dialect=dremelsql

Here is the preliminary fix:
https://chromium-review.googlesource.com/#/c/chromium/src/+/728707

I suppose we could land that fix, but we really want to be able to put real URLs in there, to make crashes more actionable, at which point it would regress. I would kind of prefer optimizing the implementation.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Would be nice to optimize this if we think it's still an issue, +more recent folks working on gpu stuff