[Mesa-dev] [PATCH 2/2] RFC i965: Share the GTT between non-robust contexts

[Chris Wilson]

Quoting Jason Ekstrand (2017-12-15 17:38:10)
> On Fri, Dec 15, 2017 at 8:27 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> 
>     Quoting Jason Ekstrand (2017-12-15 16:21:42)
>     > On Fri, Dec 15, 2017 at 5:42 AM, Chris Wilson <chris at chris-wilson.co.uk>
>     wrote:
>     >
>     >     Every client (everyone instance that opens /dev/dri/card0 or the
>     render
>     >     nodes), receives a unique per-process GTT (where supported by the
>     >     hardware, unfortunately that means only Broadwell and later). Every
>     >     context created by each client, in turns receives its own unique
>     ppGTT.
>     >     This is overkill in terms of allocations and tracking, both in the
>     >     kernel and in the hardware, as we could be sharing the per-client GTT
>     >     amongst all of its contexts. The downside is that context segregation
>     is
>     >     reduced, a stray write from one context may affect another, and so we
>     >     must honour any client requests that require robust segregation (e.g.
>     >     ARB_robustness).
>     >
>     >     Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
>     >     ---
>     >      src/mesa/drivers/dri/i965/brw_bufmgr.c  | 23 +++++++++++++++++------
>     >      src/mesa/drivers/dri/i965/brw_bufmgr.h  |  2 +-
>     >      src/mesa/drivers/dri/i965/brw_context.c |  2 +-
>     >      3 files changed, 19 insertions(+), 8 deletions(-)
>     >
>     >     diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c b/src/mesa/
>     drivers/dri/
>     >     i965/brw_bufmgr.c
>     >     index 52b5bf97a1..d8a9635f5d 100644
>     >     --- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
>     >     +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
>     >     @@ -1297,13 +1297,24 @@ init_cache_buckets(struct brw_bufmgr *bufmgr)
>     >      }
>     >
>     >      uint32_t
>     >     -brw_create_hw_context(struct brw_bufmgr *bufmgr)
>     >     +brw_create_hw_context(struct brw_bufmgr *bufmgr, unsigned int flags)
>     >      {
>     >     -   struct drm_i915_gem_context_create create = { };
>     >     -   int ret = drmIoctl(bufmgr->fd, DRM_IOCTL_I915_GEM_CONTEXT_CREATE,
>     &
>     >     create);
>     >     -   if (ret != 0) {
>     >     -      DBG("DRM_IOCTL_I915_GEM_CONTEXT_CREATE failed: %s\n", strerror
>     >     (errno));
>     >     -      return 0;
>     >     +   struct local_i915_gem_context_create_v2 {
>     >     +      uint32_t ctx_id; /* out */
>     >     +      uint32_t flags;
>     >     +#define I915_GEM_CONTEXT_SHARE_GTT 0x1
>     >     +      uint32_t share_ctx;
>     >
>     >
>     > So, we've left share_ctx as 0.  What does that mean?  Does that mean that
>     we
>     > share with some context that was implicitly created by opening /dev/dri/
>     card0? 
>     > Does it mean we share with the default context and therefore other
>     processes? 
> 
>     The default context, 0, is per fd.
> 
> So a second open() of /dev/dri/card0 will get a different default context?

Yes. But dup() retains the same, as does passing the fd over a unix
socket. At least, you have to actively circumvent the segregation.
-Chris