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:48:27 -0700 Message-ID: <20140903124827.2b92032b@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> <20140903120149.799b03aa@jbarnes-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by gabe.freedesktop.org (Postfix) with ESMTP id 827396E1C7 for ; Wed, 3 Sep 2014 12:48:21 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id ey11so18266255pad.21 for ; Wed, 03 Sep 2014 12:48:21 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter Cc: intel-gfx List-Id: intel-gfx@lists.freedesktop.org On Wed, 3 Sep 2014 21:41:02 +0200 Daniel Vetter wrote: > On Wed, Sep 3, 2014 at 9:01 PM, Jesse Barnes wrote: > > 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. > > Userspace can already do seqno writes with MI_FLUSH_DW or PIPE_CONTROL > - lots of igt tests actually do that for correctness checks. So the > only thing really is interrupts, and I think for that we really want > the full request tracking machinery in the kernel (otherwise I fear > we'll have even more fun with lost/spurious interrupts since the hw > guys just seem to not be able to get that right). Which means a full > batch split. > > I have no idea how that's supposed to work when userspace does direct > hardware submission. But that's kinda a good reason not to do that > anyway, and at least for now it looks like direct hw submission is for > opencl2 only with interop with other devices (where sync matters) not > a use-case. For interop with other processes the gpu can always do a > seqno write to some shared page. And busy-looping, but apparently > that's what people want for low-latency. Or at least what designers > seem to think people want ... Yeah I haven't thought how direct submission will work in terms of IPC. It may just have to be done in userland with a custom cooperative mechanism... -- Jesse Barnes, Intel Open Source Technology Center