commit 0044f4d1ba70c500432eee3aa93bef52df9eb5b6
author Le Hoang Quyen <lehoangquyen@chromium.org> Sun May 12 16:29:30 2024
committer Angle LUCI CQ <angle-scoped@luci-project-accounts.iam.gserviceaccount.com> Mon May 13 19:09:28 2024
tree c856a85d1fe67da74a8198b9c48aa986e9232119
parent 53cb3f480c71907301cda9db7531ba49d8ef066e

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>