Bug 224948 – Select proper IOSurface backing format for configuration

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Kyle Piddington]

Select proper IOSurface backing format for configuration

[Kyle Piddington]

Created attachment 426850 [details]
Patch

[EWS Watchlist]

Note that there are important steps to take when updating ANGLE. See https://trac.webkit.org/wiki/UpdatingANGLE

[Tim Horton]

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]

Created attachment 426855 [details]
Patch

[Kyle Piddington]

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 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]

Created attachment 426868 [details]
Patch

[Maciej Stachowiak]

<rdar://76284889>

[Kyle Piddington]

Created attachment 426924 [details]
Patch

[Radar WebKit Bug Importer]

<rdar://problem/77083138>

[Brent Fulgham]

This is actually:

<rdar://problem/76284889>

[EWS]

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].