public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Imre Deak <imre.deak@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH I-g-t V2 2/2] tests/gem_dummy_reloc_loop: Add one subtest based on multi drm_fd to test CPU<->GPU sync under multi BSD rings
Date: Tue, 22 Apr 2014 21:48:58 +0200	[thread overview]
Message-ID: <20140422194858.GG10722@phenom.ffwll.local> (raw)
In-Reply-To: <1398168303.21147.59.camel@intelbox>

On Tue, Apr 22, 2014 at 03:05:03PM +0300, Imre Deak wrote:
> On Tue, 2014-04-15 at 10:38 +0800, Zhao Yakui wrote:
> > The Broadwell GT3 machine has two independent BSD rings in kernel driver while
> > it is transparent to the user-space driver. In such case it needs to check
> > the CPU<->GPU sync for the second BSD ring.
> > 
> > V1->V2: Follow Daniel's comment to add one subtext instead of one individual
> > test case, which is used to test the CPU<->GPU sync under multi BSD rings
> > 
> > Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
> > ---
> >  tests/gem_dummy_reloc_loop.c |  102 +++++++++++++++++++++++++++++++++++++++++-
> >  1 file changed, 101 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tests/gem_dummy_reloc_loop.c b/tests/gem_dummy_reloc_loop.c
> > index a61b59b..660d8e1 100644
> > --- a/tests/gem_dummy_reloc_loop.c
> > +++ b/tests/gem_dummy_reloc_loop.c
> > @@ -48,6 +48,13 @@ static drm_intel_bufmgr *bufmgr;
> >  struct intel_batchbuffer *batch;
> >  static drm_intel_bo *target_buffer;
> >  
> > +#define NUM_FD	50
> > +
> > +static int mfd[NUM_FD];
> > +static drm_intel_bufmgr *mbufmgr[NUM_FD];
> > +static struct intel_batchbuffer *mbatch[NUM_FD];
> > +static drm_intel_bo *mbuffer[NUM_FD];
> > +
> >  /*
> >   * Testcase: Basic check of ring<->cpu sync using a dummy reloc
> >   *
> > @@ -124,6 +131,50 @@ dummy_reloc_loop_random_ring(int num_rings)
> >  	}
> >  }
> >  
> > +static void
> > +dummy_reloc_loop_random_ring_multi_fd(int num_rings)
> > +{
> > +	int i;
> > +	struct intel_batchbuffer *saved_batch;
> > +
> > +	saved_batch = batch;
> > +
> > +	srandom(0xdeadbeef);
> > +
> > +	for (i = 0; i < 0x100000; i++) {
> > +		int mindex;
> > +		int ring = random() % num_rings + 1;
> > +
> > +		mindex = random() % NUM_FD;
> > +		batch = mbatch[mindex];
> > +
> > +		if (ring == I915_EXEC_RENDER) {
> > +			BEGIN_BATCH(4);
> > +			OUT_BATCH(MI_COND_BATCH_BUFFER_END | MI_DO_COMPARE);
> > +			OUT_BATCH(0xffffffff); /* compare dword */
> > +			OUT_RELOC(mbuffer[mindex], I915_GEM_DOMAIN_RENDER,
> > +					I915_GEM_DOMAIN_RENDER, 0);
> > +			OUT_BATCH(MI_NOOP);
> > +			ADVANCE_BATCH();
> > +		} else {
> > +			BEGIN_BATCH(4);
> > +			OUT_BATCH(MI_FLUSH_DW | 1);
> > +			OUT_BATCH(0); /* reserved */
> > +			OUT_RELOC(mbuffer[mindex], I915_GEM_DOMAIN_RENDER,
> > +					I915_GEM_DOMAIN_RENDER, 0);
> > +			OUT_BATCH(MI_NOOP | (1<<22) | (0xf));
> > +			ADVANCE_BATCH();
> > +		}
> > +		intel_batchbuffer_flush_on_ring(batch, ring);
> > +
> > +		drm_intel_bo_map(target_buffer, 0);
> > +		// map to force waiting on rendering
> > +		drm_intel_bo_unmap(target_buffer);
> > +	}
> > +
> > +	batch = saved_batch;
> > +}
> > +
> >  int fd;
> >  int devid;
> >  int num_rings;
> > @@ -133,6 +184,7 @@ igt_main
> >  	igt_skip_on_simulation();
> >  
> >  	igt_fixture {
> > +		int i;
> >  		fd = drm_open_any();
> >  		devid = intel_get_drm_devid(fd);
> >  		num_rings = gem_get_num_rings(fd);
> > @@ -148,6 +200,35 @@ igt_main
> >  
> >  		target_buffer = drm_intel_bo_alloc(bufmgr, "target bo", 4096, 4096);
> >  		igt_assert(target_buffer);
> > +
> > +		/* Create multi drm_fd and map one gem object to multi gem_contexts */
> > +		{
> > +			unsigned int target_flink;
> > +			char buffer_name[32];
> > +			if (dri_bo_flink(target_buffer, &target_flink)) {
> > +				printf("fail to get flink for target buffer\n");
> > +				igt_assert(0);
> 
> For the future: could be just igt_assert_f().

Yeah I think for new testcases we should try to use the latest igt_*
macros and helpers as much as possible. Reducing control flow and
replacing it by the right igt_assert/require/... macro imo really helps
the readability of testcases.
-Daniel
> 
> > +			}
> > +			for (i = 0; i < NUM_FD; i++) {
> > +				mfd[i] = 0;
> > +				mbufmgr[i] = NULL;
> > +				mbuffer[i] = NULL;
> > +			}
> 
> Nitpick: the above are all statics, so no need to init them.
> 
> Other than the above this looks good:
> Reviewed-by: Imre Deak <imre.deak@intel.com>
> 
> > +			for (i = 0; i < NUM_FD; i++) {
> > +				sprintf(buffer_name, "Target buffer %d\n", i);
> > +				mfd[i] = drm_open_any();
> > +				mbufmgr[i] = drm_intel_bufmgr_gem_init(mfd[i], 4096);
> > +				igt_assert(mbufmgr[i]);
> > +				drm_intel_bufmgr_gem_enable_reuse(mbufmgr[i]);
> > +				mbatch[i] = intel_batchbuffer_alloc(mbufmgr[i], devid);
> > +				igt_assert(mbufmgr[i]);
> > +				mbuffer[i] = intel_bo_gem_create_from_name(
> > +								mbufmgr[i],
> > +								buffer_name,
> > +								target_flink);
> > +				igt_assert(mbuffer[i]);
> > +			}
> > +		}
> >  	}
> >  
> >  	igt_subtest("render") {
> > @@ -190,8 +271,27 @@ igt_main
> >  			printf("dummy loop run on random rings completed\n");
> >  		}
> >  	}
> > -
> > +	igt_subtest("mixed_multi_fd") {
> > +		if (num_rings > 1) {
> > +			sleep(2);
> > +			printf("running dummy loop on random rings based on "
> > +					"multi drm_fd\n");
> > +			dummy_reloc_loop_random_ring_multi_fd(num_rings);
> > +			printf("dummy loop run on random rings based on "
> > +					"multi drm_fd completed\n");
> > +		}
> > +	}
> >  	igt_fixture {
> > +		int i;
> > +		/* Free the buffer/batchbuffer/buffer mgr for multi-fd */
> > +		{
> > +			for (i = 0; i < NUM_FD; i++) {
> > +				dri_bo_unreference(mbuffer[i]);
> > +				intel_batchbuffer_free(mbatch[i]);
> > +				drm_intel_bufmgr_destroy(mbufmgr[i]);
> > +				close(mfd[i]);
> > +			}
> > +		}
> >  		drm_intel_bo_unreference(target_buffer);
> >  		intel_batchbuffer_free(batch);
> >  		drm_intel_bufmgr_destroy(bufmgr);
> 



> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx


-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

  reply	other threads:[~2014-04-22 19:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-15  2:38 [PATCH I-g-t V2 0/2] Tests: Add test cases based on multi drm_fd to test sync Zhao Yakui
2014-04-15  2:38 ` [PATCH I-g-t V2 1/2] tests: Add one ring sync case based on multi drm_fd to test ring semaphore sync under multi BSD rings Zhao Yakui
2014-04-22 11:52   ` Imre Deak
2014-04-22 19:44     ` Daniel Vetter
2014-04-23  1:13       ` Zhao Yakui
2014-04-23  9:17         ` Imre Deak
2014-04-15  2:38 ` [PATCH I-g-t V2 2/2] tests/gem_dummy_reloc_loop: Add one subtest based on multi drm_fd to test CPU<->GPU " Zhao Yakui
2014-04-22 12:05   ` Imre Deak
2014-04-22 19:48     ` Daniel Vetter [this message]
2014-04-23  0:26       ` Zhao Yakui

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140422194858.GG10722@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox