On 28/01/16 11:46, Chris Wilson wrote:
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.
How many / which ones? Can you extract them into a smaller series
(rebased so it can be applied and tested) ending with 76?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
