Re: [PATCH v2 06/11] drm/i915/scheduler: Record all dependencies upon request construction

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

On 10/11/2016 10:55, Chris Wilson wrote:
> On Thu, Nov 10, 2016 at 10:44:44AM +0000, Tvrtko Ursulin wrote:
>>
>> On 08/11/2016 12:20, Chris Wilson wrote:
>>> On Mon, Nov 07, 2016 at 01:59:45PM +0000, Chris Wilson wrote:
>>>> The scheduler needs to know the dependencies of each request for the
>>>> lifetime of the request, as it may choose to reschedule the requests at
>>>> any time and must ensure the dependency tree is not broken. This is in
>>>> additional to using the fence to only allow execution after all
>>>> dependencies have been completed.
>>>>
>>>> One option was to extend the fence to support the bidirectional
>>>> dependency tracking required by the scheduler. However the mismatch in
>>>> lifetimes between the submit fence and the request essentially meant
>>>> that we had to build a completely separate struct (and we could not
>>>> simply reuse the existing waitqueue in the fence for one half of the
>>>> dependency tracking). The extra dependency tracking simply did not mesh
>>>> well with the fence, and keeping it separate both keeps the fence
>>>> implementation simpler and allows us to extend the dependency tracking
>>>> into a priority tree (whilst maintaining support for reordering the
>>>> tree).
>>>>
>>>> To avoid the additional allocations and list manipulations, the use of
>>>> the priotree is disabled when there are no schedulers to use it.
>>>>
>>>> v2: Create a dedicated slab for i915_dependency.
>>>>    Rename the lists.
>>>
>>> Sod. I've squashed the priority sort into this as a rebase calamity.
>>
>> Waiting for the other patches to get looked at before
>> untangle/respin or just forgot? :)
>
> Just imagine the split ;) Think of the intel_lrc.c as a separate patch.

It is a little bit more than that, but more importantly, is your plan 
now to just keep it squashed? I can pre-review it squashed, but I think 
it would be very desirable to eventually split it up again.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx