On 03/25/2015 02:41 PM, Chris Wilson wrote:
On Wed, Mar 25, 2015 at 02:32:05PM +0000, Tvrtko Ursulin wrote:
On 03/25/2015 02:28 PM, Chris Wilson wrote:
What's important to make this trick work is to allocate new handles
every time. That way we fill up the GTT and thereby hope to skip over
the fragmented part.
It does do that!
I was just looking for some filler for the email!
Try Reviewed-by? :D
Only perhaps I need to make sure they are kept bound so maybe keep
them mapped or something while trying new ones?
What I was expecting to see were gem_create()s every loop. I only feel
confident in say that a pair of freshly allocated and bound objects are
likely to line up against each other (so long as space is not
fragmented).
I would allocate a new device fd for the test, leak the individual
handles on every try, then close the fd at the end of the test to avoid
having to track all the allocations. That's the pattern I was looking
for when I skimmed over your test.
Apart from reusing the fd, tracking the handles and allocating on all
loops but the first one when it re-uses the passed in ones, it is
exactly like that! :)
So far it always manages to get neighbouring BOs on my system on first
try. Which is probably not unexpected since is is PPGTT.
One thing I wasn't sure about is max_tries = 1024. That will be 8MB of
filling to avoid fragmentation. Will that be enough on GGTT systems?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
