gpu: Ensure correct shared image lifetime.
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}
Showing
Please register or sign in to comment