Here is the reason we should always insert a “sync mem” packet at the FENCE place of SDMA, not before IB emit. By always inserting “sync mem” in the FENCE place we can make sure:1
by inserting “sync mem” in prior to IB could only achieve : Avoid get staled data in g2lc during IB execution
for GFX/COMPUTE ring since they have release_mem packet so it is inherently doing the G2LC flush and invalidate upon a fence signaled
_____________________________________ Monk Liu|GPU Virtualization Team |AMD From: Liu, Monk Hi
@Koenig, Christian & Marek I still have some concerns regarding Marek’s patch, correct me if I’m wrong See that Marek put a SDMA_OP_GCR_REQ before emitting IB, to make sure SDMA won’t get stale cache data during the IB execution. But that “SDMA_OP_GCR_REQ” only invalidate/flush the GFXHUB’s G2LC cache right ? what if the memory is changed by MM or CPU (out side of GFXHUB) ? Can this “ SDMA_OP_GCR_REQ” force MMHUB or even CPU to flush their operation result from their cache to memory ?? Besides, with my understanding the “EOP” of gfx ring is doing the thing of “invalidate/flush” L2 cache upon a fence signaled, so what we should do on SDMA5 is to insert this “SDMA_OP_GCR_REQ” Right before thee “emit_fence” of SDMA (this is what windows KMD do) thanks _____________________________________ Monk Liu|GPU Virtualization Team |AMD From: amd-gfx <amd-gfx-bounces@xxxxxxxxxxxxxxxxxxxxx>
On Behalf Of Marek Ol?ák This should fix SDMA hangs on gfx10. Marek |
_______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx