Re: [RFC i-g-t] tests/gem_exec_pad_to_size: Test object padding at execbuf

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

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