Re: drm/amdgpu: invalidate L2 before SDMA IBs (on gfx10)

[Marek Olšák]

I'll answer two questions asked:

1) SDMA doesn't need GCR at the end of IBs. It's because SDMA writes bypass
GL2 and at the same time they invalidate all cache lines they touch.

2)
> 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 ?

I just sent you a counterexample on a private thread that proves that
invalidation in RELEASE_MEM doesn't accomplish anything. The invalidation
flag is there because:
1) it was inherited from gfx9, which was inherited from gfx8, which was
inherited from gfx7, which doesn't have the WB flag, so INV has to be used
instead.
2) to hide bugs

Marek

On Wed, Apr 29, 2020 at 7:24 AM Liu, Monk  wrote:

> >> 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
>
> [image: sig-cloud-gpu]
>
>
>
> *From:* Koenig, Christian 
> *Sent:* Wednesday, April 29, 2020 5:38 PM
> *To:* Liu, Monk ; Marek Olšák ;
> amd-gfx mailing list 
> *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
>
> [image: sig-cloud-gpu]
>
>
>
> *From:* Liu, Monk
> *Sent:* Wednesday, April 29, 2020 5:06 PM
> *To:* 'Marek Olšák'  ; amd-gfx
> mailing list 
> ; Koenig, Christian
>  
> *Subject:* RE: drm/amdgpu: invalidate L2 before SDMA IBs (on gfx10)
>
>
>
> 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
>
> [image: sig-cloud-gpu]
>
>
>
> *From:* amd-gfx  *On Behalf Of *Marek
> Ol?ák
> *Sent:* Saturday, April 25, 2020 4:52 PM
> *To:* amd-gfx mailing list 
> *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

RE: drm/amdgpu: invalidate L2 before SDMA IBs (on gfx10)

[Koenig, Christian]

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" :

>> 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 
Sent: Wednesday, April 29, 2020 5:38 PM
To: Liu, Monk ; Marek Olšák ; amd-gfx 
mailing list 
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' <mailto:mar...@gmail.com>; amd-gfx mailing 
list <mailto:amd-gfx@lists.freedesktop.org>; 
Koenig, Christian <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 
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 
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

RE: drm/amdgpu: invalidate L2 before SDMA IBs (on gfx10)

[Liu, Monk]

>> 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 
Sent: Wednesday, April 29, 2020 5:38 PM
To: Liu, Monk ; Marek Olšák ; amd-gfx 
mailing list 
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' <mailto:mar...@gmail.com>; amd-gfx mailing 
list <mailto:amd-gfx@lists.freedesktop.org>; 
Koenig, Christian <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 
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 
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

Re: drm/amdgpu: invalidate L2 before SDMA IBs (on gfx10)

[Christian König]

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' ; amd-gfx mailing list 
; Koenig, Christian 


*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 <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 <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

RE: drm/amdgpu: invalidate L2 before SDMA IBs (on gfx10)

[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' ; amd-gfx mailing list 
; Koenig, Christian 
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 
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 
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

RE: drm/amdgpu: invalidate L2 before SDMA IBs (on gfx10)

[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
[sig-cloud-gpu]

From: amd-gfx  On Behalf Of Marek Ol?ák
Sent: Saturday, April 25, 2020 4:52 PM
To: amd-gfx mailing list 
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

Re: drm/amdgpu: invalidate L2 before SDMA IBs (on gfx10)

[Marek Olšák]

I've already pushed the patch and marked it for stable.

I added a note into the commit message to discard the version bump for
stable.

The GCR packet is always supported in the ring regardless of firmware.

Marek

On Mon, Apr 27, 2020 at 9:01 AM Deucher, Alexander <
alexander.deuc...@amd.com> wrote:

> [AMD Official Use Only - Internal Distribution Only]
>
> Please split the patch into two, one to update the emit IB sequence, and
> one to bump the minor version.  That way we can make sure older kernels get
> the new sequence.  Also do we need an sdma fw version check for the new
> packet in the emi IB function?
>
> Alex
> --
> *From:* amd-gfx  on behalf of
> Christian König 
> *Sent:* Sunday, April 26, 2020 4:52 AM
> *To:* Marek Olšák 
> *Cc:* amd-gfx mailing list 
> *Subject:* Re: drm/amdgpu: invalidate L2 before SDMA IBs (on gfx10)
>
> Thought so, we should try to get this get it committed ASAP. And maybe add
> a CC: stable tag as well.
>
> Patch is Reviewed-by: Christian König 
> .
>
> Thanks,
> Christian.
>
> Am 26.04.20 um 02:28 schrieb Marek Olšák:
>
> Not without a mandatory firmware update. The gcr packet support for IBs
> was added into the sdma firmware just two weeks ago.
>
> Marek
>
> On Sat., Apr. 25, 2020, 11:04 Christian König, <
> ckoenig.leichtzumer...@gmail.com> wrote:
>
> Could we do this in userspace as well?
>
> Am 25.04.20 um 10:52 schrieb Marek Olšák:
>
> This should fix SDMA hangs on gfx10.
>
> Marek
>
> ___
> amd-gfx mailing 
> listamd-gfx@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/amd-gfx
>  
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx=02%7C01%7Calexander.deucher%40amd.com%7Cc88f73e068bb483bb21f08d7e9bf2cd4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637234879980330283=LZ2GMq0a0n6cm74ulhIkMq%2Fyj6XlG1lj9AH0InU1%2BdQ%3D=0>
>
>
>
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: drm/amdgpu: invalidate L2 before SDMA IBs (on gfx10)

[Deucher, Alexander]

[AMD Official Use Only - Internal Distribution Only]

Please split the patch into two, one to update the emit IB sequence, and one to 
bump the minor version.  That way we can make sure older kernels get the new 
sequence.  Also do we need an sdma fw version check for the new packet in the 
emi IB function?

Alex

From: amd-gfx  on behalf of Christian 
König 
Sent: Sunday, April 26, 2020 4:52 AM
To: Marek Olšák 
Cc: amd-gfx mailing list 
Subject: Re: drm/amdgpu: invalidate L2 before SDMA IBs (on gfx10)

Thought so, we should try to get this get it committed ASAP. And maybe add a 
CC: stable tag as well.

Patch is Reviewed-by: Christian König 
<mailto:christian.koe...@amd.com>.

Thanks,
Christian.

Am 26.04.20 um 02:28 schrieb Marek Olšák:
Not without a mandatory firmware update. The gcr packet support for IBs was 
added into the sdma firmware just two weeks ago.

Marek

On Sat., Apr. 25, 2020, 11:04 Christian König, 
mailto:ckoenig.leichtzumer...@gmail.com>> 
wrote:
Could we do this in userspace as well?

Am 25.04.20 um 10:52 schrieb Marek Olšák:
This should fix SDMA hangs on gfx10.

Marek



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/amd-gfx<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx=02%7C01%7Calexander.deucher%40amd.com%7Cc88f73e068bb483bb21f08d7e9bf2cd4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637234879980330283=LZ2GMq0a0n6cm74ulhIkMq%2Fyj6XlG1lj9AH0InU1%2BdQ%3D=0>



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

Re: drm/amdgpu: invalidate L2 before SDMA IBs (on gfx10)

[Christian König]

Thought so, we should try to get this get it committed ASAP. And maybe 
add a CC: stable tag as well.


Patch is Reviewed-by: Christian König .

Thanks,
Christian.

Am 26.04.20 um 02:28 schrieb Marek Olšák:
Not without a mandatory firmware update. The gcr packet support for 
IBs was added into the sdma firmware just two weeks ago.


Marek

On Sat., Apr. 25, 2020, 11:04 Christian König, 
> wrote:


Could we do this in userspace as well?

Am 25.04.20 um 10:52 schrieb Marek Olšák:

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  





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

Re: drm/amdgpu: invalidate L2 before SDMA IBs (on gfx10)

[Marek Olšák]

Not without a mandatory firmware update. The gcr packet support for IBs was
added into the sdma firmware just two weeks ago.

Marek

On Sat., Apr. 25, 2020, 11:04 Christian König, <
ckoenig.leichtzumer...@gmail.com> wrote:

> Could we do this in userspace as well?
>
> Am 25.04.20 um 10:52 schrieb Marek Olšák:
>
> This should fix SDMA hangs on gfx10.
>
> Marek
>
> ___
> amd-gfx mailing 
> listamd-gfx@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
>
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: drm/amdgpu: invalidate L2 before SDMA IBs (on gfx10)

[Pierre-Eric Pelloux-Prayer]

Hi Marek,

With this patch applied I could replay a trace (that usually caused a sdma
timeout on the first run) several times in a row without any issues.

So you can tag the commit as:
Tested-by: Pierre-Eric Pelloux-Prayer 

Thanks,
Pierre-Eric



On 25/04/2020 10:52, Marek Olšák wrote:
> 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
> 
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx