[Intel-gfx] [PATCH] igt/gem_exec_big: Increase stress

[Chris Wilson]

On Tue, Nov 18, 2014 at 11:33:23AM +0100, Daniel Vetter wrote:
> On Tue, Nov 18, 2014 at 09:50:23AM +0000, Chris Wilson wrote:
> > We should be able to execute batches up to the full GTT size (give or
> > take fragmentation), so let's try!
> > 
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > ---
> >  tests/gem_exec_big.c | 28 ++++++++++++++++++----------
> >  1 file changed, 18 insertions(+), 10 deletions(-)
> > 
> > diff --git a/tests/gem_exec_big.c b/tests/gem_exec_big.c
> > index b82774f..b5ec71c 100644
> > --- a/tests/gem_exec_big.c
> > +++ b/tests/gem_exec_big.c
> > @@ -46,10 +46,9 @@
> >  #include "drm.h"
> >  #include "ioctl_wrappers.h"
> >  #include "drmtest.h"
> > +#include "igt_aux.h"
> >  
> > -#define BATCH_SIZE		(1024*1024)
> > -
> > -static void exec(int fd, uint32_t handle, uint32_t reloc_ofs)
> > +static void exec(int fd, uint32_t handle, uint32_t reloc_ofs, unsigned flags)
> >  {
> >  	struct drm_i915_gem_execbuffer2 execbuf;
> >  	struct drm_i915_gem_exec_object2 gem_exec[1];
> > @@ -80,7 +79,7 @@ static void exec(int fd, uint32_t handle, uint32_t reloc_ofs)
> >  	execbuf.num_cliprects = 0;
> >  	execbuf.DR1 = 0;
> >  	execbuf.DR4 = 0;
> > -	execbuf.flags = 0;
> > +	execbuf.flags = flags;
> >  	i915_execbuffer2_set_context_id(execbuf, 0);
> >  	execbuf.rsvd2 = 0;
> >  
> > @@ -100,27 +99,36 @@ static void exec(int fd, uint32_t handle, uint32_t reloc_ofs)
> >  igt_simple_main
> >  {
> >  	uint32_t batch[2] = {MI_BATCH_BUFFER_END};
> > -	uint32_t handle;
> >  	int fd;
> >  	uint32_t reloc_ofs;
> >  	unsigned batch_size;
> > +	int max;
> >  
> >  	igt_skip_on_simulation();
> >  
> >  	fd = drm_open_any();
> > +	max = 3 * gem_aperture_size(fd) / 4;
> > +
> > +	igt_require(intel_check_memory(1, max, CHECK_RAM));
> 
> This might result in the testcase skipping and us loosing the coverage -
> our QA tends to have puny machines. Better to have two subtests?

What I wanted to do was do the check inside the loop, but that would
have resulted in premature eviction of the "leaked" objects that I was
using to make the kernel work harder.

I really wanted to be lazy and not have to convert this over to a bunch
of subtests ;-)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre