Fix for 300ms scroll lag on 2013 Mac Pros once idle for 10seconds

Fix for 300ms scroll lag on 2013 Mac Pros once idle for 10seconds

The 2013 Mac Pros have a dual discrete GPU setup. If the GPU process is
idle for 10 seconds or more, OSX transfers the OpenGL context on to the
second, "offline" GPU. This means when we try to use it again to display
on a real display, OSX must first switch the context back. This would 
trigger a ~300ms delay on the first glFlush() call to occur after the
idle threshold was reached.

To fix, detect a dual, discrete GPU setup and never set the
kCGLPFAAllowOfflineRenderers flag in the pixel format for this case.

BUG=380026

[tapted, 2015-05-18 06:31:49]

tapted@chromium.org changed reviewers:
+ ccameron@chromium.org

[tapted, 2015-05-18 07:13:39]

Hi Chris, please take a look. You might see a much nicer fix that this, so
please feel free to take it over and scrap this.

Otherwise, please review and loop in any OWNERS.

I also have no idea how specific to be in the json stuff. It currently takes the
stance that any machine with two cards (where neither is intel) will get this
workaround (so long as it's AMD).

I'm not sure if there's a nice way to make it apply for nvidia as well (if we
want that). Otherwise, we could add more filtering, e.g. to apply to these
trashcan makes specifically. However, I think it's likely that a (hypothetical)
non-trash-can MacPro with a dual discrete GPU might also be affected by this
bug.

Thanks!

[ccameron, 2015-05-18 08:38:41]

ccameron@chromium.org changed reviewers:
+ kbr@chromium.org, zmo@chromium.org

[ccameron, 2015-05-18 08:38:41]

Wow, thanks for digging in on this!

I wonder if there's a renderer property that identifies these
"auto-send-to-offline" GPUs that we could hook in to. I have a vague preference
that GpuSwitchingManager::SupportsDualGpus would return false for these
configurations (not sure how).

I'll ponder for a bit.

kbr@ and zmo@ are probably the authorities on blacklists, and might have ideas.

[Ken Russell (switch to Gerrit), 2015-05-18 20:58:58]

Thanks for tracking this down. Nice work finding this solution.

After talking with zmo@, he and I both think that a better solution to this
problem would be to teach the GpuSwitchingManager about the vendor IDs of the
dual GPUs in the system, and have GpuSwitchingManager::SupportsDualGpus return
true only if it finds two GPUs where one is Intel and the other one isn't Intel.
Despite the fact that this sort of logic can now be encoded in the blacklist,
the SupportsDualGpus call seems to be the right place to encode this decision.

We can implement this or would you be willing to update this CL to do so?

[tapted, 2015-05-18 22:48:24]

On 2015/05/18 20:58:58, Ken Russell wrote:
> Thanks for tracking this down. Nice work finding this solution.
> 
> After talking with zmo@, he and I both think that a better solution to this
> problem would be to teach the GpuSwitchingManager about the vendor IDs of the
> dual GPUs in the system, and have GpuSwitchingManager::SupportsDualGpus return
> true only if it finds two GPUs where one is Intel and the other one isn't
Intel.
> Despite the fact that this sort of logic can now be encoded in the blacklist,
> the SupportsDualGpus call seems to be the right place to encode this decision.
> 
> We can implement this or would you be willing to update this CL to do so?

I'm happy for some gpu experts to take over :). My attempt was more out of
curiosity - there's a lot to wrap my head around! But also happy to patch things
in and try out on this hardware if you need that. Thanks!

[Ken Russell (switch to Gerrit), 2015-05-19 01:16:54]

On 2015/05/18 22:48:24, tapted wrote:
> On 2015/05/18 20:58:58, Ken Russell wrote:
> > Thanks for tracking this down. Nice work finding this solution.
> > 
> > After talking with zmo@, he and I both think that a better solution to this
> > problem would be to teach the GpuSwitchingManager about the vendor IDs of
the
> > dual GPUs in the system, and have GpuSwitchingManager::SupportsDualGpus
return
> > true only if it finds two GPUs where one is Intel and the other one isn't
> Intel.
> > Despite the fact that this sort of logic can now be encoded in the
blacklist,
> > the SupportsDualGpus call seems to be the right place to encode this
decision.
> > 
> > We can implement this or would you be willing to update this CL to do so?
> 
> I'm happy for some gpu experts to take over :). My attempt was more out of
> curiosity - there's a lot to wrap my head around! But also happy to patch
things
> in and try out on this hardware if you need that. Thanks!

Thanks again. https://codereview.chromium.org/1144843005 has been uploaded with
the alternative idea, so please feel free to close this if the other CL works
for you.

[tapted, 2015-05-19 01:25:56]

On 2015/05/19 01:16:54, Ken Russell wrote:
> On 2015/05/18 22:48:24, tapted wrote:
> > On 2015/05/18 20:58:58, Ken Russell wrote:
> > > Thanks for tracking this down. Nice work finding this solution.
> > > 
> > > After talking with zmo@, he and I both think that a better solution to
this
> > > problem would be to teach the GpuSwitchingManager about the vendor IDs of
> the
> > > dual GPUs in the system, and have GpuSwitchingManager::SupportsDualGpus
> return
> > > true only if it finds two GPUs where one is Intel and the other one isn't
> > Intel.
> > > Despite the fact that this sort of logic can now be encoded in the
> blacklist,
> > > the SupportsDualGpus call seems to be the right place to encode this
> decision.
> > > 
> > > We can implement this or would you be willing to update this CL to do so?
> > 
> > I'm happy for some gpu experts to take over :). My attempt was more out of
> > curiosity - there's a lot to wrap my head around! But also happy to patch
> things
> > in and try out on this hardware if you need that. Thanks!
> 
> Thanks again. https://codereview.chromium.org/1144843005 has been uploaded
with
> the alternative idea, so please feel free to close this if the other CL works
> for you.

Awesome \o/. Alternative works great. I'll close this.