TextureVk calls onStateChange when releasing buffer views TextureVk::setBuffer releases buffer views and they don't get initialized unless a dirty bit is set. That works on the first draw call because Texture::Texture() sets DIRTY_BIT_IMPLEMENTATION in constructor, but when called twice mBufferViews remains unitialized causing mBufferViews.getView() misbehavior. Fix this by calling onStateChange when buffer views are released. As mBufferViews is only initialized conditionally for texture buffers, add a bool for tracking whether it is in the initialized state to avoid marking texture as dirty unnecessarily. Note that this isn't handled by signalDirtyStorage() inside Texture::setBufferRange because (in this test case?) there are no observers on Texture so onStateChange called from Texture is a no-op. Texture however observes its TextureVk implementation so onStateChange calls from TextureVk end up setting the dirty bit in Texture::onSubjectStateChange. Bug: b/278585075 Change-Id: I2b83160cdd89a086ed81e8412cd64d0aad930911 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4457147 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Roman Lavrov <romanl@google.com>