[Intel-gfx] [RFC i-g-t] tests/gem_exec_pad_to_size: Test object padding at execbuf
Tvrtko Ursulin
tvrtko.ursulin at linux.intel.com
Wed Mar 25 07:57:32 PDT 2015
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
More information about the Intel-gfx
mailing list