Fix RE's VulkanInterface destruction & unnecessary initialization

SurfaceFlinger's initialization of RE now:
- Only attempts to check for VK support if either the GaneshVk or
  GraphiteVk flag is set.
- Caches the VulkanInterface created to check for VK support until a VK
  instance of RE is created.
- Tears down a partially initialized VulkanInterface if some required
  feature is unsupported.

Additionally, SkiaVkRenderEngine's destructor now tears down the static
VulkanInterfaces it uses, which necessitates:
- Caching whether VK is supported.
- Ensuring all Skia resources are destroyed *before* the VK resources
  managed by VulkanInterface that they rely on are torn down. This
  involves ensuring all textures are destroyed, and all Skia
  context-like objects are destroyed.

This latter change means that tests in librenderengine_test that are
parameterized by Skia backend must now recreate RE's VulkanInterfaces
twice for each test case (once for GaneshVk, and again for GraphiteVk),
which results in a minor regression in test duration. However, this is
necessary because holding on to a VulkanInterface while attempting to
set up a test for GaneshGL will cause contention over the real-time
GPU context priority, which can only be held exclusively by either a GL
context OR a VK context on some hardware.

Many thanks to joseph.cheng@imgtec.com for raising the issue of SF's
init of RE not tearing down the VulkanInterface used to check for
support, and for proposing an initial patch (b/333477752) which this
change builds upon. And thanks to scroggo@google.com for proposing the
reordering of SF's flag vs. VK support checks.

Bug: b/293371537
Bug: b/333477752
Test: librenderengine_test && manual boot validation across 3 backends
Flag: com.android.graphics.surfaceflinger.flags.graphite_renderengine-READ-ONLY
Change-Id: I289c3f7699d16707d1462179f4d5e8c54e4bb049

0 files changed, 0 insertions, 0 deletions