Am 14.12.2017 um 09:55 schrieb Thomas Hellstrom:
Hi, Christian,
On 12/14/2017 09:40 AM, Christian König wrote:
Hi Thomas,
sorry for that. Noted on the rest of that series as well that we need
to improve the commit messages. But this one somehow slipped through
because I discussed this change previously internally with Roger.
That made the change completely logical for me, but without this
context everybody else just thinks "Hui what?". Going to keep that in
mind the next time.
But back to topic: This series allows BOs which share the same
reservation object as the BO currently allocated/validated to be
evicted even when they are reserved.
This is useful because amdgpu wants to use a single reservation
object for almost all BOs of a process.
Yes, that indeed makes the whole thing more clear, and makes sense.
Out of interest, is the shared reservation object usage a speed
optimization (avoiding the ww_mutex_locks at reservation time?)
or something else?
Avoiding taking many ww_mutex_locks is one reason. The other major
reason comes with GPU-VM page tables.
Just the same as CPU page tables multi level GPU page tables are
allocated individually when needed. But during command submission we
must make sure that all GPU page tables are validated and fences added
to all of them.
Because of this we are using the reservation object of the root page
directory (because that one is always allocated) as reservation object
for all other page tables.
The effect is that you have to add the resulting fence of a command
submission to only one reservation object and not a couple of hundreds
or even thousands.
I guess that even if LRU lists might get crowded with unevictable BOs,
iterating through those lists isn't really part of the fast path.
Yes, exactly. When we start to massively evict things performance goes
down so much anyway that this extra cycling over the LRU doesn't hurt us
much.
Christian.
/Thomas
Regards,
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
