kc3-lang/angle

2024-05-13T00:29:30

Metal: fix IOSurface's render targets invalidated by max level change. This CL fixes a bug in the following tricky situation: - Client binds an IOSurface to a texture. - Previously this would internally intialize the texture's max level to the default value 1000. - Client changes the texture's max level to 0. - Client attachs the texture to FBO 1. - Client binds FBO 1 and clear it. - This triggers TextureMtl::getAttachmentRenderTarget() that initializes the RenderTargetMtl of the texture. - Client binds FBO 0 and sample the texture. - Previously this could trigger TextureMtl::onBaseMaxLevelsChanged() which would invalidate the texture's RenderTargetMtl. - Client binds FBO 1. - Client blits FBO 0 to FBO 1. - This will set DIRTY_BIT_COLOR_BUFFER_CONTENTS_0 in FBO 1. - Client calls glFlush to restart render command encoder. - Client issues a draw call. - DIRTY_BIT_COLOR_BUFFER_CONTENTS_0 would cause FrameBufferMtl to re-initialize RenderPassDesc from invalid RenderTargetMtl. - A new render encoder would be created from the invalid RenderPassDesc. - the draw call would be encoded to a render command encoder without any valid color attachment. The fix in this CL is that when we bind an IOSurface to a texture, the texture's max level will be automatically set to 0. This will avoid its RenderTargetMtl from being invalidated if users explicitly change the max level to 0 in future. Note: this is not a foolproof fix for every scenario concerning the base/max level in IOSurface bound/or immutable textures. We will fix them in future CLs. Bug: b/335353385 Change-Id: I3a2da6991764f22393178f40c1d7bbe60503cba4 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5531388 Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Kenneth Russell <kbr@chromium.org> Commit-Queue: Quyen Le <lehoangquyen@chromium.org>