[Mesa-dev] [PATCH 33/53] i965/drm: Drop code to search for an existing bufmgr.

[Chris Wilson]

On Tue, Apr 04, 2017 at 05:10:23PM -0700, Kenneth Graunke wrote:
> This functionality was added by libdrm commit
> 743af59669386cb6e063fa4bd85f0a0b2da86295 (intel: make bufmgr_gem
> shareable from different API) in an attempt to solve libva/mesa buffer
> sharing problems.  Specifically, this was working around an issue hit
> by Chromium, which used the same drm_fd for multiple APIs, and shared
> buffers between them.
> 
> This code attempted to work around that issue by using the same bufmgr
> for both libva and Mesa.  It worked because libdrm_intel was loaded by
> both libraries.  However, now that Mesa has forked, we don't have a
> common library, and this code cannot work.
> 
> The correct solution is to have each API open its own file descriptor
> (and get a corresponding buffer manager), and then use PRIME export
> and import to share BOs across those APIs.  Then the kernel can manage
> those shared resources.  According to Chris, the kernel will pass back
> the same handle for a prime FD if the lookup is from the same device FD.
> 
> We believe Chromium has since moved to this model.
> 
> In Mesa, there is already only one screen per FD, and so there will
> only be one bufmgr per FD.  We don't need any of this code.

Who controls the fd used by mesa? It used to be that mesa opened its
own, but now it is passed in? What happens if it is given to multiple
libraries?

I think it is worth carrying that caveat during bufmgr creation.

/* Handles to buffer objects belong to the device fd and are not
 * reference counted by the kernel. If the same fd is used by
 * multiple parties (threads sharing the same screen bufmgr, or
 * even worse the same device fd passed to multiple libraries)
 * ownership of those handles is shared by those independent parties.
 *
 * Don't do this! Ensure that each library/bufmgr has its own device
 * fd so that its namespace does not clash with another.
 */

Hmm, not great. The point about namespaces is ok, but the danger is the
blurb is more confusing than helpful.

Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre