From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Subject: Re: [PATCH 2/2] drm/i915: allow sync points within batches Date: Wed, 3 Sep 2014 12:01:49 -0700 Message-ID: <20140903120149.799b03aa@jbarnes-desktop> References: <1409693561-1669-1-git-send-email-jbarnes@virtuousgeek.org> <1409693561-1669-3-git-send-email-jbarnes@virtuousgeek.org> <20140903070155.GJ25238@nuc-i3427.alporthouse.com> <20140903084106.685fb761@jbarnes-desktop> <20140903160853.GA3171@nuc-i3427.alporthouse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by gabe.freedesktop.org (Postfix) with ESMTP id C2A7F6E331 for ; Wed, 3 Sep 2014 12:01:48 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id p10so11754013pdj.32 for ; Wed, 03 Sep 2014 12:01:43 -0700 (PDT) In-Reply-To: <20140903160853.GA3171@nuc-i3427.alporthouse.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Chris Wilson Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Wed, 3 Sep 2014 17:08:53 +0100 Chris Wilson wrote: > On Wed, Sep 03, 2014 at 08:41:06AM -0700, Jesse Barnes wrote: > > On Wed, 3 Sep 2014 08:01:55 +0100 > > Chris Wilson wrote: > > > > > These commands are illegal/invalid inside the object, only valid inside > > > the ring. > > > > Hm, we ought to be able to write to no privileged space with > > STORE_DWORD, but that does mean moving to context specific pages in > > process space, or at least adding them to our existing scheme. > > The per-process context page also doesn't exist generically. I certainly > hope that userspace can't overwrite the hws! Imagine if we were using > that for interrupt status reads, or seqno tracking... Yeah I'm thinking of an additional hws that's per-context and userspace mappable. It could come in handy for userspace only sync stuff. > > > I haven't tried MI_USER_INTERRUPT from a batch, if we can't do it from > > a non-privileged batch that nixes one of the other neat features we > > could have (fine grained intra-batch userspace synchronization). > > I don't understand how writing the operation into the batch is > beneficial vs writing into the ring, unless you instended to use > something more fine grained than the batch seqno. You want to get > interrupts from inside batches? Rather than continue the existing scheme > of splitting up batches between fences? Yeah, the whole idea here was to avoid flushing batches in order to emit fences, both to avoid overhead and give userspace more rope. > > I definitely think we should think twice before allowing userspace to > arbitrarily generate interrupts. > > > > > + return 0; > > > > +} > > > > > > > > static int > > > > relocate_entry_cpu(struct drm_i915_gem_object *obj, > > > > @@ -349,7 +411,8 @@ relocate_entry_gtt(struct drm_i915_gem_object *obj, > > > > static int > > > > i915_gem_execbuffer_relocate_entry(struct drm_i915_gem_object *obj, > > > > struct eb_vmas *eb, > > > > - struct drm_i915_gem_relocation_entry *reloc) > > > > + struct drm_i915_gem_relocation_entry *reloc, > > > > + struct intel_context *ctx) > > > > > > Hmm. That's a nuisance. But no, you only use it to automatically create > > > a fence not to patch the batch, so you can just use an object-flag. > > > > > > This fits neatly into requests. > > > > Most definitely. What do you think of the potential upside in the DDX > > for this, assuming we get dword writes from batches working? > > Negative. You now have relocation overhead, you still need to split > batches to keep the gpu busy and do ring switches, and context switching > between clients, so I don't feel a need for fences from inside a batch. > > Getting seqno and a hws in the client would be nice, but if it continues > to require kernel polling, no thanks, I'll just still to approximately > tracking the active state of surfaces with the heavier accurate queries > sparingly. > > About the only thing I could see as being useful is that it would allow > you to reuse a batch buffer multiple times, rather than overallocate a > whole page and keep a pool of such pages. > > I am missing something? No I think that's about right. The need for reloc processing is a definite downside to this approach, but that could be solved with a new interface, or by just allowing userspace to map/manage a hws. The downside there is that the resulting fences wouldn't be shareable. But requiring a flush for that is probably fine. -- Jesse Barnes, Intel Open Source Technology Center