On 13/11/17 22:59, Kenneth Graunke wrote:
On Sunday, November 12, 2017 3:57:56 AM PST Lionel Landwerlin wrote:
On 12/11/17 08:35, Kenneth Graunke wrote:
This makes aubinator_error_decode's shader dumping work like aubinator.
Instead of printing them after the fact, it prints them right inside the
3DSTATE_VS/HS/DS/GS/PS packet that references them.  This saves you the
effort of cross-referencing things and jumping back and forth.

It also reduces a bunch of book-keeping, and eliminates the limitation
that we could only handle 4096 programs.  That code was also broken and
failed to print any shaders if there were under 4096 programs.
---
   src/intel/tools/aubinator_error_decode.c | 134 
+++++++++++--------------------
   1 file changed, 49 insertions(+), 85 deletions(-)

diff --git a/src/intel/tools/aubinator_error_decode.c 
b/src/intel/tools/aubinator_error_decode.c
index cea68523ae2..96b4989936e 100644
--- a/src/intel/tools/aubinator_error_decode.c
+++ b/src/intel/tools/aubinator_error_decode.c
@@ -221,35 +221,28 @@ struct section {
   #define MAX_SECTIONS 30
   static struct section sections[MAX_SECTIONS];
-struct program {
-   const char *type;
-   const char *command;
-   uint64_t command_offset;
-   uint64_t instruction_base_address;
-   uint64_t ksp;
-};
-
-#define MAX_NUM_PROGRAMS 4096
-static struct program programs[MAX_NUM_PROGRAMS];
-static int idx_program = 0, num_programs = 0;
-
-static int next_program(void)
+static void
+disassemble_program(struct gen_disasm *disasm, const char *type,
+                    const struct section *instruction_section,
+                    uint64_t ksp)
   {
-   int ret = idx_program;
-   idx_program = (idx_program + 1) % MAX_NUM_PROGRAMS;
-   num_programs = MIN(num_programs + 1, MAX_NUM_PROGRAMS);
-   return ret;
+   if (!instruction_section)
+      return;
+
+   printf("\nReferenced %s:\n", type);
+   gen_disasm_disassemble(disasm, instruction_section->data, ksp, stdout);
   }
static void
-decode(struct gen_spec *spec, const struct section *section)
+decode(struct gen_spec *spec, struct gen_disasm *disasm,
+       const struct section *section)
   {
      uint64_t gtt_offset = section->gtt_offset;
      uint32_t *data = section->data;
      uint32_t *p, *end = (data + section->count);
      int length;
      struct gen_group *inst;
-   uint64_t current_instruction_base_address = 0;
+   const struct section *current_instruction_buffer = NULL;
for (p = data; p < end; p += length) {
         const char *color = option_full_decode ? BLUE_HEADER : NORMAL,
@@ -284,7 +277,13 @@ decode(struct gen_spec *spec, const struct section 
*section)
while (gen_field_iterator_next(&iter)) {
               if (strcmp(iter.name, "Instruction Base Address") == 0) {
-               current_instruction_base_address = strtol(iter.value, NULL, 16);
+               uint64_t instr_base_address = strtol(iter.value, NULL, 16);
+               current_instruction_buffer = NULL;
+               for (int s = 0; s < MAX_SECTIONS; s++) {
+                  if (sections[s].gtt_offset == instr_base_address) {
Is it a guarantee that the instruction buffer is going to be given in
its own section?
The section corresponds to a buffer marked with EXEC_OBJECT_CAPTURE, so
assuming the driver has programmed STATE_BASE_ADDRESS to the start of a
buffer, this will be true.  Otherwise, we'll get no assembly or state
dumping.

That seems like the obvious thing for a driver to do, but I suppose they
could also point it the middle of a buffer somewhere.  Mesa and SNA both
point to the start of a buffer.

I can write a follow-up patch to allow that, if you want...

Sorry, I should have looked this up.
Looking at vaapi, it seems it uses the same approach (one BO for each base address).
I guess we don't need bounds checking, feel free to land!


Or do we need to check bounds ?

if (instr_base_address >= sections[s].gtt_offset && inst_base_address <=
sections[s].gtt_offset + sections[s].count * 4)

Otherwise it looks fine to me :

Reviewed-by: Lionel Landwerlin <[email protected]>


_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to