Enable GL context virtualization for compositor contexts on Mac.

Enable GL context virtualization for compositor contexts on Mac.

BUG=180463
NOTRY=true

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=193397

[ccameron, 2013-04-05 02:11:43]

Ptal. Fyi, I will need to do a bit more local testing (so far so good though)
and talk with the perf sheriff before checking this in.

Also, to be clear, I like the solution in the following changes
https://codereview.chromium.org/13461027/
https://codereview.chromium.org/13647014/
far more.

[Ken Russell (switch to Gerrit), 2013-04-05 02:54:23]

On 2013/04/05 02:11:43, ccameron1 wrote:
> Ptal. Fyi, I will need to do a bit more local testing (so far so good though)
> and talk with the perf sheriff before checking this in.
> 
> Also, to be clear, I like the solution in the following changes
> https://codereview.chromium.org/13461027/
> https://codereview.chromium.org/13647014/
> far more.

I prefer the other solution too. It's more flexible. I'll give an owners
thumbs-up to this if necessary but would rather the other solution be used
instead.

[jamesr, 2013-04-05 03:02:50]

I don't think the code setting up the context attributes should have any logic
related to context virtualization.  It's not up to the client side to determine
whether virtualization makes sense or not, that's a decision for the service
side to make.

[ccameron, 2013-04-05 10:20:56]

On 2013/04/05 03:02:50, jamesr wrote:
> I don't think the code setting up the context attributes should have any logic
> related to context virtualization.  It's not up to the client side to
determine
> whether virtualization makes sense or not, that's a decision for the service
> side to make.

Well, the client side is the one who decides -- the decision is "I'm a
compositor, hear me be virtualized" vs "I'm WebGL/Canvas/whatever, hear me not".
That said, I'm content to do this at this level and then let it metastasize if
need be.

[Ken Russell (switch to Gerrit), 2013-04-05 20:28:50]

On 2013/04/05 10:20:56, ccameron1 wrote:
> On 2013/04/05 03:02:50, jamesr wrote:
> > I don't think the code setting up the context attributes should have any
logic
> > related to context virtualization.  It's not up to the client side to
> determine
> > whether virtualization makes sense or not, that's a decision for the service
> > side to make.
> 
> Well, the client side is the one who decides -- the decision is "I'm a
> compositor, hear me be virtualized" vs "I'm WebGL/Canvas/whatever, hear me
not".
> That said, I'm content to do this at this level and then let it metastasize if
> need be.

For platforms that want to do context virtualization, I agree that it will
eventually be done behind the scenes for all contexts. The only question is how
the intermediate stages look. This is fine. LGTM

[jamesr, 2013-04-05 20:34:23]

this lgtm as well

[ccameron, 2013-04-05 20:50:38]

Thanks!!

I agree* that the end goal should be having this on everywhere -- it may be that
this has to be made more complicated in the short term (due to query support
racing with übercompositor, etc, etc).

[*] I'm not 100% sure that we should virtualize all context from WebGL and NaCL,
etc -- I can construct scenarios where some drivers will do a better job
managing state than we do (but then again "can construct" and "some drivers"
don't make the most compelling arguments).

[jamesr, 2013-04-05 20:53:22]

On 2013/04/05 20:50:38, ccameron1 wrote:
> Thanks!!
> 
> I agree* that the end goal should be having this on everywhere -- it may be
that
> this has to be made more complicated in the short term (due to query support
> racing with übercompositor, etc, etc).
> 
> [*] I'm not 100% sure that we should virtualize all context from WebGL and
NaCL,
> etc -- I can construct scenarios where some drivers will do a better job
> managing state than we do (but then again "can construct" and "some drivers"
> don't make the most compelling arguments).

Keep in mind that on windows we are virtualizing everything onto one D3D context
already (via angle).

[Ken Russell (switch to Gerrit), 2013-04-05 21:19:56]

On 2013/04/05 20:53:22, jamesr wrote:
> On 2013/04/05 20:50:38, ccameron1 wrote:
> > Thanks!!
> > 
> > I agree* that the end goal should be having this on everywhere -- it may be
> that
> > this has to be made more complicated in the short term (due to query support
> > racing with übercompositor, etc, etc).
> > 
> > [*] I'm not 100% sure that we should virtualize all context from WebGL and
> NaCL,
> > etc -- I can construct scenarios where some drivers will do a better job
> > managing state than we do (but then again "can construct" and "some drivers"
> > don't make the most compelling arguments).
> 
> Keep in mind that on windows we are virtualizing everything onto one D3D
context
> already (via angle).

The command buffer's service side GL contexts (built on ANGLE) aren't
virtualized yet there, though. There are multiple layers at which bugs or
performance regressions can creep in; that's the motivation for not just
switching over to virtualized GL contexts everywhere.

[commit-bot: I haz the power, 2013-04-10 00:26:27]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ccameron@chromium.org/13689003/19001

[commit-bot: I haz the power, 2013-04-10 02:29:39]

Retried try job too often on win_rel for step(s) sync_integration_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[commit-bot: I haz the power, 2013-04-10 16:44:14]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ccameron@chromium.org/13689003/19001

[commit-bot: I haz the power, 2013-04-10 16:44:50]

Change committed as 193397