panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
/*
|
|
|
|
|
* Copyright (C) 2017-2019 Alyssa Rosenzweig
|
|
|
|
|
* Copyright (C) 2017-2019 Connor Abbott
|
2019-06-25 13:30:17 -07:00
|
|
|
* Copyright (C) 2019 Collabora, Ltd.
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
*
|
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
|
* copy of this software and associated documentation files (the "Software"),
|
|
|
|
|
* to deal in the Software without restriction, including without limitation
|
|
|
|
|
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
|
|
|
|
|
* and/or sell copies of the Software, and to permit persons to whom the
|
|
|
|
|
* Software is furnished to do so, subject to the following conditions:
|
|
|
|
|
*
|
|
|
|
|
* The above copyright notice and this permission notice (including the next
|
|
|
|
|
* paragraph) shall be included in all copies or substantial portions of the
|
|
|
|
|
* Software.
|
|
|
|
|
*
|
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
|
|
|
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
|
|
|
* SOFTWARE.
|
|
|
|
|
*/
|
|
|
|
|
|
2021-08-05 11:12:53 +02:00
|
|
|
#include <genxml/gen_macros.h>
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
#include <stdio.h>
|
|
|
|
|
#include <stdlib.h>
|
|
|
|
|
#include <memory.h>
|
|
|
|
|
#include <stdbool.h>
|
|
|
|
|
#include <stdarg.h>
|
2021-05-21 17:38:00 -04:00
|
|
|
#include <errno.h>
|
2019-08-20 14:34:09 -07:00
|
|
|
#include <ctype.h>
|
2019-06-11 12:25:35 -07:00
|
|
|
#include "decode.h"
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2022-03-26 02:13:16 +00:00
|
|
|
#include "util/set.h"
|
2019-07-10 10:33:24 -07:00
|
|
|
#include "midgard/disassemble.h"
|
|
|
|
|
#include "bifrost/disassemble.h"
|
2021-11-18 18:17:01 -05:00
|
|
|
#include "bifrost/valhall/disassemble.h"
|
2019-07-10 10:33:24 -07:00
|
|
|
|
2020-09-05 18:14:17 +02:00
|
|
|
#define DUMP_UNPACKED(T, var, ...) { \
|
2020-09-09 17:56:53 +02:00
|
|
|
pandecode_log(__VA_ARGS__); \
|
2020-09-05 18:14:17 +02:00
|
|
|
pan_print(pandecode_dump_stream, T, var, (pandecode_indent + 1) * 2); \
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#define DUMP_CL(T, cl, ...) {\
|
2020-09-05 18:04:43 +02:00
|
|
|
pan_unpack(cl, T, temp); \
|
2020-09-05 18:14:17 +02:00
|
|
|
DUMP_UNPACKED(T, temp, __VA_ARGS__); \
|
2020-08-05 19:43:58 -04:00
|
|
|
}
|
|
|
|
|
|
2020-09-06 11:01:09 +02:00
|
|
|
#define DUMP_SECTION(A, S, cl, ...) { \
|
|
|
|
|
pan_section_unpack(cl, A, S, temp); \
|
|
|
|
|
pandecode_log(__VA_ARGS__); \
|
|
|
|
|
pan_section_print(pandecode_dump_stream, A, S, temp, (pandecode_indent + 1) * 2); \
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-14 16:03:12 -04:00
|
|
|
#define MAP_ADDR(T, addr, cl) \
|
2022-08-15 18:35:45 +00:00
|
|
|
const uint8_t *cl = pandecode_fetch_gpu_mem(addr, pan_size(T));
|
2020-08-14 16:03:12 -04:00
|
|
|
|
2020-09-09 17:56:53 +02:00
|
|
|
#define DUMP_ADDR(T, addr, ...) {\
|
2020-08-14 16:03:12 -04:00
|
|
|
MAP_ADDR(T, addr, cl) \
|
2020-09-09 17:56:53 +02:00
|
|
|
DUMP_CL(T, cl, __VA_ARGS__); \
|
2020-08-05 19:43:58 -04:00
|
|
|
}
|
|
|
|
|
|
2021-08-06 10:22:28 +02:00
|
|
|
static unsigned pandecode_indent = 0;
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
pandecode_make_indent(void)
|
|
|
|
|
{
|
|
|
|
|
for (unsigned i = 0; i < pandecode_indent; ++i)
|
2020-09-09 17:52:23 +02:00
|
|
|
fprintf(pandecode_dump_stream, " ");
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
}
|
|
|
|
|
|
2022-08-15 18:38:56 +00:00
|
|
|
static void PRINTFLIKE(1, 2)
|
|
|
|
|
pandecode_log(const char *format, ...)
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
{
|
|
|
|
|
va_list ap;
|
|
|
|
|
|
|
|
|
|
pandecode_make_indent();
|
|
|
|
|
va_start(ap, format);
|
2020-01-23 10:14:35 +13:00
|
|
|
vfprintf(pandecode_dump_stream, format, ap);
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
va_end(ap);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
pandecode_log_cont(const char *format, ...)
|
|
|
|
|
{
|
|
|
|
|
va_list ap;
|
|
|
|
|
|
|
|
|
|
va_start(ap, format);
|
2020-01-23 10:14:35 +13:00
|
|
|
vfprintf(pandecode_dump_stream, format, ap);
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
va_end(ap);
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-19 15:14:48 -07:00
|
|
|
/* To check for memory safety issues, validates that the given pointer in GPU
|
|
|
|
|
* memory is valid, containing at least sz bytes. The goal is to eliminate
|
|
|
|
|
* GPU-side memory bugs (NULL pointer dereferences, buffer overflows, or buffer
|
|
|
|
|
* overruns) by statically validating pointers.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
pandecode_validate_buffer(mali_ptr addr, size_t sz)
|
|
|
|
|
{
|
|
|
|
|
if (!addr) {
|
2022-08-15 18:38:56 +00:00
|
|
|
pandecode_log("// XXX: null pointer deref\n");
|
2019-08-19 15:14:48 -07:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Find a BO */
|
|
|
|
|
|
|
|
|
|
struct pandecode_mapped_memory *bo =
|
|
|
|
|
pandecode_find_mapped_gpu_mem_containing(addr);
|
|
|
|
|
|
|
|
|
|
if (!bo) {
|
2022-08-15 18:38:56 +00:00
|
|
|
pandecode_log("// XXX: invalid memory dereference\n");
|
2019-08-19 15:14:48 -07:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Bounds check */
|
|
|
|
|
|
|
|
|
|
unsigned offset = addr - bo->gpu_va;
|
|
|
|
|
unsigned total = offset + sz;
|
|
|
|
|
|
|
|
|
|
if (total > bo->length) {
|
2022-08-15 18:38:56 +00:00
|
|
|
pandecode_log("// XXX: buffer overrun. "
|
2019-08-30 17:02:43 -07:00
|
|
|
"Chunk of size %zu at offset %d in buffer of size %zu. "
|
|
|
|
|
"Overrun by %zu bytes. \n",
|
2019-08-19 15:14:48 -07:00
|
|
|
sz, offset, bo->length, total - bo->length);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-08-06 10:22:28 +02:00
|
|
|
#if PAN_ARCH <= 5
|
2019-07-10 07:22:19 -07:00
|
|
|
/* Midgard's tiler descriptor is embedded within the
|
|
|
|
|
* larger FBD */
|
|
|
|
|
|
|
|
|
|
static void
|
2019-08-19 11:48:32 -07:00
|
|
|
pandecode_midgard_tiler_descriptor(
|
2021-07-29 17:19:39 +02:00
|
|
|
const struct mali_tiler_context_packed *tp,
|
|
|
|
|
const struct mali_tiler_weights_packed *wp)
|
2019-07-10 07:22:19 -07:00
|
|
|
{
|
2021-08-06 10:22:28 +02:00
|
|
|
pan_unpack(tp, TILER_CONTEXT, t);
|
|
|
|
|
DUMP_UNPACKED(TILER_CONTEXT, t, "Tiler:\n");
|
2019-08-19 14:47:50 -07:00
|
|
|
|
2021-01-18 13:08:56 -05:00
|
|
|
/* We've never seen weights used in practice, but they exist */
|
2021-07-29 17:19:39 +02:00
|
|
|
pan_unpack(wp, TILER_WEIGHTS, w);
|
2019-07-10 07:22:19 -07:00
|
|
|
bool nonzero_weights = false;
|
|
|
|
|
|
2020-09-05 18:16:37 +02:00
|
|
|
nonzero_weights |= w.weight0 != 0x0;
|
|
|
|
|
nonzero_weights |= w.weight1 != 0x0;
|
|
|
|
|
nonzero_weights |= w.weight2 != 0x0;
|
|
|
|
|
nonzero_weights |= w.weight3 != 0x0;
|
|
|
|
|
nonzero_weights |= w.weight4 != 0x0;
|
|
|
|
|
nonzero_weights |= w.weight5 != 0x0;
|
|
|
|
|
nonzero_weights |= w.weight6 != 0x0;
|
|
|
|
|
nonzero_weights |= w.weight7 != 0x0;
|
|
|
|
|
|
|
|
|
|
if (nonzero_weights)
|
2021-07-29 17:19:39 +02:00
|
|
|
DUMP_UNPACKED(TILER_WEIGHTS, w, "Tiler Weights:\n");
|
2019-07-10 07:22:19 -07:00
|
|
|
}
|
2021-08-06 10:22:28 +02:00
|
|
|
#endif
|
2019-07-10 07:22:19 -07:00
|
|
|
|
2021-07-29 17:19:39 +02:00
|
|
|
#if PAN_ARCH >= 5
|
2019-06-19 08:41:51 -07:00
|
|
|
static void
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_local_storage(uint64_t gpu_va)
|
2019-06-19 08:41:51 -07:00
|
|
|
{
|
2022-08-15 18:35:45 +00:00
|
|
|
const struct mali_local_storage_packed *PANDECODE_PTR_VAR(s, (mali_ptr) gpu_va);
|
2020-09-03 09:18:09 +02:00
|
|
|
DUMP_CL(LOCAL_STORAGE, s, "Local Storage:\n");
|
2019-06-19 08:41:51 -07:00
|
|
|
}
|
|
|
|
|
|
2019-02-24 06:22:23 +00:00
|
|
|
static void
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_render_target(uint64_t gpu_va, unsigned gpu_id,
|
2021-07-29 17:19:39 +02:00
|
|
|
const struct MALI_FRAMEBUFFER_PARAMETERS *fb)
|
2019-02-24 06:22:23 +00:00
|
|
|
{
|
2020-09-08 10:17:40 +02:00
|
|
|
pandecode_log("Color Render Targets:\n");
|
2019-02-24 06:22:23 +00:00
|
|
|
pandecode_indent++;
|
|
|
|
|
|
2020-09-08 10:17:40 +02:00
|
|
|
for (int i = 0; i < (fb->render_target_count); i++) {
|
2021-07-28 11:03:13 +02:00
|
|
|
mali_ptr rt_va = gpu_va + i * pan_size(RENDER_TARGET);
|
2022-08-15 18:35:45 +00:00
|
|
|
const struct mali_render_target_packed *PANDECODE_PTR_VAR(rtp, (mali_ptr) rt_va);
|
2020-09-08 10:17:40 +02:00
|
|
|
DUMP_CL(RENDER_TARGET, rtp, "Color Render Target %d:\n", i);
|
2019-08-20 11:11:46 -07:00
|
|
|
}
|
2019-08-14 16:01:38 -07:00
|
|
|
|
2019-02-24 06:22:23 +00:00
|
|
|
pandecode_indent--;
|
2020-09-08 10:17:40 +02:00
|
|
|
pandecode_log("\n");
|
2019-02-24 06:22:23 +00:00
|
|
|
}
|
2021-07-29 17:19:39 +02:00
|
|
|
#endif
|
2019-02-24 06:22:23 +00:00
|
|
|
|
2021-08-06 10:22:28 +02:00
|
|
|
#if PAN_ARCH >= 6
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
static void
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_sample_locations(const void *fb)
|
2019-06-11 14:56:30 -07:00
|
|
|
{
|
2021-07-29 17:19:39 +02:00
|
|
|
pan_section_unpack(fb, FRAMEBUFFER, PARAMETERS, params);
|
2020-09-08 10:17:40 +02:00
|
|
|
|
2022-08-15 18:35:45 +00:00
|
|
|
const u16 *PANDECODE_PTR_VAR(samples, params.sample_locations);
|
2019-06-11 14:56:30 -07:00
|
|
|
|
2021-01-29 16:52:45 -05:00
|
|
|
pandecode_log("Sample locations:\n");
|
|
|
|
|
for (int i = 0; i < 33; i++) {
|
|
|
|
|
pandecode_log(" (%d, %d),\n",
|
|
|
|
|
samples[2 * i] - 128,
|
|
|
|
|
samples[2 * i + 1] - 128);
|
2019-06-11 14:56:30 -07:00
|
|
|
}
|
|
|
|
|
}
|
2021-08-06 10:22:28 +02:00
|
|
|
#endif
|
2019-06-11 14:56:30 -07:00
|
|
|
|
2021-04-07 15:31:16 +02:00
|
|
|
static void
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_dcd(const struct MALI_DRAW *p, enum mali_job_type job_type,
|
2022-08-15 18:49:04 +00:00
|
|
|
unsigned gpu_id);
|
2021-04-07 15:31:16 +02:00
|
|
|
|
2022-08-15 19:10:04 +00:00
|
|
|
/* Information about the framebuffer passed back for additional analysis */
|
|
|
|
|
struct pandecode_fbd {
|
|
|
|
|
unsigned rt_count;
|
|
|
|
|
bool has_extra;
|
|
|
|
|
};
|
|
|
|
|
|
2019-08-21 12:06:50 -07:00
|
|
|
static struct pandecode_fbd
|
2022-08-15 19:10:04 +00:00
|
|
|
pandecode_fbd(uint64_t gpu_va, bool is_fragment, unsigned gpu_id)
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
{
|
2022-08-15 19:10:04 +00:00
|
|
|
#if PAN_ARCH >= 5
|
|
|
|
|
/* We only see MFBDs on architectures that support them */
|
|
|
|
|
assert(gpu_va & MALI_FBD_TAG_IS_MFBD);
|
|
|
|
|
gpu_va &= ~MALI_FBD_TAG_MASK;
|
|
|
|
|
#endif
|
|
|
|
|
|
2022-08-15 18:35:45 +00:00
|
|
|
const void *PANDECODE_PTR_VAR(fb, (mali_ptr) gpu_va);
|
2021-07-29 17:19:39 +02:00
|
|
|
pan_section_unpack(fb, FRAMEBUFFER, PARAMETERS, params);
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2021-08-06 10:22:28 +02:00
|
|
|
#if PAN_ARCH >= 6
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_sample_locations(fb);
|
2021-04-22 11:08:49 +12:00
|
|
|
|
2021-07-29 17:19:39 +02:00
|
|
|
unsigned dcd_size = pan_size(DRAW);
|
2021-04-22 11:08:49 +12:00
|
|
|
|
2022-08-15 19:10:04 +00:00
|
|
|
if (params.pre_frame_0 != MALI_PRE_POST_FRAME_SHADER_MODE_NEVER) {
|
|
|
|
|
const void *PANDECODE_PTR_VAR(dcd, params.frame_shader_dcds + (0 * dcd_size));
|
2021-08-06 10:22:28 +02:00
|
|
|
pan_unpack(dcd, DRAW, draw);
|
|
|
|
|
pandecode_log("Pre frame 0:\n");
|
2022-08-15 18:49:04 +00:00
|
|
|
pandecode_dcd(&draw, MALI_JOB_TYPE_FRAGMENT, gpu_id);
|
2021-08-06 10:22:28 +02:00
|
|
|
}
|
2021-04-07 15:31:16 +02:00
|
|
|
|
2022-08-15 19:10:04 +00:00
|
|
|
if (params.pre_frame_1 != MALI_PRE_POST_FRAME_SHADER_MODE_NEVER) {
|
|
|
|
|
const void *PANDECODE_PTR_VAR(dcd, params.frame_shader_dcds + (1 * dcd_size));
|
2021-08-06 10:22:28 +02:00
|
|
|
pan_unpack(dcd, DRAW, draw);
|
|
|
|
|
pandecode_log("Pre frame 1:\n");
|
2022-08-15 18:49:04 +00:00
|
|
|
pandecode_dcd(&draw, MALI_JOB_TYPE_FRAGMENT, gpu_id);
|
2021-08-06 10:22:28 +02:00
|
|
|
}
|
2021-04-07 15:31:16 +02:00
|
|
|
|
2022-08-15 19:10:04 +00:00
|
|
|
if (params.post_frame != MALI_PRE_POST_FRAME_SHADER_MODE_NEVER) {
|
|
|
|
|
const void *PANDECODE_PTR_VAR(dcd, params.frame_shader_dcds + (2 * dcd_size));
|
2021-08-06 10:22:28 +02:00
|
|
|
pan_unpack(dcd, DRAW, draw);
|
|
|
|
|
pandecode_log("Post frame:\n");
|
2022-08-15 18:49:04 +00:00
|
|
|
pandecode_dcd(&draw, MALI_JOB_TYPE_FRAGMENT, gpu_id);
|
2021-04-07 15:31:16 +02:00
|
|
|
}
|
2022-08-15 18:55:17 +00:00
|
|
|
#else
|
2021-07-29 17:19:39 +02:00
|
|
|
DUMP_SECTION(FRAMEBUFFER, LOCAL_STORAGE, fb, "Local Storage:\n");
|
2019-08-21 12:06:50 -07:00
|
|
|
|
2021-07-29 17:19:39 +02:00
|
|
|
const void *t = pan_section_ptr(fb, FRAMEBUFFER, TILER);
|
|
|
|
|
const void *w = pan_section_ptr(fb, FRAMEBUFFER, TILER_WEIGHTS);
|
2021-08-06 10:22:28 +02:00
|
|
|
pandecode_midgard_tiler_descriptor(t, w);
|
|
|
|
|
#endif
|
2019-06-12 09:33:06 -07:00
|
|
|
|
2022-08-15 19:10:04 +00:00
|
|
|
pandecode_log("Framebuffer:\n");
|
2022-08-15 18:55:17 +00:00
|
|
|
pandecode_indent++;
|
|
|
|
|
|
|
|
|
|
DUMP_UNPACKED(FRAMEBUFFER_PARAMETERS, params, "Parameters:\n");
|
|
|
|
|
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
pandecode_indent--;
|
2020-09-08 10:17:40 +02:00
|
|
|
pandecode_log("\n");
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2022-08-15 19:10:04 +00:00
|
|
|
#if PAN_ARCH >= 5
|
2021-07-29 17:19:39 +02:00
|
|
|
gpu_va += pan_size(FRAMEBUFFER);
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2022-08-15 18:54:20 +00:00
|
|
|
if (params.has_zs_crc_extension) {
|
2022-08-15 18:35:45 +00:00
|
|
|
const struct mali_zs_crc_extension_packed *PANDECODE_PTR_VAR(zs_crc, (mali_ptr)gpu_va);
|
2020-09-08 10:17:40 +02:00
|
|
|
DUMP_CL(ZS_CRC_EXTENSION, zs_crc, "ZS CRC Extension:\n");
|
|
|
|
|
pandecode_log("\n");
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2021-07-28 11:03:13 +02:00
|
|
|
gpu_va += pan_size(ZS_CRC_EXTENSION);
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
}
|
|
|
|
|
|
2019-08-19 14:47:50 -07:00
|
|
|
if (is_fragment)
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_render_target(gpu_va, gpu_id, ¶ms);
|
2019-06-23 11:29:46 -07:00
|
|
|
|
2022-08-15 18:54:20 +00:00
|
|
|
return (struct pandecode_fbd) {
|
|
|
|
|
.rt_count = params.render_target_count,
|
|
|
|
|
.has_extra = params.has_zs_crc_extension
|
|
|
|
|
};
|
2022-08-15 19:10:04 +00:00
|
|
|
#else
|
|
|
|
|
/* Dummy unpack of the padding section to make sure all words are 0.
|
|
|
|
|
* No need to call print here since the section is supposed to be empty.
|
|
|
|
|
*/
|
|
|
|
|
pan_section_unpack(fb, FRAMEBUFFER, PADDING_1, padding1);
|
|
|
|
|
pan_section_unpack(fb, FRAMEBUFFER, PADDING_2, padding2);
|
|
|
|
|
|
|
|
|
|
return (struct pandecode_fbd) {
|
|
|
|
|
.rt_count = 1
|
|
|
|
|
};
|
2021-07-29 17:19:39 +02:00
|
|
|
#endif
|
2022-08-15 19:10:04 +00:00
|
|
|
}
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2021-11-18 18:17:01 -05:00
|
|
|
#if PAN_ARCH <= 7
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
static void
|
2022-08-15 18:49:04 +00:00
|
|
|
pandecode_attributes(mali_ptr addr, int count,
|
2022-08-15 18:35:45 +00:00
|
|
|
bool varying, enum mali_job_type job_type)
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
{
|
2020-08-14 16:03:12 -04:00
|
|
|
char *prefix = varying ? "Varying" : "Attribute";
|
2019-08-22 13:07:01 -07:00
|
|
|
assert(addr);
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2019-08-22 13:07:01 -07:00
|
|
|
if (!count) {
|
2022-08-15 18:38:56 +00:00
|
|
|
pandecode_log("// warn: No %s records\n", prefix);
|
2019-08-08 09:23:29 -07:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-14 16:03:12 -04:00
|
|
|
MAP_ADDR(ATTRIBUTE_BUFFER, addr, cl);
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
|
|
|
|
for (int i = 0; i < count; ++i) {
|
2021-07-28 11:03:13 +02:00
|
|
|
pan_unpack(cl + i * pan_size(ATTRIBUTE_BUFFER), ATTRIBUTE_BUFFER, temp);
|
2020-09-05 18:14:17 +02:00
|
|
|
DUMP_UNPACKED(ATTRIBUTE_BUFFER, temp, "%s:\n", prefix);
|
2019-08-21 14:57:23 -07:00
|
|
|
|
2020-12-11 07:58:41 +00:00
|
|
|
switch (temp.type) {
|
|
|
|
|
case MALI_ATTRIBUTE_TYPE_1D_NPOT_DIVISOR_WRITE_REDUCTION:
|
|
|
|
|
case MALI_ATTRIBUTE_TYPE_1D_NPOT_DIVISOR: {
|
2021-07-28 11:03:13 +02:00
|
|
|
pan_unpack(cl + (i + 1) * pan_size(ATTRIBUTE_BUFFER),
|
2020-12-11 07:57:23 +00:00
|
|
|
ATTRIBUTE_BUFFER_CONTINUATION_NPOT, temp2);
|
|
|
|
|
pan_print(pandecode_dump_stream, ATTRIBUTE_BUFFER_CONTINUATION_NPOT,
|
|
|
|
|
temp2, (pandecode_indent + 1) * 2);
|
2021-06-02 15:42:05 -04:00
|
|
|
i++;
|
2020-12-11 07:58:41 +00:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case MALI_ATTRIBUTE_TYPE_3D_LINEAR:
|
|
|
|
|
case MALI_ATTRIBUTE_TYPE_3D_INTERLEAVED: {
|
2021-07-28 11:03:13 +02:00
|
|
|
pan_unpack(cl + (i + 1) * pan_size(ATTRIBUTE_BUFFER_CONTINUATION_3D),
|
2020-12-11 07:58:41 +00:00
|
|
|
ATTRIBUTE_BUFFER_CONTINUATION_3D, temp2);
|
|
|
|
|
pan_print(pandecode_dump_stream, ATTRIBUTE_BUFFER_CONTINUATION_3D,
|
|
|
|
|
temp2, (pandecode_indent + 1) * 2);
|
2021-06-02 15:42:05 -04:00
|
|
|
i++;
|
2020-12-11 07:58:41 +00:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
default:
|
|
|
|
|
break;
|
2020-12-11 07:57:23 +00:00
|
|
|
}
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
}
|
2020-09-10 12:46:33 +02:00
|
|
|
pandecode_log("\n");
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
}
|
2021-11-18 18:17:01 -05:00
|
|
|
#endif
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2022-08-15 23:58:43 +00:00
|
|
|
#if PAN_ARCH >= 5
|
2019-05-04 21:57:01 +00:00
|
|
|
static mali_ptr
|
2022-08-15 23:58:43 +00:00
|
|
|
pandecode_blend(void *descs, int rt_no, mali_ptr frag_shader)
|
2019-05-04 21:57:01 +00:00
|
|
|
{
|
2021-07-28 11:03:13 +02:00
|
|
|
pan_unpack(descs + (rt_no * pan_size(BLEND)), BLEND, b);
|
2020-09-16 13:31:37 +02:00
|
|
|
DUMP_UNPACKED(BLEND, b, "Blend RT %d:\n", rt_no);
|
2022-08-15 23:58:43 +00:00
|
|
|
#if PAN_ARCH >= 6
|
2021-07-29 17:19:39 +02:00
|
|
|
if (b.internal.mode != MALI_BLEND_MODE_SHADER)
|
2019-06-19 09:31:16 -07:00
|
|
|
return 0;
|
|
|
|
|
|
2021-07-29 17:19:39 +02:00
|
|
|
return (frag_shader & 0xFFFFFFFF00000000ULL) | b.internal.shader.pc;
|
2022-08-15 23:58:43 +00:00
|
|
|
#else
|
2021-07-29 17:19:39 +02:00
|
|
|
return b.blend_shader ? (b.shader_pc & ~0xf) : 0;
|
2022-08-15 23:58:43 +00:00
|
|
|
#endif
|
2019-05-04 21:57:01 +00:00
|
|
|
}
|
2021-08-06 10:22:28 +02:00
|
|
|
#endif
|
2019-05-04 21:57:01 +00:00
|
|
|
|
2021-11-18 18:17:01 -05:00
|
|
|
#if PAN_ARCH <= 7
|
2021-06-02 15:42:05 -04:00
|
|
|
static unsigned
|
|
|
|
|
pandecode_attribute_meta(int count, mali_ptr attribute, bool varying)
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
{
|
2021-06-02 15:42:05 -04:00
|
|
|
unsigned max = 0;
|
|
|
|
|
|
2021-07-28 11:03:13 +02:00
|
|
|
for (int i = 0; i < count; ++i, attribute += pan_size(ATTRIBUTE)) {
|
2021-06-02 15:42:05 -04:00
|
|
|
MAP_ADDR(ATTRIBUTE, attribute, cl);
|
|
|
|
|
pan_unpack(cl, ATTRIBUTE, a);
|
|
|
|
|
DUMP_UNPACKED(ATTRIBUTE, a, "%s:\n", varying ? "Varying" : "Attribute");
|
|
|
|
|
max = MAX2(max, a.buffer_index);
|
|
|
|
|
}
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2020-09-10 12:46:33 +02:00
|
|
|
pandecode_log("\n");
|
2021-06-02 15:42:05 -04:00
|
|
|
return MIN2(max + 1, 256);
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* return bits [lo, hi) of word */
|
|
|
|
|
static u32
|
|
|
|
|
bits(u32 word, u32 lo, u32 hi)
|
|
|
|
|
{
|
|
|
|
|
if (hi - lo >= 32)
|
|
|
|
|
return word; // avoid undefined behavior with the shift
|
|
|
|
|
|
2021-07-14 12:47:30 +12:00
|
|
|
if (lo >= 32)
|
|
|
|
|
return 0;
|
|
|
|
|
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
return (word >> lo) & ((1 << (hi - lo)) - 1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2021-01-18 12:58:36 -05:00
|
|
|
pandecode_invocation(const void *i)
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
{
|
|
|
|
|
/* Decode invocation_count. See the comment before the definition of
|
|
|
|
|
* invocation_count for an explanation.
|
|
|
|
|
*/
|
2020-09-08 19:41:51 +02:00
|
|
|
pan_unpack(i, INVOCATION, invocation);
|
2019-08-16 16:22:38 -07:00
|
|
|
|
2020-08-26 13:04:17 -04:00
|
|
|
unsigned size_x = bits(invocation.invocations, 0, invocation.size_y_shift) + 1;
|
|
|
|
|
unsigned size_y = bits(invocation.invocations, invocation.size_y_shift, invocation.size_z_shift) + 1;
|
|
|
|
|
unsigned size_z = bits(invocation.invocations, invocation.size_z_shift, invocation.workgroups_x_shift) + 1;
|
2019-08-16 16:22:38 -07:00
|
|
|
|
2020-08-26 13:04:17 -04:00
|
|
|
unsigned groups_x = bits(invocation.invocations, invocation.workgroups_x_shift, invocation.workgroups_y_shift) + 1;
|
|
|
|
|
unsigned groups_y = bits(invocation.invocations, invocation.workgroups_y_shift, invocation.workgroups_z_shift) + 1;
|
|
|
|
|
unsigned groups_z = bits(invocation.invocations, invocation.workgroups_z_shift, 32) + 1;
|
2019-08-16 16:22:38 -07:00
|
|
|
|
2020-09-05 18:14:17 +02:00
|
|
|
pandecode_log("Invocation (%d, %d, %d) x (%d, %d, %d)\n",
|
|
|
|
|
size_x, size_y, size_z,
|
|
|
|
|
groups_x, groups_y, groups_z);
|
2021-01-18 12:58:36 -05:00
|
|
|
|
|
|
|
|
DUMP_UNPACKED(INVOCATION, invocation, "Invocation:\n")
|
2020-09-08 19:41:51 +02:00
|
|
|
}
|
2021-11-18 18:17:01 -05:00
|
|
|
#endif
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2020-09-08 19:41:51 +02:00
|
|
|
static void
|
|
|
|
|
pandecode_primitive(const void *p)
|
|
|
|
|
{
|
|
|
|
|
pan_unpack(p, PRIMITIVE, primitive);
|
2020-09-05 18:14:17 +02:00
|
|
|
DUMP_UNPACKED(PRIMITIVE, primitive, "Primitive:\n");
|
2019-08-21 16:06:23 -07:00
|
|
|
|
2022-03-17 13:23:52 -04:00
|
|
|
#if PAN_ARCH <= 7
|
2019-08-21 16:06:23 -07:00
|
|
|
/* Validate an index buffer is present if we need one. TODO: verify
|
|
|
|
|
* relationship between invocation_count and index_count */
|
|
|
|
|
|
2020-08-25 16:59:14 -04:00
|
|
|
if (primitive.indices) {
|
2019-08-21 16:06:23 -07:00
|
|
|
/* Grab the size */
|
2020-08-25 16:59:14 -04:00
|
|
|
unsigned size = (primitive.index_type == MALI_INDEX_TYPE_UINT32) ?
|
|
|
|
|
sizeof(uint32_t) : primitive.index_type;
|
2019-08-21 16:06:23 -07:00
|
|
|
|
|
|
|
|
/* Ensure we got a size, and if so, validate the index buffer
|
|
|
|
|
* is large enough to hold a full set of indices of the given
|
|
|
|
|
* size */
|
|
|
|
|
|
2020-08-25 16:59:14 -04:00
|
|
|
if (!size)
|
2022-08-15 18:38:56 +00:00
|
|
|
pandecode_log("// XXX: index size missing\n");
|
2019-08-21 16:06:23 -07:00
|
|
|
else
|
2020-08-25 16:59:14 -04:00
|
|
|
pandecode_validate_buffer(primitive.indices, primitive.index_count * size);
|
|
|
|
|
} else if (primitive.index_type)
|
2022-08-15 18:38:56 +00:00
|
|
|
pandecode_log("// XXX: unexpected index size\n");
|
2022-03-17 13:23:52 -04:00
|
|
|
#endif
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
}
|
|
|
|
|
|
2022-03-17 13:23:52 -04:00
|
|
|
static void
|
|
|
|
|
pandecode_primitive_size(const void *s, bool constant)
|
|
|
|
|
{
|
|
|
|
|
pan_unpack(s, PRIMITIVE_SIZE, ps);
|
|
|
|
|
if (ps.size_array == 0x0)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
DUMP_UNPACKED(PRIMITIVE_SIZE, ps, "Primitive Size:\n")
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#if PAN_ARCH <= 7
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
static void
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_uniform_buffers(mali_ptr pubufs, int ubufs_count)
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
{
|
2022-08-15 18:35:45 +00:00
|
|
|
uint64_t *PANDECODE_PTR_VAR(ubufs, pubufs);
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
|
|
|
|
for (int i = 0; i < ubufs_count; i++) {
|
2020-02-16 17:01:02 -05:00
|
|
|
mali_ptr addr = (ubufs[i] >> 10) << 2;
|
2021-03-05 13:21:19 +01:00
|
|
|
unsigned size = addr ? (((ubufs[i] & ((1 << 10) - 1)) + 1) * 16) : 0;
|
2019-08-19 15:16:01 -07:00
|
|
|
|
|
|
|
|
pandecode_validate_buffer(addr, size);
|
|
|
|
|
|
2020-02-16 17:01:02 -05:00
|
|
|
char *ptr = pointer_as_memory_reference(addr);
|
2019-08-21 11:46:06 -07:00
|
|
|
pandecode_log("ubuf_%d[%u] = %s;\n", i, size, ptr);
|
2019-08-19 15:16:01 -07:00
|
|
|
free(ptr);
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
}
|
|
|
|
|
|
2019-08-21 11:46:06 -07:00
|
|
|
pandecode_log("\n");
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
}
|
|
|
|
|
|
2019-08-22 11:30:13 -07:00
|
|
|
static void
|
|
|
|
|
pandecode_uniforms(mali_ptr uniforms, unsigned uniform_count)
|
|
|
|
|
{
|
|
|
|
|
pandecode_validate_buffer(uniforms, uniform_count * 16);
|
|
|
|
|
|
|
|
|
|
char *ptr = pointer_as_memory_reference(uniforms);
|
|
|
|
|
pandecode_log("vec4 uniforms[%u] = %s;\n", uniform_count, ptr);
|
|
|
|
|
free(ptr);
|
2020-09-10 12:46:33 +02:00
|
|
|
pandecode_log("\n");
|
2019-08-22 11:30:13 -07:00
|
|
|
}
|
2021-11-18 18:17:01 -05:00
|
|
|
#endif
|
2019-08-22 11:30:13 -07:00
|
|
|
|
2022-08-15 21:18:22 +00:00
|
|
|
static void
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_shader_disassemble(mali_ptr shader_ptr, int type, unsigned gpu_id)
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
{
|
2022-08-15 18:35:45 +00:00
|
|
|
uint8_t *PANDECODE_PTR_VAR(code, shader_ptr);
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
|
|
|
|
/* Compute maximum possible size */
|
2022-08-15 18:35:45 +00:00
|
|
|
struct pandecode_mapped_memory *mem = pandecode_find_mapped_gpu_mem_containing(shader_ptr);
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
size_t sz = mem->length - (shader_ptr - mem->gpu_va);
|
|
|
|
|
|
|
|
|
|
/* Print some boilerplate to clearly denote the assembly (which doesn't
|
|
|
|
|
* obey indentation rules), and actually do the disassembly! */
|
|
|
|
|
|
2020-01-23 10:14:35 +13:00
|
|
|
pandecode_log_cont("\n\n");
|
2019-05-18 18:58:56 +00:00
|
|
|
|
2021-11-18 18:17:01 -05:00
|
|
|
#if PAN_ARCH >= 9
|
|
|
|
|
disassemble_valhall(pandecode_dump_stream, (const uint64_t *) code, sz, true);
|
|
|
|
|
#elif PAN_ARCH >= 6 && PAN_ARCH <= 7
|
2022-01-15 11:48:32 -05:00
|
|
|
disassemble_bifrost(pandecode_dump_stream, code, sz, false);
|
2021-08-06 10:22:28 +02:00
|
|
|
#else
|
2022-08-15 21:18:22 +00:00
|
|
|
disassemble_midgard(pandecode_dump_stream, code, sz, gpu_id, true);
|
2021-08-06 10:22:28 +02:00
|
|
|
#endif
|
2019-05-18 18:58:56 +00:00
|
|
|
|
2022-08-15 21:18:22 +00:00
|
|
|
pandecode_log_cont("\n\n");
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
}
|
|
|
|
|
|
2022-01-13 17:32:35 -05:00
|
|
|
#if PAN_ARCH <= 7
|
2020-04-21 16:08:07 -04:00
|
|
|
static void
|
|
|
|
|
pandecode_texture_payload(mali_ptr payload,
|
2020-08-11 17:27:36 -04:00
|
|
|
enum mali_texture_dimension dim,
|
2020-04-21 16:08:07 -04:00
|
|
|
enum mali_texture_layout layout,
|
|
|
|
|
bool manual_stride,
|
|
|
|
|
uint8_t levels,
|
2020-12-02 11:10:04 +01:00
|
|
|
uint16_t nr_samples,
|
2022-08-15 18:35:45 +00:00
|
|
|
uint16_t array_size)
|
2020-04-21 16:08:07 -04:00
|
|
|
{
|
|
|
|
|
pandecode_log(".payload = {\n");
|
|
|
|
|
pandecode_indent++;
|
|
|
|
|
|
|
|
|
|
/* A bunch of bitmap pointers follow.
|
|
|
|
|
* We work out the correct number,
|
|
|
|
|
* based on the mipmap/cubemap
|
|
|
|
|
* properties, but dump extra
|
|
|
|
|
* possibilities to futureproof */
|
|
|
|
|
|
2020-11-18 15:22:59 +01:00
|
|
|
int bitmap_count = levels;
|
2020-04-21 16:08:07 -04:00
|
|
|
|
|
|
|
|
/* Miptree for each face */
|
2020-08-11 17:27:36 -04:00
|
|
|
if (dim == MALI_TEXTURE_DIMENSION_CUBE)
|
2020-04-21 16:08:07 -04:00
|
|
|
bitmap_count *= 6;
|
2020-06-30 16:21:30 -04:00
|
|
|
|
|
|
|
|
/* Array of layers */
|
2020-12-02 11:10:04 +01:00
|
|
|
bitmap_count *= nr_samples;
|
2020-04-21 16:08:07 -04:00
|
|
|
|
|
|
|
|
/* Array of textures */
|
2020-08-11 17:27:36 -04:00
|
|
|
bitmap_count *= array_size;
|
2020-04-21 16:08:07 -04:00
|
|
|
|
|
|
|
|
/* Stride for each element */
|
|
|
|
|
if (manual_stride)
|
|
|
|
|
bitmap_count *= 2;
|
|
|
|
|
|
2022-08-15 18:35:45 +00:00
|
|
|
mali_ptr *pointers_and_strides = pandecode_fetch_gpu_mem(payload,
|
|
|
|
|
sizeof(mali_ptr) * bitmap_count);
|
2020-04-21 16:08:07 -04:00
|
|
|
for (int i = 0; i < bitmap_count; ++i) {
|
|
|
|
|
/* How we dump depends if this is a stride or a pointer */
|
|
|
|
|
|
|
|
|
|
if (manual_stride && (i & 1)) {
|
|
|
|
|
/* signed 32-bit snuck in as a 64-bit pointer */
|
|
|
|
|
uint64_t stride_set = pointers_and_strides[i];
|
2022-04-27 11:31:39 -04:00
|
|
|
int32_t row_stride = stride_set;
|
2020-11-17 19:18:42 +01:00
|
|
|
int32_t surface_stride = stride_set >> 32;
|
2022-04-27 11:31:39 -04:00
|
|
|
pandecode_log("(mali_ptr) %d /* surface stride */ %d /* row stride */, \n",
|
|
|
|
|
surface_stride, row_stride);
|
2020-04-21 16:08:07 -04:00
|
|
|
} else {
|
|
|
|
|
char *a = pointer_as_memory_reference(pointers_and_strides[i]);
|
|
|
|
|
pandecode_log("%s, \n", a);
|
|
|
|
|
free(a);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pandecode_indent--;
|
|
|
|
|
pandecode_log("},\n");
|
|
|
|
|
}
|
2022-01-13 17:32:35 -05:00
|
|
|
#endif
|
2020-04-21 16:08:07 -04:00
|
|
|
|
2021-08-06 10:22:28 +02:00
|
|
|
#if PAN_ARCH <= 5
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
static void
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_texture(mali_ptr u, unsigned tex)
|
2019-08-20 14:48:55 -07:00
|
|
|
{
|
2022-08-15 18:35:45 +00:00
|
|
|
const uint8_t *cl = pandecode_fetch_gpu_mem(u, pan_size(TEXTURE));
|
2019-08-20 14:48:55 -07:00
|
|
|
|
2021-08-06 10:22:28 +02:00
|
|
|
pan_unpack(cl, TEXTURE, temp);
|
|
|
|
|
DUMP_UNPACKED(TEXTURE, temp, "Texture:\n")
|
2019-08-20 14:58:46 -07:00
|
|
|
|
2020-09-05 18:14:17 +02:00
|
|
|
pandecode_indent++;
|
2020-12-02 11:10:04 +01:00
|
|
|
unsigned nr_samples = temp.dimension == MALI_TEXTURE_DIMENSION_3D ?
|
|
|
|
|
1 : temp.sample_count;
|
2021-08-06 10:22:28 +02:00
|
|
|
pandecode_texture_payload(u + pan_size(TEXTURE),
|
2020-08-11 17:27:36 -04:00
|
|
|
temp.dimension, temp.texel_ordering, temp.manual_stride,
|
2022-08-15 18:35:45 +00:00
|
|
|
temp.levels, nr_samples, temp.array_size);
|
2020-09-05 18:14:17 +02:00
|
|
|
pandecode_indent--;
|
2019-08-20 14:48:55 -07:00
|
|
|
}
|
2021-08-06 10:22:28 +02:00
|
|
|
#else
|
2020-03-09 13:51:39 -04:00
|
|
|
static void
|
2022-08-15 23:58:43 +00:00
|
|
|
pandecode_texture(const void *cl, unsigned tex)
|
2020-03-09 13:51:39 -04:00
|
|
|
{
|
2021-08-06 10:22:28 +02:00
|
|
|
pan_unpack(cl, TEXTURE, temp);
|
|
|
|
|
DUMP_UNPACKED(TEXTURE, temp, "Texture:\n")
|
2020-03-09 13:51:39 -04:00
|
|
|
|
2022-01-13 17:32:35 -05:00
|
|
|
pandecode_indent++;
|
|
|
|
|
|
|
|
|
|
#if PAN_ARCH >= 9
|
2022-08-01 18:56:49 -04:00
|
|
|
int plane_count = temp.levels * temp.array_size;
|
|
|
|
|
|
|
|
|
|
/* Miptree for each face */
|
|
|
|
|
if (temp.dimension == MALI_TEXTURE_DIMENSION_CUBE)
|
|
|
|
|
plane_count *= 6;
|
|
|
|
|
|
|
|
|
|
for (unsigned i = 0; i < plane_count; ++i)
|
2022-02-02 17:13:20 -05:00
|
|
|
DUMP_ADDR(PLANE, temp.surfaces + i * pan_size(PLANE), "Plane %u:\n", i);
|
2022-01-13 17:32:35 -05:00
|
|
|
#else
|
2020-12-02 11:10:04 +01:00
|
|
|
unsigned nr_samples = temp.dimension == MALI_TEXTURE_DIMENSION_3D ?
|
|
|
|
|
1 : temp.sample_count;
|
2022-01-13 17:32:35 -05:00
|
|
|
|
2020-08-06 18:12:28 -04:00
|
|
|
pandecode_texture_payload(temp.surfaces, temp.dimension, temp.texel_ordering,
|
2022-08-15 18:35:45 +00:00
|
|
|
true, temp.levels, nr_samples, temp.array_size);
|
2022-01-13 17:32:35 -05:00
|
|
|
#endif
|
2020-09-05 18:14:17 +02:00
|
|
|
pandecode_indent--;
|
2020-03-09 13:51:39 -04:00
|
|
|
}
|
2021-08-06 10:22:28 +02:00
|
|
|
#endif
|
2020-03-09 13:51:39 -04:00
|
|
|
|
2021-11-18 18:17:01 -05:00
|
|
|
#if PAN_ARCH <= 7
|
2020-03-09 13:51:39 -04:00
|
|
|
static void
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_textures(mali_ptr textures, unsigned texture_count)
|
2020-03-09 13:51:39 -04:00
|
|
|
{
|
2022-08-15 18:35:45 +00:00
|
|
|
if (!textures)
|
2020-03-09 13:51:39 -04:00
|
|
|
return;
|
|
|
|
|
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_log("Textures %"PRIx64":\n", textures);
|
2020-09-10 12:46:33 +02:00
|
|
|
pandecode_indent++;
|
2020-03-09 13:51:39 -04:00
|
|
|
|
2021-08-06 10:22:28 +02:00
|
|
|
#if PAN_ARCH >= 6
|
2022-08-15 18:35:45 +00:00
|
|
|
const void *cl = pandecode_fetch_gpu_mem(textures, pan_size(TEXTURE) *
|
|
|
|
|
texture_count);
|
2020-03-09 13:51:39 -04:00
|
|
|
|
2022-08-15 18:45:28 +00:00
|
|
|
for (unsigned tex = 0; tex < texture_count; ++tex)
|
2022-08-15 23:58:43 +00:00
|
|
|
pandecode_texture(cl + pan_size(TEXTURE) * tex, tex);
|
2021-08-06 10:22:28 +02:00
|
|
|
#else
|
2022-08-15 18:35:45 +00:00
|
|
|
mali_ptr *PANDECODE_PTR_VAR(u, textures);
|
2021-08-06 10:22:28 +02:00
|
|
|
|
|
|
|
|
for (int tex = 0; tex < texture_count; ++tex) {
|
2022-08-15 18:35:45 +00:00
|
|
|
mali_ptr *PANDECODE_PTR_VAR(u, textures + tex * sizeof(mali_ptr));
|
2021-08-06 10:22:28 +02:00
|
|
|
char *a = pointer_as_memory_reference(*u);
|
|
|
|
|
pandecode_log("%s,\n", a);
|
|
|
|
|
free(a);
|
|
|
|
|
}
|
2020-03-09 13:51:39 -04:00
|
|
|
|
2021-08-06 10:22:28 +02:00
|
|
|
/* Now, finally, descend down into the texture descriptor */
|
|
|
|
|
for (unsigned tex = 0; tex < texture_count; ++tex) {
|
2022-08-15 18:35:45 +00:00
|
|
|
mali_ptr *PANDECODE_PTR_VAR(u, textures + tex * sizeof(mali_ptr));
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_texture(*u, tex);
|
2020-03-09 13:51:39 -04:00
|
|
|
}
|
2021-08-06 10:22:28 +02:00
|
|
|
#endif
|
2020-09-10 12:46:33 +02:00
|
|
|
pandecode_indent--;
|
|
|
|
|
pandecode_log("\n");
|
2020-03-09 13:51:39 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_samplers(mali_ptr samplers, unsigned sampler_count)
|
2020-03-09 13:51:39 -04:00
|
|
|
{
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_log("Samplers %"PRIx64":\n", samplers);
|
2020-09-10 12:46:33 +02:00
|
|
|
pandecode_indent++;
|
|
|
|
|
|
2021-08-06 10:22:28 +02:00
|
|
|
for (int i = 0; i < sampler_count; ++i)
|
|
|
|
|
DUMP_ADDR(SAMPLER, samplers + (pan_size(SAMPLER) * i), "Sampler %d:\n", i);
|
2020-09-10 12:46:33 +02:00
|
|
|
|
|
|
|
|
pandecode_indent--;
|
|
|
|
|
pandecode_log("\n");
|
2020-03-09 13:51:39 -04:00
|
|
|
}
|
|
|
|
|
|
2019-08-20 14:48:55 -07:00
|
|
|
static void
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_dcd(const struct MALI_DRAW *p, enum mali_job_type job_type,
|
2022-08-15 18:49:04 +00:00
|
|
|
unsigned gpu_id)
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
{
|
2021-07-29 17:19:39 +02:00
|
|
|
#if PAN_ARCH >= 5
|
2019-08-21 12:06:50 -07:00
|
|
|
struct pandecode_fbd fbd_info = {
|
|
|
|
|
.rt_count = 1
|
|
|
|
|
};
|
2021-07-29 17:19:39 +02:00
|
|
|
#endif
|
2019-08-21 12:06:50 -07:00
|
|
|
|
2022-08-15 19:10:04 +00:00
|
|
|
if (PAN_ARCH >= 6 || (PAN_ARCH == 5 && job_type != MALI_JOB_TYPE_TILER)) {
|
|
|
|
|
#if PAN_ARCH >= 5
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_local_storage(p->thread_storage & ~1);
|
2022-08-15 19:10:04 +00:00
|
|
|
#endif
|
2021-07-29 17:19:39 +02:00
|
|
|
} else {
|
2022-08-15 19:10:04 +00:00
|
|
|
#if PAN_ARCH <= 5
|
|
|
|
|
pandecode_fbd(p->fbd, false, gpu_id);
|
2021-08-06 10:22:28 +02:00
|
|
|
#endif
|
2022-08-15 19:10:04 +00:00
|
|
|
}
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
|
|
|
|
int varying_count = 0, attribute_count = 0, uniform_count = 0, uniform_buffer_count = 0;
|
|
|
|
|
int texture_count = 0, sampler_count = 0;
|
|
|
|
|
|
2020-08-26 17:05:41 -04:00
|
|
|
if (p->state) {
|
2022-08-15 18:35:45 +00:00
|
|
|
uint32_t *cl = pandecode_fetch_gpu_mem(p->state, pan_size(RENDERER_STATE));
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2020-09-29 15:47:04 +02:00
|
|
|
pan_unpack(cl, RENDERER_STATE, state);
|
2020-08-21 10:34:06 -04:00
|
|
|
|
2020-08-21 19:59:22 -04:00
|
|
|
if (state.shader.shader & ~0xF)
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_shader_disassemble(state.shader.shader & ~0xF, job_type, gpu_id);
|
2021-08-06 10:22:28 +02:00
|
|
|
|
|
|
|
|
#if PAN_ARCH >= 6
|
|
|
|
|
bool idvs = (job_type == MALI_JOB_TYPE_INDEXED_VERTEX);
|
2020-08-21 10:34:06 -04:00
|
|
|
|
2021-06-22 11:16:37 -04:00
|
|
|
if (idvs && state.secondary_shader)
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_shader_disassemble(state.secondary_shader, job_type, gpu_id);
|
2021-08-06 10:22:28 +02:00
|
|
|
#endif
|
2020-09-29 15:47:04 +02:00
|
|
|
DUMP_UNPACKED(RENDERER_STATE, state, "State:\n");
|
2020-09-05 18:14:17 +02:00
|
|
|
pandecode_indent++;
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
|
|
|
|
/* Save for dumps */
|
2020-08-21 19:59:22 -04:00
|
|
|
attribute_count = state.shader.attribute_count;
|
|
|
|
|
varying_count = state.shader.varying_count;
|
|
|
|
|
texture_count = state.shader.texture_count;
|
|
|
|
|
sampler_count = state.shader.sampler_count;
|
2020-09-15 17:03:28 +02:00
|
|
|
uniform_buffer_count = state.properties.uniform_buffer_count;
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2021-08-06 10:22:28 +02:00
|
|
|
#if PAN_ARCH >= 6
|
|
|
|
|
uniform_count = state.preload.uniform_count;
|
|
|
|
|
#else
|
2021-07-29 17:19:39 +02:00
|
|
|
uniform_count = state.properties.uniform_count;
|
2021-08-06 10:22:28 +02:00
|
|
|
#endif
|
|
|
|
|
|
2022-01-15 11:46:12 -05:00
|
|
|
#if PAN_ARCH == 4
|
2021-07-29 17:19:39 +02:00
|
|
|
mali_ptr shader = state.blend_shader & ~0xF;
|
|
|
|
|
if (state.multisample_misc.blend_shader && shader)
|
2022-08-15 21:18:22 +00:00
|
|
|
pandecode_shader_disassemble(shader, job_type, gpu_id);
|
2021-08-06 10:22:28 +02:00
|
|
|
#endif
|
2020-09-05 18:14:17 +02:00
|
|
|
pandecode_indent--;
|
2020-09-10 12:46:33 +02:00
|
|
|
pandecode_log("\n");
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2019-05-04 21:57:01 +00:00
|
|
|
/* MRT blend fields are used whenever MFBD is used, with
|
|
|
|
|
* per-RT descriptors */
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2021-07-29 17:19:39 +02:00
|
|
|
#if PAN_ARCH >= 5
|
2021-04-07 15:31:16 +02:00
|
|
|
if ((job_type == MALI_JOB_TYPE_TILER || job_type == MALI_JOB_TYPE_FRAGMENT) &&
|
2021-08-06 10:22:28 +02:00
|
|
|
(PAN_ARCH >= 6 || p->thread_storage & MALI_FBD_TAG_IS_MFBD)) {
|
2021-07-28 11:03:13 +02:00
|
|
|
void* blend_base = ((void *) cl) + pan_size(RENDERER_STATE);
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2019-08-21 12:06:50 -07:00
|
|
|
for (unsigned i = 0; i < fbd_info.rt_count; i++) {
|
2022-08-15 23:58:43 +00:00
|
|
|
mali_ptr shader =
|
|
|
|
|
pandecode_blend(blend_base, i,
|
|
|
|
|
state.shader.shader);
|
2019-11-05 15:31:42 +01:00
|
|
|
if (shader & ~0xF)
|
2022-08-15 21:18:22 +00:00
|
|
|
pandecode_shader_disassemble(shader, job_type,
|
2021-08-06 10:22:28 +02:00
|
|
|
gpu_id);
|
2019-05-04 21:57:01 +00:00
|
|
|
}
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
}
|
2021-07-29 17:19:39 +02:00
|
|
|
#endif
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
} else
|
2022-08-15 18:38:56 +00:00
|
|
|
pandecode_log("// XXX: missing shader descriptor\n");
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2020-09-10 12:46:33 +02:00
|
|
|
if (p->viewport) {
|
2020-09-09 17:56:53 +02:00
|
|
|
DUMP_ADDR(VIEWPORT, p->viewport, "Viewport:\n");
|
2020-09-10 12:46:33 +02:00
|
|
|
pandecode_log("\n");
|
|
|
|
|
}
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2019-08-22 13:07:01 -07:00
|
|
|
unsigned max_attr_index = 0;
|
|
|
|
|
|
2020-08-26 17:05:41 -04:00
|
|
|
if (p->attributes)
|
2021-06-02 15:42:05 -04:00
|
|
|
max_attr_index = pandecode_attribute_meta(attribute_count, p->attributes, false);
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2022-08-15 18:35:45 +00:00
|
|
|
if (p->attribute_buffers)
|
2022-08-15 18:49:04 +00:00
|
|
|
pandecode_attributes(p->attribute_buffers, max_attr_index, false, job_type);
|
2019-07-31 11:52:52 -07:00
|
|
|
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
if (p->varyings) {
|
2021-06-02 15:42:05 -04:00
|
|
|
varying_count = pandecode_attribute_meta(varying_count, p->varyings, true);
|
2020-08-26 17:05:41 -04:00
|
|
|
}
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2022-08-15 18:35:45 +00:00
|
|
|
if (p->varying_buffers)
|
2022-08-15 18:49:04 +00:00
|
|
|
pandecode_attributes(p->varying_buffers, varying_count, true, job_type);
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
|
|
|
|
if (p->uniform_buffers) {
|
2019-08-19 15:16:01 -07:00
|
|
|
if (uniform_buffer_count)
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_uniform_buffers(p->uniform_buffers, uniform_buffer_count);
|
2019-08-19 15:16:01 -07:00
|
|
|
else
|
2022-08-15 18:38:56 +00:00
|
|
|
pandecode_log("// warn: UBOs specified but not referenced\n");
|
2019-08-19 15:16:01 -07:00
|
|
|
} else if (uniform_buffer_count)
|
2022-08-15 18:38:56 +00:00
|
|
|
pandecode_log("// XXX: UBOs referenced but not specified\n");
|
2019-08-19 15:16:01 -07:00
|
|
|
|
|
|
|
|
/* We don't want to actually dump uniforms, but we do need to validate
|
|
|
|
|
* that the counts we were given are sane */
|
|
|
|
|
|
2020-08-26 17:05:41 -04:00
|
|
|
if (p->push_uniforms) {
|
2019-08-19 15:16:01 -07:00
|
|
|
if (uniform_count)
|
2020-08-26 17:05:41 -04:00
|
|
|
pandecode_uniforms(p->push_uniforms, uniform_count);
|
2019-08-19 15:16:01 -07:00
|
|
|
else
|
2022-08-15 18:38:56 +00:00
|
|
|
pandecode_log("// warn: Uniforms specified but not referenced\n");
|
2019-08-19 15:16:01 -07:00
|
|
|
} else if (uniform_count)
|
2022-08-15 18:38:56 +00:00
|
|
|
pandecode_log("// XXX: Uniforms referenced but not specified\n");
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2020-03-09 13:51:39 -04:00
|
|
|
if (p->textures)
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_textures(p->textures, texture_count);
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2020-08-26 17:05:41 -04:00
|
|
|
if (p->samplers)
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_samplers(p->samplers, sampler_count);
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
}
|
|
|
|
|
|
2020-09-08 19:41:51 +02:00
|
|
|
static void
|
|
|
|
|
pandecode_vertex_compute_geometry_job(const struct MALI_JOB_HEADER *h,
|
2022-08-15 18:45:28 +00:00
|
|
|
mali_ptr job, unsigned gpu_id)
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
{
|
2022-08-15 18:35:45 +00:00
|
|
|
struct mali_compute_job_packed *PANDECODE_PTR_VAR(p, job);
|
2020-09-08 19:41:51 +02:00
|
|
|
pan_section_unpack(p, COMPUTE_JOB, DRAW, draw);
|
2022-08-15 18:49:04 +00:00
|
|
|
pandecode_dcd(&draw, h->type, gpu_id);
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2020-09-08 19:41:51 +02:00
|
|
|
pandecode_log("Vertex Job Payload:\n");
|
|
|
|
|
pandecode_indent++;
|
2021-01-18 12:58:36 -05:00
|
|
|
pandecode_invocation(pan_section_ptr(p, COMPUTE_JOB, INVOCATION));
|
2020-09-08 19:41:51 +02:00
|
|
|
DUMP_SECTION(COMPUTE_JOB, PARAMETERS, p, "Vertex Job Parameters:\n");
|
|
|
|
|
DUMP_UNPACKED(DRAW, draw, "Draw:\n");
|
|
|
|
|
pandecode_indent--;
|
|
|
|
|
pandecode_log("\n");
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
}
|
2021-11-18 18:17:01 -05:00
|
|
|
#endif
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2021-08-06 10:22:28 +02:00
|
|
|
#if PAN_ARCH >= 6
|
|
|
|
|
static void
|
2022-08-15 23:58:43 +00:00
|
|
|
pandecode_tiler(mali_ptr gpu_va)
|
2021-08-06 10:22:28 +02:00
|
|
|
{
|
2022-08-15 18:35:45 +00:00
|
|
|
pan_unpack(PANDECODE_PTR(gpu_va, void), TILER_CONTEXT, t);
|
2021-08-06 10:22:28 +02:00
|
|
|
|
2022-08-15 23:58:43 +00:00
|
|
|
if (t.heap) {
|
|
|
|
|
pan_unpack(PANDECODE_PTR(t.heap, void), TILER_HEAP, h);
|
|
|
|
|
DUMP_UNPACKED(TILER_HEAP, h, "Tiler Heap:\n");
|
|
|
|
|
}
|
2021-08-06 10:22:28 +02:00
|
|
|
|
2022-08-15 23:58:43 +00:00
|
|
|
DUMP_UNPACKED(TILER_CONTEXT, t, "Tiler:\n");
|
2021-08-06 10:22:28 +02:00
|
|
|
}
|
|
|
|
|
|
2021-11-18 18:17:01 -05:00
|
|
|
#if PAN_ARCH <= 7
|
2021-06-22 11:16:37 -04:00
|
|
|
static void
|
|
|
|
|
pandecode_indexed_vertex_job(const struct MALI_JOB_HEADER *h,
|
2022-08-15 18:45:28 +00:00
|
|
|
mali_ptr job, unsigned gpu_id)
|
2021-06-22 11:16:37 -04:00
|
|
|
{
|
2022-08-15 18:35:45 +00:00
|
|
|
struct mali_indexed_vertex_job_packed *PANDECODE_PTR_VAR(p, job);
|
2021-06-22 11:16:37 -04:00
|
|
|
|
|
|
|
|
pandecode_log("Vertex:\n");
|
2021-07-29 17:19:39 +02:00
|
|
|
pan_section_unpack(p, INDEXED_VERTEX_JOB, VERTEX_DRAW, vert_draw);
|
2022-08-15 18:49:04 +00:00
|
|
|
pandecode_dcd(&vert_draw, h->type, gpu_id);
|
2021-06-22 11:16:37 -04:00
|
|
|
DUMP_UNPACKED(DRAW, vert_draw, "Vertex Draw:\n");
|
|
|
|
|
|
|
|
|
|
pandecode_log("Fragment:\n");
|
2021-07-29 17:19:39 +02:00
|
|
|
pan_section_unpack(p, INDEXED_VERTEX_JOB, FRAGMENT_DRAW, frag_draw);
|
2022-08-15 18:49:04 +00:00
|
|
|
pandecode_dcd(&frag_draw, MALI_JOB_TYPE_FRAGMENT, gpu_id);
|
2021-06-22 11:16:37 -04:00
|
|
|
DUMP_UNPACKED(DRAW, frag_draw, "Fragment Draw:\n");
|
|
|
|
|
|
2021-07-29 17:19:39 +02:00
|
|
|
pan_section_unpack(p, INDEXED_VERTEX_JOB, TILER, tiler_ptr);
|
2021-06-22 11:16:37 -04:00
|
|
|
pandecode_log("Tiler Job Payload:\n");
|
|
|
|
|
pandecode_indent++;
|
2022-08-15 23:58:43 +00:00
|
|
|
pandecode_tiler(tiler_ptr.address);
|
2021-06-22 11:16:37 -04:00
|
|
|
pandecode_indent--;
|
|
|
|
|
|
2021-07-29 17:19:39 +02:00
|
|
|
pandecode_invocation(pan_section_ptr(p, INDEXED_VERTEX_JOB, INVOCATION));
|
|
|
|
|
pandecode_primitive(pan_section_ptr(p, INDEXED_VERTEX_JOB, PRIMITIVE));
|
2021-06-22 11:16:37 -04:00
|
|
|
|
|
|
|
|
/* TODO: gl_PointSize on Bifrost */
|
2021-07-29 17:19:39 +02:00
|
|
|
pandecode_primitive_size(pan_section_ptr(p, INDEXED_VERTEX_JOB, PRIMITIVE_SIZE), true);
|
2021-06-22 11:16:37 -04:00
|
|
|
|
2021-07-29 17:19:39 +02:00
|
|
|
pan_section_unpack(p, INDEXED_VERTEX_JOB, PADDING, padding);
|
2021-06-22 11:16:37 -04:00
|
|
|
}
|
2022-03-17 15:34:25 -04:00
|
|
|
#endif
|
|
|
|
|
#endif
|
2021-06-22 11:16:37 -04:00
|
|
|
|
2020-09-08 19:41:51 +02:00
|
|
|
static void
|
2022-03-17 15:34:25 -04:00
|
|
|
pandecode_tiler_job(const struct MALI_JOB_HEADER *h,
|
2022-08-15 18:45:28 +00:00
|
|
|
mali_ptr job, unsigned gpu_id)
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
{
|
2022-08-15 18:35:45 +00:00
|
|
|
struct mali_tiler_job_packed *PANDECODE_PTR_VAR(p, job);
|
2021-08-06 10:22:28 +02:00
|
|
|
pan_section_unpack(p, TILER_JOB, DRAW, draw);
|
2022-08-15 18:49:04 +00:00
|
|
|
pandecode_dcd(&draw, h->type, gpu_id);
|
2020-09-08 19:41:51 +02:00
|
|
|
pandecode_log("Tiler Job Payload:\n");
|
|
|
|
|
pandecode_indent++;
|
2022-03-17 13:23:52 -04:00
|
|
|
|
|
|
|
|
#if PAN_ARCH <= 7
|
2021-08-06 10:22:28 +02:00
|
|
|
pandecode_invocation(pan_section_ptr(p, TILER_JOB, INVOCATION));
|
2022-03-17 13:23:52 -04:00
|
|
|
#endif
|
|
|
|
|
|
2021-08-06 10:22:28 +02:00
|
|
|
pandecode_primitive(pan_section_ptr(p, TILER_JOB, PRIMITIVE));
|
2022-03-17 15:34:25 -04:00
|
|
|
DUMP_UNPACKED(DRAW, draw, "Draw:\n");
|
|
|
|
|
|
|
|
|
|
#if PAN_ARCH >= 6
|
|
|
|
|
pan_section_unpack(p, TILER_JOB, TILER, tiler_ptr);
|
2022-08-15 23:58:43 +00:00
|
|
|
pandecode_tiler(tiler_ptr.address);
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2020-09-08 19:41:51 +02:00
|
|
|
/* TODO: gl_PointSize on Bifrost */
|
2021-08-06 10:22:28 +02:00
|
|
|
pandecode_primitive_size(pan_section_ptr(p, TILER_JOB, PRIMITIVE_SIZE), true);
|
2022-03-17 13:23:52 -04:00
|
|
|
|
|
|
|
|
#if PAN_ARCH >= 9
|
|
|
|
|
DUMP_SECTION(TILER_JOB, INSTANCE_COUNT, p, "Instance count:\n");
|
|
|
|
|
DUMP_SECTION(TILER_JOB, VERTEX_COUNT, p, "Vertex count:\n");
|
|
|
|
|
DUMP_SECTION(TILER_JOB, SCISSOR, p, "Scissor:\n");
|
|
|
|
|
DUMP_SECTION(TILER_JOB, INDICES, p, "Indices:\n");
|
|
|
|
|
#else
|
2021-08-06 10:22:28 +02:00
|
|
|
pan_section_unpack(p, TILER_JOB, PADDING, padding);
|
2022-03-17 13:23:52 -04:00
|
|
|
#endif
|
|
|
|
|
|
2021-08-06 10:22:28 +02:00
|
|
|
#else
|
|
|
|
|
pan_section_unpack(p, TILER_JOB, PRIMITIVE, primitive);
|
|
|
|
|
pandecode_primitive_size(pan_section_ptr(p, TILER_JOB, PRIMITIVE_SIZE),
|
2020-09-29 11:21:33 +02:00
|
|
|
primitive.point_size_array_format == MALI_POINT_SIZE_ARRAY_FORMAT_NONE);
|
2022-03-17 15:34:25 -04:00
|
|
|
#endif
|
2020-09-08 19:41:51 +02:00
|
|
|
pandecode_indent--;
|
|
|
|
|
pandecode_log("\n");
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
}
|
|
|
|
|
|
2020-09-08 12:43:48 +02:00
|
|
|
static void
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_fragment_job(mali_ptr job, unsigned gpu_id)
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
{
|
2022-08-15 18:35:45 +00:00
|
|
|
struct mali_fragment_job_packed *PANDECODE_PTR_VAR(p, job);
|
2020-09-08 12:43:48 +02:00
|
|
|
pan_section_unpack(p, FRAGMENT_JOB, PAYLOAD, s);
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2022-08-15 19:10:04 +00:00
|
|
|
UNUSED struct pandecode_fbd info = pandecode_fbd(s.framebuffer, true, gpu_id);
|
2019-08-21 12:06:50 -07:00
|
|
|
|
2021-07-29 17:19:39 +02:00
|
|
|
#if PAN_ARCH >= 5
|
|
|
|
|
unsigned expected_tag = 0;
|
|
|
|
|
|
2019-08-21 12:06:50 -07:00
|
|
|
/* Compute the tag for the tagged pointer. This contains the type of
|
|
|
|
|
* FBD (MFBD/SFBD), and in the case of an MFBD, information about which
|
|
|
|
|
* additional structures follow the MFBD header (an extra payload or
|
|
|
|
|
* not, as well as a count of render targets) */
|
|
|
|
|
|
2021-07-29 17:19:39 +02:00
|
|
|
expected_tag = MALI_FBD_TAG_IS_MFBD;
|
|
|
|
|
if (info.has_extra)
|
|
|
|
|
expected_tag |= MALI_FBD_TAG_HAS_ZS_RT;
|
2019-08-21 12:06:50 -07:00
|
|
|
|
2021-07-29 17:19:39 +02:00
|
|
|
expected_tag |= MALI_FBD_TAG_IS_MFBD | (MALI_POSITIVE(info.rt_count) << 2);
|
|
|
|
|
#endif
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2020-09-22 17:22:12 -07:00
|
|
|
DUMP_UNPACKED(FRAGMENT_JOB_PAYLOAD, s, "Fragment Job Payload:\n");
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2021-07-29 17:19:39 +02:00
|
|
|
#if PAN_ARCH >= 5
|
2019-08-21 12:06:50 -07:00
|
|
|
/* The FBD is a tagged pointer */
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2020-09-08 12:43:48 +02:00
|
|
|
unsigned tag = (s.framebuffer & MALI_FBD_TAG_MASK);
|
2019-08-12 11:07:00 -07:00
|
|
|
|
2019-08-21 12:06:50 -07:00
|
|
|
if (tag != expected_tag)
|
2022-08-15 18:38:56 +00:00
|
|
|
pandecode_log("// XXX: expected FBD tag %X but got %X\n", expected_tag, tag);
|
2021-07-29 17:19:39 +02:00
|
|
|
#endif
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2020-09-08 12:43:48 +02:00
|
|
|
pandecode_log("\n");
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
}
|
|
|
|
|
|
2020-09-08 10:39:23 +02:00
|
|
|
static void
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_write_value_job(mali_ptr job)
|
2020-09-08 10:39:23 +02:00
|
|
|
{
|
2022-08-15 18:35:45 +00:00
|
|
|
struct mali_write_value_job_packed *PANDECODE_PTR_VAR(p, job);
|
2020-09-08 10:39:23 +02:00
|
|
|
pan_section_unpack(p, WRITE_VALUE_JOB, PAYLOAD, u);
|
|
|
|
|
DUMP_SECTION(WRITE_VALUE_JOB, PAYLOAD, p, "Write Value Payload:\n");
|
|
|
|
|
pandecode_log("\n");
|
|
|
|
|
}
|
|
|
|
|
|
2021-06-09 16:43:29 -04:00
|
|
|
static void
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_cache_flush_job(mali_ptr job)
|
2021-06-09 16:43:29 -04:00
|
|
|
{
|
2022-08-15 18:35:45 +00:00
|
|
|
struct mali_cache_flush_job_packed *PANDECODE_PTR_VAR(p, job);
|
2021-06-09 16:43:29 -04:00
|
|
|
pan_section_unpack(p, CACHE_FLUSH_JOB, PAYLOAD, u);
|
|
|
|
|
DUMP_SECTION(CACHE_FLUSH_JOB, PAYLOAD, p, "Cache Flush Payload:\n");
|
|
|
|
|
pandecode_log("\n");
|
|
|
|
|
}
|
|
|
|
|
|
2021-11-18 18:17:01 -05:00
|
|
|
#if PAN_ARCH >= 9
|
|
|
|
|
static void
|
|
|
|
|
dump_fau(mali_ptr addr, unsigned count, const char *name)
|
|
|
|
|
{
|
2022-08-15 18:35:45 +00:00
|
|
|
const uint32_t *PANDECODE_PTR_VAR(raw, addr);
|
2021-11-18 18:17:01 -05:00
|
|
|
|
|
|
|
|
pandecode_validate_buffer(addr, count * 8);
|
|
|
|
|
|
|
|
|
|
fprintf(pandecode_dump_stream, "%s:\n", name);
|
|
|
|
|
for (unsigned i = 0; i < count; ++i) {
|
|
|
|
|
fprintf(pandecode_dump_stream, " %08X %08X\n",
|
|
|
|
|
raw[2*i], raw[2*i + 1]);
|
|
|
|
|
}
|
|
|
|
|
fprintf(pandecode_dump_stream, "\n");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static mali_ptr
|
|
|
|
|
pandecode_shader(mali_ptr addr, const char *label, unsigned gpu_id)
|
|
|
|
|
{
|
|
|
|
|
MAP_ADDR(SHADER_PROGRAM, addr, cl);
|
|
|
|
|
pan_unpack(cl, SHADER_PROGRAM, desc);
|
|
|
|
|
|
|
|
|
|
assert(desc.type == 8);
|
|
|
|
|
|
|
|
|
|
DUMP_UNPACKED(SHADER_PROGRAM, desc, "%s Shader:\n", label);
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_shader_disassemble(desc.binary, 0, gpu_id);
|
2021-11-18 18:17:01 -05:00
|
|
|
return desc.binary;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
pandecode_resources(mali_ptr addr, unsigned size)
|
|
|
|
|
{
|
2022-08-15 18:35:45 +00:00
|
|
|
const uint8_t *cl = pandecode_fetch_gpu_mem(addr, size);
|
2021-11-18 18:17:01 -05:00
|
|
|
assert((size % 0x20) == 0);
|
|
|
|
|
|
|
|
|
|
for (unsigned i = 0; i < size; i += 0x20) {
|
|
|
|
|
unsigned type = (cl[i] & 0xF);
|
|
|
|
|
|
|
|
|
|
switch (type) {
|
|
|
|
|
case MALI_DESCRIPTOR_TYPE_SAMPLER:
|
|
|
|
|
DUMP_CL(SAMPLER, cl + i, "Sampler:\n");
|
|
|
|
|
break;
|
|
|
|
|
case MALI_DESCRIPTOR_TYPE_TEXTURE:
|
2022-08-15 23:58:43 +00:00
|
|
|
pandecode_texture(cl + i, i);
|
2021-11-18 18:17:01 -05:00
|
|
|
break;
|
|
|
|
|
case MALI_DESCRIPTOR_TYPE_ATTRIBUTE:
|
|
|
|
|
DUMP_CL(ATTRIBUTE, cl + i, "Attribute:\n");
|
|
|
|
|
break;
|
|
|
|
|
case MALI_DESCRIPTOR_TYPE_BUFFER:
|
|
|
|
|
DUMP_CL(BUFFER, cl + i, "Buffer:\n");
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
fprintf(pandecode_dump_stream, "Unknown descriptor type %X\n", type);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
pandecode_resource_tables(mali_ptr addr, const char *label)
|
|
|
|
|
{
|
2022-07-07 12:26:03 +12:00
|
|
|
unsigned count = addr & 0x3F;
|
|
|
|
|
addr = addr & ~0x3F;
|
2021-11-18 18:17:01 -05:00
|
|
|
|
2022-08-15 18:35:45 +00:00
|
|
|
const uint8_t *cl = pandecode_fetch_gpu_mem(addr, MALI_RESOURCE_LENGTH * count);
|
2021-11-18 18:17:01 -05:00
|
|
|
|
|
|
|
|
for (unsigned i = 0; i < count; ++i) {
|
|
|
|
|
pan_unpack(cl + i * MALI_RESOURCE_LENGTH, RESOURCE, entry);
|
|
|
|
|
DUMP_UNPACKED(RESOURCE, entry, "Entry %u:\n", i);
|
|
|
|
|
|
2022-07-07 12:27:50 +12:00
|
|
|
pandecode_indent += 2;
|
2021-11-18 18:17:01 -05:00
|
|
|
if (entry.address)
|
|
|
|
|
pandecode_resources(entry.address, entry.size);
|
2022-07-07 12:27:50 +12:00
|
|
|
pandecode_indent -= 2;
|
2021-11-18 18:17:01 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
pandecode_depth_stencil(mali_ptr addr)
|
|
|
|
|
{
|
|
|
|
|
MAP_ADDR(DEPTH_STENCIL, addr, cl);
|
|
|
|
|
pan_unpack(cl, DEPTH_STENCIL, desc);
|
|
|
|
|
DUMP_UNPACKED(DEPTH_STENCIL, desc, "Depth/stencil");
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-17 12:56:27 -04:00
|
|
|
static void
|
|
|
|
|
pandecode_shader_environment(const struct MALI_SHADER_ENVIRONMENT *p,
|
|
|
|
|
unsigned gpu_id)
|
|
|
|
|
{
|
|
|
|
|
if (p->shader)
|
|
|
|
|
pandecode_shader(p->shader, "Shader", gpu_id);
|
|
|
|
|
|
|
|
|
|
if (p->resources)
|
|
|
|
|
pandecode_resource_tables(p->resources, "Resources");
|
|
|
|
|
|
|
|
|
|
if (p->thread_storage)
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_local_storage(p->thread_storage);
|
2022-03-17 12:56:27 -04:00
|
|
|
|
|
|
|
|
if (p->fau)
|
|
|
|
|
dump_fau(p->fau, p->fau_count, "FAU");
|
|
|
|
|
}
|
|
|
|
|
|
2021-11-18 18:17:01 -05:00
|
|
|
static void
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_dcd(const struct MALI_DRAW *p, enum mali_job_type job_type,
|
2022-08-15 18:49:04 +00:00
|
|
|
unsigned gpu_id)
|
2021-11-18 18:17:01 -05:00
|
|
|
{
|
|
|
|
|
mali_ptr frag_shader = 0;
|
|
|
|
|
|
|
|
|
|
pandecode_depth_stencil(p->depth_stencil);
|
|
|
|
|
|
2022-03-14 18:46:14 -04:00
|
|
|
for (unsigned i = 0; i < p->blend_count; ++i) {
|
2022-08-15 18:35:45 +00:00
|
|
|
struct mali_blend_packed *PANDECODE_PTR_VAR(blend_descs, p->blend);
|
2021-11-18 18:17:01 -05:00
|
|
|
|
2022-08-15 23:58:43 +00:00
|
|
|
mali_ptr blend_shader = pandecode_blend(blend_descs, i, frag_shader);
|
2021-11-18 18:17:01 -05:00
|
|
|
if (blend_shader) {
|
2022-03-14 18:46:14 -04:00
|
|
|
fprintf(pandecode_dump_stream, "Blend shader %u", i);
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_shader_disassemble(blend_shader, 0, gpu_id);
|
2021-11-18 18:17:01 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-17 12:56:27 -04:00
|
|
|
pandecode_shader_environment(&p->shader, gpu_id);
|
2021-11-18 18:17:01 -05:00
|
|
|
DUMP_UNPACKED(DRAW, *p, "Draw:\n");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2022-08-15 18:35:45 +00:00
|
|
|
pandecode_malloc_vertex_job(mali_ptr job, unsigned gpu_id)
|
2021-11-18 18:17:01 -05:00
|
|
|
{
|
2022-08-15 18:35:45 +00:00
|
|
|
struct mali_malloc_vertex_job_packed *PANDECODE_PTR_VAR(p, job);
|
2021-11-18 18:17:01 -05:00
|
|
|
|
2022-02-02 18:43:32 -05:00
|
|
|
DUMP_SECTION(MALLOC_VERTEX_JOB, PRIMITIVE, p, "Primitive:\n");
|
2022-03-17 13:22:10 -04:00
|
|
|
DUMP_SECTION(MALLOC_VERTEX_JOB, INSTANCE_COUNT, p, "Instance count:\n");
|
|
|
|
|
DUMP_SECTION(MALLOC_VERTEX_JOB, ALLOCATION, p, "Allocation:\n");
|
2022-02-02 18:43:32 -05:00
|
|
|
DUMP_SECTION(MALLOC_VERTEX_JOB, TILER, p, "Tiler:\n");
|
|
|
|
|
DUMP_SECTION(MALLOC_VERTEX_JOB, SCISSOR, p, "Scissor:\n");
|
|
|
|
|
DUMP_SECTION(MALLOC_VERTEX_JOB, PRIMITIVE_SIZE, p, "Primitive Size:\n");
|
|
|
|
|
DUMP_SECTION(MALLOC_VERTEX_JOB, INDICES, p, "Indices:\n");
|
2021-11-18 18:17:01 -05:00
|
|
|
|
2022-02-02 18:43:32 -05:00
|
|
|
pan_section_unpack(p, MALLOC_VERTEX_JOB, DRAW, dcd);
|
2021-11-18 18:17:01 -05:00
|
|
|
|
2022-02-02 18:43:32 -05:00
|
|
|
pan_section_unpack(p, MALLOC_VERTEX_JOB, TILER, tiler_ptr);
|
2021-11-18 18:17:01 -05:00
|
|
|
pandecode_log("Tiler Job Payload:\n");
|
|
|
|
|
pandecode_indent++;
|
|
|
|
|
if (tiler_ptr.address)
|
2022-08-15 23:58:43 +00:00
|
|
|
pandecode_tiler(tiler_ptr.address);
|
2021-11-18 18:17:01 -05:00
|
|
|
else
|
|
|
|
|
pandecode_log("<omitted>\n");
|
|
|
|
|
pandecode_indent--;
|
|
|
|
|
|
2022-08-15 18:49:04 +00:00
|
|
|
pandecode_dcd(&dcd, 0, gpu_id);
|
2022-03-17 12:56:27 -04:00
|
|
|
|
|
|
|
|
pan_section_unpack(p, MALLOC_VERTEX_JOB, POSITION, position);
|
|
|
|
|
pan_section_unpack(p, MALLOC_VERTEX_JOB, VARYING, varying);
|
|
|
|
|
pandecode_shader_environment(&position, gpu_id);
|
|
|
|
|
pandecode_shader_environment(&varying, gpu_id);
|
2021-11-18 18:17:01 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2022-08-15 18:35:45 +00:00
|
|
|
pandecode_compute_job(mali_ptr job, unsigned gpu_id)
|
2021-11-18 18:17:01 -05:00
|
|
|
{
|
2022-08-15 18:35:45 +00:00
|
|
|
struct mali_compute_job_packed *PANDECODE_PTR_VAR(p, job);
|
2021-11-18 18:17:01 -05:00
|
|
|
pan_section_unpack(p, COMPUTE_JOB, PAYLOAD, payload);
|
|
|
|
|
|
|
|
|
|
pandecode_shader(payload.compute.shader, "Shader", gpu_id);
|
|
|
|
|
if (payload.compute.thread_storage)
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_local_storage(payload.compute.thread_storage);
|
2021-11-18 18:17:01 -05:00
|
|
|
if (payload.compute.fau)
|
|
|
|
|
dump_fau(payload.compute.fau, payload.compute.fau_count, "FAU");
|
|
|
|
|
if (payload.compute.resources)
|
|
|
|
|
pandecode_resource_tables(payload.compute.resources, "Resources");
|
|
|
|
|
|
|
|
|
|
DUMP_UNPACKED(COMPUTE_PAYLOAD, payload, "Compute:\n");
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2020-02-18 07:43:51 -05:00
|
|
|
/* Entrypoint to start tracing. jc_gpu_va is the GPU address for the first job
|
2022-05-10 01:03:03 +01:00
|
|
|
* in the chain; later jobs are found by walking the chain. GPU ID is the
|
|
|
|
|
* more finegrained ID because some details are model-specific even within a
|
|
|
|
|
* particular architecture. */
|
2020-02-18 07:43:51 -05:00
|
|
|
|
2020-02-18 07:46:03 -05:00
|
|
|
void
|
2021-08-06 10:22:28 +02:00
|
|
|
GENX(pandecode_jc)(mali_ptr jc_gpu_va, unsigned gpu_id)
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
{
|
2020-07-16 16:12:13 +12:00
|
|
|
pandecode_dump_file_open();
|
|
|
|
|
|
2022-03-26 02:13:16 +00:00
|
|
|
struct set *va_set = _mesa_pointer_set_create(NULL);
|
|
|
|
|
struct set_entry *entry = NULL;
|
|
|
|
|
|
2020-09-08 07:07:41 +02:00
|
|
|
mali_ptr next_job = 0;
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
|
|
|
|
do {
|
2022-09-11 18:12:09 -04:00
|
|
|
struct mali_job_header_packed *hdr =
|
|
|
|
|
PANDECODE_PTR(jc_gpu_va, struct mali_job_header_packed);
|
2022-03-26 02:13:16 +00:00
|
|
|
|
2022-09-11 18:12:09 -04:00
|
|
|
entry = _mesa_set_search(va_set, hdr);
|
2022-03-26 02:13:16 +00:00
|
|
|
if (entry != NULL) {
|
|
|
|
|
fprintf(stdout, "Job list has a cycle\n");
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-11 18:12:09 -04:00
|
|
|
pan_unpack(hdr, JOB_HEADER, h);
|
2020-09-08 07:07:41 +02:00
|
|
|
next_job = h.next;
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2022-01-09 13:04:34 -05:00
|
|
|
DUMP_UNPACKED(JOB_HEADER, h, "Job Header (%" PRIx64 "):\n", jc_gpu_va);
|
2020-09-08 07:07:41 +02:00
|
|
|
pandecode_log("\n");
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
|
2020-09-08 07:07:41 +02:00
|
|
|
switch (h.type) {
|
2020-09-08 10:39:23 +02:00
|
|
|
case MALI_JOB_TYPE_WRITE_VALUE:
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_write_value_job(jc_gpu_va);
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
break;
|
|
|
|
|
|
2021-06-09 16:43:29 -04:00
|
|
|
case MALI_JOB_TYPE_CACHE_FLUSH:
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_cache_flush_job(jc_gpu_va);
|
2021-06-09 16:43:29 -04:00
|
|
|
break;
|
|
|
|
|
|
2020-08-05 18:40:44 -04:00
|
|
|
case MALI_JOB_TYPE_TILER:
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_tiler_job(&h, jc_gpu_va, gpu_id);
|
2020-09-08 19:41:51 +02:00
|
|
|
break;
|
|
|
|
|
|
2022-03-17 13:23:52 -04:00
|
|
|
#if PAN_ARCH <= 7
|
2020-08-05 18:40:44 -04:00
|
|
|
case MALI_JOB_TYPE_VERTEX:
|
|
|
|
|
case MALI_JOB_TYPE_COMPUTE:
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_vertex_compute_geometry_job(&h, jc_gpu_va, gpu_id);
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
break;
|
|
|
|
|
|
2021-08-06 10:22:28 +02:00
|
|
|
#if PAN_ARCH >= 6
|
2021-06-22 11:16:37 -04:00
|
|
|
case MALI_JOB_TYPE_INDEXED_VERTEX:
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_indexed_vertex_job(&h, jc_gpu_va, gpu_id);
|
2021-06-22 11:16:37 -04:00
|
|
|
break;
|
2021-08-06 10:22:28 +02:00
|
|
|
#endif
|
2021-11-18 18:17:01 -05:00
|
|
|
#else
|
|
|
|
|
case MALI_JOB_TYPE_COMPUTE:
|
2022-08-15 18:35:45 +00:00
|
|
|
pandecode_compute_job(jc_gpu_va, gpu_id);
|
2021-11-18 18:17:01 -05:00
|
|
|
break;
|
|
|
|
|
|
2022-02-02 18:43:32 -05:00
|
|
|
case MALI_JOB_TYPE_MALLOC_VERTEX:
|
2022-08-15 18:35:45 +00:00
|
|
|
pandecode_malloc_vertex_job(jc_gpu_va, gpu_id);
|
2021-11-18 18:17:01 -05:00
|
|
|
break;
|
|
|
|
|
#endif
|
2021-06-22 11:16:37 -04:00
|
|
|
|
2020-08-05 18:40:44 -04:00
|
|
|
case MALI_JOB_TYPE_FRAGMENT:
|
2022-08-15 18:45:28 +00:00
|
|
|
pandecode_fragment_job(jc_gpu_va, gpu_id);
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
2022-03-26 02:13:16 +00:00
|
|
|
|
2022-09-11 18:12:09 -04:00
|
|
|
/* Track the latest visited job CPU VA to detect cycles */
|
|
|
|
|
_mesa_set_add(va_set, hdr);
|
2022-03-26 02:13:16 +00:00
|
|
|
|
2020-09-08 07:07:41 +02:00
|
|
|
} while ((jc_gpu_va = next_job));
|
2020-06-22 22:49:53 +12:00
|
|
|
|
2022-03-26 02:13:16 +00:00
|
|
|
_mesa_set_destroy(va_set, NULL);
|
|
|
|
|
|
2021-05-31 23:18:48 +12:00
|
|
|
fflush(pandecode_dump_stream);
|
2020-06-22 22:49:53 +12:00
|
|
|
pandecode_map_read_write();
|
panfrost: Add pandecode (command stream debugger)
The `panwrap` utility can be LD_PRELOAD'd into a GLES app, intercepting
communication between the driver and the kernel. Modern panwrap versions
do no processing of their own; instead, they create a trace directory.
This directory contains the following files:
- control.log: a line-by-line plain text file, denoting important
syscalls (mmaps and job submits) along with their arguments
- memory_*.bin, shader_*.bin: binary dumps of mapped memory
Together, these files contain enough information to reconstruct the
command stream and shaders of (at minimum) a single frame.
The `pandecode` utility takes this directory structure as input,
reconstructing the mapped memory and using the job submit command as an
entrypoint. It then walks the descriptors as the hardware would, parsing
and pretty-printing. Its final output is the pretty-printed command
stream interleaved with the disassembled shaders, suitable for driver
debugging. For instance, the behaviour of two driver versions (one
working, one broken) can be compared by diff'ing their decoded logs.
pandecode/decode.c was originally a part of `panwrap`; it is the oldest
living code in the project. Its history is generally not worth
preserving.
panwrap itself will continue to live downstream for the foreseeable
future, as it is specifically written for the vendor kernel. It is
possible, however, to produce equivalent traces directly from Panfrost,
bypassing the intermediate wrapping layer for well-behaved drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-19 05:50:14 +00:00
|
|
|
}
|
2021-05-21 17:38:00 -04:00
|
|
|
|
|
|
|
|
void
|
2021-08-06 10:22:28 +02:00
|
|
|
GENX(pandecode_abort_on_fault)(mali_ptr jc_gpu_va)
|
2021-05-21 17:38:00 -04:00
|
|
|
{
|
|
|
|
|
mali_ptr next_job = 0;
|
|
|
|
|
|
|
|
|
|
do {
|
2022-08-15 18:35:45 +00:00
|
|
|
pan_unpack(PANDECODE_PTR(jc_gpu_va, struct mali_job_header_packed),
|
2021-05-21 17:38:00 -04:00
|
|
|
JOB_HEADER, h);
|
|
|
|
|
next_job = h.next;
|
|
|
|
|
|
|
|
|
|
/* Ensure the job is marked COMPLETE */
|
|
|
|
|
if (h.exception_status != 0x1) {
|
2022-01-15 10:06:37 -05:00
|
|
|
fprintf(stderr, "Incomplete job or timeout\n");
|
2022-07-07 11:51:49 +12:00
|
|
|
fflush(NULL);
|
2021-05-31 23:18:07 +12:00
|
|
|
abort();
|
2021-05-21 17:38:00 -04:00
|
|
|
}
|
|
|
|
|
} while ((jc_gpu_va = next_job));
|
|
|
|
|
|
|
|
|
|
pandecode_map_read_write();
|
|
|
|
|
}
|