ASSIGNED 228192
getBufferSubData() incorrectly returns all zeros for pixel buffers on iOS 15 with WebGL 2
https://bugs.webkit.org/show_bug.cgi?id=228192
Summary getBufferSubData() incorrectly returns all zeros for pixel buffers on iOS 15 ...
Paris Morgan
Reported 2021-07-22 13:03:08 PDT
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
Smoley
Comment 1 2021-07-22 16:49:47 PDT
Thanks for filing, please do update with a reduced test case :)
Radar WebKit Bug Importer
Comment 2 2021-07-22 16:49:58 PDT
Kenneth Russell
Comment 3 2021-07-22 16:59:19 PDT
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
Comment 4 2021-07-23 09:47:52 PDT
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
Comment 5 2021-07-23 12:48:07 PDT
I'm not sure but let me ask Kyle to triage this since only Apple employees can deploy builds to iOS devices.
Kyle Piddington
Comment 6 2021-07-23 15:03:40 PDT
I will be keeping an eye on this, Please let me know if you have a repro, Paris! Thank you!
Kyle Piddington
Comment 7 2021-07-26 11:05:39 PDT
(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.
Note You need to log in before you can comment on or make changes to this bug.