public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Volkin, Bradley D" <bradley.d.volkin@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 1/2] tests/gem_exec_parse: fix batch_len setting for cmd-crossing-page
Date: Fri, 7 Nov 2014 10:42:06 +0100	[thread overview]
Message-ID: <20141107094206.GC6135@phenom.ffwll.local> (raw)
In-Reply-To: <20141106223953.GA13474@bdvolkin-ubuntu-desktop>

On Thu, Nov 06, 2014 at 02:39:53PM -0800, Volkin, Bradley D wrote:
> Ping on this series. They're related to the batch copy series, but
> the changes are valid and tests should still pass even without the
> kernel changes being merged.

Merged - I kinda forgotten that you don't have commit access.
> 
> On Mon, Nov 03, 2014 at 11:18:59AM -0800, Volkin, Bradley D 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.
> > 
> > To fix this, modify the test to set batch_start_offset and batch_len
> > such that they define the range of actual commands in the batch,
> > including a few of the surrounding nops for alignment purposes.
> > 
> > v2: update batch_start_offset as well
> > 
> > Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
> > ---
> >  tests/gem_exec_parse.c | 16 ++++++++++++----
> >  1 file changed, 12 insertions(+), 4 deletions(-)
> > 
> > diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
> > index 1dc9103..e48b83a 100644
> > --- a/tests/gem_exec_parse.c
> > +++ b/tests/gem_exec_parse.c
> > @@ -144,16 +144,18 @@ 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;
> > +	const int actual_start_offset = 4096-sizeof(uint32_t);
> >  
> >  	// 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));
> >  
> >  	// Write the provided commands such that the first dword
> >  	// of the command buffer is the last dword of the first
> >  	// page (i.e. the command is split across the two pages).
> > -	gem_write(fd, cmd_bo, 4096-sizeof(uint32_t), cmds, size);
> > +	gem_write(fd, cmd_bo, actual_start_offset, cmds, size);
> >  
> >  	objs[0].handle = cmd_bo;
> >  	objs[0].relocation_count = 0;
> > @@ -166,8 +168,14 @@ 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;
> > -	execbuf.batch_len = size;
> > +	// NB: We want batch_start_offset and batch_len to point to the block
> > +	// of the actual commands (i.e. at the last dword of the first page),
> > +	// but have to adjust both the start offset and length to meet the
> > +	// kernel driver's requirements on the alignment of those fields.

Also pushed a patch on top to change all the comments to C-style, just for
my OCD ;-)
-Daniel

> > +	execbuf.batch_start_offset = actual_start_offset & ~0x7;
> > +	execbuf.batch_len =
> > +		ALIGN(size + actual_start_offset - execbuf.batch_start_offset,
> > +		      0x8);
> >  	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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2014-11-07  9:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-03 19:18 [PATCH 1/2] tests/gem_exec_parse: fix batch_len setting for cmd-crossing-page bradley.d.volkin
2014-11-03 19:19 ` [PATCH 2/2] tests/gem_madvise: set execbuf.batch_len before doing an execbuf bradley.d.volkin
2014-11-06 22:39 ` [PATCH 1/2] tests/gem_exec_parse: fix batch_len setting for cmd-crossing-page Volkin, Bradley D
2014-11-07  9:42   ` Daniel Vetter [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-10-15 21:52 bradley.d.volkin
2014-10-21 15:26 ` Daniel Vetter
2014-10-22 15:29   ` Volkin, Bradley D

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=20141107094206.GC6135@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