On 10/06/18 13:23, Chris Wilson wrote:
Quoting Lionel Landwerlin (2018-06-10 13:15:10)
Now that we're softpinning the address of our BOs in anv & i965, the
addresses selected start at the top of the addressing space. This is a
problem for the current implementation of aubinator which uses only a
40bit mmapped address space.
This change keeps track of all the memory writes from the aub file and
fetch them on request by the batch decoder. As a result we can get rid
of the 1<<40 mmapped address space and only rely on the mmap aub file
\o/
Signed-off-by: Lionel Landwerlin <lionel.g.landwer...@intel.com>
---
src/intel/tools/aubinator.c | 116 +++++++++++++++++++++---------------
1 file changed, 68 insertions(+), 48 deletions(-)
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index 3120e82b22e..4a60a606f63 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -68,8 +68,14 @@ char *input_file = NULL, *xml_path = NULL;
struct gen_device_info devinfo;
struct gen_batch_decode_ctx batch_ctx;
-uint64_t gtt_size, gtt_end;
-void *gtt;
+static struct memory_chunk {
+ void *map;
+ uint64_t address;
+ uint32_t size;
Why is size only 32b? I didn't see where large bo would be split into
multiple chunks.
-Chris
Most of the memory write commands seem to have sizes encoded on 32bits.
-
Lionel
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
