1555002 - Panic in glBlitFramebuffer with some wrench reftests on the android emulator

Status: NEW

(Core :: Graphics: WebRender, defect, P3)

Description

[Kartikaya Gupta (email:[e-mail])]

Filing this to track the panics in blit_framebuffer on android debug wrench reftests in the android emulator. The STR to repro are:

• Build the wrench APK for android, per instructions here
• Edit the wrench/reftests/**/reftests.list files so that the blend/multiply.yaml reftest is enabled on android (can comment out all the rest of the reftests to make it easier)
• Run the reftests using the command here

For me this results in a panic, and the emulator log (which goes in ~/.wrench/logs) shows it coming from this line which in turn is getting called from here and here.

The panic is due the call returning GL_INVALID_OPERATION (0x502). So I looked at the API documentation and checked for the various conditions that might trigger this error, and as far as I could tell everything was good. I also found what I think is the emulator code that implements this API here and :kvark noticed that the code there is obviously wrong (using | instead of & for checking bits in a mask). So that might explain the failure, although I also looked at the extra conditions this would result in checking and as far as I could tell none of those should have failed either. Regardless I filed an upstream issue for it.

Comment 1

[Jamie Nicol [:jnicol]]

I think this is an emulator (or perhaps swiftshader) bug when blitting between texture arrays. If we force webrender to use 2d textures the blit succeeds. I will create a minimal test case to confirm it's not more nuanced than that, and will file a bug against the emulator.

Comment 2

[Jamie Nicol [:jnicol]]

This appears to have been fixed so should trickle down to the emulator eventually. Though this might not matter urgently for android reftests since we're switching to use the gpu backend.

Comment 3

[Dzmitry Malyshau [:kvark]]

I'm seeing this in https://phabricator.services.mozilla.com/D39912 try:
https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=259047935&revision=2ba306f660b57422861a3d7dcc0f112e7e512372

Comment 4

[Dzmitry Malyshau [:kvark]]

Marking as blocking. Although, technically, we could be eagerly clearing the texture cache on each allocation (like we used to), but that seems like a hack specifically working around the issue not seen in the wild.