Reenable MSAA on Mali

Reenable MSAA on Mali

Now that we have a WebGL implementation of MSAA using
EXT_multisampled_render_to_texture, we can reenable MSAA on Mali GPUs.

BUG=322706
TEST=run on daisy, WebGL now uses multisampling and simple demos run at 60 fps.

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

[marcheu, 2014-03-06 00:05:15]

I'm also going to send this to GPU bots and see what explodes.

[piman, 2014-03-06 00:09:19]

lgtm

[Ken Russell (switch to Gerrit), 2014-03-06 00:29:19]

In the TEST= line, do you mean "WebGL now uses"?

+sievers and bsalomon, because I think this blacklist entry most notably
affected Skia. I thought this blacklist entry affected GL 3 core's multisampling
and not EXT_multisampled_render_to_texture.

[marcheu, 2014-03-06 00:32:10]

On 2014/03/06 00:29:19, Ken Russell wrote:
> In the TEST= line, do you mean "WebGL now uses"?

Hmm, yes that's what I meant. I'll update the message.

> 
> +sievers and bsalomon, because I think this blacklist entry most notably
> affected Skia. I thought this blacklist entry affected GL 3 core's
multisampling
> and not EXT_multisampled_render_to_texture.

[bsalomon_chromium, 2014-03-06 13:48:42]

On 2014/03/06 00:32:10, marcheu wrote:
> On 2014/03/06 00:29:19, Ken Russell wrote:
> > In the TEST= line, do you mean "WebGL now uses"?
> 
> Hmm, yes that's what I meant. I'll update the message.
> 
> > 
> > +sievers and bsalomon, because I think this blacklist entry most notably
> > affected Skia. I thought this blacklist entry affected GL 3 core's
> multisampling
> > and not EXT_multisampled_render_to_texture.

I believe that is correct. My experiments (outside of Chromium using Skia) found
that ES3 MSAA on the N10 was far buggier than using the render_to_texture
extension and had worse performance. The narrower API of the extension is a
better match for the HW, and the ES3 MSAA implementation jumps through hoops to
try to behave like the extension when possible, that is not actually write out a
full MSAA buffer but resolve tiles when they are written out the FB.

[Ken Russell (switch to Gerrit), 2014-03-06 21:21:05]

On 2014/03/06 13:48:42, bsalomon1 wrote:
> On 2014/03/06 00:32:10, marcheu wrote:
> > On 2014/03/06 00:29:19, Ken Russell wrote:
> > > In the TEST= line, do you mean "WebGL now uses"?
> > 
> > Hmm, yes that's what I meant. I'll update the message.
> > 
> > > 
> > > +sievers and bsalomon, because I think this blacklist entry most notably
> > > affected Skia. I thought this blacklist entry affected GL 3 core's
> > multisampling
> > > and not EXT_multisampled_render_to_texture.
> 
> I believe that is correct. My experiments (outside of Chromium using Skia)
found
> that ES3 MSAA on the N10 was far buggier than using the render_to_texture
> extension and had worse performance. The narrower API of the extension is a
> better match for the HW, and the ES3 MSAA implementation jumps through hoops
to
> try to behave like the extension when possible, that is not actually write out
a
> full MSAA buffer but resolve tiles when they are written out the FB.

Brian: can you confirm whether removing this blacklist entry is going to break
anything? Or Daniel, could you do the same?

[no sievers, 2014-03-06 21:51:40]

On 2014/03/06 21:21:05, Ken Russell wrote:
> On 2014/03/06 13:48:42, bsalomon1 wrote:
> > On 2014/03/06 00:32:10, marcheu wrote:
> > > On 2014/03/06 00:29:19, Ken Russell wrote:
> > > > In the TEST= line, do you mean "WebGL now uses"?
> > > 
> > > Hmm, yes that's what I meant. I'll update the message.
> > > 
> > > > 
> > > > +sievers and bsalomon, because I think this blacklist entry most notably
> > > > affected Skia. I thought this blacklist entry affected GL 3 core's
> > > multisampling
> > > > and not EXT_multisampled_render_to_texture.
> > 
> > I believe that is correct. My experiments (outside of Chromium using Skia)
> found
> > that ES3 MSAA on the N10 was far buggier than using the render_to_texture
> > extension and had worse performance. The narrower API of the extension is a
> > better match for the HW, and the ES3 MSAA implementation jumps through hoops
> to
> > try to behave like the extension when possible, that is not actually write
out
> a
> > full MSAA buffer but resolve tiles when they are written out the FB.
> 
> Brian: can you confirm whether removing this blacklist entry is going to break
> anything? Or Daniel, could you do the same?

The workaround disables both es3 msaa (GL_EXT_framebuffer_multisample) and
GL_EXT_multisampled_render_to_texture.

If you are paranoid you could split up the flag in two, but I think it's
probably fine to delete the ARM entry if WebGL will never use
framebuffer_multisample (I assume multisample_render_to_texture is always there
on es3 drivers). I don't think anything else would use it and hit a slow path.

[no sievers, 2014-03-06 21:53:24]

LGTM

+Sami for FYI in case this (multisampled_render_to_texture) doesn't work as
expected on Nexus 10.

[Ken Russell (switch to Gerrit), 2014-03-06 22:01:47]

Great. Thanks. LGTM

+zmo as FYI

[marcheu, 2014-03-06 22:06:36]

The CQ bit was checked by marcheu@chromium.org

[commit-bot: I haz the power, 2014-03-06 22:33:43]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/marcheu@chromium.org/188173002/1

[Sami, 2014-03-07 11:32:19]

lgtm, thanks for doing this!

[commit-bot: I haz the power, 2014-03-07 13:11:45]

Change committed as 255601