All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Liu, Monk" <Monk.Liu@amd.com>
To: "Marek Olšák" <maraeo@gmail.com>,
	"amd-gfx mailing list" <amd-gfx@lists.freedesktop.org>,
	"Koenig, Christian" <Christian.Koenig@amd.com>
Subject: RE: drm/amdgpu: invalidate L2 before SDMA IBs (on gfx10)
Date: Wed, 29 Apr 2020 09:35:26 +0000	[thread overview]
Message-ID: <DM5PR12MB170863A130B7FFDBC2511CE584AD0@DM5PR12MB1708.namprd12.prod.outlook.com> (raw)
In-Reply-To: <DM5PR12MB170843C25AC1D5342A0726BF84AD0@DM5PR12MB1708.namprd12.prod.outlook.com>


[-- Attachment #1.1.1: Type: text/plain, Size: 2338 bytes --]

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' <maraeo@gmail.com>; amd-gfx mailing list <amd-gfx@lists.freedesktop.org>; Koenig, Christian <Christian.Koenig@amd.com>
Subject: RE: drm/amdgpu: invalidate L2 before SDMA IBs (on gfx10)

Hi @Koenig, Christian<mailto:Christian.Koenig@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-bounces@lists.freedesktop.org<mailto:amd-gfx-bounces@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

[-- Attachment #1.1.2: Type: text/html, Size: 9095 bytes --]

[-- Attachment #1.2: image001.png --]
[-- Type: image/png, Size: 12243 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

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

  reply	other threads:[~2020-04-29  9:35 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-25  8:52 drm/amdgpu: invalidate L2 before SDMA IBs (on gfx10) Marek Olšák
2020-04-25 15:04 ` Christian König
2020-04-26  0:28   ` Marek Olšák
2020-04-26  8:52     ` Christian König
2020-04-27 13:01       ` Deucher, Alexander
2020-04-27 13:53         ` Marek Olšák
2020-04-25 16:28 ` Pierre-Eric Pelloux-Prayer
2020-04-29  9:06 ` Liu, Monk
2020-04-29  9:35   ` Liu, Monk [this message]
2020-04-29  9:37     ` Christian König
2020-04-29 11:24       ` Liu, Monk
2020-05-01 16:02         ` Marek Olšák
2020-04-29 12:17 Koenig, Christian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DM5PR12MB170863A130B7FFDBC2511CE584AD0@DM5PR12MB1708.namprd12.prod.outlook.com \
    --to=monk.liu@amd.com \
    --cc=Christian.Koenig@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=maraeo@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.