Dual GPU systems are common and they make it trickier to analyze gfx performance Telemetry because we don't know which GPU is in use during each measurement. We should report gfx performance Telemetry (e.g. FX_TAB_ANIM_OPEN_FRAME_INTERVAL_MS) separately for each GPU.

(In reply to Vladan Djeric (:vladan) from comment #0) > Dual GPU systems are common and they make it trickier to analyze gfx > performance Telemetry because we don't know which GPU is in use during each > measurement. > > We should report gfx performance Telemetry (e.g. > FX_TAB_ANIM_OPEN_FRAME_INTERVAL_MS) separately for each GPU. Doesn't firefox just lock to one gpu per session?

Taras, Vladan mentioned briefly that the GPU locking is a consequence of using the Windows API. Do you happen to have some reference that explain how the whole process works? That doesn't seem to be the case on OSX where a switch might occur when rendering WebGL content, for instance.

(In reply to Roberto Agostino Vitillo (:rvitillo) from comment #2) > Taras, Vladan mentioned briefly that the GPU locking is a consequence of > using the Windows API. Do you happen to have some reference that explain how > the whole process works? > > That doesn't seem to be the case on OSX where a switch might occur when > rendering WebGL content, for instance. No, but ask Bas on irc

Bas, could you shed some light on how the GPU locking works on Windows?

(In reply to Roberto Agostino Vitillo (:rvitillo) from comment #4) > Bas, could you shed some light on how the GPU locking works on Windows? That is an extremely broad question, there's 'gpu locking' is a very generic term.. You'll have to come up with a more specific question if you want an answer :).

Fair enough, let me give you some context. We are currently collecting some metrics in Telemetry that allow us to inspect the distributions of various animation related probes, like FX_TAB_ANIM_OPEN_FRAME_INTERVAL_MS. The problem is that, since some systems have multiple GPUs, we need a way to discern which GPU was used when an entry was added to an animation histogram on the client. My understanding as a layman was that since we don't know which GPU is used when, we should have multiple histograms for the same metric, one for each GPU. That would allow us to correctly count for instance the frame rate while opening a tab with GPU1 or GPU2 (if available). Taras hinted that on Windows, Firefox might lock on a specific GPU and so we wouldn't need to have multiple histograms. Given the previous problem statement, could you shed some light on how we should properly perform accounting of animation histograms?

It's actually very tricky on windows on Optimus devices to know which GPU you're using. In general mAdapter in gfxWindowsPlatform is the GPU that firefox locks on to and uses though. But with Optimus I believe than once GPU is actually always presented as the active one regardless of which one is used.

I wonder if we should have proper measurement implementations for this and related kind of problems. This sounds like we want to record [(timestamp,value),...] measurements and could then, for this case, correlate the timestamped gpu-activity to the timestamped tab-anim-interval?

The current way to do this is to use a keyed measurement with the key being an index into the adapters array reported in the environment. If this is still important.