From: Daniel Vetter <daniel@ffwll.ch>
To: bradley.d.volkin@intel.com
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/2] tests/gem_exec_parse: fix batch_len setting for cmd-crossing-page
Date: Tue, 21 Oct 2014 17:26:05 +0200 [thread overview]
Message-ID: <20141021152605.GS26941@phenom.ffwll.local> (raw)
In-Reply-To: <1413409962-23097-1-git-send-email-bradley.d.volkin@intel.com>
On Wed, Oct 15, 2014 at 02:52:41PM -0700, bradley.d.volkin@intel.com wrote:
> From: Brad Volkin <bradley.d.volkin@intel.com>
>
> The size of the batch buffer passed to the kernel is significantly
> larger than the size of the batch buffer passed to the function. A
> proposed optimization as part of the batch copy kernel series is to
> use batch_len for the copy and parse operations, which leads to a
> false "batch without MI_BATCH_BUFFER_END" failure for this test.
>
> Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
> ---
> tests/gem_exec_parse.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
> index 05f271c..568bd4a 100644
> --- a/tests/gem_exec_parse.c
> +++ b/tests/gem_exec_parse.c
> @@ -144,9 +144,10 @@ static void exec_split_batch(int fd, uint32_t *cmds,
> struct drm_i915_gem_exec_object2 objs[1];
> uint32_t cmd_bo;
> uint32_t noop[1024] = { 0 };
> + const int alloc_size = 4096 * 2;
>
> // Allocate and fill a 2-page batch with noops
> - cmd_bo = gem_create(fd, 4096 * 2);
> + cmd_bo = gem_create(fd, alloc_size);
> gem_write(fd, cmd_bo, 0, noop, sizeof(noop));
> gem_write(fd, cmd_bo, 4096, noop, sizeof(noop));
>
> @@ -167,7 +168,7 @@ static void exec_split_batch(int fd, uint32_t *cmds,
> execbuf.buffers_ptr = (uintptr_t)objs;
> execbuf.buffer_count = 1;
> execbuf.batch_start_offset = 0;
Shouldn't we simply adjust batch_start_offset to be 4096-4, i.e. where
we've placed the batch? Would have the benifit of also testing offset
batches ;-)
-Daniel
> - execbuf.batch_len = size;
> + execbuf.batch_len = alloc_size;
> execbuf.cliprects_ptr = 0;
> execbuf.num_cliprects = 0;
> execbuf.DR1 = 0;
> --
> 1.9.1
>
> _______________________________________________
> 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
next prev parent reply other threads:[~2014-10-21 15:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-15 21:52 [PATCH 1/2] tests/gem_exec_parse: fix batch_len setting for cmd-crossing-page bradley.d.volkin
2014-10-15 21:52 ` [PATCH 2/2] tests/gem_exec_parse: test for chained batch buffers bradley.d.volkin
2014-10-21 15:26 ` Daniel Vetter [this message]
2014-10-22 15:29 ` [PATCH 1/2] tests/gem_exec_parse: fix batch_len setting for cmd-crossing-page Volkin, Bradley D
-- strict thread matches above, loose matches on Subject: below --
2014-11-03 19:18 bradley.d.volkin
2014-11-06 22:39 ` Volkin, Bradley D
2014-11-07 9:42 ` Daniel Vetter
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=20141021152605.GS26941@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=bradley.d.volkin@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