Open Bug 1555002 Opened 5 years ago Updated 2 years ago

Panic in glBlitFramebuffer with some wrench reftests on the android emulator

Categories

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

Other Branch
defect

Tracking

()

People

(Reporter: kats, Unassigned)

References

Details

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.

Priority: -- → P3

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.

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.

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.

Blocks: 1567577
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.