Am 29.08.2018 um 05:53 schrieb Dave Airlie:
From: Dave Airlie <airl...@redhat.com>
While adding transfer queues to radv, I started writing some tests,
the first test I wrote fell over copying a buffer larger than this
limit.
Checked AMDVLK and found the correct limit.
Cc: <mesa-sta...@lists.freedesktop.org>
---
src/amd/common/sid.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/amd/common/sid.h b/src/amd/common/sid.h
index 0671f7d3998..edb7d06afa6 100644
--- a/src/amd/common/sid.h
+++ b/src/amd/common/sid.h
@@ -9139,7 +9139,9 @@
#define CIK_SDMA_PACKET_SEMAPHORE 0x7
#define CIK_SDMA_PACKET_CONSTANT_FILL 0xb
#define CIK_SDMA_PACKET_SRBM_WRITE 0xe
-#define CIK_SDMA_COPY_MAX_SIZE 0x3fffe0
+/* There is apparently an undocumented HW "feature" that
+ prevents the HW from copying past 256 bytes of (1 << 22) */
+#define CIK_SDMA_COPY_MAX_SIZE 0x3fff00
Well that is interesting. IIRC, the hardware documentation explicitly
states that 0x3fffe0 is the maximum size.
That would also explain a couple of problems we see with on CIK because
the kernel doesn't get that right either.
Christian.
enum amd_cmp_class_flags {
S_NAN = 1 << 0, // Signaling NaN
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
