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: Tue, 29 Oct 2013 17:10:11 -0700 Message-ID: <20131029171011.155521c1@jbarnes-desktop> References: <1372375867-1003-1-git-send-email-ben@bwidawsk.net> <20130701213930.GF18285@phenom.ffwll.local> <87a9hrfzfb.fsf@eliezer.anholt.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from oproxy12-pub.mail.unifiedlayer.com (oproxy12-pub.mail.unifiedlayer.com [50.87.16.10]) by gabe.freedesktop.org (Postfix) with SMTP id E2314EEC4C for ; Tue, 29 Oct 2013 17:13:33 -0700 (PDT) In-Reply-To: <87a9hrfzfb.fsf@eliezer.anholt.net> 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: Eric Anholt Cc: Ben Widawsky , Intel GFX List-Id: intel-gfx@lists.freedesktop.org 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. -- Jesse Barnes, Intel Open Source Technology Center