From: Zhao Yakui <yakui.zhao@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: "intel-gfx@lists.freedesktop.org" <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: Wed, 23 Apr 2014 08:26:40 +0800 [thread overview]
Message-ID: <1398212800.2045.164.camel@genxdev-ykzhao.sh.intel.com> (raw)
In-Reply-To: <20140422194858.GG10722@phenom.ffwll.local>
On Tue, 2014-04-22 at 13:48 -0600, Daniel Vetter wrote:
> 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.
Hi, Daniel/Imre
Thanks for your comments and advice.
I will update it.
Thanks.
Yakui
> -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
>
>
prev parent reply other threads:[~2014-04-23 0:27 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
2014-04-23 0:26 ` Zhao Yakui [this message]
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=1398212800.2045.164.camel@genxdev-ykzhao.sh.intel.com \
--to=yakui.zhao@intel.com \
--cc=daniel@ffwll.ch \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.