Bug 228192
| Summary: | getBufferSubData() incorrectly returns all zeros for pixel buffers on iOS 15 with WebGL 2 | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Paris Morgan <paris> |
| Component: | WebGL | Assignee: | Kyle Piddington <kpiddington> |
| Status: | ASSIGNED | ||
| Severity: | Normal | CC: | dino, jean-yves.avenard, kbr, kkinnunen, kpiddington, smoley, tony, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Other | ||
| Hardware: | iPhone / iPad | ||
| OS: | Other | ||
| Bug Depends on: | 228012 | ||
| Bug Blocks: | |||
Paris Morgan
I have found a regression where a particular shading pipeline using pixel buffers on iOS 15 with WebGL 2 (with both WebGL via Metal = true & false) always returns all zeros from `getBufferSubData()`. Note that while this effect is 100% reliable on this particular pipeline, it does not reproduce on other simpler pipelines. If we switch from reading from a pixel buffer to directly reading from the frame buffer, the issue goes away and the same pipeline works correctly with 100% reliability.
Our code is relatively complex, involving multiple proprietary shaders drawing to multiple intermediate frame buffers before ultimately reaching the frame buffer that's bound to the pixel buffer. My attempts to write a simple repro for this using a non-proprietary shallow pipeline have failed to reproduce the issue, but opening this bug to put it on your radar. Perhaps you know of something that may cause this, or this is an area that may be somewhat untested?
Some extra details:
- There are no WebGL errors printed.
- This same shader pipeline works with iOS 14 and below (with WebGL 2), and also on Android (with WebGL 2). Only on iOS 15 (with WebGL 2) did this code stop working.
I will update this bug with a simple repro if I am able to, thank you.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Smoley
Thanks for filing, please do update with a reduced test case :)
Radar WebKit Bug Importer
<rdar://problem/80990603>
Kenneth Russell
Can you add explicit error checking code in your application (getError() calls) and double-check that no OpenGL errors are being generated?
A reduced test case would be extremely helpful. The WebKit-side code for getBufferSubData is straightforward, so it's hard to guess where an error might be.
There is a chance that the fix for Bug 228012 may have fixed this. In that bug, the implementation of fences in ANGLE's Metal backend wasn't working correctly because some IOKit calls weren't being allowed by the sandbox. There's a chance that the same synchronization primitives are used in ANGLE's implementation of glMapBuffer, which WebGL2RenderingContext.getBufferSubData calls.
Paris Morgan
An issue where a fence gets incorrectly triggered before data is ready is possibly a good explanation for what we're seeing. Would you have expect the fix for Bug 228012 to improve both Metal and OpenGL backends? We are seeing the issue on both.
Kenneth Russell
I'm not sure but let me ask Kyle to triage this since only Apple employees can deploy builds to iOS devices.
Kyle Piddington
I will be keeping an eye on this, Please let me know if you have a repro, Paris!
Thank you!
Kyle Piddington
(In reply to Paris Morgan from comment #4)
> An issue where a fence gets incorrectly triggered before data is ready is
> possibly a good explanation for what we're seeing. Would you have expect the
> fix for Bug 228012 to improve both Metal and OpenGL backends? We are seeing
> the issue on both.
Unfortunately, no. The fencing fix should have only impacted the Metal backend.