[Intel-gfx] [RFC 00/21] Replace seqno values with request structures
Chris Wilson
chris at chris-wilson.co.uk
Mon Oct 20 09:19:18 CEST 2014
On Sun, Oct 19, 2014 at 07:15:53PM +0200, Daniel Vetter wrote:
> On Mon, Oct 6, 2014 at 5:17 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > On Mon, Oct 06, 2014 at 03:15:04PM +0100, John.C.Harrison at Intel.com wrote:
> >> From: John Harrison <John.C.Harrison at Intel.com>
> >>
> >> Work in progress for replacing seqno usage with requst structures.
> >
> > You fail to end up with my earlier code. Nak.
>
> Well I've tried to split up your patch into small independent changes
> and failed at that. And given how many changes there are in there I
> simply can't merge your patch as-is. I know that it does seem to fix
> some random hangs, but with massive behaviour changes like the
> read-read stuff in there this could very well just be a random fluke.
Nope. Try reading it again. The most invasive change is defining the
order of engine/context/ppgtt/ring creation (and doing the setup/enable
split). Everything else is about making a request a transaction and
using that to fix bugs in our state tacking.
The fundamental change, that I am going to be a stickler for, is that the
request is the ring access. It defines the context, owner and interface
to both the ring and the engine/scheduler. In doing so it drops the
inconsistent and unmaintainable approach of introducing separate but almost
duplicate code paths inside the core of GEM.
> But if there's anything amiss in John's work for the plain
> s/seqno/request/ change, or anything else that we absolutely need to
> have then I very much want your opinion on this. But a flat outright
> nak without further content isn't useful to move forward.
It doesn't reduce the technical debt of execlists, which was the
motivation for the changes. It even brings a breath of sanity to
contexts and ppgtt as well, a massive boon.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list