Hi Monk,

because some parallel execution could load the GL2C.

See you need to insert cache invalidations before you start reading something 
which another engine has written.

And you need cache flushes to make sure that something your engine has written 
has reached memory before you signal finished execution.

That's perfectly normal cache handling what Marek is doing here.

Regards,
Christian.

Am 29.04.2020 13:24 schrieb "Liu, Monk" <monk....@amd.com>:

>> Well from my understanding I think that a G2LC invalidation is still 
>> necessary before an IB executes.

Agree, I think before an IB executes the only thing we need on GL2C is the 
invalidation, not the flush .

>> The problem is that the memory of the IB could also be cached because of 
>> some activity of the GFX or Compute rings.

If we always insert a GL2C invalidate at every EOP of every IB from every 
engine, why we need a GL2C invalidate before IB  execute ?

_____________________________________

Monk Liu|GPU Virtualization Team |AMD

[sig-cloud-gpu]



From: Koenig, Christian <christian.koe...@amd.com>
Sent: Wednesday, April 29, 2020 5:38 PM
To: Liu, Monk <monk....@amd.com>; Marek Olšák <mar...@gmail.com>; amd-gfx 
mailing list <amd-gfx@lists.freedesktop.org>
Subject: Re: drm/amdgpu: invalidate L2 before SDMA IBs (on gfx10)



Well from my understanding I think that a G2LC invalidation is still necessary 
before an IB executes.

The problem is that the memory of the IB could also be cached because of some 
activity of the GFX or Compute rings.

Regards,
Christian.

Am 29.04.20 um 11:35 schrieb Liu, Monk:

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

  1.  data is really flushed to system memory before CPU try to read it
  2.  all the G2LC is invalidated by “sync mem”, thus in the next round SDMA 
IB, it won’t get staled data from G2LC cache



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

[sig-cloud-gpu]



From: Liu, Monk
Sent: Wednesday, April 29, 2020 5:06 PM
To: 'Marek Olšák' <mar...@gmail.com><mailto:mar...@gmail.com>; amd-gfx mailing 
list <amd-gfx@lists.freedesktop.org><mailto:amd-gfx@lists.freedesktop.org>; 
Koenig, Christian <christian.koe...@amd.com><mailto:christian.koe...@amd.com>
Subject: RE: drm/amdgpu: invalidate L2 before SDMA IBs (on gfx10)



Hi @Koenig, Christian<mailto:christian.koe...@amd.com> & 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

[sig-cloud-gpu]



From: amd-gfx 
<amd-gfx-boun...@lists.freedesktop.org<mailto:amd-gfx-boun...@lists.freedesktop.org>>
 On Behalf Of Marek Ol?ák
Sent: Saturday, April 25, 2020 4:52 PM
To: amd-gfx mailing list 
<amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>>
Subject: drm/amdgpu: invalidate L2 before SDMA IBs (on gfx10)



This should fix SDMA hangs on gfx10.



Marek



_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Reply via email to