Panic in glBlitFramebuffer with some wrench reftests on the android emulator
Categories
(Core :: Graphics: WebRender, defect, P3)
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 theblend/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.
Reporter | ||
Updated•5 years ago
|
Comment 1•5 years ago
|
||
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•5 years ago
|
||
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•5 years ago
|
||
Comment 4•5 years ago
|
||
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.
Updated•2 years ago
|
Description
•