On 01/11/2016 09:06, Chris Wilson wrote:
On Tue, Nov 01, 2016 at 08:54:09AM +0000, Tvrtko Ursulin wrote:
On 01/11/2016 08:50, Chris Wilson wrote:
On Tue, Nov 01, 2016 at 08:41:01AM +0000, Tvrtko Ursulin wrote:
On 31/10/2016 10:26, Chris Wilson wrote:
With full-ppgtt one of the main bottlenecks is the lookup of the VMA
underneath the object. For execbuf there is merit in having a very fast
direct lookup of ctx:handle to the vma using a hashtree, but that still
leaves a large number of other lookups. One way to speed up the lookup
would be to use a rhashtable, but that requires extra allocations and
may exhibit poor worse case behaviour. An alternative is to use an
embedded rbtree, i.e. no extra allocations and deterministic behaviour,
but at the slight cost of O(lgN) lookups (instead of O(1) for
rhashtable). The major of such tree will be very shallow and so not much
slower, and still scales much, much better than the current unsorted
list.
References: https://bugs.freedesktop.org/show_bug.cgi?id=87726
Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
I suggest leaving this out of the mini-series which fixes the
recently introduced bugs.
Just review it now, it's a two year old bug that was impacting the test
cases I was running... :-p Then we won't have to review it next week ;)
I'll review it, just split it out please so the CI fire can be
extinguished first.
Sure, I'm pushing the fixes as soon as they've been baked. There's a
regression fix that builds upon this patch for multiple timelines (the
linear walk in reservation_object is particularly nasty for scaling).
Which one is that, the reservation_object_get_fences_rcu in
i915_gem_object_wait_reservation?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
