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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx