[igt-dev] [i-g-t] lib/rendercopy: Specify the correct vertex buffer offset

[Chris Wilson]

Quoting Laxminarayan Bharadiya, Pankaj (2020-06-17 08:24:31)
> 
> 
> > -----Original Message-----
> > From: Chris Wilson <chris at chris-wilson.co.uk>
> > Sent: 15 June 2020 16:13
> > To: Laxminarayan Bharadiya, Pankaj
> > <pankaj.laxminarayan.bharadiya at intel.com>; igt-dev at lists.freedesktop.org;
> > Kempczynski, Zbigniew <zbigniew.kempczynski at intel.com>
> > Subject: Re: [igt-dev] [i-g-t] lib/rendercopy: Specify the correct vertex buffer
> > offset
> > 
> > Quoting Pankaj Bharadiya (2020-06-15 06:18:48)
> > > We must specify the correct vertex buffer offset as "End Offset
> > > Enable" bit is not enabled in 3DPRIMITIVE instruction.
> > >
> > > This fixes below fatal error:
> > >
> > >  [FATAL]:
> > >  ***** **** *** ** * FATAL * ** *** **** *****  StateArbiter>Surface
> > > State Pointers in the binding table must be 64 byte aligned.
> > >  Be sure that the binding table is set up correctly. Address found:
> > > 6b6b6b6b
> > >  ***** **** *** ** END FATAL ** *** **** *****
> > 
> > That is nothing to do with vertex offset. That says as it read the binding table, it
> > dereferenced the scratch page.
> 
> With this patch, the fatal error disappeared (for kms_big_fb, kms_cursor_crc tests)
> on the newer platform so I thought it could be a possible fix.
> 
> As I understood from the spec, we should provide the correct vertex buffer offset to 
> 3DPRIMITIVE instruction, but this affecting gem_render_linear_blits,
> gem_render_tiled_blits and  kms_frontbuffer_tracking tests.

We are passing the correct offset to 3DPRIM. It is nothing to do with
the binding table offset.

> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4674/index.html? 
> 
> Any suggestion on how to debug this issue further? I tried dumping content of
> batchbuffer but could not find the 6b6b6b6b address in dump.

> > That is nothing to do with vertex offset. That says as it read the binding table, it
> > dereferenced the scratch page.

As a rough guess our binding table was too close to the end of the page
and it traversed over the page boundary into scratch.
-Chris