Re: [PATCH i-g-t] lib/intel_compute: Wait for compute walker before returning to ring

[Matthew Brost <matthew.brost@intel.com>]

On Tue, Feb 03, 2026 at 08:57:56AM +0100, Zbigniew Kempczyński wrote:
> On Mon, Feb 02, 2026 at 03:15:58PM +0100, Francois Dugast wrote:
> > On Thu, Jan 22, 2026 at 11:45:29AM +0100, Zbigniew Kempczyński wrote:
> > > Most compute tests don't need to synchronize at the batch level as
> > > kmd executes pipe-control at some point. Last xe driver proposal (link
> > > below) causes turning off preemption before pipe-control preventing
> > > entering to SIP and finish the WMTP test properly.
> > > 
> > > Change adds pipe-control at batch level causing sync wait on
> > > compute-walker and preventing disabling the preemption prematurely.
> > 
> > This looks right and does solve the issue when applying the referenced KMD
> > change, so it would be necessary going forward.
> > 
> > For maintainability, can we please replace the 8 occurrences of 0x00100000
> > with a define, maybe in a preparation patch?
> 
> Maybe emit_pipe_control() function similar to xe_ring_ops.c  would be better?
> 

Yes, let's drop the hard coded numbers in this IGT but this can be done
in a follow up as this patch is no worse than the existing code. I also
just merged the KMD part which will break so CI so...

Reviewed-by: Matthew Brost <matthew.brost@intel.com>

> --
> Zbigniew
> 
> > 
> > Francois
> > 
> > > 
> > > Link: https://patchwork.freedesktop.org/series/160113/
> > > Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
> > > Cc: Matthew Brost <matthew.brost@intel.com>
> > > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> > > Cc: Francois Dugast <francois.dugast@intel.com>
> > > ---
> > >  lib/intel_compute.c | 14 ++++++++++++++
> > >  1 file changed, 14 insertions(+)
> > > 
> > > diff --git a/lib/intel_compute.c b/lib/intel_compute.c
> > > index 00ef280e8f..8578b6e402 100644
> > > --- a/lib/intel_compute.c
> > > +++ b/lib/intel_compute.c
> > > @@ -1694,6 +1694,13 @@ static void xe2lpg_compute_exec_compute(int fd,
> > >  	addr_bo_buffer_batch[b++] = 0x00000000;
> > >  	addr_bo_buffer_batch[b++] = 0x00000000;
> > >  
> > > +	addr_bo_buffer_batch[b++] = PIPE_CONTROL;
> > > +	addr_bo_buffer_batch[b++] = 0x00100000;
> > > +	addr_bo_buffer_batch[b++] = 0x00000000;
> > > +	addr_bo_buffer_batch[b++] = 0x00000000;
> > > +	addr_bo_buffer_batch[b++] = 0x00000000;
> > > +	addr_bo_buffer_batch[b++] = 0x00000000;
> > > +
> > >  	addr_bo_buffer_batch[b++] = MI_BATCH_BUFFER_END;
> > >  }
> > >  
> > > @@ -2032,6 +2039,13 @@ static void xe3p_compute_exec_compute(int fd,
> > >  	addr_bo_buffer_batch[b++] = 0x00000000; /* dw62 */
> > >  	addr_bo_buffer_batch[b++] = 0x00000000; /* dw63 */
> > >  
> > > +	addr_bo_buffer_batch[b++] = PIPE_CONTROL;
> > > +	addr_bo_buffer_batch[b++] = 0x00100000;
> > > +	addr_bo_buffer_batch[b++] = 0x00000000;
> > > +	addr_bo_buffer_batch[b++] = 0x00000000;
> > > +	addr_bo_buffer_batch[b++] = 0x00000000;
> > > +	addr_bo_buffer_batch[b++] = 0x00000000;
> > > +
> > >  	addr_bo_buffer_batch[b++] = MI_BATCH_BUFFER_END;
> > >  }
> > >  
> > > -- 
> > > 2.43.0
> > >