gfxstream: Fix GEM object handling, precedence, and ownership for imported FDs in LinuxVirtGpuDevice
What does this MR do and why?
First commit changes the predence of the importFd; it should be first. It's entirely possible to have both exportDmabuf and importDmabuf be true. In this case, we import the FD, then we already have a VirtGpuResourcePtr. There's no need to go into the exportDmabuf block of creating a new underyling VirtGpu resource. This was crashing the guest compositor frequently.
Second change solves another long-time show-stopper issue of closing a GEM handle too early. As stated in the xf86drm.h DRM API header, it is up to the caller to to reference counting on GEM handles, by their handle value. drmPrimeFdToHandle will return the same GEM handle for an FD that points to the same underyling object. So, we basically have to override the generic shared_ptr destructor, and do our own reference counting for the underlying GEM handle, in order to track how many references we have on it.
This use-case comes up often with Weston -> Zink -> gfxstream-vulkan. You might export a dmabuf, import it in one Vulkan object, import in another Vulkan object, then close the original Vulkan object, all in the same process.
Testing: Compositor no longer crashes, no more warnings about reference an unopened GEM object.