[PATCH 0/3] drm: Allow PRIME 'self-import' for all drivers

Zack Rusin zackr at vmware.com
Fri Jun 16 03:59:43 UTC 2023


On Thu, 2023-06-15 at 11:31 +0200, Thomas Zimmermann wrote:
> Set drm_gem_prime_handle_to_fd() and drm_gem_prime_fd_to_handle()
> for all DRM drivers. Even drivers that do not support PRIME import
> or export of dma-bufs can now import their own buffer objects. This
> is required by some userspace, such as wlroots-based compositors, to
> share buffers among processes.
> 
> The only driver that does not use the drm_gem_prime_*() helpers is
> vmwgfx. Once it has been converted, the callbacks in struct drm_driver
> can be removed.

Hmm, I'm not sure that's ever going to be possible on vmwgfx. Or at least not until
Xorg is used by anything. Some things in vmwgfx stack create "surfaces" which are
not GEM's (they can be backed by a GEM object, but don't have to) and the prime
implementation on vmwgfx has to be able to export and import those. 

In an ideal world I'd just delete the ioctl's that allow creating those "surfaces",
but of course that's a no-no, so possibility of introducing vmwgfx2 with a
saner/modern ioctl model has been floating around internally. Which at least would
open a path to removing vmwgfx at some point in the future, but there's not much
that can be done about vmwgfx having to be able to prime import/export GEM's and
wonky non-GEM objects.

z



More information about the dri-devel mailing list