Select proper IOSurface backing format for configuration
Created attachment 426850 [details] Patch
Note that there are important steps to take when updating ANGLE. See https://trac.webkit.org/wiki/UpdatingANGLE
Comment on attachment 426850 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=426850&action=review > Source/ThirdParty/ANGLE/ChangeLog:3 > + [Metal ANGLE] Select proper IOSurface backing format for WebGL environment Something crazy happened with the indentation here. > Source/ThirdParty/ANGLE/ChangeLog:5 > + rdar://? > Source/ThirdParty/ANGLE/ChangeLog:7 > + Depending on the architecture, WebCore expects different > + IOSurface texture targets for the main buffer. When running catalyst on Is it possible for the WebCore code that has this expectation, and the ANGLE code that is expected to behave this way, to both predicate their behavior on a single bit? (so that they don't have to be kept in sync?). I guess that might be tricky since ANGLE can't use our feature macros. > Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/DisplayMtl.mm:440 > +#if TARGET_OS_MAC || TARGET_OS_MACCATALYST Does not actually seem like you need this function on macOS proper.
Created attachment 426855 [details] Patch
Comment on attachment 426850 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=426850&action=review >> Source/ThirdParty/ANGLE/ChangeLog:7 >> + IOSurface texture targets for the main buffer. When running catalyst on > > Is it possible for the WebCore code that has this expectation, and the ANGLE code that is expected to behave this way, to both predicate their behavior on a single bit? (so that they don't have to be kept in sync?). I guess that might be tricky since ANGLE can't use our feature macros. It's tricky to do here, since this bind point needs to be set at initialization, and our only hint is data that could be passed down at display initialization. For OpenGL, Webkit selects a CGL or EAGL display depending on the backend they need. For Metal, we alway select DisplayMTL. We could do this with an additional context bit, or by creating multiple ConfigSets and letting Webkit select the one that matches the context we need to create. (Which would allow us to select Texture2D or TextureRect separate from the architecture)
Comment on attachment 426855 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=426855&action=review > Source/ThirdParty/ANGLE/ChangeLog:5 > + Could you put the radar link (just the link part, not the title) here as well (on a new line)? That way the bug will automatically move to integrate.
Created attachment 426868 [details] Patch
<rdar://76284889>
Created attachment 426924 [details] Patch
<rdar://problem/77083138>
This is actually: <rdar://problem/76284889>
Committed r276567 (237003@main): <https://commits.webkit.org/237003@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 426924 [details].