981856 - WebGL tests fail on AWS

Status: RESOLVED FIXED

(Testing :: General, defect)

Description

[Jeff Muizelaar [:jrmuizel]]

This is what we get:

11:53:49     INFO -  03-10 18:21:04.698   668   668 E EGL_emulation: rcCreateWindowSurface returned 0
11:53:49     INFO -  03-10 18:21:04.698   668   668 E EGL_emulation: tid 668: eglCreatePbufferSurface(687): error 0x3003 (EGL_BAD_ALLOC)

Comment 1

[Jeff Muizelaar [:jrmuizel]]

Attachment: Don't ask for 565

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 8390800 [details] [diff] [review]
Don't ask for 565

Review of attachment 8390800 [details] [diff] [review]:
-----------------------------------------------------------------

llvmpipe seems to give out 565 configs that it can't actually make PBuffers for. This patch avoids that.

Comment 3

[Armen [:armenzg]]

Pushed it to Elm to see early results:
https://tbpl.mozilla.org/?tree=Elm&jobname=b2g

Comment 4

[Kelsey Gilbert [:jgilbert]]

Comment on attachment 8390800 [details] [diff] [review]
Don't ask for 565

Review of attachment 8390800 [details] [diff] [review]:
-----------------------------------------------------------------

I really don't like papering over these issues.

However, in this case, I'm fine with taking this patch for a different reason: WebGL requires 8-bit color-channels, so we shouldn't accept 565 anyways.

Comment 5

[Kelsey Gilbert [:jgilbert]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #2)
> Comment on attachment 8390800 [details] [diff] [review]
> Don't ask for 565
> 
> Review of attachment 8390800 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> llvmpipe seems to give out 565 configs that it can't actually make PBuffers
> for. This patch avoids that.

Please link to the bug report made against llvmpipe.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

(In reply to Jeff Gilbert [:jgilbert] from comment #5)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #2)
> > Comment on attachment 8390800 [details] [diff] [review]
> > Don't ask for 565
> > 
> > Review of attachment 8390800 [details] [diff] [review]:
> > -----------------------------------------------------------------
> > 
> > llvmpipe seems to give out 565 configs that it can't actually make PBuffers
> > for. This patch avoids that.
> 
> Please link to the bug report made against llvmpipe.

This doesn't happen with current llvmpipe, just with old version that we're using on the AWS machines.

Comment 7

[Jeff Muizelaar [:jrmuizel]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/a2ec4ab256e8

https://hg.mozilla.org/integration/mozilla-inbound/rev/46d18be48bc4

Comment 8

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #7)
> https://hg.mozilla.org/integration/mozilla-inbound/rev/a2ec4ab256e8
> 
> https://hg.mozilla.org/integration/mozilla-inbound/rev/46d18be48bc4

Both backed out in http://hg.mozilla.org/integration/mozilla-inbound/rev/5e86e89e463f for various webgl failures on b2g:
https://tbpl.mozilla.org/php/getParsedLog.php?id=36172249&tree=Mozilla-Inbound

Comment 9

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

https://hg.mozilla.org/mozilla-central/rev/664df0574f11

Comment 10

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 8390800 [details] [diff] [review]
Don't ask for 565

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Switching to AWS test machines
User impact if declined: All of the webgl tests will fail on the AWS test machines
Testing completed: Has been on m-c for two weeks. 
Risk to taking this patch (and alternatives if risky): Quite limited, this code is exercised when ever we create a webgl context. If it breaks all of WebGL will be broken so it should be pretty noticeable.

Comment 11

[bhavana bajaj [:bajaj]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #10)
> Comment on attachment 8390800 [details] [diff] [review]
> Don't ask for 565
> 
> [Approval Request Comment]
> Bug caused by (feature/regressing bug #): Switching to AWS test machines
> User impact if declined: All of the webgl tests will fail on the AWS test
> machines
> Testing completed: Has been on m-c for two weeks. 
> Risk to taking this patch (and alternatives if risky): Quite limited, this
> code is exercised when ever we create a webgl context. If it breaks all of
> WebGL will be broken so it should be pretty noticeable.

There is no manual testing going-on for the builds generated from b2g18/b2g26, so will the failures be obvious by automation ?
Also these branches are strictly restricted to security uplifts and this exception is being made due to   infra change and assuming this is transparent to end user impact.

Comment 12

[Jeff Muizelaar [:jrmuizel]]

(In reply to bhavana bajaj [:bajaj] from comment #11)
> 
> There is no manual testing going-on for the builds generated from
> b2g18/b2g26, so will the failures be obvious by automation ?

Yes I expect so.

> Also these branches are strictly restricted to security uplifts and this
> exception is being made due to   infra change and assuming this is
> transparent to end user impact.

Yeah, it is unfortunate this change needs to be made, but I think the cost of maintaining the old system far out weighs the risk that this change introduces.

Comment 13

[Jonathan Griffin (:jgriffin)]

https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/33b122abc04a

Comment 14

[Armen [:armenzg]]

https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/8aff3077abe8

The patch does not apply to b2g26_v1_2.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

The tests in this bug don't exist on b2g26/b2g18, so I assume ignoring those hunks is fine. Also, this didn't apply to b2g18 because bug 716859 never landed there. On the other hand, we only run reftest-sanity there anyway, so do we care?

https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/c88078199277

Comment 16

[Jeff Muizelaar [:jrmuizel]]

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #15)
> The tests in this bug don't exist on b2g26/b2g18, so I assume ignoring those
> hunks is fine. Also, this didn't apply to b2g18 because bug 716859 never
> landed there. On the other hand, we only run reftest-sanity there anyway, so
> do we care?
> 
> https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/c88078199277

If things are green then we have no problems.

Comment 17

[Armen [:armenzg]]

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #15)
> The tests in this bug don't exist on b2g26/b2g18, so I assume ignoring those
> hunks is fine. Also, this didn't apply to b2g18 because bug 716859 never
> landed there. On the other hand, we only run reftest-sanity there anyway, so
> do we care?
> 
> https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/c88078199277

Let's ignore b2g18. My apologies if I asked to land the patches there as well.