GitLab

A lot of client code assumes that if a context is lost (which could be
a GPU process crash or an error in the command stream) any resources
created by it will be cleaned up automatically. This is particularly
true for SharedGpuContext where all users hold a weakptr and the object
is destroyed on a context error.

While the above assumption is true for any resources created using the
command buffer (GL/Raster/Dawn) which is per context, its not true for
shared images where the service side ties their lifetime to the shared
GpuChannel for a process. This inconsistency can result in leaking these
images if the client doesn't try to re-create a new context to delete
them. On the flip side deleting a non-existent shared image results in a
fatal error on the service side which tears down the GpuChannel, which
means clients need to distinguish between losing a single context versus
the GpuChannel to know when cleanup is needed making the ownership
management here quite brittle.

This change makes shared image ownership semantics similar to other
resources created using a context by adding tracking for shared images
created using the SharedImageInterface on a particular context. If that
context is destroyed, it internally ensures any associated alive shared
images are destroyed.

R=ericrk@chromium.org

Change-Id: Iaba4b1f791a2c0ed7890d3a593b9f158c152bc7d
Bug: 1042446,1042481,1036142
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2006731Reviewed-by: Eric Karl <ericrk@chromium.org>
Reviewed-by: Frank Liberato <liberato@chromium.org>
Commit-Queue: Khushal <khushalsagar@chromium.org>
Auto-Submit: Khushal <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#734034}