On Wed, Jul 15, 2026 at 5:00 AM Christian König
<[email protected]> wrote:
>
> On 7/14/26 17:19, Alex Deucher wrote:
> >> Why are we using the MES for per VMID invalidation?
> >
> > gfxoff. We can't access the registers directly unless we disallow gfxoff.
>
> Well there is a remark that VM_INVALIDATE_ENG*_ACK is always save to read,
> even when gfxoff is active.
>
> And we explicitly acquire the semaphore to avoid that GFXOFF kicks in.
I'm pretty sure the semaphore just keeps it active if it's already
active, but the registers are in the gfx tile so they are gfxoff
controlled. I think the semaphore is just meant to be used as a lock
to keep gfxoff from kicking in in the middle of an invalidation.
>
> I also don't see how we use the MES here?
>
> What we do is to use the KIQ on gfx9, but that is actually only as a
> workaround for some SRIOV problems.
>
We do it for everything gfx9 and newer. For example gmc_v11_0_flush_gpu_tlb():
/* This is necessary for SRIOV as well as for GFXOFF to
function
* properly under bare metal
*/
if ((adev->gfx.kiq[0].ring.sched.ready ||
adev->mes.ring[0].sched.ready) &&
(amdgpu_sriov_runtime(adev) || !amdgpu_sriov_vf(adev))) {
amdgpu_gmc_fw_reg_write_reg_wait(adev, req, ack, inv_req,
1 << vmid, GET_INST(GC, 0));
return;
}
The only time we use the MMIO path is if KIQ or MES is not ready yet.
The goal of this patch set was to switch to using SDMA rather than MES
and to clean up the gmc code since most of the logic is the same for
gfx9 and above.
Alex
> Christian.
>
> >
> > Alex
