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

[Tvrtko Ursulin]

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