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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
