[Intel-gfx] [PATCH 00/66] [v1] Full PPGTT minus soft pin

Jesse Barnes jbarnes at virtuousgeek.org
Wed Oct 30 01:10:11 CET 2013


On Tue, 29 Oct 2013 16:08:24 -0700
Eric Anholt <eric at anholt.net> wrote:

> Daniel Vetter <daniel at ffwll.ch> writes:
> 
> > Hi Ben
> >
> > So first things first: I rather like what the code looks like overall at
> > the end. I've done a light read-through (by far not a full review) and
> > besides a few bikesheds (all mentioned by mail already) the big thing is
> > the 1:1 context:ppgtt address space relationship.
> >
> > We've discussed this at length in private irc and agreed that we need to
> > changes this two a n:1 relationship, so I'll just reiterate the reasons
> > for that on the list:
> >
> > - Current userspace expects that different contexts created on the same fd
> >   all use the same address space (since there's really only one). So if we
> >   want to no add a new ABI (and for testing I really think we want to
> >   enable ppgtt on current unchanged userspace) we must keep that promise.
> >   Hence we need to be able to point the different contexts created on an
> >   fd all at the same (per-fd) address space.
> 
> I'm not coming up with anything in userland requiring this.  Can you
> clarify?
> 
> For the GL context reset stuff, it is required that we have more than
> one address space per fd, because the fd is global to all contexts, not
> just a share group.

I think Daniel was just worried about the potential semantic change?
But if userspace doesn't rely on it, we can go the easier route of
simply creating one address space per context.

But overall, do we need to allow creating multiple contexts in the same
address space for GL share groups or any other feature?  If so, we'd
need to track contexts and address spaces separately and refcount them
like Ben has done with the per-fd work, though we could go back
to sharing a single fd and exposing the feature through the context
create ioctl instead, or possibly a new one if we need the notion of an
ASID as a separate entity.

-- 
Jesse Barnes, Intel Open Source Technology Center



More information about the Intel-gfx mailing list