An internal reporter says: It looks like WebGL capabilities have also changed between 15.3 and 15.4 (on MacOS + Metal, at any rate). Iām seeing GL_MAX_FRAGMENT_UNIFORM_VECTORS (and VERTEX too) drop from 1024 (15.3) to 256 (15.4) on several devices: MacBook Pro intel MacBook Pro radeon MacBook Pro M1 Max Presumably another side effect of the ANGLE bump. (Apple folks - there is some discussion on Slack about what might have gone wrong - see radar)
<rdar://problem/91384766>
Created attachment 456994 [details] Patch
Note that there are important steps to take when updating ANGLE. See https://trac.webkit.org/wiki/UpdatingANGLE
Comment on attachment 456994 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=456994&action=review > Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/ProgramMtl.mm:1294 > + > + Nit: Blank lines.
Created attachment 456997 [details] Patch
Comment on attachment 456997 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=456997&action=review > Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/ProgramMtl.mm:1286 > + ANGLE_TRY(getBufferPool(context)->allocate(context, > + uniformBlock.uniformData.size(), &ptrOut, &mtlBufferOut, &offsetOut)); I'm not familiar with ANGLE but I expect you don't need to worry about deallocation? > Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/ProgramMtl.mm:1288 > + memcpy(ptrOut, uniformBlock.uniformData.data(), uniformBlock.uniformData.size()); And we don't need to worry about reading out of bounds here?
Comment on attachment 456997 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=456997&action=review >> Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/ProgramMtl.mm:1286 >> + uniformBlock.uniformData.size(), &ptrOut, &mtlBufferOut, &offsetOut)); > > I'm not familiar with ANGLE but I expect you don't need to worry about deallocation? That's correct, deallocation will happen when the buffer pool is destroyed. Any in-flight buffers can be reused. >> Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/ProgramMtl.mm:1288 >> + memcpy(ptrOut, uniformBlock.uniformData.data(), uniformBlock.uniformData.size()); > > And we don't need to worry about reading out of bounds here? Also correct, ANGLE_TRY will return early if we fail to allocate a buffer of proper size.
the kDefaultUniformsMaxSize = 16 * 1024; is just one UBO buffer max size. does it support that if i define many UBOs in one shader program each size is 16 * 1024?
Committed r293494 (250027@main): <https://commits.webkit.org/250027@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 456997 [details].
*** Bug 239116 has been marked as a duplicate of this bug. ***