[igt-dev] [PATCH i-g-t v4 37/56] tests/gem_tiled_fence_blits: Adopt to use allocator

[Zbigniew Kempczyński]

On Fri, Aug 06, 2021 at 05:37:25PM -0700, Dixit, Ashutosh wrote:
> On Fri, 06 Aug 2021 06:41:26 -0700, Zbigniew Kempczyński wrote:
> >
> > For newer gens we're not able to rely on relocations. Adopt to use
> > offsets acquired from the allocator.
> 
> Reviewed-by: Ashutosh Dixit <ashutosh.dixit at intel.com>
> 
> Just a question below.
> 
> > @@ -198,7 +209,23 @@ static void run_test(int fd, int count)
> >			reloc[0].target_handle = obj[0].handle = bo[dst];
> >			reloc[1].target_handle = obj[1].handle = bo[src];
> >
> > +			if (ahnd) {
> > +				obj[0].offset = get_offset(ahnd, obj[0].handle,
> > +						sizeof(linear), 0);
> > +				obj[1].offset = get_offset(ahnd, obj[1].handle,
> > +						sizeof(linear), 0);
> > +				obj[2].offset = get_offset(ahnd, obj[2].handle,
> > +						4096, 0);
> > +				update_batch(fd, obj[2].handle, reloc,
> > +					     obj[0].offset, obj[1].offset);
> > +			}
> > +
> >			gem_execbuf(fd, &eb);
> > +			if (ahnd) {
> > +				gem_close(fd, obj[2].handle);
> > +				obj[2].handle = gem_create(fd, 4096);
> 
> Is it necessary to update these offsets above, rather than just fix the
> offsets at the beginning of the function? Also to recreate obj[2]? What we
> have above is fine but just wondering the reason for it. Thanks.

Original - reloc version uses single batch which is patched by kernel 
when it completes. i915 knows when it can be altered with new relocation
data then executed. For softpin we're not able to do so on same active bb.
We should wait until bb will be not busy and then we could patch it. 
Doing this in userspace can be done using out-fence, poll() then patch
bb and execbuf(). But this strategy is prone to stalls because time 
we spend in userspace is idle from gpu point of view. Another attitude
is to prepare more execbufs which enqueued on same context will be
executed sequentially but without gaps between. This is strategy
above. 

--
Zbigniew