[Intel-gfx] [PATCH 00/66] [v1] Full PPGTT minus soft pin
Jesse Barnes
jbarnes at virtuousgeek.org
Fri Nov 1 18:20:59 CET 2013
On Tue, 29 Oct 2013 17:10:11 -0700
Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> 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.
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
More information about the Intel-gfx
mailing list