From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Subject: Re: [PATCH 00/66] [v1] Full PPGTT minus soft pin Date: Fri, 1 Nov 2013 10:20:59 -0700 Message-ID: <20131101102059.0d44c837@jbarnes-desktop> References: <1372375867-1003-1-git-send-email-ben@bwidawsk.net> <20130701213930.GF18285@phenom.ffwll.local> <87a9hrfzfb.fsf@eliezer.anholt.net> <20131029171011.155521c1@jbarnes-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from outbound-ss-2.hostmonster.com (outbound-ss-2.hostmonster.com [66.147.240.26]) by gabe.freedesktop.org (Postfix) with SMTP id 204C1F0701 for ; Fri, 1 Nov 2013 10:20:25 -0700 (PDT) In-Reply-To: <20131029171011.155521c1@jbarnes-desktop> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org To: Jesse Barnes Cc: Ben Widawsky , Intel GFX List-Id: intel-gfx@lists.freedesktop.org On Tue, 29 Oct 2013 17:10:11 -0700 Jesse Barnes wrote: > On Tue, 29 Oct 2013 16:08:24 -0700 > Eric Anholt wrote: > > > Daniel Vetter 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