RESOLVED FIXED 224948
Select proper IOSurface backing format for configuration
https://bugs.webkit.org/show_bug.cgi?id=224948
Summary Select proper IOSurface backing format for configuration
Kyle Piddington
Reported 2021-04-22 14:01:13 PDT
Select proper IOSurface backing format for configuration
Attachments
Patch (3.51 KB, patch)
2021-04-22 14:05 PDT, Kyle Piddington
no flags
Patch (3.47 KB, patch)
2021-04-22 15:11 PDT, Kyle Piddington
no flags
Patch (3.49 KB, patch)
2021-04-22 17:09 PDT, Kyle Piddington
no flags
Patch (3.46 KB, patch)
2021-04-23 10:44 PDT, Kyle Piddington
kpiddington: commit-queue+
Kyle Piddington
Comment 1 2021-04-22 14:05:57 PDT
EWS Watchlist
Comment 2 2021-04-22 14:06:54 PDT
Note that there are important steps to take when updating ANGLE. See https://trac.webkit.org/wiki/UpdatingANGLE
Tim Horton
Comment 3 2021-04-22 14:57:36 PDT
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.
Kyle Piddington
Comment 4 2021-04-22 15:11:33 PDT
Kyle Piddington
Comment 5 2021-04-22 16:00:26 PDT
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)
Dean Jackson
Comment 6 2021-04-22 16:02:24 PDT
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.
Kyle Piddington
Comment 7 2021-04-22 17:09:43 PDT
Maciej Stachowiak
Comment 8 2021-04-23 02:22:49 PDT
Kyle Piddington
Comment 9 2021-04-23 10:44:16 PDT
Radar WebKit Bug Importer
Comment 10 2021-04-23 13:09:57 PDT
Brent Fulgham
Comment 11 2021-04-23 13:28:03 PDT
This is actually: <rdar://problem/76284889>
EWS
Comment 12 2021-04-25 12:06:15 PDT
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].
Note You need to log in before you can comment on or make changes to this bug.