gpu: Enable WebGL on Mali-400 GPUs that support EXT_robustness

gpu: Enable WebGL on Mali-400 GPUs that support EXT_robustness

Enable WebGL on Mali-400 GPUs that support the EXT_robustness extension
but do *not* send context reset notifications. The reason we can do
this is that virtualized contexts are not used on these devices, so
badly behaving WebGL shaders do not affect other GL contexts. This means
that the user can close or reload the WebGL tab and other tabs in the
browser remain responsive.

BUG=288731, 416690
TEST=https://www.khronos.org/registry/webgl/conformance-suites/1.0.1/extra/slow-shader-example.html on a Galaxy Tab 3

Committed: https://crrev.com/f56d21f26ff4f09f8dfe35d84d20f4ce45f45c2e
Cr-Commit-Position: refs/heads/master@{#296768}

[Sami, 2013-09-23 18:20:02]

This is partly an RFC of how you guys would feel about this. I tested that WebGL
with long running shaders and complex geometry runs well on the Galaxy Tab 3.

One problem is that I couldn't come up with a way to actually make sure we're
not using virtual contexts, because the software rendering list is parsed before
the workarounds list. There is a chance that virtual contexts and this patch
could become out of sync.

[Ken Russell (switch to Gerrit), 2013-09-23 19:05:41]

What's the behavior if tab A starts a long-running draw call, tab B is created,
and tab A is shut down? Without EXT_robustness' implicit watchdog timer and kill
switch, I suspect that tab A's OpenGL context will still consume all of the
GPU's time until the draw call actually completes. Either that, or the phone
will be unresponsive until tab A's draw call completes.

I'd support turning on WebGL on all devices where DoS defense mechanisms are in
place. If behavior is reasonable on this device then turning it on sounds good
to me, but there needs to be some tracking bug for ARM actually adding the reset
notification and associated watchdog timer in the driver.

[Sami, 2013-09-24 10:30:41]

On 2013/09/23 19:05:41, Ken Russell wrote:
> What's the behavior if tab A starts a long-running draw call, tab B is
created,
> and tab A is shut down? Without EXT_robustness' implicit watchdog timer and
kill
> switch, I suspect that tab A's OpenGL context will still consume all of the
> GPU's time until the draw call actually completes. Either that, or the phone
> will be unresponsive until tab A's draw call completes.

You're right. I tested again with some more expensive shaders. Apparently the
Khronos ones aren't that bad on this GPU. The effect is that the entire device
UI -- not just Chrome -- hangs while the shader is executing and there's no way
to break out of this state. Based on this we probably don't want to turn on
WebGL here.
 
> I'd support turning on WebGL on all devices where DoS defense mechanisms are
in
> place. If behavior is reasonable on this device then turning it on sounds good
> to me, but there needs to be some tracking bug for ARM actually adding the
reset
> notification and associated watchdog timer in the driver.

I can check with ARM but given that this is a previous-gen GPU they might not be
able to change the driver substantially. It's too bad really since Mali-400
makes up 35% of all the devices supporting *_robustness on gfxbench.com.

[Sami, 2013-09-25 16:13:55]

On 2013/09/24 10:30:41, Sami wrote:
> I can check with ARM but given that this is a previous-gen GPU they might not
be
> able to change the driver substantially.

Verified with ARM that this is indeed the case. Closing the issue.

[Sami, 2014-09-25 18:23:48]

PTAL. I don't have a device to test this on at the moment.

[Ken Russell (switch to Gerrit), 2014-09-25 18:28:51]

LGTM given the discussion on bug 416690.

[Sami, 2014-09-25 18:32:21]

The CQ bit was checked by skyostil@chromium.org

[commit-bot: I haz the power, 2014-09-25 18:33:40]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/24037006/10001

[no sievers, 2014-09-25 19:19:36]

On 2013/09/23 18:20:02, Sami wrote:
> One problem is that I couldn't come up with a way to actually make sure we're
> not using virtual contexts, because the software rendering list is parsed
before
> the workarounds list. There is a chance that virtual contexts and this patch
> could become out of sync.

I think now everything should be parsed in GpuDataManager(Private) and we pass
the workarounds to the gpu process.
Do you think we could hard-code something that blows up in there if
'uses_virtual_contexts && allows_webgl && !has_reset_notifications'?

So we whitelist Mali-400 because we tested it and believe it to behave robustly,
although it does not support reset notifications.
Is that true for all drivers including older ones?

I don't fully understand the check for GL_EXT_robustness. Do all Mali-400MP
drivers report this?
Or only newer ones? Does this somehow relate to any expected behavior in the
driver?
(The spec only seems to say that the presence of the extension means it supports
robust buffer access, which I think we don't use, and that you can query whether
it supports reset notifications.)

[commit-bot: I haz the power, 2014-09-25 19:40:58]

Committed patchset #3 (id:10001) as 4a3a318dbd686735c5d1a55c838e2005cecf92b7

[commit-bot: I haz the power, 2014-09-25 19:42:16]

Patchset 3 (id:??) landed as
https://crrev.com/f56d21f26ff4f09f8dfe35d84d20f4ce45f45c2e
Cr-Commit-Position: refs/heads/master@{#296768}

[Ken Russell (switch to Gerrit), 2014-09-25 19:43:35]

On 2014/09/25 19:19:36, sievers wrote:
> So we whitelist Mali-400 because we tested it and believe it to behave
robustly,
> although it does not support reset notifications.
> Is that true for all drivers including older ones?

As ARM pointed out in an offline email, there was an unfortunate bug in the
first version of their driver exposing the GL_EXT_robustness extension. Future
drivers and devices will fix this bug. The whitelisting of the Mali 400 when
EXT_robustness is exposed should cover exactly the drivers on which we care
about enabling WebGL.

[no sievers, 2014-09-25 19:52:55]

On 2014/09/25 19:43:35, Ken Russell wrote:
> On 2014/09/25 19:19:36, sievers wrote:
> > So we whitelist Mali-400 because we tested it and believe it to behave
> robustly,
> > although it does not support reset notifications.
> > Is that true for all drivers including older ones?
> 
> As ARM pointed out in an offline email, there was an unfortunate bug in the
> first version of their driver exposing the GL_EXT_robustness extension. Future
> drivers and devices will fix this bug. The whitelisting of the Mali 400 when
> EXT_robustness is exposed should cover exactly the drivers on which we care
> about enabling WebGL.

Makes sense. A comment in the whitelist would be great though explaining that.

LGTM. But Sami, would you mind filing a bug at least for enforcing virtual
context to OFF when we whitelist webgl without reset? Assign it to me, I'd be
happy to look into that. I'm just worried that eventually we'll end up with a
configuration with exactly that otherwise (by turning on virtual contexts
somewhere to work around a problem and/or extending the robust_without_reset
whitelist).

[Sami, 2014-09-26 09:37:06]

On 2014/09/25 19:52:55, sievers wrote:
> On 2014/09/25 19:43:35, Ken Russell wrote:
> > On 2014/09/25 19:19:36, sievers wrote:
> > > So we whitelist Mali-400 because we tested it and believe it to behave
> > robustly,
> > > although it does not support reset notifications.
> > > Is that true for all drivers including older ones?
> > 
> > As ARM pointed out in an offline email, there was an unfortunate bug in the
> > first version of their driver exposing the GL_EXT_robustness extension.
Future
> > drivers and devices will fix this bug. The whitelisting of the Mali 400 when
> > EXT_robustness is exposed should cover exactly the drivers on which we care
> > about enabling WebGL.
> 
> Makes sense. A comment in the whitelist would be great though explaining that.
> 
> LGTM. But Sami, would you mind filing a bug at least for enforcing virtual
> context to OFF when we whitelist webgl without reset? Assign it to me, I'd be
> happy to look into that. I'm just worried that eventually we'll end up with a
> configuration with exactly that otherwise (by turning on virtual contexts
> somewhere to work around a problem and/or extending the robust_without_reset
> whitelist).

Good idea, done: https://code.google.com/p/chromium/issues/detail?id=418037

[tkilarski, 2014-11-27 10:54:07]

Sorry, maybe not the best place to ask that question, but let me try.
This thread is indicating WebGL working on Mali400 GPU. I am investigating 
Chromium/WebGL issues on linux device with same GPU.
When WebGL context is created without alpha channel I get 
GL_FRAMEBUFFER_UNSUPPORTED error. In general chromium code flow is same as 
indicated here http://community.arm.com/message/12954#12954 (FBO with 
GL_RGB color attachment not supported?). On the other hand, the same 
chromium version compiled for android GalaxySII, and executing the same FBO 
initialization flow, does not expose any problem with GL_RGB format. How 
then understand the answer from ARM forum? Is GL_RGB making just 
performance issue, or is it not supported by the hardware? Is there any 
workaround then in Android GL driver, which is then not present in linux 
version?

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[chromium-reviews, 2014-11-27 13:15:32]

I think this question would be better directed at the ARM folks. In general
Chromium shouldn't be depending on being able to render to GL_RGB8 since
that format is optional. One thing to check is whether the FBO is using a
texture or a renderbuffer to back the color attachment and what the format
of that object is. I think some drivers may for instance allow the use of
an GL_RGBA texture as a GL_RGB color attachment.

- Sami

2014-11-27 10:54 GMT+00:00 <tkilarski@opera.com>:

> Sorry, maybe not the best place to ask that question, but let me try.
> This thread is indicating WebGL working on Mali400 GPU. I am investigating
> Chromium/WebGL issues on linux device with same GPU.
> When WebGL context is created without alpha channel I get
> GL_FRAMEBUFFER_UNSUPPORTED error. In general chromium code flow is same
> as indicated here http://community.arm.com/message/12954#12954 (FBO with
> GL_RGB color attachment not supported?). On the other hand, the same
> chromium version compiled for android GalaxySII, and executing the same FBO
> initialization flow, does not expose any problem with GL_RGB format. How
> then understand the answer from ARM forum? Is GL_RGB making just
> performance issue, or is it not supported by the hardware? Is there any
> workaround then in Android GL driver, which is then not present in linux
> version?
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.