Re: [PATCH 00/66] [v1] Full PPGTT minus soft pin

[Jesse Barnes <jbarnes@virtuousgeek.org>]

On Tue, 29 Oct 2013 17:10:11 -0700
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> On Tue, 29 Oct 2013 16:08:24 -0700
> Eric Anholt <eric@anholt.net> wrote:
> 
> > Daniel Vetter <daniel@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.

Ok so per discussion on IRC:
  - requiring multiple opens and fds is definitely not desired
  - multiple contexts sharing a single address space is not required

Thus simply creating a new ppgtt instance with every new context via
the context create ioctl ought to be sufficient.

Any objections?

-- 
Jesse Barnes, Intel Open Source Technology Center