[Intel-gfx] [PATCH 075/190] drm/i915: Refactor activity tracking for requests

Chris Wilson chris at chris-wilson.co.uk
Thu Jan 28 03:46:39 PST 2016


On Thu, Jan 28, 2016 at 11:41:37AM +0000, Tvrtko Ursulin wrote:
> 
> Hi,
> 
> On 11/01/16 09:17, Chris Wilson wrote:
> >With the introduction of requests, we amplified the number of atomic
> >refcounted objects we use and update every execbuffer; from none to
> >several references, and a set of references that need to be changed. We
> >also introduced interesting side-effects in the order of retiring
> >requests and objects.
> >
> >Instead of independently tracking the last request for an object, track
> >the active objects for each request. The object will reside in the
> >buffer list of its most recent active request and so we reduce the kref
> >interchange to a list_move. Now retirements are entirely driven by the
> >request, dramatically simplifying activity tracking on the object
> >themselves, and removing the ambiguity between retiring objects and
> >retiring requests.
> >
> >All told, less code, simpler and faster, and more extensible.
> 
> I've looked in this in detail before holidays and unfortunately a
> lot if if evaporated from my head since. I remember I thought the
> idea was good and really simplifies things.
> 
> But it is also difficult to apply the subset of patches to look at
> the resulting code in more detail.
> 
> So would it be possible to extract and rebase relevant patches? I
> think that would be from 73 to 76. (Together with the renaming we
> agreed already. And those trivial renames of list/link already have
> r-b's.)

Actually no, if you read some of the earlier patches you will see the
required bug fixes.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list