All of lore.kernel.org
 help / color / mirror / Atom feed
* drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to compute IBs too
@ 2020-04-25  8:52 Marek Olšák
  2020-04-25 15:03 ` Christian König
  2020-04-28  9:50 ` Liu, Monk
  0 siblings, 2 replies; 11+ messages in thread
From: Marek Olšák @ 2020-04-25  8:52 UTC (permalink / raw)
  To: amd-gfx mailing list


[-- Attachment #1.1: Type: text/plain, Size: 24 bytes --]

This was missed.

Marek

[-- Attachment #1.2: Type: text/html, Size: 84 bytes --]

[-- Attachment #2: 0001-drm-amdgpu-apply-AMDGPU_IB_FLAG_EMIT_MEM_SYNC-to-com.patch --]
[-- Type: text/x-patch, Size: 7295 bytes --]

From 6d5b59a4200627b6edafcb2d69635d4d9a4b4a45 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Ol=C5=A1=C3=A1k?= <marek.olsak@amd.com>
Date: Wed, 22 Apr 2020 04:11:00 -0400
Subject: [PATCH] drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to compute IBs
 too
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Marek Olšák <marek.olsak@amd.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  3 ++-
 drivers/gpu/drm/amd/amdgpu/cikd.h       |  2 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c  |  1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c   |  1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c   | 15 +++++++++++++++
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c   | 16 ++++++++++++++++
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c   |  1 +
 drivers/gpu/drm/amd/amdgpu/vid.h        |  2 +-
 8 files changed, 38 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 0177892e609a..76a6198f5b6e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -87,9 +87,10 @@
  * - 3.36.0 - Allow reading more status registers on si/cik
  * - 3.37.0 - Add AMDGPU_IB_FLAG_EMIT_MEM_SYNC
  * - 3.38.0 - L2 is invalidated before SDMA IBs, needed for correctness
+ * - 3.39.0 - AMDGPU_IB_FLAG_EMIT_MEM_SYNC also affects compute IBs
  */
 #define KMS_DRIVER_MAJOR	3
-#define KMS_DRIVER_MINOR	38
+#define KMS_DRIVER_MINOR	39
 #define KMS_DRIVER_PATCHLEVEL	0
 
 int amdgpu_vram_limit = 0;
diff --git a/drivers/gpu/drm/amd/amdgpu/cikd.h b/drivers/gpu/drm/amd/amdgpu/cikd.h
index cee6e8a3ad9c..5f3f6ebfb387 100644
--- a/drivers/gpu/drm/amd/amdgpu/cikd.h
+++ b/drivers/gpu/drm/amd/amdgpu/cikd.h
@@ -450,7 +450,7 @@
 #              define PACKET3_DMA_DATA_CMD_SAIC    (1 << 28)
 #              define PACKET3_DMA_DATA_CMD_DAIC    (1 << 29)
 #              define PACKET3_DMA_DATA_CMD_RAW_WAIT  (1 << 30)
-#define	PACKET3_AQUIRE_MEM				0x58
+#define	PACKET3_ACQUIRE_MEM				0x58
 #define	PACKET3_REWIND					0x59
 #define	PACKET3_LOAD_UCONFIG_REG			0x5E
 #define	PACKET3_LOAD_SH_REG				0x5F
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 0a03e2ad5d95..34791c089f81 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -8108,6 +8108,7 @@ static const struct amdgpu_ring_funcs gfx_v10_0_ring_funcs_compute = {
 	.emit_wreg = gfx_v10_0_ring_emit_wreg,
 	.emit_reg_wait = gfx_v10_0_ring_emit_reg_wait,
 	.emit_reg_write_reg_wait = gfx_v10_0_ring_emit_reg_write_reg_wait,
+	.emit_mem_sync = gfx_v10_0_emit_mem_sync,
 };
 
 static const struct amdgpu_ring_funcs gfx_v10_0_ring_funcs_kiq = {
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
index 96112fb9273b..05e94379c7b3 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
@@ -3543,6 +3543,7 @@ static const struct amdgpu_ring_funcs gfx_v6_0_ring_funcs_compute = {
 	.test_ib = gfx_v6_0_ring_test_ib,
 	.insert_nop = amdgpu_ring_insert_nop,
 	.emit_wreg = gfx_v6_0_ring_emit_wreg,
+	.emit_mem_sync = gfx_v6_0_emit_mem_sync,
 };
 
 static void gfx_v6_0_set_ring_funcs(struct amdgpu_device *adev)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
index b2f10e39eff1..5d9226b871fa 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
@@ -5010,6 +5010,20 @@ static void gfx_v7_0_emit_mem_sync(struct amdgpu_ring *ring)
 	amdgpu_ring_write(ring, 0x0000000A); /* poll interval */
 }
 
+static void gfx_v7_0_emit_mem_sync_compute(struct amdgpu_ring *ring)
+{
+	amdgpu_ring_write(ring, PACKET3(PACKET3_ACQUIRE_MEM, 5));
+	amdgpu_ring_write(ring, PACKET3_TCL1_ACTION_ENA |
+			  PACKET3_TC_ACTION_ENA |
+			  PACKET3_SH_KCACHE_ACTION_ENA |
+			  PACKET3_SH_ICACHE_ACTION_ENA);  /* CP_COHER_CNTL */
+	amdgpu_ring_write(ring, 0xffffffff);	/* CP_COHER_SIZE */
+	amdgpu_ring_write(ring, 0xff);		/* CP_COHER_SIZE_HI */
+	amdgpu_ring_write(ring, 0);		/* CP_COHER_BASE */
+	amdgpu_ring_write(ring, 0);		/* CP_COHER_BASE_HI */
+	amdgpu_ring_write(ring, 0x0000000A);	/* poll interval */
+}
+
 static const struct amd_ip_funcs gfx_v7_0_ip_funcs = {
 	.name = "gfx_v7_0",
 	.early_init = gfx_v7_0_early_init,
@@ -5088,6 +5102,7 @@ static const struct amdgpu_ring_funcs gfx_v7_0_ring_funcs_compute = {
 	.insert_nop = amdgpu_ring_insert_nop,
 	.pad_ib = amdgpu_ring_generic_pad_ib,
 	.emit_wreg = gfx_v7_0_ring_emit_wreg,
+	.emit_mem_sync = gfx_v7_0_emit_mem_sync_compute,
 };
 
 static void gfx_v7_0_set_ring_funcs(struct amdgpu_device *adev)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index fc6c2f2bc76c..02db42c7cd9f 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -6824,6 +6824,21 @@ static void gfx_v8_0_emit_mem_sync(struct amdgpu_ring *ring)
 	amdgpu_ring_write(ring, 0x0000000A); /* poll interval */
 }
 
+static void gfx_v8_0_emit_mem_sync_compute(struct amdgpu_ring *ring)
+{
+	amdgpu_ring_write(ring, PACKET3(PACKET3_ACQUIRE_MEM, 5));
+	amdgpu_ring_write(ring, PACKET3_TCL1_ACTION_ENA |
+			  PACKET3_TC_ACTION_ENA |
+			  PACKET3_SH_KCACHE_ACTION_ENA |
+			  PACKET3_SH_ICACHE_ACTION_ENA |
+			  PACKET3_TC_WB_ACTION_ENA);  /* CP_COHER_CNTL */
+	amdgpu_ring_write(ring, 0xffffffff);	/* CP_COHER_SIZE */
+	amdgpu_ring_write(ring, 0xff);		/* CP_COHER_SIZE_HI */
+	amdgpu_ring_write(ring, 0);		/* CP_COHER_BASE */
+	amdgpu_ring_write(ring, 0);		/* CP_COHER_BASE_HI */
+	amdgpu_ring_write(ring, 0x0000000A);	/* poll interval */
+}
+
 static const struct amd_ip_funcs gfx_v8_0_ip_funcs = {
 	.name = "gfx_v8_0",
 	.early_init = gfx_v8_0_early_init,
@@ -6919,6 +6934,7 @@ static const struct amdgpu_ring_funcs gfx_v8_0_ring_funcs_compute = {
 	.insert_nop = amdgpu_ring_insert_nop,
 	.pad_ib = amdgpu_ring_generic_pad_ib,
 	.emit_wreg = gfx_v8_0_ring_emit_wreg,
+	.emit_mem_sync = gfx_v8_0_emit_mem_sync_compute,
 };
 
 static const struct amdgpu_ring_funcs gfx_v8_0_ring_funcs_kiq = {
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 54eded9a6ac5..f38f01677b59 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -6736,6 +6736,7 @@ static const struct amdgpu_ring_funcs gfx_v9_0_ring_funcs_compute = {
 	.emit_wreg = gfx_v9_0_ring_emit_wreg,
 	.emit_reg_wait = gfx_v9_0_ring_emit_reg_wait,
 	.emit_reg_write_reg_wait = gfx_v9_0_ring_emit_reg_write_reg_wait,
+	.emit_mem_sync = gfx_v9_0_emit_mem_sync,
 };
 
 static const struct amdgpu_ring_funcs gfx_v9_0_ring_funcs_kiq = {
diff --git a/drivers/gpu/drm/amd/amdgpu/vid.h b/drivers/gpu/drm/amd/amdgpu/vid.h
index 19ddd2312e00..7a01e6133798 100644
--- a/drivers/gpu/drm/amd/amdgpu/vid.h
+++ b/drivers/gpu/drm/amd/amdgpu/vid.h
@@ -332,7 +332,7 @@
 #              define PACKET3_DMA_DATA_CMD_SAIC    (1 << 28)
 #              define PACKET3_DMA_DATA_CMD_DAIC    (1 << 29)
 #              define PACKET3_DMA_DATA_CMD_RAW_WAIT  (1 << 30)
-#define	PACKET3_AQUIRE_MEM				0x58
+#define	PACKET3_ACQUIRE_MEM				0x58
 #define	PACKET3_REWIND					0x59
 #define	PACKET3_LOAD_UCONFIG_REG			0x5E
 #define	PACKET3_LOAD_SH_REG				0x5F
-- 
2.17.1


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

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

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to compute IBs too
  2020-04-25  8:52 drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to compute IBs too Marek Olšák
@ 2020-04-25 15:03 ` Christian König
  2020-04-26  0:43   ` Marek Olšák
  2020-04-28  9:50 ` Liu, Monk
  1 sibling, 1 reply; 11+ messages in thread
From: Christian König @ 2020-04-25 15:03 UTC (permalink / raw)
  To: Marek Olšák, amd-gfx mailing list, Alex Deucher


[-- Attachment #1.1: Type: text/plain, Size: 384 bytes --]

Was that patch set actually merged upstream? My last status is that we 
couldn't find a reason why we need to do this in the kernel.

Christian.

Am 25.04.20 um 10:52 schrieb Marek Olšák:
> This was missed.
>
> Marek
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[-- Attachment #1.2: Type: text/html, Size: 1250 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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to compute IBs too
  2020-04-25 15:03 ` Christian König
@ 2020-04-26  0:43   ` Marek Olšák
  2020-04-26  8:55     ` Christian König
  0 siblings, 1 reply; 11+ messages in thread
From: Marek Olšák @ 2020-04-26  0:43 UTC (permalink / raw)
  To: Christian König; +Cc: Alex Deucher, amd-gfx mailing list


[-- Attachment #1.1: Type: text/plain, Size: 1053 bytes --]

It was merged into amd-staging-drm-next.

I'm not absolutely sure, but I think we need to invalidate before IBs if an
IB is cached in L2 and the CPU has updated it. It can only be cached in L2
if something other than CP has read it or written to it without
invalidation. CP reads don't cache it but they can hit the cache if it's
already cached.

For CE, we need to invalidate before the IB in the kernel, because CE IBs
can't do cache invalidations IIRC. This is the number one reason for
merging the already pushed commits.

Marek

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

> Was that patch set actually merged upstream? My last status is that we
> couldn't find a reason why we need to do this in the kernel.
>
> Christian.
>
> Am 25.04.20 um 10:52 schrieb Marek Olšák:
>
> This was missed.
>
> Marek
>
> _______________________________________________
> amd-gfx mailing listamd-gfx@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 2020 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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to compute IBs too
  2020-04-26  0:43   ` Marek Olšák
@ 2020-04-26  8:55     ` Christian König
  2020-04-27 13:02       ` Deucher, Alexander
  0 siblings, 1 reply; 11+ messages in thread
From: Christian König @ 2020-04-26  8:55 UTC (permalink / raw)
  To: Marek Olšák, Christian König
  Cc: Alex Deucher, amd-gfx mailing list


[-- Attachment #1.1: Type: text/plain, Size: 1698 bytes --]

Thanks for that explanation. I suspected that there was a good reason to 
have that in the kernel, but couldn't find one.

In this case the patch is Reviewed-by: Christian König 
<christian.koenig@amd.com>

We should probably add this explanation as comment to the flag as well.

Thanks,
Christian.

Am 26.04.20 um 02:43 schrieb Marek Olšák:
> It was merged into amd-staging-drm-next.
>
> I'm not absolutely sure, but I think we need to invalidate before IBs 
> if an IB is cached in L2 and the CPU has updated it. It can only be 
> cached in L2 if something other than CP has read it or written to it 
> without invalidation. CP reads don't cache it but they can hit the 
> cache if it's already cached.
>
> For CE, we need to invalidate before the IB in the kernel, because CE 
> IBs can't do cache invalidations IIRC. This is the number one reason 
> for merging the already pushed commits.
>
> Marek
>
> On Sat., Apr. 25, 2020, 11:03 Christian König, 
> <ckoenig.leichtzumerken@gmail.com 
> <mailto:ckoenig.leichtzumerken@gmail.com>> wrote:
>
>     Was that patch set actually merged upstream? My last status is
>     that we couldn't find a reason why we need to do this in the kernel.
>
>     Christian.
>
>     Am 25.04.20 um 10:52 schrieb Marek Olšák:
>>     This was missed.
>>
>>     Marek
>>
>>     _______________________________________________
>>     amd-gfx mailing list
>>     amd-gfx@lists.freedesktop.org  <mailto: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


[-- Attachment #1.2: Type: text/html, Size: 3890 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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to compute IBs too
  2020-04-26  8:55     ` Christian König
@ 2020-04-27 13:02       ` Deucher, Alexander
  2020-04-27 13:54         ` Marek Olšák
  0 siblings, 1 reply; 11+ messages in thread
From: Deucher, Alexander @ 2020-04-27 13:02 UTC (permalink / raw)
  To: Marek Olšák, Koenig, Christian; +Cc: amd-gfx mailing list


[-- Attachment #1.1: Type: text/plain, Size: 2862 bytes --]

[AMD Official Use Only - Internal Distribution Only]

Do we have open source code UMD code which uses this?

Alex
________________________________
From: Christian König <ckoenig.leichtzumerken@gmail.com>
Sent: Sunday, April 26, 2020 4:55 AM
To: Marek Olšák <maraeo@gmail.com>; Koenig, Christian <Christian.Koenig@amd.com>
Cc: Deucher, Alexander <Alexander.Deucher@amd.com>; amd-gfx mailing list <amd-gfx@lists.freedesktop.org>
Subject: Re: drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to compute IBs too

Thanks for that explanation. I suspected that there was a good reason to have that in the kernel, but couldn't find one.

In this case the patch is Reviewed-by: Christian König <christian.koenig@amd.com><mailto:christian.koenig@amd.com>

We should probably add this explanation as comment to the flag as well.

Thanks,
Christian.

Am 26.04.20 um 02:43 schrieb Marek Olšák:
It was merged into amd-staging-drm-next.

I'm not absolutely sure, but I think we need to invalidate before IBs if an IB is cached in L2 and the CPU has updated it. It can only be cached in L2 if something other than CP has read it or written to it without invalidation. CP reads don't cache it but they can hit the cache if it's already cached.

For CE, we need to invalidate before the IB in the kernel, because CE IBs can't do cache invalidations IIRC. This is the number one reason for merging the already pushed commits.

Marek

On Sat., Apr. 25, 2020, 11:03 Christian König, <ckoenig.leichtzumerken@gmail.com<mailto:ckoenig.leichtzumerken@gmail.com>> wrote:
Was that patch set actually merged upstream? My last status is that we couldn't find a reason why we need to do this in the kernel.

Christian.

Am 25.04.20 um 10:52 schrieb Marek Olšák:
This was missed.

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&data=02%7C01%7CAlexander.Deucher%40amd.com%7C6b35f61512d34bf2dc8b08d7e9bfa1a6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637234881577782939&sdata=%2B95wpbjY3Q675FaX9iH1BNIFyEz5jpN4PzjEOOpIu9Q%3D&reserved=0>





_______________________________________________
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&data=02%7C01%7CAlexander.Deucher%40amd.com%7C6b35f61512d34bf2dc8b08d7e9bfa1a6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637234881577782939&sdata=%2B95wpbjY3Q675FaX9iH1BNIFyEz5jpN4PzjEOOpIu9Q%3D&reserved=0>



[-- Attachment #1.2: Type: text/html, Size: 5520 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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to compute IBs too
  2020-04-27 13:02       ` Deucher, Alexander
@ 2020-04-27 13:54         ` Marek Olšák
  2020-04-27 14:53           ` Christian König
  0 siblings, 1 reply; 11+ messages in thread
From: Marek Olšák @ 2020-04-27 13:54 UTC (permalink / raw)
  To: Deucher, Alexander; +Cc: Koenig, Christian, amd-gfx mailing list


[-- Attachment #1.1: Type: text/plain, Size: 3076 bytes --]

PAL requested it and they are going to use it. (it looks like they have to
use it for correctness)

Marek

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

> [AMD Official Use Only - Internal Distribution Only]
>
> Do we have open source code UMD code which uses this?
>
> Alex
> ------------------------------
> *From:* Christian König <ckoenig.leichtzumerken@gmail.com>
> *Sent:* Sunday, April 26, 2020 4:55 AM
> *To:* Marek Olšák <maraeo@gmail.com>; Koenig, Christian <
> Christian.Koenig@amd.com>
> *Cc:* Deucher, Alexander <Alexander.Deucher@amd.com>; amd-gfx mailing
> list <amd-gfx@lists.freedesktop.org>
> *Subject:* Re: drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to compute
> IBs too
>
> Thanks for that explanation. I suspected that there was a good reason to
> have that in the kernel, but couldn't find one.
>
> In this case the patch is Reviewed-by: Christian König
> <christian.koenig@amd.com> <christian.koenig@amd.com>
>
> We should probably add this explanation as comment to the flag as well.
>
> Thanks,
> Christian.
>
> Am 26.04.20 um 02:43 schrieb Marek Olšák:
>
> It was merged into amd-staging-drm-next.
>
> I'm not absolutely sure, but I think we need to invalidate before IBs if
> an IB is cached in L2 and the CPU has updated it. It can only be cached in
> L2 if something other than CP has read it or written to it without
> invalidation. CP reads don't cache it but they can hit the cache if it's
> already cached.
>
> For CE, we need to invalidate before the IB in the kernel, because CE IBs
> can't do cache invalidations IIRC. This is the number one reason for
> merging the already pushed commits.
>
> Marek
>
> On Sat., Apr. 25, 2020, 11:03 Christian König, <
> ckoenig.leichtzumerken@gmail.com> wrote:
>
> Was that patch set actually merged upstream? My last status is that we
> couldn't find a reason why we need to do this in the kernel.
>
> Christian.
>
> Am 25.04.20 um 10:52 schrieb Marek Olšák:
>
> This was missed.
>
> 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&data=02%7C01%7CAlexander.Deucher%40amd.com%7C6b35f61512d34bf2dc8b08d7e9bfa1a6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637234881577782939&sdata=%2B95wpbjY3Q675FaX9iH1BNIFyEz5jpN4PzjEOOpIu9Q%3D&reserved=0>
>
>
>
> _______________________________________________
> 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&data=02%7C01%7CAlexander.Deucher%40amd.com%7C6b35f61512d34bf2dc8b08d7e9bfa1a6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637234881577782939&sdata=%2B95wpbjY3Q675FaX9iH1BNIFyEz5jpN4PzjEOOpIu9Q%3D&reserved=0>
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 5506 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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to compute IBs too
  2020-04-27 13:54         ` Marek Olšák
@ 2020-04-27 14:53           ` Christian König
  2020-04-28  3:22             ` Chunming Zhou
  2020-04-28  5:12             ` Marek Olšák
  0 siblings, 2 replies; 11+ messages in thread
From: Christian König @ 2020-04-27 14:53 UTC (permalink / raw)
  To: Marek Olšák, Deucher, Alexander
  Cc: Koenig, Christian, amd-gfx mailing list


[-- Attachment #1.1: Type: text/plain, Size: 3968 bytes --]

Yeah, but is Mesa going to use it?

Christian.

Am 27.04.20 um 15:54 schrieb Marek Olšák:
> PAL requested it and they are going to use it. (it looks like they 
> have to use it for correctness)
>
> Marek
>
> On Mon, Apr 27, 2020 at 9:02 AM Deucher, Alexander 
> <Alexander.Deucher@amd.com <mailto:Alexander.Deucher@amd.com>> wrote:
>
>     [AMD Official Use Only - Internal Distribution Only]
>
>
>     Do we have open source code UMD code which uses this?
>
>     Alex
>     ------------------------------------------------------------------------
>     *From:* Christian König <ckoenig.leichtzumerken@gmail.com
>     <mailto:ckoenig.leichtzumerken@gmail.com>>
>     *Sent:* Sunday, April 26, 2020 4:55 AM
>     *To:* Marek Olšák <maraeo@gmail.com <mailto:maraeo@gmail.com>>;
>     Koenig, Christian <Christian.Koenig@amd.com
>     <mailto:Christian.Koenig@amd.com>>
>     *Cc:* Deucher, Alexander <Alexander.Deucher@amd.com
>     <mailto:Alexander.Deucher@amd.com>>; amd-gfx mailing list
>     <amd-gfx@lists.freedesktop.org <mailto:amd-gfx@lists.freedesktop.org>>
>     *Subject:* Re: drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to
>     compute IBs too
>     Thanks for that explanation. I suspected that there was a good
>     reason to have that in the kernel, but couldn't find one.
>
>     In this case the patch is Reviewed-by: Christian König
>     <christian.koenig@amd.com> <mailto:christian.koenig@amd.com>
>
>     We should probably add this explanation as comment to the flag as
>     well.
>
>     Thanks,
>     Christian.
>
>     Am 26.04.20 um 02:43 schrieb Marek Olšák:
>>     It was merged into amd-staging-drm-next.
>>
>>     I'm not absolutely sure, but I think we need to invalidate before
>>     IBs if an IB is cached in L2 and the CPU has updated it. It can
>>     only be cached in L2 if something other than CP has read it or
>>     written to it without invalidation. CP reads don't cache it but
>>     they can hit the cache if it's already cached.
>>
>>     For CE, we need to invalidate before the IB in the kernel,
>>     because CE IBs can't do cache invalidations IIRC. This is the
>>     number one reason for merging the already pushed commits.
>>
>>     Marek
>>
>>     On Sat., Apr. 25, 2020, 11:03 Christian König,
>>     <ckoenig.leichtzumerken@gmail.com
>>     <mailto:ckoenig.leichtzumerken@gmail.com>> wrote:
>>
>>         Was that patch set actually merged upstream? My last status
>>         is that we couldn't find a reason why we need to do this in
>>         the kernel.
>>
>>         Christian.
>>
>>         Am 25.04.20 um 10:52 schrieb Marek Olšák:
>>>         This was missed.
>>>
>>>         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&data=02%7C01%7CAlexander.Deucher%40amd.com%7C6b35f61512d34bf2dc8b08d7e9bfa1a6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637234881577782939&sdata=%2B95wpbjY3Q675FaX9iH1BNIFyEz5jpN4PzjEOOpIu9Q%3D&reserved=0>
>>
>>
>>     _______________________________________________
>>     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&data=02%7C01%7CAlexander.Deucher%40amd.com%7C6b35f61512d34bf2dc8b08d7e9bfa1a6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637234881577782939&sdata=%2B95wpbjY3Q675FaX9iH1BNIFyEz5jpN4PzjEOOpIu9Q%3D&reserved=0>
>
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[-- Attachment #1.2: Type: text/html, Size: 9163 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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to compute IBs too
  2020-04-27 14:53           ` Christian König
@ 2020-04-28  3:22             ` Chunming Zhou
  2020-04-28  5:12             ` Marek Olšák
  1 sibling, 0 replies; 11+ messages in thread
From: Chunming Zhou @ 2020-04-28  3:22 UTC (permalink / raw)
  To: christian.koenig, Marek Olšák, Deucher, Alexander
  Cc: amd-gfx mailing list


[-- Attachment #1.1: Type: text/plain, Size: 4688 bytes --]

Yes, same question.

In fact, PAL cmd stream has itself Relase/Acquire packets. That we use 
the flag is per your request.

-David

在 2020/4/27 22:53, Christian König 写道:
> Yeah, but is Mesa going to use it?
>
> Christian.
>
> Am 27.04.20 um 15:54 schrieb Marek Olšák:
>> PAL requested it and they are going to use it. (it looks like they 
>> have to use it for correctness)
>>
>> Marek
>>
>> On Mon, Apr 27, 2020 at 9:02 AM Deucher, Alexander 
>> <Alexander.Deucher@amd.com <mailto:Alexander.Deucher@amd.com>> wrote:
>>
>>     [AMD Official Use Only - Internal Distribution Only]
>>
>>
>>     Do we have open source code UMD code which uses this?
>>
>>     Alex
>>     ------------------------------------------------------------------------
>>     *From:* Christian König <ckoenig.leichtzumerken@gmail.com
>>     <mailto:ckoenig.leichtzumerken@gmail.com>>
>>     *Sent:* Sunday, April 26, 2020 4:55 AM
>>     *To:* Marek Olšák <maraeo@gmail.com <mailto:maraeo@gmail.com>>;
>>     Koenig, Christian <Christian.Koenig@amd.com
>>     <mailto:Christian.Koenig@amd.com>>
>>     *Cc:* Deucher, Alexander <Alexander.Deucher@amd.com
>>     <mailto:Alexander.Deucher@amd.com>>; amd-gfx mailing list
>>     <amd-gfx@lists.freedesktop.org
>>     <mailto:amd-gfx@lists.freedesktop.org>>
>>     *Subject:* Re: drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to
>>     compute IBs too
>>     Thanks for that explanation. I suspected that there was a good
>>     reason to have that in the kernel, but couldn't find one.
>>
>>     In this case the patch is Reviewed-by: Christian König
>>     <christian.koenig@amd.com> <mailto:christian.koenig@amd.com>
>>
>>     We should probably add this explanation as comment to the flag as
>>     well.
>>
>>     Thanks,
>>     Christian.
>>
>>     Am 26.04.20 um 02:43 schrieb Marek Olšák:
>>>     It was merged into amd-staging-drm-next.
>>>
>>>     I'm not absolutely sure, but I think we need to invalidate
>>>     before IBs if an IB is cached in L2 and the CPU has updated it.
>>>     It can only be cached in L2 if something other than CP has read
>>>     it or written to it without invalidation. CP reads don't cache
>>>     it but they can hit the cache if it's already cached.
>>>
>>>     For CE, we need to invalidate before the IB in the kernel,
>>>     because CE IBs can't do cache invalidations IIRC. This is the
>>>     number one reason for merging the already pushed commits.
>>>
>>>     Marek
>>>
>>>     On Sat., Apr. 25, 2020, 11:03 Christian König,
>>>     <ckoenig.leichtzumerken@gmail.com
>>>     <mailto:ckoenig.leichtzumerken@gmail.com>> wrote:
>>>
>>>         Was that patch set actually merged upstream? My last status
>>>         is that we couldn't find a reason why we need to do this in
>>>         the kernel.
>>>
>>>         Christian.
>>>
>>>         Am 25.04.20 um 10:52 schrieb Marek Olšák:
>>>>         This was missed.
>>>>
>>>>         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&data=02%7C01%7Cdavid1.zhou%40amd.com%7Ced56cca1a5214cf9132808d7eabac6d9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637235960880865820&sdata=1eMdG%2Fr07okHFC%2F%2B3Oz4mg6dAvnd%2FULM6ucEoy7xXDc%3D&reserved=0>
>>>
>>>
>>>     _______________________________________________
>>>     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&data=02%7C01%7Cdavid1.zhou%40amd.com%7Ced56cca1a5214cf9132808d7eabac6d9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637235960880875773&sdata=8IuVdWV7WS%2BZR60H8B9rWug64%2Bb7xnEUOucMzOlr1wY%3D&reserved=0>
>>
>>
>> _______________________________________________
>> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&amp;data=02%7C01%7Cdavid1.zhou%40amd.com%7Ced56cca1a5214cf9132808d7eabac6d9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637235960880895689&amp;sdata=6p%2BAuZXHiUrO8wElftOqsJzHF%2BVLe5TMDIF%2BbJNV6ac%3D&amp;reserved=0

[-- Attachment #1.2: Type: text/html, Size: 11554 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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to compute IBs too
  2020-04-27 14:53           ` Christian König
  2020-04-28  3:22             ` Chunming Zhou
@ 2020-04-28  5:12             ` Marek Olšák
  2020-04-28  5:16               ` Marek Olšák
  1 sibling, 1 reply; 11+ messages in thread
From: Marek Olšák @ 2020-04-28  5:12 UTC (permalink / raw)
  To: Christian König; +Cc: Deucher, Alexander, amd-gfx mailing list


[-- Attachment #1.1: Type: text/plain, Size: 3759 bytes --]

No, Mesa won't use it. It's only necessary for the constant engine. My
understanding from various discussions with the PAL team is that they need
it, but I don't know if they even understand what the MEM_SYNC flag does.

Marek

On Mon., Apr. 27, 2020, 10:53 Christian König, <
ckoenig.leichtzumerken@gmail.com> wrote:

> Yeah, but is Mesa going to use it?
>
> Christian.
>
> Am 27.04.20 um 15:54 schrieb Marek Olšák:
>
> PAL requested it and they are going to use it. (it looks like they have to
> use it for correctness)
>
> Marek
>
> On Mon, Apr 27, 2020 at 9:02 AM Deucher, Alexander <
> Alexander.Deucher@amd.com> wrote:
>
>> [AMD Official Use Only - Internal Distribution Only]
>>
>> Do we have open source code UMD code which uses this?
>>
>> Alex
>> ------------------------------
>> *From:* Christian König <ckoenig.leichtzumerken@gmail.com>
>> *Sent:* Sunday, April 26, 2020 4:55 AM
>> *To:* Marek Olšák <maraeo@gmail.com>; Koenig, Christian <
>> Christian.Koenig@amd.com>
>> *Cc:* Deucher, Alexander <Alexander.Deucher@amd.com>; amd-gfx mailing
>> list <amd-gfx@lists.freedesktop.org>
>> *Subject:* Re: drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to compute
>> IBs too
>>
>> Thanks for that explanation. I suspected that there was a good reason to
>> have that in the kernel, but couldn't find one.
>>
>> In this case the patch is Reviewed-by: Christian König
>> <christian.koenig@amd.com> <christian.koenig@amd.com>
>>
>> We should probably add this explanation as comment to the flag as well.
>>
>> Thanks,
>> Christian.
>>
>> Am 26.04.20 um 02:43 schrieb Marek Olšák:
>>
>> It was merged into amd-staging-drm-next.
>>
>> I'm not absolutely sure, but I think we need to invalidate before IBs if
>> an IB is cached in L2 and the CPU has updated it. It can only be cached in
>> L2 if something other than CP has read it or written to it without
>> invalidation. CP reads don't cache it but they can hit the cache if it's
>> already cached.
>>
>> For CE, we need to invalidate before the IB in the kernel, because CE IBs
>> can't do cache invalidations IIRC. This is the number one reason for
>> merging the already pushed commits.
>>
>> Marek
>>
>> On Sat., Apr. 25, 2020, 11:03 Christian König, <
>> ckoenig.leichtzumerken@gmail.com> wrote:
>>
>> Was that patch set actually merged upstream? My last status is that we
>> couldn't find a reason why we need to do this in the kernel.
>>
>> Christian.
>>
>> Am 25.04.20 um 10:52 schrieb Marek Olšák:
>>
>> This was missed.
>>
>> 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&data=02%7C01%7CAlexander.Deucher%40amd.com%7C6b35f61512d34bf2dc8b08d7e9bfa1a6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637234881577782939&sdata=%2B95wpbjY3Q675FaX9iH1BNIFyEz5jpN4PzjEOOpIu9Q%3D&reserved=0>
>>
>>
>>
>> _______________________________________________
>> 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&data=02%7C01%7CAlexander.Deucher%40amd.com%7C6b35f61512d34bf2dc8b08d7e9bfa1a6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637234881577782939&sdata=%2B95wpbjY3Q675FaX9iH1BNIFyEz5jpN4PzjEOOpIu9Q%3D&reserved=0>
>>
>>
>>
> _______________________________________________
> amd-gfx mailing listamd-gfx@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 9251 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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to compute IBs too
  2020-04-28  5:12             ` Marek Olšák
@ 2020-04-28  5:16               ` Marek Olšák
  0 siblings, 0 replies; 11+ messages in thread
From: Marek Olšák @ 2020-04-28  5:16 UTC (permalink / raw)
  To: Christian König; +Cc: Deucher, Alexander, amd-gfx mailing list


[-- Attachment #1.1: Type: text/plain, Size: 4055 bytes --]

It's possible that what they really needed was the SDMA fix, so I don't
know if they need this flag anymore.

Marek

On Tue., Apr. 28, 2020, 01:12 Marek Olšák, <maraeo@gmail.com> wrote:

> No, Mesa won't use it. It's only necessary for the constant engine. My
> understanding from various discussions with the PAL team is that they need
> it, but I don't know if they even understand what the MEM_SYNC flag does.
>
> Marek
>
> On Mon., Apr. 27, 2020, 10:53 Christian König, <
> ckoenig.leichtzumerken@gmail.com> wrote:
>
>> Yeah, but is Mesa going to use it?
>>
>> Christian.
>>
>> Am 27.04.20 um 15:54 schrieb Marek Olšák:
>>
>> PAL requested it and they are going to use it. (it looks like they have
>> to use it for correctness)
>>
>> Marek
>>
>> On Mon, Apr 27, 2020 at 9:02 AM Deucher, Alexander <
>> Alexander.Deucher@amd.com> wrote:
>>
>>> [AMD Official Use Only - Internal Distribution Only]
>>>
>>> Do we have open source code UMD code which uses this?
>>>
>>> Alex
>>> ------------------------------
>>> *From:* Christian König <ckoenig.leichtzumerken@gmail.com>
>>> *Sent:* Sunday, April 26, 2020 4:55 AM
>>> *To:* Marek Olšák <maraeo@gmail.com>; Koenig, Christian <
>>> Christian.Koenig@amd.com>
>>> *Cc:* Deucher, Alexander <Alexander.Deucher@amd.com>; amd-gfx mailing
>>> list <amd-gfx@lists.freedesktop.org>
>>> *Subject:* Re: drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to
>>> compute IBs too
>>>
>>> Thanks for that explanation. I suspected that there was a good reason to
>>> have that in the kernel, but couldn't find one.
>>>
>>> In this case the patch is Reviewed-by: Christian König
>>> <christian.koenig@amd.com> <christian.koenig@amd.com>
>>>
>>> We should probably add this explanation as comment to the flag as well.
>>>
>>> Thanks,
>>> Christian.
>>>
>>> Am 26.04.20 um 02:43 schrieb Marek Olšák:
>>>
>>> It was merged into amd-staging-drm-next.
>>>
>>> I'm not absolutely sure, but I think we need to invalidate before IBs if
>>> an IB is cached in L2 and the CPU has updated it. It can only be cached in
>>> L2 if something other than CP has read it or written to it without
>>> invalidation. CP reads don't cache it but they can hit the cache if it's
>>> already cached.
>>>
>>> For CE, we need to invalidate before the IB in the kernel, because CE
>>> IBs can't do cache invalidations IIRC. This is the number one reason for
>>> merging the already pushed commits.
>>>
>>> Marek
>>>
>>> On Sat., Apr. 25, 2020, 11:03 Christian König, <
>>> ckoenig.leichtzumerken@gmail.com> wrote:
>>>
>>> Was that patch set actually merged upstream? My last status is that we
>>> couldn't find a reason why we need to do this in the kernel.
>>>
>>> Christian.
>>>
>>> Am 25.04.20 um 10:52 schrieb Marek Olšák:
>>>
>>> This was missed.
>>>
>>> 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&data=02%7C01%7CAlexander.Deucher%40amd.com%7C6b35f61512d34bf2dc8b08d7e9bfa1a6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637234881577782939&sdata=%2B95wpbjY3Q675FaX9iH1BNIFyEz5jpN4PzjEOOpIu9Q%3D&reserved=0>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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&data=02%7C01%7CAlexander.Deucher%40amd.com%7C6b35f61512d34bf2dc8b08d7e9bfa1a6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637234881577782939&sdata=%2B95wpbjY3Q675FaX9iH1BNIFyEz5jpN4PzjEOOpIu9Q%3D&reserved=0>
>>>
>>>
>>>
>> _______________________________________________
>> amd-gfx mailing listamd-gfx@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>
>>
>>

[-- Attachment #1.2: Type: text/html, Size: 9959 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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to compute IBs too
  2020-04-25  8:52 drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to compute IBs too Marek Olšák
  2020-04-25 15:03 ` Christian König
@ 2020-04-28  9:50 ` Liu, Monk
  1 sibling, 0 replies; 11+ messages in thread
From: Liu, Monk @ 2020-04-28  9:50 UTC (permalink / raw)
  To: Marek Olšák, amd-gfx mailing list


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

Hi Marek

I’m not very familiar with the background of your patch, but I have a question: why you only apply this change on SDMA and compute ring, but ignore GFX ring ?

Thanks

_____________________________________
Monk Liu|GPU Virtualization Team |AMD
[sig-cloud-gpu]

From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> On Behalf Of Marek Ol?ák
Sent: Saturday, April 25, 2020 4:53 PM
To: amd-gfx mailing list <amd-gfx@lists.freedesktop.org>
Subject: drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to compute IBs too

This was missed.

Marek

[-- Attachment #1.1.2: Type: text/html, Size: 3738 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

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2020-04-28  9:50 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-25  8:52 drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to compute IBs too Marek Olšák
2020-04-25 15:03 ` Christian König
2020-04-26  0:43   ` Marek Olšák
2020-04-26  8:55     ` Christian König
2020-04-27 13:02       ` Deucher, Alexander
2020-04-27 13:54         ` Marek Olšák
2020-04-27 14:53           ` Christian König
2020-04-28  3:22             ` Chunming Zhou
2020-04-28  5:12             ` Marek Olšák
2020-04-28  5:16               ` Marek Olšák
2020-04-28  9:50 ` Liu, Monk

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.