fdo-mirrors/mesa
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/mesa/mesa.git synced 2025-12-22 09:10:11 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 1
mesa/src/gallium/drivers/panfrost/pandecode/decode.c

2262 lines
84 KiB
C
Raw Normal View History

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
panfrost: Update copyright identifiers "Collabora, Ltd." should be listed in lieu of simply "Collabora" Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Suggested-by: Daniel Stone <daniels@collabora.com>
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.
*/
#include <panfrost-job.h>
#include <stdio.h>
#include <stdlib.h>
#include <memory.h>
#include <stdbool.h>
#include <stdarg.h>
panfrost: Replace pantrace with direct decoding History lesson! In the early days of a Panfrost, we had a library independent of the driver called `panwrap` which would be LD_PRELOAD'ed into a driver to decode its cmdstream in real-time. When upstreaming Panfrost, we realized that we would much rather have this decode functionality maintained in-tree to avoid divergence, but that we could not upstream panwrap because of its use with the legacy API. So we instead dumped GPU memory to the filesystem with an out-of-tree panwrap, and decoded that with the in-tree pandecode module. When we migrated to the new kernel, we just added support for doing this memory dump directly from the driver (via a module "pantrace"). This works, but dumping memory every frame is sloooooooooooooow and error-prone. I figured if we have pandecode in-tree, we might as well link to it directly in the driver, allowing us to decode Panfrost's command streams without dumping memory to the filesystem first. This cleans up the code *substantially* and improves dumping performance by a HUGE margin. I'm talking "several seconds per frame" to "dumping in real-time" kind of jump. Note to users: this removes the environmental option "PANTRACE_BASE". Instead, for equivalent functionality set "PAN_MESA_DEBUG=trace" and redirect stdout to the file of your choosing. This should be debugging Panfrost much more pleasant. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-11 12:25:35 -07:00
#include "decode.h"
panfrost/decode: Futureproof texture dumping One field was not dumped for some reason. It's observed to be 0, but it's still good to have it available. Also, extra fields might be snuck in the bitmaps array (it's variable-lengthed at the end), and we want to guard against that possibility, so we dump a little more. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-05-14 22:21:39 +00:00
#include "util/u_math.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 "../pan_pretty_print.h"
#include "../midgard/disassemble.h"
panfrost/decode: Disassemble Bifrost shaders We already have the Bifrost disassembler in-tree, so now that panwrap is able to dump Bifrost command streams, hook up the disassembler to pandecode. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Ryan Houdek <Sonicadvance1@gmail.com>
2019-05-18 18:58:56 +00:00
#include "../bifrost/disassemble.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
int pandecode_replay_jc(mali_ptr jc_gpu_va, bool bifrost);
#define MEMORY_PROP(obj, p) {\
panfrost/decode: Elide more zero fields Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 09:35:57 -07:00
if (obj->p) { \
char *a = pointer_as_memory_reference(obj->p); \
pandecode_prop("%s = %s", #p, a); \
free(a); \
} \
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
}
#define DYN_MEMORY_PROP(obj, no, p) { \
if (obj->p) \
pandecode_prop("%s = %s_%d_p", #p, #p, no); \
}
/* Semantic logging type.
*
* Raw: for raw messages to be printed as is.
* Message: for helpful information to be commented out in replays.
* Property: for properties of a struct
*
* Use one of pandecode_log, pandecode_msg, or pandecode_prop as syntax sugar.
*/
enum pandecode_log_type {
PANDECODE_RAW,
PANDECODE_MESSAGE,
PANDECODE_PROPERTY
};
#define pandecode_log(...) pandecode_log_typed(PANDECODE_RAW, __VA_ARGS__)
#define pandecode_msg(...) pandecode_log_typed(PANDECODE_MESSAGE, __VA_ARGS__)
#define pandecode_prop(...) pandecode_log_typed(PANDECODE_PROPERTY, __VA_ARGS__)
unsigned pandecode_indent = 0;
static void
pandecode_make_indent(void)
{
for (unsigned i = 0; i < pandecode_indent; ++i)
printf(" ");
}
static void
pandecode_log_typed(enum pandecode_log_type type, const char *format, ...)
{
va_list ap;
pandecode_make_indent();
if (type == PANDECODE_MESSAGE)
printf("// ");
else if (type == PANDECODE_PROPERTY)
printf(".");
va_start(ap, format);
vprintf(format, ap);
va_end(ap);
if (type == PANDECODE_PROPERTY)
printf(",\n");
}
static void
pandecode_log_cont(const char *format, ...)
{
va_list ap;
va_start(ap, format);
vprintf(format, ap);
va_end(ap);
}
struct pandecode_flag_info {
u64 flag;
const char *name;
};
static void
pandecode_log_decoded_flags(const struct pandecode_flag_info *flag_info,
u64 flags)
{
bool decodable_flags_found = false;
for (int i = 0; flag_info[i].name; i++) {
if ((flags & flag_info[i].flag) != flag_info[i].flag)
continue;
if (!decodable_flags_found) {
decodable_flags_found = true;
} else {
pandecode_log_cont(" | ");
}
pandecode_log_cont("%s", flag_info[i].name);
flags &= ~flag_info[i].flag;
}
if (decodable_flags_found) {
if (flags)
pandecode_log_cont(" | 0x%" PRIx64, flags);
} else {
pandecode_log_cont("0x%" PRIx64, flags);
}
}
#define FLAG_INFO(flag) { MALI_##flag, "MALI_" #flag }
static const struct pandecode_flag_info gl_enable_flag_info[] = {
FLAG_INFO(OCCLUSION_QUERY),
FLAG_INFO(OCCLUSION_PRECISE),
panfrost: Don't flip scanout The mesa/st flips the viewport, so we respect that rather than trying to flip the framebuffer itself and ignoring the viewport and using a messy heuristic. However, this brings an underlying disagreement about the interpretation of winding order to light. The blob uses a different strategy than Mesa for handling viewport Y flipping, so the meanings of the winding order bit are flipped for it. To keep things clean on our end, we rename to explicitly use Gallium (rather than flipped OpenGL) conventions. Fixes upside-down Xwayland/egl windows. v2: Adjust lowering configuration to correctly flip gl_PointCoord.y and gl_FragCoord.y. v1 was R-b'd by Tomeu, but then retracted due to these regressions which are not fixed. Suggested-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Sort-of-reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
2019-05-23 03:01:32 +00:00
FLAG_INFO(FRONT_CCW_TOP),
FLAG_INFO(CULL_FACE_FRONT),
FLAG_INFO(CULL_FACE_BACK),
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
{}
};
#undef FLAG_INFO
#define FLAG_INFO(flag) { MALI_CLEAR_##flag, "MALI_CLEAR_" #flag }
static const struct pandecode_flag_info clear_flag_info[] = {
FLAG_INFO(FAST),
FLAG_INFO(SLOW),
FLAG_INFO(SLOW_STENCIL),
{}
};
#undef FLAG_INFO
#define FLAG_INFO(flag) { MALI_MASK_##flag, "MALI_MASK_" #flag }
static const struct pandecode_flag_info mask_flag_info[] = {
FLAG_INFO(R),
FLAG_INFO(G),
FLAG_INFO(B),
FLAG_INFO(A),
{}
};
#undef FLAG_INFO
#define FLAG_INFO(flag) { MALI_##flag, "MALI_" #flag }
static const struct pandecode_flag_info u3_flag_info[] = {
FLAG_INFO(HAS_MSAA),
FLAG_INFO(CAN_DISCARD),
FLAG_INFO(HAS_BLEND_SHADER),
FLAG_INFO(DEPTH_TEST),
{}
};
static const struct pandecode_flag_info u4_flag_info[] = {
FLAG_INFO(NO_MSAA),
FLAG_INFO(NO_DITHER),
FLAG_INFO(DEPTH_RANGE_A),
FLAG_INFO(DEPTH_RANGE_B),
FLAG_INFO(STENCIL_TEST),
FLAG_INFO(SAMPLE_ALPHA_TO_COVERAGE_NO_BLEND_SHADER),
{}
};
#undef FLAG_INFO
#define FLAG_INFO(flag) { MALI_FRAMEBUFFER_##flag, "MALI_FRAMEBUFFER_" #flag }
static const struct pandecode_flag_info fb_fmt_flag_info[] = {
FLAG_INFO(MSAA_A),
FLAG_INFO(MSAA_B),
FLAG_INFO(MSAA_8),
{}
};
#undef FLAG_INFO
panfrost: Decode render target swizzle/channels On MRT-capable systems, the framebuffer format is encoded as a 64-bit word in the render target descriptor. Previously, the two 32-bit words were exposed as opaque hex values. This commit identifies a 12-bit Mali swizzle and a 2-bit channel counter, removing some of the magic. It also adds decoding support for the AFBC and MSAA enable bits, which were already known but otherwise ignored in pandecode. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-24 06:22:23 +00:00
#define FLAG_INFO(flag) { MALI_MFBD_FORMAT_##flag, "MALI_MFBD_FORMAT_" #flag }
static const struct pandecode_flag_info mfbd_fmt_flag_info[] = {
FLAG_INFO(MSAA),
panfrost: Add sRGB render target flag Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-17 16:01:24 -07:00
FLAG_INFO(SRGB),
panfrost: Decode render target swizzle/channels On MRT-capable systems, the framebuffer format is encoded as a 64-bit word in the render target descriptor. Previously, the two 32-bit words were exposed as opaque hex values. This commit identifies a 12-bit Mali swizzle and a 2-bit channel counter, removing some of the magic. It also adds decoding support for the AFBC and MSAA enable bits, which were already known but otherwise ignored in pandecode. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-24 06:22:23 +00:00
{}
};
#undef FLAG_INFO
panfrost: Identify fragment_extra flags The fragment_extra structure contains additional fields extending the MRT framebuffer descriptor, snuck in between the main framebuffer descriptor and the render targets. Its fields include those related to transaction elimination and depth/stencil buffers. This patch identifies the flags field (previously just "unk" with some magic values) as well as identifying some (but not all) flags set by the driver. The process of identifying flags brought a bug to light where transaction elimination (checksumming) could not be enabled unless AFBC was in-use. This issue is now resolved. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
2019-03-09 00:45:23 +00:00
#define FLAG_INFO(flag) { MALI_EXTRA_##flag, "MALI_EXTRA_" #flag }
static const struct pandecode_flag_info mfbd_extra_flag_info[] = {
FLAG_INFO(PRESENT),
FLAG_INFO(AFBC),
FLAG_INFO(ZS),
{}
};
#undef FLAG_INFO
panfrost/decode: Add flags for tilebuffer readback These flags are set when reading back the tilebuffer from a fragment shader via various mechanisms (including ARM_shader_framebuffer_fetch and EXT_pixel_local_storage). Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-04-05 01:17:21 +00:00
#define FLAG_INFO(flag) { MALI_##flag, "MALI_" #flag }
panfrost: Identify "uniform buffer count" bits We've known about this for a while, but it was never formally in the machine header files / decoder, so let's add them in. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-20 16:41:39 -07:00
static const struct pandecode_flag_info shader_midgard1_flag_info [] = {
panfrost: Enable helper invocations when texturing it turns out we have explicit control over helper invocations; if a particular bit in the fragment shader descriptor is set, helper invocations are launched; if it clear, they are not. Helper invocations are required whenever computing derivatives, whether explicitly (dFdx/dFdy) *or* implicitly (any texturing). Accordingly, we set this bit when texturing to fix edge case behaviour (literally, haha). Thank you to Jason Ekstrand and Ilia Mirkin for pointing out the representative dEQP test failed along triangle edges and for suggesting helper invocations / derivatives as a list of suspect pieces (which led to discovering the helper invocations enable bit in the first place). Ideally we would use the new NIR analysis pass for this, but that hasn't landed quite yet. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-07 16:00:49 -07:00
FLAG_INFO(EARLY_Z),
FLAG_INFO(HELPER_INVOCATIONS),
panfrost/decode: Add flags for tilebuffer readback These flags are set when reading back the tilebuffer from a fragment shader via various mechanisms (including ARM_shader_framebuffer_fetch and EXT_pixel_local_storage). Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-04-05 01:17:21 +00:00
FLAG_INFO(READS_TILEBUFFER),
FLAG_INFO(READS_ZS),
{}
};
#undef FLAG_INFO
panfrost: Identify and decode mfbd_flags Previously known as the unk3 field. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-14 11:14:01 -07:00
#define FLAG_INFO(flag) { MALI_MFBD_##flag, "MALI_MFBD_" #flag }
static const struct pandecode_flag_info mfbd_flag_info [] = {
FLAG_INFO(DEPTH_WRITE),
FLAG_INFO(EXTRA),
{}
};
#undef FLAG_INFO
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
extern char *replace_fragment;
extern char *replace_vertex;
static char *
pandecode_job_type_name(enum mali_job_type type)
{
#define DEFINE_CASE(name) case JOB_TYPE_ ## name: return "JOB_TYPE_" #name
switch (type) {
DEFINE_CASE(NULL);
DEFINE_CASE(SET_VALUE);
DEFINE_CASE(CACHE_FLUSH);
DEFINE_CASE(COMPUTE);
DEFINE_CASE(VERTEX);
DEFINE_CASE(TILER);
DEFINE_CASE(FUSED);
DEFINE_CASE(FRAGMENT);
case JOB_NOT_STARTED:
return "NOT_STARTED";
default:
pandecode_log("Warning! Unknown job type %x\n", type);
return "!?!?!?";
}
#undef DEFINE_CASE
}
static char *
pandecode_draw_mode_name(enum mali_draw_mode mode)
{
#define DEFINE_CASE(name) case MALI_ ## name: return "MALI_" #name
switch (mode) {
DEFINE_CASE(DRAW_NONE);
DEFINE_CASE(POINTS);
DEFINE_CASE(LINES);
DEFINE_CASE(TRIANGLES);
DEFINE_CASE(TRIANGLE_STRIP);
DEFINE_CASE(TRIANGLE_FAN);
DEFINE_CASE(LINE_STRIP);
DEFINE_CASE(LINE_LOOP);
DEFINE_CASE(POLYGON);
DEFINE_CASE(QUADS);
DEFINE_CASE(QUAD_STRIP);
default:
return "MALI_TRIANGLES /* XXX: Unknown GL mode, check dump */";
}
#undef DEFINE_CASE
}
#define DEFINE_CASE(name) case MALI_FUNC_ ## name: return "MALI_FUNC_" #name
static char *
pandecode_func_name(enum mali_func mode)
{
switch (mode) {
DEFINE_CASE(NEVER);
DEFINE_CASE(LESS);
DEFINE_CASE(EQUAL);
DEFINE_CASE(LEQUAL);
DEFINE_CASE(GREATER);
DEFINE_CASE(NOTEQUAL);
DEFINE_CASE(GEQUAL);
DEFINE_CASE(ALWAYS);
default:
return "MALI_FUNC_NEVER /* XXX: Unknown function, check dump */";
}
}
#undef DEFINE_CASE
/* Why is this duplicated? Who knows... */
#define DEFINE_CASE(name) case MALI_ALT_FUNC_ ## name: return "MALI_ALT_FUNC_" #name
static char *
pandecode_alt_func_name(enum mali_alt_func mode)
{
switch (mode) {
DEFINE_CASE(NEVER);
DEFINE_CASE(LESS);
DEFINE_CASE(EQUAL);
DEFINE_CASE(LEQUAL);
DEFINE_CASE(GREATER);
DEFINE_CASE(NOTEQUAL);
DEFINE_CASE(GEQUAL);
DEFINE_CASE(ALWAYS);
default:
return "MALI_FUNC_NEVER /* XXX: Unknown function, check dump */";
}
}
#undef DEFINE_CASE
#define DEFINE_CASE(name) case MALI_STENCIL_ ## name: return "MALI_STENCIL_" #name
static char *
pandecode_stencil_op_name(enum mali_stencil_op op)
{
switch (op) {
DEFINE_CASE(KEEP);
DEFINE_CASE(REPLACE);
DEFINE_CASE(ZERO);
DEFINE_CASE(INVERT);
DEFINE_CASE(INCR_WRAP);
DEFINE_CASE(DECR_WRAP);
DEFINE_CASE(INCR);
DEFINE_CASE(DECR);
default:
return "MALI_STENCIL_KEEP /* XXX: Unknown stencil op, check dump */";
}
}
#undef DEFINE_CASE
#define DEFINE_CASE(name) case MALI_ATTR_ ## name: return "MALI_ATTR_" #name
static char *pandecode_attr_mode_name(enum mali_attr_mode mode)
{
switch(mode) {
DEFINE_CASE(UNUSED);
DEFINE_CASE(LINEAR);
DEFINE_CASE(POT_DIVIDE);
DEFINE_CASE(MODULO);
DEFINE_CASE(NPOT_DIVIDE);
default: return "MALI_ATTR_UNUSED /* XXX: Unknown stencil op, check dump */";
}
}
#undef DEFINE_CASE
#define DEFINE_CASE(name) case MALI_CHANNEL_## name: return "MALI_CHANNEL_" #name
static char *
pandecode_channel_name(enum mali_channel channel)
{
switch (channel) {
DEFINE_CASE(RED);
DEFINE_CASE(GREEN);
DEFINE_CASE(BLUE);
DEFINE_CASE(ALPHA);
DEFINE_CASE(ZERO);
DEFINE_CASE(ONE);
DEFINE_CASE(RESERVED_0);
DEFINE_CASE(RESERVED_1);
default:
return "MALI_CHANNEL_ZERO /* XXX: Unknown channel, check dump */";
}
}
#undef DEFINE_CASE
#define DEFINE_CASE(name) case MALI_WRAP_## name: return "MALI_WRAP_" #name
static char *
pandecode_wrap_mode_name(enum mali_wrap_mode op)
{
switch (op) {
DEFINE_CASE(REPEAT);
DEFINE_CASE(CLAMP_TO_EDGE);
DEFINE_CASE(CLAMP_TO_BORDER);
DEFINE_CASE(MIRRORED_REPEAT);
default:
return "MALI_WRAP_REPEAT /* XXX: Unknown wrap mode, check dump */";
}
}
#undef DEFINE_CASE
panfrost: Refactor texture targets This combines the two cmdstream bits "is_3d" and "is_not_cubemap" into a single 2-bit texture target selection, noticing it's the same as the 2-bit selection in Midgard and Bifrost texturing ops. Accordingly, we share this definition and add the missing entry for 1D/buffer textures. This requires a nontrivial (but functionally similar) refactor of all parts of the driver to use the new definitions appropriately. Theoretically, this should add support for buffer textures, but that's obviously not tested and probably wouldn't work. While doing so, we notice the sRGB enable bit, which we document and decode as well here so we don't forget about it. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-17 14:26:08 -07:00
#define DEFINE_CASE(name) case MALI_TEX_## name: return "MALI_TEX_" #name
static char *
pandecode_texture_type(enum mali_texture_type type)
{
switch (type) {
DEFINE_CASE(1D);
DEFINE_CASE(2D);
DEFINE_CASE(3D);
DEFINE_CASE(CUBE);
default:
unreachable("Unknown case");
}
}
#undef DEFINE_CASE
panfrost: Decode rendering block type A mode for rendering tiled/uncompressed was noticed, so we reshuffle the MFBD render target definitions to explicitly include block type. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-17 15:53:09 -07:00
#define DEFINE_CASE(name) case MALI_MFBD_BLOCK_## name: return "MALI_MFBD_BLOCK_" #name
static char *
pandecode_mfbd_block_format(enum mali_mfbd_block_format fmt)
{
switch (fmt) {
DEFINE_CASE(TILED);
DEFINE_CASE(UNKNOWN);
DEFINE_CASE(LINEAR);
DEFINE_CASE(AFBC);
default:
unreachable("Invalid case");
}
}
#undef DEFINE_CASE
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 inline char *
pandecode_decode_fbd_type(enum mali_fbd_type type)
{
if (type == MALI_SFBD) return "SFBD";
else if (type == MALI_MFBD) return "MFBD";
else return "WATFBD /* XXX */";
}
static void
pandecode_replay_sfbd(uint64_t gpu_va, int job_no)
{
struct pandecode_mapped_memory *mem = pandecode_find_mapped_gpu_mem_containing(gpu_va);
const struct mali_single_framebuffer *PANDECODE_PTR_VAR(s, mem, (mali_ptr) gpu_va);
pandecode_log("struct mali_single_framebuffer framebuffer_%d = {\n", job_no);
pandecode_indent++;
pandecode_prop("unknown1 = 0x%" PRIx32, s->unknown1);
pandecode_prop("unknown2 = 0x%" PRIx32, s->unknown2);
pandecode_log(".format = ");
pandecode_log_decoded_flags(fb_fmt_flag_info, s->format);
pandecode_log_cont(",\n");
pandecode_prop("width = MALI_POSITIVE(%" PRId16 ")", s->width + 1);
pandecode_prop("height = MALI_POSITIVE(%" PRId16 ")", s->height + 1);
MEMORY_PROP(s, framebuffer);
pandecode_prop("stride = %d", s->stride);
/* Earlier in the actual commandstream -- right before width -- but we
* delay to flow nicer */
pandecode_log(".clear_flags = ");
pandecode_log_decoded_flags(clear_flag_info, s->clear_flags);
pandecode_log_cont(",\n");
if (s->depth_buffer | s->depth_buffer_enable) {
MEMORY_PROP(s, depth_buffer);
pandecode_prop("depth_buffer_enable = %s", DS_ENABLE(s->depth_buffer_enable));
}
if (s->stencil_buffer | s->stencil_buffer_enable) {
MEMORY_PROP(s, stencil_buffer);
pandecode_prop("stencil_buffer_enable = %s", DS_ENABLE(s->stencil_buffer_enable));
}
if (s->clear_color_1 | s->clear_color_2 | s->clear_color_3 | s->clear_color_4) {
pandecode_prop("clear_color_1 = 0x%" PRIx32, s->clear_color_1);
pandecode_prop("clear_color_2 = 0x%" PRIx32, s->clear_color_2);
pandecode_prop("clear_color_3 = 0x%" PRIx32, s->clear_color_3);
pandecode_prop("clear_color_4 = 0x%" PRIx32, s->clear_color_4);
}
if (s->clear_depth_1 != 0 || s->clear_depth_2 != 0 || s->clear_depth_3 != 0 || s->clear_depth_4 != 0) {
pandecode_prop("clear_depth_1 = %f", s->clear_depth_1);
pandecode_prop("clear_depth_2 = %f", s->clear_depth_2);
pandecode_prop("clear_depth_3 = %f", s->clear_depth_3);
pandecode_prop("clear_depth_4 = %f", s->clear_depth_4);
}
if (s->clear_stencil) {
pandecode_prop("clear_stencil = 0x%x", s->clear_stencil);
}
MEMORY_PROP(s, unknown_address_0);
panfrost: Rename tiler fields per tiler research Following the research into Midgard's hierarchical tiling infrastructure, we now understand (in broad stokes) the purpose of each tiler field in the MFBD. Additionally, we understand more of the tiling fields in the SFBD and in Bifrost's structures, although this knowledge is still incomplete. Update the names, decoder, and comments to reflect this new understanding. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-13 10:25:32 -07:00
MEMORY_PROP(s, tiler_polygon_list);
MEMORY_PROP(s, tiler_polygon_list_body);
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
panfrost: Integrate kernel names for tiler FBD These names are from the replay workaround in kbase; they begin to shine some light on the meaning of these fields. In particular, we now understand why the "tiler_meta" field has the effect it does on performance in certain scenes (controlling tile granularity). Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-12 09:33:06 -07:00
pandecode_prop("tiler_resolution_check = 0x%" PRIx32, s->tiler_resolution_check);
panfrost: Rename tiler fields per tiler research Following the research into Midgard's hierarchical tiling infrastructure, we now understand (in broad stokes) the purpose of each tiler field in the MFBD. Additionally, we understand more of the tiling fields in the SFBD and in Bifrost's structures, although this knowledge is still incomplete. Update the names, decoder, and comments to reflect this new understanding. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-13 10:25:32 -07:00
pandecode_prop("tiler_hierarchy_mask = 0x%" PRIx16, s->tiler_hierarchy_mask);
pandecode_prop("tiler_flags = 0x%" PRIx16, s->tiler_flags);
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
MEMORY_PROP(s, tiler_heap_free);
MEMORY_PROP(s, tiler_heap_end);
pandecode_indent--;
pandecode_log("};\n");
pandecode_prop("zero0 = 0x%" PRIx64, s->zero0);
pandecode_prop("zero1 = 0x%" PRIx64, s->zero1);
pandecode_prop("zero2 = 0x%" PRIx32, s->zero2);
pandecode_prop("zero4 = 0x%" PRIx32, s->zero4);
printf(".zero3 = {");
for (int i = 0; i < sizeof(s->zero3) / sizeof(s->zero3[0]); ++i)
printf("%X, ", s->zero3[i]);
printf("},\n");
printf(".zero6 = {");
for (int i = 0; i < sizeof(s->zero6) / sizeof(s->zero6[0]); ++i)
printf("%X, ", s->zero6[i]);
printf("},\n");
}
panfrost/decode: Expand pointers in compute descriptor Just as an aid. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 08:55:03 -07:00
static void
pandecode_u32_slide(unsigned name, const u32 *slide, unsigned count)
{
pandecode_log(".unknown%d = {", name);
for (int i = 0; i < count; ++i)
printf("%X, ", slide[i]);
pandecode_log("},\n");
}
#define SHORT_SLIDE(num) \
pandecode_u32_slide(num, s->unknown ## num, ARRAY_SIZE(s->unknown ## num))
panfrost/decode: Identify "compute FBD" There is fundamentally not a framebuffer associated with a compute job. Allocate a new structure for it so we don't mess up graphics when decoding. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 08:41:51 -07:00
static void
pandecode_compute_fbd(uint64_t gpu_va, int job_no)
{
struct pandecode_mapped_memory *mem = pandecode_find_mapped_gpu_mem_containing(gpu_va);
const struct mali_compute_fbd *PANDECODE_PTR_VAR(s, mem, (mali_ptr) gpu_va);
pandecode_log("struct mali_compute_fbd framebuffer_%d = {\n", job_no);
pandecode_indent++;
panfrost/decode: Expand pointers in compute descriptor Just as an aid. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 08:55:03 -07:00
SHORT_SLIDE(1);
panfrost/decode: Identify "compute FBD" There is fundamentally not a framebuffer associated with a compute job. Allocate a new structure for it so we don't mess up graphics when decoding. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 08:41:51 -07:00
pandecode_indent--;
printf("},\n");
}
panfrost: Decode render target swizzle/channels On MRT-capable systems, the framebuffer format is encoded as a 64-bit word in the render target descriptor. Previously, the two 32-bit words were exposed as opaque hex values. This commit identifies a 12-bit Mali swizzle and a 2-bit channel counter, removing some of the magic. It also adds decoding support for the AFBC and MSAA enable bits, which were already known but otherwise ignored in pandecode. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-24 06:22:23 +00:00
static void
pandecode_replay_swizzle(unsigned swizzle)
{
pandecode_prop("swizzle = %s | (%s << 3) | (%s << 6) | (%s << 9)",
pandecode_channel_name((swizzle >> 0) & 0x7),
pandecode_channel_name((swizzle >> 3) & 0x7),
pandecode_channel_name((swizzle >> 6) & 0x7),
pandecode_channel_name((swizzle >> 9) & 0x7));
}
static void
pandecode_rt_format(struct mali_rt_format format)
{
pandecode_log(".format = {\n");
pandecode_indent++;
pandecode_prop("unk1 = 0x%" PRIx32, format.unk1);
pandecode_prop("unk2 = 0x%" PRIx32, format.unk2);
panfrost: Decode rendering block type A mode for rendering tiled/uncompressed was noticed, so we reshuffle the MFBD render target definitions to explicitly include block type. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-17 15:53:09 -07:00
pandecode_prop("unk3 = 0x%" PRIx32, format.unk3);
pandecode_prop("block = %s",
pandecode_mfbd_block_format(format.block));
panfrost: Decode render target swizzle/channels On MRT-capable systems, the framebuffer format is encoded as a 64-bit word in the render target descriptor. Previously, the two 32-bit words were exposed as opaque hex values. This commit identifies a 12-bit Mali swizzle and a 2-bit channel counter, removing some of the magic. It also adds decoding support for the AFBC and MSAA enable bits, which were already known but otherwise ignored in pandecode. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-02-24 06:22:23 +00:00
pandecode_prop("nr_channels = MALI_POSITIVE(%d)",
MALI_NEGATIVE(format.nr_channels));
pandecode_log(".flags = ");
pandecode_log_decoded_flags(mfbd_fmt_flag_info, format.flags);
pandecode_log_cont(",\n");
pandecode_replay_swizzle(format.swizzle);
pandecode_prop("unk4 = 0x%" PRIx32, format.unk4);
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
static void
panfrost: Remove "vertex/tiler render target" silliness I don't think these are actual structures, just figments over cargoculting dumped memory without making any sense of it. Nothing seems to break if the region is zeroed out, anyway. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-11 14:56:30 -07:00
pandecode_render_target(uint64_t gpu_va, unsigned job_no, const struct bifrost_framebuffer *fb)
{
pandecode_log("struct bifrost_render_target rts_list_%d[] = {\n", job_no);
pandecode_indent++;
for (int i = 0; i < MALI_NEGATIVE(fb->rt_count_1); i++) {
mali_ptr rt_va = gpu_va + i * sizeof(struct bifrost_render_target);
struct pandecode_mapped_memory *mem =
pandecode_find_mapped_gpu_mem_containing(rt_va);
const struct bifrost_render_target *PANDECODE_PTR_VAR(rt, mem, (mali_ptr) rt_va);
pandecode_log("{\n");
pandecode_indent++;
pandecode_rt_format(rt->format);
panfrost/decode: Print AFBC struct when appropriate Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-25 08:21:15 +02:00
if (rt->format.block == MALI_MFBD_BLOCK_AFBC) {
panfrost: Remove "vertex/tiler render target" silliness I don't think these are actual structures, just figments over cargoculting dumped memory without making any sense of it. Nothing seems to break if the region is zeroed out, anyway. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-11 14:56:30 -07:00
pandecode_log(".afbc = {\n");
pandecode_indent++;
char *a = pointer_as_memory_reference(rt->afbc.metadata);
pandecode_prop("metadata = %s", a);
free(a);
pandecode_prop("stride = %d", rt->afbc.stride);
pandecode_prop("unk = 0x%" PRIx32, rt->afbc.unk);
pandecode_indent--;
pandecode_log("},\n");
} else {
pandecode_log(".chunknown = {\n");
pandecode_indent++;
pandecode_prop("unk = 0x%" PRIx64, rt->chunknown.unk);
char *a = pointer_as_memory_reference(rt->chunknown.pointer);
pandecode_prop("pointer = %s", a);
free(a);
pandecode_indent--;
pandecode_log("},\n");
}
MEMORY_PROP(rt, framebuffer);
pandecode_prop("framebuffer_stride = %d", rt->framebuffer_stride);
if (rt->clear_color_1 | rt->clear_color_2 | rt->clear_color_3 | rt->clear_color_4) {
pandecode_prop("clear_color_1 = 0x%" PRIx32, rt->clear_color_1);
pandecode_prop("clear_color_2 = 0x%" PRIx32, rt->clear_color_2);
pandecode_prop("clear_color_3 = 0x%" PRIx32, rt->clear_color_3);
pandecode_prop("clear_color_4 = 0x%" PRIx32, rt->clear_color_4);
}
if (rt->zero1 || rt->zero2 || rt->zero3) {
pandecode_msg("render target zeros tripped\n");
pandecode_prop("zero1 = 0x%" PRIx64, rt->zero1);
pandecode_prop("zero2 = 0x%" PRIx32, rt->zero2);
pandecode_prop("zero3 = 0x%" PRIx32, rt->zero3);
}
pandecode_indent--;
pandecode_log("},\n");
}
pandecode_indent--;
pandecode_log("};\n");
}
panfrost/decode: Limit MRT blend count I thought I already fixed this. Maybe that was a dream...? Then again, I might be dreaming now. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-23 11:29:46 -07:00
static unsigned
panfrost: Remove "vertex/tiler render target" silliness I don't think these are actual structures, just figments over cargoculting dumped memory without making any sense of it. Nothing seems to break if the region is zeroed out, anyway. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-11 14:56:30 -07:00
pandecode_replay_mfbd_bfr(uint64_t gpu_va, int job_no, bool with_render_targets)
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
{
struct pandecode_mapped_memory *mem = pandecode_find_mapped_gpu_mem_containing(gpu_va);
const struct bifrost_framebuffer *PANDECODE_PTR_VAR(fb, mem, (mali_ptr) gpu_va);
if (fb->sample_locations) {
/* The blob stores all possible sample locations in a single buffer
* allocated on startup, and just switches the pointer when switching
* MSAA state. For now, we just put the data into the cmdstream, but we
* should do something like what the blob does with a real driver.
*
* There seem to be 32 slots for sample locations, followed by another
* 16. The second 16 is just the center location followed by 15 zeros
* in all the cases I've identified (maybe shader vs. depth/color
* samples?).
*/
struct pandecode_mapped_memory *smem = pandecode_find_mapped_gpu_mem_containing(fb->sample_locations);
const u16 *PANDECODE_PTR_VAR(samples, smem, fb->sample_locations);
pandecode_log("uint16_t sample_locations_%d[] = {\n", job_no);
pandecode_indent++;
for (int i = 0; i < 32 + 16; i++) {
pandecode_log("%d, %d,\n", samples[2 * i], samples[2 * i + 1]);
}
pandecode_indent--;
pandecode_log("};\n");
}
pandecode_log("struct bifrost_framebuffer framebuffer_%d = {\n", job_no);
pandecode_indent++;
pandecode_prop("unk0 = 0x%x", fb->unk0);
if (fb->sample_locations)
pandecode_prop("sample_locations = sample_locations_%d", job_no);
panfrost: Integrate kernel names for tiler FBD These names are from the replay workaround in kbase; they begin to shine some light on the meaning of these fields. In particular, we now understand why the "tiler_meta" field has the effect it does on performance in certain scenes (controlling tile granularity). Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-12 09:33:06 -07:00
/* Assume that unknown1 was emitted in the last job for
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
* now */
MEMORY_PROP(fb, unknown1);
panfrost: Integrate kernel names for tiler FBD These names are from the replay workaround in kbase; they begin to shine some light on the meaning of these fields. In particular, we now understand why the "tiler_meta" field has the effect it does on performance in certain scenes (controlling tile granularity). Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-12 09:33:06 -07:00
panfrost: Rename tiler fields per tiler research Following the research into Midgard's hierarchical tiling infrastructure, we now understand (in broad stokes) the purpose of each tiler field in the MFBD. Additionally, we understand more of the tiling fields in the SFBD and in Bifrost's structures, although this knowledge is still incomplete. Update the names, decoder, and comments to reflect this new understanding. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-13 10:25:32 -07:00
pandecode_prop("tiler_polygon_list_size = 0x%x", fb->tiler_polygon_list_size);
pandecode_prop("tiler_hierarchy_mask = 0x%" PRIx16, fb->tiler_hierarchy_mask);
pandecode_prop("tiler_flags = 0x%" PRIx16, fb->tiler_flags);
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_prop("width1 = MALI_POSITIVE(%d)", fb->width1 + 1);
pandecode_prop("height1 = MALI_POSITIVE(%d)", fb->height1 + 1);
pandecode_prop("width2 = MALI_POSITIVE(%d)", fb->width2 + 1);
pandecode_prop("height2 = MALI_POSITIVE(%d)", fb->height2 + 1);
pandecode_prop("unk1 = 0x%x", fb->unk1);
pandecode_prop("unk2 = 0x%x", fb->unk2);
pandecode_prop("rt_count_1 = MALI_POSITIVE(%d)", fb->rt_count_1 + 1);
pandecode_prop("rt_count_2 = %d", fb->rt_count_2);
panfrost: Identify and decode mfbd_flags Previously known as the unk3 field. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-14 11:14:01 -07:00
pandecode_log(".mfbd_flags = ");
pandecode_log_decoded_flags(mfbd_flag_info, fb->mfbd_flags);
pandecode_log_cont(",\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_prop("clear_stencil = 0x%x", fb->clear_stencil);
pandecode_prop("clear_depth = %f", fb->clear_depth);
pandecode_prop("unknown2 = 0x%x", fb->unknown2);
MEMORY_PROP(fb, scratchpad);
panfrost: Rename tiler fields per tiler research Following the research into Midgard's hierarchical tiling infrastructure, we now understand (in broad stokes) the purpose of each tiler field in the MFBD. Additionally, we understand more of the tiling fields in the SFBD and in Bifrost's structures, although this knowledge is still incomplete. Update the names, decoder, and comments to reflect this new understanding. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-13 10:25:32 -07:00
MEMORY_PROP(fb, tiler_polygon_list);
MEMORY_PROP(fb, tiler_polygon_list_body);
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
MEMORY_PROP(fb, tiler_heap_start);
MEMORY_PROP(fb, tiler_heap_end);
panfrost: Integrate kernel names for tiler FBD These names are from the replay workaround in kbase; they begin to shine some light on the meaning of these fields. In particular, we now understand why the "tiler_meta" field has the effect it does on performance in certain scenes (controlling tile granularity). Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-12 09:33:06 -07:00
if (fb->zero3 || fb->zero4) {
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_msg("framebuffer zeros tripped\n");
pandecode_prop("zero3 = 0x%" PRIx32, fb->zero3);
pandecode_prop("zero4 = 0x%" PRIx32, fb->zero4);
panfrost: Integrate kernel names for tiler FBD These names are from the replay workaround in kbase; they begin to shine some light on the meaning of these fields. In particular, we now understand why the "tiler_meta" field has the effect it does on performance in certain scenes (controlling tile granularity). Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-12 09:33:06 -07:00
}
bool nonzero_weights = false;
for (unsigned w = 0; w < ARRAY_SIZE(fb->tiler_weights); ++w) {
nonzero_weights |= fb->tiler_weights[w] != 0x0;
}
if (nonzero_weights) {
pandecode_log(".tiler_weights = {");
for (unsigned w = 0; w < ARRAY_SIZE(fb->tiler_weights); ++w) {
pandecode_log("%d, ", fb->tiler_weights[w]);
}
pandecode_log("},");
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--;
pandecode_log("};\n");
gpu_va += sizeof(struct bifrost_framebuffer);
panfrost: Identify and decode mfbd_flags Previously known as the unk3 field. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-14 11:14:01 -07:00
if ((fb->mfbd_flags & MALI_MFBD_EXTRA) && with_render_targets) {
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
mem = pandecode_find_mapped_gpu_mem_containing(gpu_va);
const struct bifrost_fb_extra *PANDECODE_PTR_VAR(fbx, mem, (mali_ptr) gpu_va);
pandecode_log("struct bifrost_fb_extra fb_extra_%d = {\n", job_no);
pandecode_indent++;
MEMORY_PROP(fbx, checksum);
if (fbx->checksum_stride)
pandecode_prop("checksum_stride = %d", fbx->checksum_stride);
panfrost: Identify fragment_extra flags The fragment_extra structure contains additional fields extending the MRT framebuffer descriptor, snuck in between the main framebuffer descriptor and the render targets. Its fields include those related to transaction elimination and depth/stencil buffers. This patch identifies the flags field (previously just "unk" with some magic values) as well as identifying some (but not all) flags set by the driver. The process of identifying flags brought a bug to light where transaction elimination (checksumming) could not be enabled unless AFBC was in-use. This issue is now resolved. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
2019-03-09 00:45:23 +00:00
pandecode_log(".flags = ");
pandecode_log_decoded_flags(mfbd_extra_flag_info, fbx->flags);
pandecode_log_cont(",\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
panfrost: Identify fragment_extra flags The fragment_extra structure contains additional fields extending the MRT framebuffer descriptor, snuck in between the main framebuffer descriptor and the render targets. Its fields include those related to transaction elimination and depth/stencil buffers. This patch identifies the flags field (previously just "unk" with some magic values) as well as identifying some (but not all) flags set by the driver. The process of identifying flags brought a bug to light where transaction elimination (checksumming) could not be enabled unless AFBC was in-use. This issue is now resolved. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
2019-03-09 00:45:23 +00:00
if (fbx->flags & MALI_EXTRA_AFBC_ZS) {
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_log(".ds_afbc = {\n");
pandecode_indent++;
MEMORY_PROP((&fbx->ds_afbc), depth_stencil_afbc_metadata);
pandecode_prop("depth_stencil_afbc_stride = %d",
fbx->ds_afbc.depth_stencil_afbc_stride);
MEMORY_PROP((&fbx->ds_afbc), depth_stencil);
if (fbx->ds_afbc.zero1 || fbx->ds_afbc.padding) {
pandecode_msg("Depth/stencil AFBC zeros tripped\n");
pandecode_prop("zero1 = 0x%" PRIx32,
fbx->ds_afbc.zero1);
pandecode_prop("padding = 0x%" PRIx64,
fbx->ds_afbc.padding);
}
pandecode_indent--;
pandecode_log("},\n");
} else {
pandecode_log(".ds_linear = {\n");
pandecode_indent++;
if (fbx->ds_linear.depth) {
MEMORY_PROP((&fbx->ds_linear), depth);
pandecode_prop("depth_stride = %d",
fbx->ds_linear.depth_stride);
}
if (fbx->ds_linear.stencil) {
MEMORY_PROP((&fbx->ds_linear), stencil);
pandecode_prop("stencil_stride = %d",
fbx->ds_linear.stencil_stride);
}
if (fbx->ds_linear.depth_stride_zero ||
fbx->ds_linear.stencil_stride_zero ||
fbx->ds_linear.zero1 || fbx->ds_linear.zero2) {
pandecode_msg("Depth/stencil zeros tripped\n");
pandecode_prop("depth_stride_zero = 0x%x",
fbx->ds_linear.depth_stride_zero);
pandecode_prop("stencil_stride_zero = 0x%x",
fbx->ds_linear.stencil_stride_zero);
pandecode_prop("zero1 = 0x%" PRIx32,
fbx->ds_linear.zero1);
pandecode_prop("zero2 = 0x%" PRIx32,
fbx->ds_linear.zero2);
}
pandecode_indent--;
pandecode_log("},\n");
}
if (fbx->zero3 || fbx->zero4) {
pandecode_msg("fb_extra zeros tripped\n");
pandecode_prop("zero3 = 0x%" PRIx64, fbx->zero3);
pandecode_prop("zero4 = 0x%" PRIx64, fbx->zero4);
}
pandecode_indent--;
pandecode_log("};\n");
gpu_va += sizeof(struct bifrost_fb_extra);
}
panfrost: Remove "vertex/tiler render target" silliness I don't think these are actual structures, just figments over cargoculting dumped memory without making any sense of it. Nothing seems to break if the region is zeroed out, anyway. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-11 14:56:30 -07:00
if (with_render_targets)
pandecode_render_target(gpu_va, job_no, fb);
panfrost/decode: Limit MRT blend count I thought I already fixed this. Maybe that was a dream...? Then again, I might be dreaming now. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-23 11:29:46 -07:00
/* Passback the render target count */
return MALI_NEGATIVE(fb->rt_count_1);
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_replay_attributes(const struct pandecode_mapped_memory *mem,
mali_ptr addr, int job_no, char *suffix,
int count, bool varying)
{
char *prefix = varying ? "varyings" : "attributes";
union mali_attr *attr = pandecode_fetch_gpu_mem(mem, addr, sizeof(union mali_attr) * count);
char base[128];
snprintf(base, sizeof(base), "%s_data_%d%s", prefix, job_no, suffix);
for (int i = 0; i < count; ++i) {
enum mali_attr_mode mode = attr[i].elements & 7;
if (mode == MALI_ATTR_UNUSED)
continue;
mali_ptr raw_elements = attr[i].elements & ~7;
/* TODO: Do we maybe want to dump the attribute values
* themselves given the specified format? Or is that too hard?
* */
char *a = pointer_as_memory_reference(raw_elements);
pandecode_log("mali_ptr %s_%d_p = %s;\n", base, i, a);
free(a);
}
pandecode_log("union mali_attr %s_%d[] = {\n", prefix, job_no);
pandecode_indent++;
for (int i = 0; i < count; ++i) {
pandecode_log("{\n");
pandecode_indent++;
pandecode_prop("elements = (%s_%d_p) | %s", base, i, pandecode_attr_mode_name(attr[i].elements & 7));
pandecode_prop("shift = %d", attr[i].shift);
pandecode_prop("extra_flags = %d", attr[i].extra_flags);
pandecode_prop("stride = 0x%" PRIx32, attr[i].stride);
pandecode_prop("size = 0x%" PRIx32, attr[i].size);
pandecode_indent--;
pandecode_log("}, \n");
if ((attr[i].elements & 7) == MALI_ATTR_NPOT_DIVIDE) {
i++;
pandecode_log("{\n");
pandecode_indent++;
pandecode_prop("unk = 0x%x", attr[i].unk);
pandecode_prop("magic_divisor = 0x%08x", attr[i].magic_divisor);
if (attr[i].zero != 0)
pandecode_prop("zero = 0x%x /* XXX zero tripped */", attr[i].zero);
pandecode_prop("divisor = %d", attr[i].divisor);
pandecode_indent--;
pandecode_log("}, \n");
}
}
pandecode_indent--;
pandecode_log("};\n");
}
static mali_ptr
pandecode_replay_shader_address(const char *name, mali_ptr ptr)
{
/* TODO: Decode flags */
mali_ptr shader_ptr = ptr & ~15;
char *a = pointer_as_memory_reference(shader_ptr);
pandecode_prop("%s = (%s) | %d", name, a, (int) (ptr & 15));
free(a);
return shader_ptr;
}
panfrost/decode: Skip decode of fragment backend in non-fragment This is all zero for anything but fragment shaders. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 09:31:16 -07:00
static bool
all_zero(unsigned *buffer, unsigned count)
{
for (unsigned i = 0; i < count; ++i) {
if (buffer[i])
return false;
}
return true;
}
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_replay_stencil(const char *name, const struct mali_stencil_test *stencil)
{
panfrost/decode: Skip decode of fragment backend in non-fragment This is all zero for anything but fragment shaders. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 09:31:16 -07:00
if (all_zero((unsigned *) stencil, sizeof(stencil) / sizeof(unsigned)))
return;
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
const char *func = pandecode_func_name(stencil->func);
const char *sfail = pandecode_stencil_op_name(stencil->sfail);
const char *dpfail = pandecode_stencil_op_name(stencil->dpfail);
const char *dppass = pandecode_stencil_op_name(stencil->dppass);
if (stencil->zero)
pandecode_msg("Stencil zero tripped: %X\n", stencil->zero);
pandecode_log(".stencil_%s = {\n", name);
pandecode_indent++;
pandecode_prop("ref = %d", stencil->ref);
pandecode_prop("mask = 0x%02X", stencil->mask);
pandecode_prop("func = %s", func);
pandecode_prop("sfail = %s", sfail);
pandecode_prop("dpfail = %s", dpfail);
pandecode_prop("dppass = %s", dppass);
pandecode_indent--;
pandecode_log("},\n");
}
static void
panfrost: Refactor blend descriptors This commit does a fairly large cleanup of blend descriptors, although there should not be any functional changes. In particular, we split apart the Midgard and Bifrost blend descriptors, since they are radically different. From there, we can identify that the Midgard descriptor as previously written was really two render targets' descriptors stuck together. From this observation, we split the Midgard descriptor into what a single RT actually needs. This enables us to correctly dump blending configuration for MRT samples on Midgard. It also allows the Midgard and Bifrost blend code to peacefully coexist, with runtime selection rather than a #ifdef. So, as a bonus, this will help the future Bifrost effort, eliminating one major source of compile-time architectural divergence. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-05-04 21:57:01 +00:00
pandecode_replay_blend_equation(const struct mali_blend_equation *blend)
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 (blend->zero1)
pandecode_msg("Blend zero tripped: %X\n", blend->zero1);
panfrost: Refactor blend descriptors This commit does a fairly large cleanup of blend descriptors, although there should not be any functional changes. In particular, we split apart the Midgard and Bifrost blend descriptors, since they are radically different. From there, we can identify that the Midgard descriptor as previously written was really two render targets' descriptors stuck together. From this observation, we split the Midgard descriptor into what a single RT actually needs. This enables us to correctly dump blending configuration for MRT samples on Midgard. It also allows the Midgard and Bifrost blend code to peacefully coexist, with runtime selection rather than a #ifdef. So, as a bonus, this will help the future Bifrost effort, eliminating one major source of compile-time architectural divergence. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-05-04 21:57:01 +00:00
pandecode_log(".equation = {\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++;
pandecode_prop("rgb_mode = 0x%X", blend->rgb_mode);
pandecode_prop("alpha_mode = 0x%X", blend->alpha_mode);
pandecode_log(".color_mask = ");
pandecode_log_decoded_flags(mask_flag_info, blend->color_mask);
pandecode_log_cont(",\n");
pandecode_indent--;
pandecode_log("},\n");
}
panfrost/decode: Decode blend constant This adds a forgotten decode line on Midgard and adds the field of a blend constant on Bifrost. The Bifrost encoding is fairly weird; whereas Midgard is just a regular 32-bit float, Bifrost uses a fancy fixed-point-esque encoding. The decode logic here is experimentally correct. The encode logic is a sort of "guesstimate", assuming that the high byte is just int(f / 255.0) and then solving algebraicly for the low byte. This might be slightly off in some cases. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Ryan Houdek <Sonicadvance1@gmail.com>
2019-05-18 20:48:43 +00:00
/* Decodes a Bifrost blend constant. See the notes in bifrost_blend_rt */
static unsigned
decode_bifrost_constant(u16 constant)
{
float lo = (float) (constant & 0xFF);
float hi = (float) (constant >> 8);
return (hi / 255.0) + (lo / 65535.0);
}
panfrost: Refactor blend descriptors This commit does a fairly large cleanup of blend descriptors, although there should not be any functional changes. In particular, we split apart the Midgard and Bifrost blend descriptors, since they are radically different. From there, we can identify that the Midgard descriptor as previously written was really two render targets' descriptors stuck together. From this observation, we split the Midgard descriptor into what a single RT actually needs. This enables us to correctly dump blending configuration for MRT samples on Midgard. It also allows the Midgard and Bifrost blend code to peacefully coexist, with runtime selection rather than a #ifdef. So, as a bonus, this will help the future Bifrost effort, eliminating one major source of compile-time architectural divergence. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-05-04 21:57:01 +00:00
static mali_ptr
pandecode_bifrost_blend(void *descs, int job_no, int rt_no)
{
struct bifrost_blend_rt *b =
((struct bifrost_blend_rt *) descs) + rt_no;
pandecode_log("struct bifrost_blend_rt blend_rt_%d_%d = {\n", job_no, rt_no);
pandecode_indent++;
panfrost/decode: Decode blend constant This adds a forgotten decode line on Midgard and adds the field of a blend constant on Bifrost. The Bifrost encoding is fairly weird; whereas Midgard is just a regular 32-bit float, Bifrost uses a fancy fixed-point-esque encoding. The decode logic here is experimentally correct. The encode logic is a sort of "guesstimate", assuming that the high byte is just int(f / 255.0) and then solving algebraicly for the low byte. This might be slightly off in some cases. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Ryan Houdek <Sonicadvance1@gmail.com>
2019-05-18 20:48:43 +00:00
pandecode_prop("flags = 0x%" PRIx16, b->flags);
pandecode_prop("constant = 0x%" PRIx8 " /* %f */",
b->constant, decode_bifrost_constant(b->constant));
panfrost: Refactor blend descriptors This commit does a fairly large cleanup of blend descriptors, although there should not be any functional changes. In particular, we split apart the Midgard and Bifrost blend descriptors, since they are radically different. From there, we can identify that the Midgard descriptor as previously written was really two render targets' descriptors stuck together. From this observation, we split the Midgard descriptor into what a single RT actually needs. This enables us to correctly dump blending configuration for MRT samples on Midgard. It also allows the Midgard and Bifrost blend code to peacefully coexist, with runtime selection rather than a #ifdef. So, as a bonus, this will help the future Bifrost effort, eliminating one major source of compile-time architectural divergence. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-05-04 21:57:01 +00:00
/* TODO figure out blend shader enable bit */
pandecode_replay_blend_equation(&b->equation);
pandecode_prop("unk2 = 0x%" PRIx16, b->unk2);
pandecode_prop("index = 0x%" PRIx16, b->index);
pandecode_prop("shader = 0x%" PRIx32, b->shader);
pandecode_indent--;
pandecode_log("},\n");
return 0;
}
static mali_ptr
pandecode_midgard_blend(union midgard_blend *blend, bool is_shader)
{
panfrost/decode: Skip decode of fragment backend in non-fragment This is all zero for anything but fragment shaders. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 09:31:16 -07:00
if (all_zero((unsigned *) blend, sizeof(blend) / sizeof(unsigned)))
return 0;
panfrost: Refactor blend descriptors This commit does a fairly large cleanup of blend descriptors, although there should not be any functional changes. In particular, we split apart the Midgard and Bifrost blend descriptors, since they are radically different. From there, we can identify that the Midgard descriptor as previously written was really two render targets' descriptors stuck together. From this observation, we split the Midgard descriptor into what a single RT actually needs. This enables us to correctly dump blending configuration for MRT samples on Midgard. It also allows the Midgard and Bifrost blend code to peacefully coexist, with runtime selection rather than a #ifdef. So, as a bonus, this will help the future Bifrost effort, eliminating one major source of compile-time architectural divergence. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-05-04 21:57:01 +00:00
pandecode_log(".blend = {\n");
pandecode_indent++;
if (is_shader) {
pandecode_replay_shader_address("shader", blend->shader);
} else {
pandecode_replay_blend_equation(&blend->equation);
panfrost/decode: Decode blend constant This adds a forgotten decode line on Midgard and adds the field of a blend constant on Bifrost. The Bifrost encoding is fairly weird; whereas Midgard is just a regular 32-bit float, Bifrost uses a fancy fixed-point-esque encoding. The decode logic here is experimentally correct. The encode logic is a sort of "guesstimate", assuming that the high byte is just int(f / 255.0) and then solving algebraicly for the low byte. This might be slightly off in some cases. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Ryan Houdek <Sonicadvance1@gmail.com>
2019-05-18 20:48:43 +00:00
pandecode_prop("constant = %f", blend->constant);
panfrost: Refactor blend descriptors This commit does a fairly large cleanup of blend descriptors, although there should not be any functional changes. In particular, we split apart the Midgard and Bifrost blend descriptors, since they are radically different. From there, we can identify that the Midgard descriptor as previously written was really two render targets' descriptors stuck together. From this observation, we split the Midgard descriptor into what a single RT actually needs. This enables us to correctly dump blending configuration for MRT samples on Midgard. It also allows the Midgard and Bifrost blend code to peacefully coexist, with runtime selection rather than a #ifdef. So, as a bonus, this will help the future Bifrost effort, eliminating one major source of compile-time architectural divergence. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-05-04 21:57:01 +00:00
}
pandecode_indent--;
pandecode_log("},\n");
/* Return blend shader to disassemble if present */
return is_shader ? (blend->shader & ~0xF) : 0;
}
static mali_ptr
pandecode_midgard_blend_mrt(void *descs, int job_no, int rt_no)
{
struct midgard_blend_rt *b =
((struct midgard_blend_rt *) descs) + rt_no;
/* Flags determine presence of blend shader */
bool is_shader = (b->flags & 0xF) >= 0x2;
pandecode_log("struct midgard_blend_rt blend_rt_%d_%d = {\n", job_no, rt_no);
pandecode_indent++;
pandecode_prop("flags = 0x%" PRIx64, b->flags);
mali_ptr shader = pandecode_midgard_blend(&b->blend, is_shader);
pandecode_indent--;
pandecode_log("};\n");
return shader;
}
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 int
pandecode_replay_attribute_meta(int job_no, int count, const struct mali_vertex_tiler_postfix *v, bool varying, char *suffix)
{
char base[128];
char *prefix = varying ? "varying" : "attribute";
unsigned max_index = 0;
snprintf(base, sizeof(base), "%s_meta", prefix);
pandecode_log("struct mali_attr_meta %s_%d%s[] = {\n", base, job_no, suffix);
pandecode_indent++;
struct mali_attr_meta *attr_meta;
mali_ptr p = varying ? (v->varying_meta & ~0xF) : v->attribute_meta;
struct pandecode_mapped_memory *attr_mem = pandecode_find_mapped_gpu_mem_containing(p);
for (int i = 0; i < count; ++i, p += sizeof(struct mali_attr_meta)) {
attr_meta = pandecode_fetch_gpu_mem(attr_mem, p,
sizeof(*attr_mem));
pandecode_log("{\n");
pandecode_indent++;
pandecode_prop("index = %d", attr_meta->index);
if (attr_meta->index > max_index)
max_index = attr_meta->index;
pandecode_replay_swizzle(attr_meta->swizzle);
pandecode_prop("format = %s", pandecode_format_name(attr_meta->format));
pandecode_prop("unknown1 = 0x%" PRIx64, (u64) attr_meta->unknown1);
pandecode_prop("unknown3 = 0x%" PRIx64, (u64) attr_meta->unknown3);
pandecode_prop("src_offset = 0x%" PRIx64, (u64) attr_meta->src_offset);
pandecode_indent--;
pandecode_log("},\n");
}
pandecode_indent--;
pandecode_log("};\n");
return max_index;
}
static void
pandecode_replay_indices(uintptr_t pindices, uint32_t index_count, int job_no)
{
struct pandecode_mapped_memory *imem = pandecode_find_mapped_gpu_mem_containing(pindices);
if (imem) {
/* Indices are literally just a u32 array :) */
uint32_t *PANDECODE_PTR_VAR(indices, imem, pindices);
pandecode_log("uint32_t indices_%d[] = {\n", job_no);
pandecode_indent++;
for (unsigned i = 0; i < (index_count + 1); i += 3)
pandecode_log("%d, %d, %d,\n",
indices[i],
indices[i + 1],
indices[i + 2]);
pandecode_indent--;
pandecode_log("};\n");
}
}
/* 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
return (word >> lo) & ((1 << (hi - lo)) - 1);
}
static void
pandecode_replay_vertex_tiler_prefix(struct mali_vertex_tiler_prefix *p, int job_no)
{
pandecode_log_cont("{\n");
pandecode_indent++;
panfrost: Add missing 0x in invocation_count Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 09:31:49 -07:00
pandecode_prop("invocation_count = 0x%" PRIx32, p->invocation_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
pandecode_prop("size_y_shift = %d", p->size_y_shift);
pandecode_prop("size_z_shift = %d", p->size_z_shift);
pandecode_prop("workgroups_x_shift = %d", p->workgroups_x_shift);
pandecode_prop("workgroups_y_shift = %d", p->workgroups_y_shift);
pandecode_prop("workgroups_z_shift = %d", p->workgroups_z_shift);
pandecode_prop("workgroups_x_shift_2 = 0x%" PRIx32, p->workgroups_x_shift_2);
/* Decode invocation_count. See the comment before the definition of
* invocation_count for an explanation.
*/
pandecode_msg("size: (%d, %d, %d)\n",
bits(p->invocation_count, 0, p->size_y_shift) + 1,
bits(p->invocation_count, p->size_y_shift, p->size_z_shift) + 1,
bits(p->invocation_count, p->size_z_shift,
p->workgroups_x_shift) + 1);
pandecode_msg("workgroups: (%d, %d, %d)\n",
bits(p->invocation_count, p->workgroups_x_shift,
p->workgroups_y_shift) + 1,
bits(p->invocation_count, p->workgroups_y_shift,
p->workgroups_z_shift) + 1,
bits(p->invocation_count, p->workgroups_z_shift,
32) + 1);
/* TODO: Decode */
panfrost/decode: Elide more zero fields Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 09:35:57 -07:00
if (p->unknown_draw)
pandecode_prop("unknown_draw = 0x%" PRIx32, p->unknown_draw);
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_prop("workgroups_x_shift_3 = 0x%" PRIx32, p->workgroups_x_shift_3);
pandecode_prop("draw_mode = %s", pandecode_draw_mode_name(p->draw_mode));
/* Index count only exists for tiler jobs anyway */
if (p->index_count)
pandecode_prop("index_count = MALI_POSITIVE(%" PRId32 ")", p->index_count + 1);
panfrost/decode: Elide more zero fields Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 09:35:57 -07:00
if (p->negative_start)
pandecode_prop("negative_start = %d", p->negative_start);
panfrost/decode: Print negative_start This property slipped through.. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-03-31 04:15:46 +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
DYN_MEMORY_PROP(p, job_no, indices);
if (p->zero1) {
pandecode_msg("Zero tripped\n");
pandecode_prop("zero1 = 0x%" PRIx32, p->zero1);
}
pandecode_indent--;
pandecode_log("},\n");
}
static void
pandecode_replay_uniform_buffers(mali_ptr pubufs, int ubufs_count, int job_no)
{
struct pandecode_mapped_memory *umem = pandecode_find_mapped_gpu_mem_containing(pubufs);
struct mali_uniform_buffer_meta *PANDECODE_PTR_VAR(ubufs, umem, pubufs);
for (int i = 0; i < ubufs_count; i++) {
mali_ptr ptr = ubufs[i].ptr << 2;
struct pandecode_mapped_memory *umem2 = pandecode_find_mapped_gpu_mem_containing(ptr);
uint32_t *PANDECODE_PTR_VAR(ubuf, umem2, ptr);
char name[50];
snprintf(name, sizeof(name), "ubuf_%d", i);
/* The blob uses ubuf 0 to upload internal stuff and
* uniforms that won't fit/are accessed indirectly, so
* it puts it in the batchbuffer.
*/
pandecode_log("uint32_t %s_%d[] = {\n", name, job_no);
pandecode_indent++;
for (int j = 0; j <= ubufs[i].size; j++) {
for (int k = 0; k < 4; k++) {
if (k == 0)
pandecode_log("0x%"PRIx32", ", ubuf[4 * j + k]);
else
pandecode_log_cont("0x%"PRIx32", ", ubuf[4 * j + k]);
}
pandecode_log_cont("\n");
}
pandecode_indent--;
pandecode_log("};\n");
}
pandecode_log("struct mali_uniform_buffer_meta uniform_buffers_%d[] = {\n",
job_no);
pandecode_indent++;
for (int i = 0; i < ubufs_count; i++) {
pandecode_log("{\n");
pandecode_indent++;
pandecode_prop("size = MALI_POSITIVE(%d)", ubufs[i].size + 1);
pandecode_prop("ptr = ubuf_%d_%d_p >> 2", i, job_no);
pandecode_indent--;
pandecode_log("},\n");
}
pandecode_indent--;
pandecode_log("};\n");
}
static void
pandecode_replay_scratchpad(uintptr_t pscratchpad, int job_no, char *suffix)
{
struct pandecode_mapped_memory *mem = pandecode_find_mapped_gpu_mem_containing(pscratchpad);
struct bifrost_scratchpad *PANDECODE_PTR_VAR(scratchpad, mem, pscratchpad);
if (scratchpad->zero)
pandecode_msg("XXX scratchpad zero tripped");
pandecode_log("struct bifrost_scratchpad scratchpad_%d%s = {\n", job_no, suffix);
pandecode_indent++;
pandecode_prop("flags = 0x%x", scratchpad->flags);
MEMORY_PROP(scratchpad, gpu_scratchpad);
pandecode_indent--;
pandecode_log("};\n");
}
static void
pandecode_shader_disassemble(mali_ptr shader_ptr, int shader_no, int type,
bool is_bifrost)
{
struct pandecode_mapped_memory *mem = pandecode_find_mapped_gpu_mem_containing(shader_ptr);
uint8_t *PANDECODE_PTR_VAR(code, mem, shader_ptr);
/* Compute maximum possible size */
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! */
printf("\n\n");
panfrost/decode: Disassemble Bifrost shaders We already have the Bifrost disassembler in-tree, so now that panwrap is able to dump Bifrost command streams, hook up the disassembler to pandecode. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Ryan Houdek <Sonicadvance1@gmail.com>
2019-05-18 18:58:56 +00:00
if (is_bifrost) {
disassemble_bifrost(code, sz, false);
} else {
disassemble_midgard(code, sz);
}
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
printf("\n\n");
}
static void
pandecode_replay_vertex_tiler_postfix_pre(const struct mali_vertex_tiler_postfix *p,
int job_no, enum mali_job_type job_type,
char *suffix, bool is_bifrost)
{
mali_ptr shader_meta_ptr = (u64) (uintptr_t) (p->_shader_upper << 4);
struct pandecode_mapped_memory *attr_mem;
panfrost/decode: Limit MRT blend count I thought I already fixed this. Maybe that was a dream...? Then again, I might be dreaming now. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-23 11:29:46 -07:00
unsigned rt_count = 1;
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
/* On Bifrost, since the tiler heap (for tiler jobs) and the scratchpad
* are the only things actually needed from the FBD, vertex/tiler jobs
* no longer reference the FBD -- instead, this field points to some
* info about the scratchpad.
*/
if (is_bifrost)
pandecode_replay_scratchpad(p->framebuffer & ~FBD_TYPE, job_no, suffix);
else if (p->framebuffer & MALI_MFBD)
panfrost/decode: Limit MRT blend count I thought I already fixed this. Maybe that was a dream...? Then again, I might be dreaming now. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-23 11:29:46 -07:00
rt_count = pandecode_replay_mfbd_bfr((u64) ((uintptr_t) p->framebuffer) & FBD_MASK, job_no, false);
panfrost/decode: Identify "compute FBD" There is fundamentally not a framebuffer associated with a compute job. Allocate a new structure for it so we don't mess up graphics when decoding. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 08:41:51 -07:00
else if (job_type == JOB_TYPE_COMPUTE)
pandecode_compute_fbd((u64) (uintptr_t) p->framebuffer, job_no);
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
pandecode_replay_sfbd((u64) (uintptr_t) p->framebuffer, job_no);
int varying_count = 0, attribute_count = 0, uniform_count = 0, uniform_buffer_count = 0;
int texture_count = 0, sampler_count = 0;
if (shader_meta_ptr) {
struct pandecode_mapped_memory *smem = pandecode_find_mapped_gpu_mem_containing(shader_meta_ptr);
struct mali_shader_meta *PANDECODE_PTR_VAR(s, smem, shader_meta_ptr);
pandecode_log("struct mali_shader_meta shader_meta_%d%s = {\n", job_no, suffix);
pandecode_indent++;
/* Save for dumps */
attribute_count = s->attribute_count;
varying_count = s->varying_count;
texture_count = s->texture_count;
sampler_count = s->sampler_count;
if (is_bifrost) {
uniform_count = s->bifrost2.uniform_count;
uniform_buffer_count = s->bifrost1.uniform_buffer_count;
} else {
uniform_count = s->midgard1.uniform_count;
panfrost: Identify "uniform buffer count" bits We've known about this for a while, but it was never formally in the machine header files / decoder, so let's add them in. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-20 16:41:39 -07:00
uniform_buffer_count = s->midgard1.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
}
mali_ptr shader_ptr = pandecode_replay_shader_address("shader", s->shader);
pandecode_prop("texture_count = %" PRId16, s->texture_count);
pandecode_prop("sampler_count = %" PRId16, s->sampler_count);
pandecode_prop("attribute_count = %" PRId16, s->attribute_count);
pandecode_prop("varying_count = %" PRId16, s->varying_count);
if (is_bifrost) {
pandecode_log(".bifrost1 = {\n");
pandecode_indent++;
pandecode_prop("uniform_buffer_count = %" PRId32, s->bifrost1.uniform_buffer_count);
pandecode_prop("unk1 = 0x%" PRIx32, s->bifrost1.unk1);
pandecode_indent--;
pandecode_log("},\n");
} else {
pandecode_log(".midgard1 = {\n");
pandecode_indent++;
pandecode_prop("uniform_count = %" PRId16, s->midgard1.uniform_count);
panfrost: Identify "uniform buffer count" bits We've known about this for a while, but it was never formally in the machine header files / decoder, so let's add them in. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-20 16:41:39 -07:00
pandecode_prop("uniform_buffer_count = %" PRId16, s->midgard1.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
pandecode_prop("work_count = %" PRId16, s->midgard1.work_count);
panfrost/decode: Add flags for tilebuffer readback These flags are set when reading back the tilebuffer from a fragment shader via various mechanisms (including ARM_shader_framebuffer_fetch and EXT_pixel_local_storage). Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-04-05 01:17:21 +00:00
panfrost: Identify "uniform buffer count" bits We've known about this for a while, but it was never formally in the machine header files / decoder, so let's add them in. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-20 16:41:39 -07:00
pandecode_log(".flags = ");
pandecode_log_decoded_flags(shader_midgard1_flag_info, s->midgard1.flags);
panfrost/decode: Add flags for tilebuffer readback These flags are set when reading back the tilebuffer from a fragment shader via various mechanisms (including ARM_shader_framebuffer_fetch and EXT_pixel_local_storage). Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-04-05 01:17:21 +00:00
pandecode_log_cont(",\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_prop("unknown2 = 0x%" PRIx32, s->midgard1.unknown2);
pandecode_indent--;
pandecode_log("},\n");
}
if (s->depth_units || s->depth_factor) {
if (is_bifrost)
pandecode_prop("depth_units = %f", s->depth_units);
else
pandecode_prop("depth_units = MALI_NEGATIVE(%f)", s->depth_units - 1.0f);
pandecode_prop("depth_factor = %f", s->depth_factor);
}
panfrost/decode: Skip decode of fragment backend in non-fragment This is all zero for anything but fragment shaders. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 09:31:16 -07:00
if (s->alpha_coverage) {
bool invert_alpha_coverage = s->alpha_coverage & 0xFFF0;
uint16_t inverted_coverage = invert_alpha_coverage ? ~s->alpha_coverage : s->alpha_coverage;
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
panfrost/decode: Skip decode of fragment backend in non-fragment This is all zero for anything but fragment shaders. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 09:31:16 -07:00
pandecode_prop("alpha_coverage = %sMALI_ALPHA_COVERAGE(%f)",
invert_alpha_coverage ? "~" : "",
MALI_GET_ALPHA_COVERAGE(inverted_coverage));
}
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
panfrost/decode: Skip decode of fragment backend in non-fragment This is all zero for anything but fragment shaders. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 09:31:16 -07:00
if (s->unknown2_3 || s->unknown2_4) {
pandecode_log(".unknown2_3 = ");
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
panfrost/decode: Skip decode of fragment backend in non-fragment This is all zero for anything but fragment shaders. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 09:31:16 -07:00
int unknown2_3 = s->unknown2_3;
int unknown2_4 = s->unknown2_4;
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
panfrost/decode: Skip decode of fragment backend in non-fragment This is all zero for anything but fragment shaders. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 09:31:16 -07:00
/* We're not quite sure what these flags mean without the depth test, if anything */
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
panfrost/decode: Skip decode of fragment backend in non-fragment This is all zero for anything but fragment shaders. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 09:31:16 -07:00
if (unknown2_3 & (MALI_DEPTH_TEST | MALI_DEPTH_FUNC_MASK)) {
const char *func = pandecode_func_name(MALI_GET_DEPTH_FUNC(unknown2_3));
unknown2_3 &= ~MALI_DEPTH_FUNC_MASK;
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
panfrost/decode: Skip decode of fragment backend in non-fragment This is all zero for anything but fragment shaders. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 09:31:16 -07:00
pandecode_log_cont("MALI_DEPTH_FUNC(%s) | ", func);
}
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
panfrost/decode: Skip decode of fragment backend in non-fragment This is all zero for anything but fragment shaders. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 09:31:16 -07:00
pandecode_log_decoded_flags(u3_flag_info, unknown2_3);
pandecode_log_cont(",\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
panfrost/decode: Skip decode of fragment backend in non-fragment This is all zero for anything but fragment shaders. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 09:31:16 -07:00
pandecode_log(".unknown2_4 = ");
pandecode_log_decoded_flags(u4_flag_info, unknown2_4);
pandecode_log_cont(",\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
panfrost/decode: Skip decode of fragment backend in non-fragment This is all zero for anything but fragment shaders. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 09:31:16 -07:00
if (s->stencil_mask_front || s->stencil_mask_back) {
pandecode_prop("stencil_mask_front = 0x%02X", s->stencil_mask_front);
pandecode_prop("stencil_mask_back = 0x%02X", s->stencil_mask_back);
}
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_replay_stencil("front", &s->stencil_front);
pandecode_replay_stencil("back", &s->stencil_back);
if (is_bifrost) {
pandecode_log(".bifrost2 = {\n");
pandecode_indent++;
pandecode_prop("unk3 = 0x%" PRIx32, s->bifrost2.unk3);
pandecode_prop("preload_regs = 0x%" PRIx32, s->bifrost2.preload_regs);
pandecode_prop("uniform_count = %" PRId32, s->bifrost2.uniform_count);
pandecode_prop("unk4 = 0x%" PRIx32, s->bifrost2.unk4);
pandecode_indent--;
pandecode_log("},\n");
panfrost/decode: Skip decode of fragment backend in non-fragment This is all zero for anything but fragment shaders. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 09:31:16 -07:00
} else if (s->midgard2.unknown2_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
pandecode_log(".midgard2 = {\n");
pandecode_indent++;
pandecode_prop("unknown2_7 = 0x%" PRIx32, s->midgard2.unknown2_7);
pandecode_indent--;
pandecode_log("},\n");
}
panfrost/decode: Skip decode of fragment backend in non-fragment This is all zero for anything but fragment shaders. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 09:31:16 -07:00
if (s->unknown2_8)
pandecode_prop("unknown2_8 = 0x%" PRIx32, s->unknown2_8);
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 (!is_bifrost) {
panfrost: Refactor blend descriptors This commit does a fairly large cleanup of blend descriptors, although there should not be any functional changes. In particular, we split apart the Midgard and Bifrost blend descriptors, since they are radically different. From there, we can identify that the Midgard descriptor as previously written was really two render targets' descriptors stuck together. From this observation, we split the Midgard descriptor into what a single RT actually needs. This enables us to correctly dump blending configuration for MRT samples on Midgard. It also allows the Midgard and Bifrost blend code to peacefully coexist, with runtime selection rather than a #ifdef. So, as a bonus, this will help the future Bifrost effort, eliminating one major source of compile-time architectural divergence. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-05-04 21:57:01 +00:00
/* TODO: Blend shaders routing/disasm */
pandecode_midgard_blend(&s->blend, 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
}
pandecode_indent--;
pandecode_log("};\n");
panfrost: Refactor blend descriptors This commit does a fairly large cleanup of blend descriptors, although there should not be any functional changes. In particular, we split apart the Midgard and Bifrost blend descriptors, since they are radically different. From there, we can identify that the Midgard descriptor as previously written was really two render targets' descriptors stuck together. From this observation, we split the Midgard descriptor into what a single RT actually needs. This enables us to correctly dump blending configuration for MRT samples on Midgard. It also allows the Midgard and Bifrost blend code to peacefully coexist, with runtime selection rather than a #ifdef. So, as a bonus, this will help the future Bifrost effort, eliminating one major source of compile-time architectural divergence. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
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
if (job_type == JOB_TYPE_TILER) {
panfrost: Refactor blend descriptors This commit does a fairly large cleanup of blend descriptors, although there should not be any functional changes. In particular, we split apart the Midgard and Bifrost blend descriptors, since they are radically different. From there, we can identify that the Midgard descriptor as previously written was really two render targets' descriptors stuck together. From this observation, we split the Midgard descriptor into what a single RT actually needs. This enables us to correctly dump blending configuration for MRT samples on Midgard. It also allows the Midgard and Bifrost blend code to peacefully coexist, with runtime selection rather than a #ifdef. So, as a bonus, this will help the future Bifrost effort, eliminating one major source of compile-time architectural divergence. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-05-04 21:57:01 +00:00
void* blend_base = (void *) (s + 1);
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
panfrost/decode: Limit MRT blend count I thought I already fixed this. Maybe that was a dream...? Then again, I might be dreaming now. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-23 11:29:46 -07:00
for (unsigned i = 0; i < rt_count; i++) {
panfrost: Refactor blend descriptors This commit does a fairly large cleanup of blend descriptors, although there should not be any functional changes. In particular, we split apart the Midgard and Bifrost blend descriptors, since they are radically different. From there, we can identify that the Midgard descriptor as previously written was really two render targets' descriptors stuck together. From this observation, we split the Midgard descriptor into what a single RT actually needs. This enables us to correctly dump blending configuration for MRT samples on Midgard. It also allows the Midgard and Bifrost blend code to peacefully coexist, with runtime selection rather than a #ifdef. So, as a bonus, this will help the future Bifrost effort, eliminating one major source of compile-time architectural divergence. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-05-04 21:57:01 +00:00
mali_ptr shader = 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
panfrost: Refactor blend descriptors This commit does a fairly large cleanup of blend descriptors, although there should not be any functional changes. In particular, we split apart the Midgard and Bifrost blend descriptors, since they are radically different. From there, we can identify that the Midgard descriptor as previously written was really two render targets' descriptors stuck together. From this observation, we split the Midgard descriptor into what a single RT actually needs. This enables us to correctly dump blending configuration for MRT samples on Midgard. It also allows the Midgard and Bifrost blend code to peacefully coexist, with runtime selection rather than a #ifdef. So, as a bonus, this will help the future Bifrost effort, eliminating one major source of compile-time architectural divergence. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-05-04 21:57:01 +00:00
if (is_bifrost)
shader = pandecode_bifrost_blend(blend_base, job_no, i);
else
shader = pandecode_midgard_blend_mrt(blend_base, job_no, 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
panfrost: Refactor blend descriptors This commit does a fairly large cleanup of blend descriptors, although there should not be any functional changes. In particular, we split apart the Midgard and Bifrost blend descriptors, since they are radically different. From there, we can identify that the Midgard descriptor as previously written was really two render targets' descriptors stuck together. From this observation, we split the Midgard descriptor into what a single RT actually needs. This enables us to correctly dump blending configuration for MRT samples on Midgard. It also allows the Midgard and Bifrost blend code to peacefully coexist, with runtime selection rather than a #ifdef. So, as a bonus, this will help the future Bifrost effort, eliminating one major source of compile-time architectural divergence. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-05-04 21:57:01 +00:00
if (shader)
pandecode_shader_disassemble(shader, job_no, job_type, 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
}
pandecode_shader_disassemble(shader_ptr, job_no, job_type, is_bifrost);
} else
pandecode_msg("<no shader>\n");
if (p->viewport) {
struct pandecode_mapped_memory *fmem = pandecode_find_mapped_gpu_mem_containing(p->viewport);
struct mali_viewport *PANDECODE_PTR_VAR(f, fmem, p->viewport);
pandecode_log("struct mali_viewport viewport_%d%s = {\n", job_no, suffix);
pandecode_indent++;
pandecode_prop("clip_minx = %f", f->clip_minx);
pandecode_prop("clip_miny = %f", f->clip_miny);
pandecode_prop("clip_minz = %f", f->clip_minz);
pandecode_prop("clip_maxx = %f", f->clip_maxx);
pandecode_prop("clip_maxy = %f", f->clip_maxy);
pandecode_prop("clip_maxz = %f", f->clip_maxz);
/* Only the higher coordinates are MALI_POSITIVE scaled */
pandecode_prop("viewport0 = { %d, %d }",
f->viewport0[0], f->viewport0[1]);
pandecode_prop("viewport1 = { MALI_POSITIVE(%d), MALI_POSITIVE(%d) }",
f->viewport1[0] + 1, f->viewport1[1] + 1);
pandecode_indent--;
pandecode_log("};\n");
}
if (p->attribute_meta) {
unsigned max_attr_index = pandecode_replay_attribute_meta(job_no, attribute_count, p, false, suffix);
attr_mem = pandecode_find_mapped_gpu_mem_containing(p->attributes);
pandecode_replay_attributes(attr_mem, p->attributes, job_no, suffix, max_attr_index + 1, false);
}
/* Varyings are encoded like attributes but not actually sent; we just
* pass a zero buffer with the right stride/size set, (or whatever)
* since the GPU will write to it itself */
if (p->varyings) {
attr_mem = pandecode_find_mapped_gpu_mem_containing(p->varyings);
/* Number of descriptors depends on whether there are
* non-internal varyings */
panfrost: Replay more varying buffers This is required for gl_PointCoord to show up on decodes. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-03-15 03:34:25 +00:00
pandecode_replay_attributes(attr_mem, p->varyings, job_no, suffix, varying_count > 1 ? 4 : 1, true);
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->varying_meta) {
pandecode_replay_attribute_meta(job_no, varying_count, p, true, suffix);
}
panfrost/decode: Print COMPUTE uniforms as pointers In OpenGL, uniforms generally represent fp32 vec4s (at least in highp mode). In OpenCL, they represent vec2s of 64-bit pointers. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 09:07:13 -07:00
bool is_compute = job_type == JOB_TYPE_COMPUTE;
if (p->uniforms && !is_compute) {
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 rows = uniform_count, width = 4;
size_t sz = rows * width * sizeof(float);
struct pandecode_mapped_memory *uniform_mem = pandecode_find_mapped_gpu_mem_containing(p->uniforms);
pandecode_fetch_gpu_mem(uniform_mem, p->uniforms, sz);
panfrost/decode: Show int uniforms Float is ambiguous. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 08:59:23 -07:00
u32 *PANDECODE_PTR_VAR(uniforms, uniform_mem, p->uniforms);
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
panfrost/decode: Show int uniforms Float is ambiguous. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 08:59:23 -07:00
pandecode_log("u32 uniforms_%d%s[] = {\n", job_no, suffix);
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++;
for (int row = 0; row < rows; row++) {
panfrost/decode: Show int uniforms Float is ambiguous. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 08:59:23 -07:00
for (int i = 0; i < width; i++) {
u32 v = uniforms[i];
float f;
memcpy(&f, &v, sizeof(v));
pandecode_log_cont("%X /* %f */, ", v, f);
}
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_log_cont("\n");
uniforms += width;
}
pandecode_indent--;
pandecode_log("};\n");
panfrost/decode: Print COMPUTE uniforms as pointers In OpenGL, uniforms generally represent fp32 vec4s (at least in highp mode). In OpenCL, they represent vec2s of 64-bit pointers. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 09:07:13 -07:00
} else if (p->uniforms) {
int rows = uniform_count * 2;
size_t sz = rows * sizeof(mali_ptr);
struct pandecode_mapped_memory *uniform_mem = pandecode_find_mapped_gpu_mem_containing(p->uniforms);
pandecode_fetch_gpu_mem(uniform_mem, p->uniforms, sz);
mali_ptr *PANDECODE_PTR_VAR(uniforms, uniform_mem, p->uniforms);
pandecode_log("mali_ptr uniforms_%d%s[] = {\n", job_no, suffix);
pandecode_indent++;
for (int row = 0; row < rows; row++) {
char *a = pointer_as_memory_reference(uniforms[row]);
pandecode_log("%s,\n", a);
free(a);
}
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
}
if (p->uniform_buffers) {
pandecode_replay_uniform_buffers(p->uniform_buffers, uniform_buffer_count, job_no);
}
if (p->texture_trampoline) {
struct pandecode_mapped_memory *mmem = pandecode_find_mapped_gpu_mem_containing(p->texture_trampoline);
if (mmem) {
mali_ptr *PANDECODE_PTR_VAR(u, mmem, p->texture_trampoline);
pandecode_log("uint64_t texture_trampoline_%d[] = {\n", job_no);
pandecode_indent++;
for (int tex = 0; tex < texture_count; ++tex) {
mali_ptr *PANDECODE_PTR_VAR(u, mmem, p->texture_trampoline + tex * sizeof(mali_ptr));
char *a = pointer_as_memory_reference(*u);
pandecode_log("%s,\n", a);
free(a);
}
pandecode_indent--;
pandecode_log("};\n");
/* Now, finally, descend down into the texture descriptor */
for (int tex = 0; tex < texture_count; ++tex) {
mali_ptr *PANDECODE_PTR_VAR(u, mmem, p->texture_trampoline + tex * sizeof(mali_ptr));
struct pandecode_mapped_memory *tmem = pandecode_find_mapped_gpu_mem_containing(*u);
if (tmem) {
struct mali_texture_descriptor *PANDECODE_PTR_VAR(t, tmem, *u);
pandecode_log("struct mali_texture_descriptor texture_descriptor_%d_%d = {\n", job_no, tex);
pandecode_indent++;
pandecode_prop("width = MALI_POSITIVE(%" PRId16 ")", t->width + 1);
pandecode_prop("height = MALI_POSITIVE(%" PRId16 ")", t->height + 1);
pandecode_prop("depth = MALI_POSITIVE(%" PRId16 ")", t->depth + 1);
panfrost: Decode array textures Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-14 16:23:32 -07:00
pandecode_prop("array_size = MALI_POSITIVE(%" PRId16 ")", t->array_size + 1);
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_prop("unknown3 = %" PRId16, t->unknown3);
pandecode_prop("unknown3A = %" PRId8, t->unknown3A);
pandecode_prop("nr_mipmap_levels = %" PRId8, t->nr_mipmap_levels);
struct mali_texture_format f = t->format;
pandecode_log(".format = {\n");
pandecode_indent++;
pandecode_replay_swizzle(f.swizzle);
pandecode_prop("format = %s", pandecode_format_name(f.format));
panfrost: Refactor texture targets This combines the two cmdstream bits "is_3d" and "is_not_cubemap" into a single 2-bit texture target selection, noticing it's the same as the 2-bit selection in Midgard and Bifrost texturing ops. Accordingly, we share this definition and add the missing entry for 1D/buffer textures. This requires a nontrivial (but functionally similar) refactor of all parts of the driver to use the new definitions appropriately. Theoretically, this should add support for buffer textures, but that's obviously not tested and probably wouldn't work. While doing so, we notice the sRGB enable bit, which we document and decode as well here so we don't forget about it. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-17 14:26:08 -07:00
pandecode_prop("type = %s", pandecode_texture_type(f.type));
pandecode_prop("srgb = %" PRId32, f.srgb);
pandecode_prop("unknown1 = %" PRId32, f.unknown1);
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_prop("usage2 = 0x%" PRIx32, f.usage2);
pandecode_indent--;
pandecode_log("},\n");
pandecode_replay_swizzle(t->swizzle);
if (t->swizzle_zero) {
/* Shouldn't happen */
pandecode_msg("Swizzle zero tripped but replay will be fine anyway");
pandecode_prop("swizzle_zero = %d", t->swizzle_zero);
}
pandecode_prop("unknown3 = 0x%" PRIx32, t->unknown3);
pandecode_prop("unknown5 = 0x%" PRIx32, t->unknown5);
pandecode_prop("unknown6 = 0x%" PRIx32, t->unknown6);
pandecode_prop("unknown7 = 0x%" PRIx32, t->unknown7);
panfrost: Refactor texture/sampler upload We move some coding packing the texture/sampler descriptors into dedicated functions (out of the terrifyingly long emit_for_draw monolith), cleaning them up as we go. The discovery triggering the cleanup is the format for including manual strides in the presence of mipmaps/cubemaps. Rather than placed at the end like previously assumed, they are interleaved after each address. This difference is relevant when handling NPOT linear mipmaps. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-07 14:25:28 -07:00
pandecode_log(".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
pandecode_indent++;
panfrost/decode: Futureproof texture dumping One field was not dumped for some reason. It's observed to be 0, but it's still good to have it available. Also, extra fields might be snuck in the bitmaps array (it's variable-lengthed at the end), and we want to guard against that possibility, so we dump a little more. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-05-14 22:21:39 +00:00
/* A bunch of bitmap pointers follow.
* We work out the correct number,
* based on the mipmap/cubemap
* properties, but dump extra
* possibilities to futureproof */
panfrost/decode: Decode all cubemap faces Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-03-28 01:59:02 +00:00
int bitmap_count = MALI_NEGATIVE(t->nr_mipmap_levels);
panfrost: Refactor texture/sampler upload We move some coding packing the texture/sampler descriptors into dedicated functions (out of the terrifyingly long emit_for_draw monolith), cleaning them up as we go. The discovery triggering the cleanup is the format for including manual strides in the presence of mipmaps/cubemaps. Rather than placed at the end like previously assumed, they are interleaved after each address. This difference is relevant when handling NPOT linear mipmaps. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-07 14:25:28 -07:00
bool manual_stride = f.usage2 & MALI_TEX_MANUAL_STRIDE;
panfrost/decode: Decode all cubemap faces Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-03-28 01:59:02 +00:00
panfrost: Refactor texture/sampler upload We move some coding packing the texture/sampler descriptors into dedicated functions (out of the terrifyingly long emit_for_draw monolith), cleaning them up as we go. The discovery triggering the cleanup is the format for including manual strides in the presence of mipmaps/cubemaps. Rather than placed at the end like previously assumed, they are interleaved after each address. This difference is relevant when handling NPOT linear mipmaps. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-07 14:25:28 -07:00
/* Miptree for each face */
panfrost: Refactor texture targets This combines the two cmdstream bits "is_3d" and "is_not_cubemap" into a single 2-bit texture target selection, noticing it's the same as the 2-bit selection in Midgard and Bifrost texturing ops. Accordingly, we share this definition and add the missing entry for 1D/buffer textures. This requires a nontrivial (but functionally similar) refactor of all parts of the driver to use the new definitions appropriately. Theoretically, this should add support for buffer textures, but that's obviously not tested and probably wouldn't work. While doing so, we notice the sRGB enable bit, which we document and decode as well here so we don't forget about it. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-17 14:26:08 -07:00
if (f.type == MALI_TEX_CUBE)
panfrost/decode: Decode all cubemap faces Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-03-28 01:59:02 +00:00
bitmap_count *= 6;
panfrost/decode: Stride decoding With a special flag, texture descriptors can include custom stride(s). We haven't seen a case of this used for mipmaps/cubemaps, so it's not clear how that will be encoded, but this dumps correctly for single one-level 2D textures. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-05-14 22:42:47 +00:00
panfrost: Decode array textures Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-14 16:23:32 -07:00
/* Array of textures */
bitmap_count *= MALI_NEGATIVE(t->array_size);
panfrost: Refactor texture/sampler upload We move some coding packing the texture/sampler descriptors into dedicated functions (out of the terrifyingly long emit_for_draw monolith), cleaning them up as we go. The discovery triggering the cleanup is the format for including manual strides in the presence of mipmaps/cubemaps. Rather than placed at the end like previously assumed, they are interleaved after each address. This difference is relevant when handling NPOT linear mipmaps. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-07 14:25:28 -07:00
/* Stride for each element */
if (manual_stride)
bitmap_count *= 2;
panfrost/decode: Stride decoding With a special flag, texture descriptors can include custom stride(s). We haven't seen a case of this used for mipmaps/cubemaps, so it's not clear how that will be encoded, but this dumps correctly for single one-level 2D textures. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-05-14 22:42:47 +00:00
panfrost: Refactor texture/sampler upload We move some coding packing the texture/sampler descriptors into dedicated functions (out of the terrifyingly long emit_for_draw monolith), cleaning them up as we go. The discovery triggering the cleanup is the format for including manual strides in the presence of mipmaps/cubemaps. Rather than placed at the end like previously assumed, they are interleaved after each address. This difference is relevant when handling NPOT linear mipmaps. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-07 14:25:28 -07:00
/* Sanity check the size */
int max_count = sizeof(t->payload) / sizeof(t->payload[0]);
assert (bitmap_count <= max_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
panfrost/decode: Futureproof texture dumping One field was not dumped for some reason. It's observed to be 0, but it's still good to have it available. Also, extra fields might be snuck in the bitmaps array (it's variable-lengthed at the end), and we want to guard against that possibility, so we dump a little more. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-05-14 22:21:39 +00:00
/* Dump more to be safe, but not _that_ much more */
int safe_count = MIN2(bitmap_count * 2, max_count);
for (int i = 0; i < safe_count; ++i) {
panfrost/decode: Stride decoding With a special flag, texture descriptors can include custom stride(s). We haven't seen a case of this used for mipmaps/cubemaps, so it's not clear how that will be encoded, but this dumps correctly for single one-level 2D textures. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-05-14 22:42:47 +00:00
char *prefix = (i >= bitmap_count) ? "// " : "";
/* How we dump depends if this is a stride or a pointer */
panfrost: Refactor texture/sampler upload We move some coding packing the texture/sampler descriptors into dedicated functions (out of the terrifyingly long emit_for_draw monolith), cleaning them up as we go. The discovery triggering the cleanup is the format for including manual strides in the presence of mipmaps/cubemaps. Rather than placed at the end like previously assumed, they are interleaved after each address. This difference is relevant when handling NPOT linear mipmaps. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-07 14:25:28 -07:00
if ((f.usage2 & MALI_TEX_MANUAL_STRIDE) && (i & 1)) {
panfrost/decode: Stride decoding With a special flag, texture descriptors can include custom stride(s). We haven't seen a case of this used for mipmaps/cubemaps, so it's not clear how that will be encoded, but this dumps correctly for single one-level 2D textures. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-05-14 22:42:47 +00:00
/* signed 32-bit snuck in as a 64-bit pointer */
panfrost: Refactor texture/sampler upload We move some coding packing the texture/sampler descriptors into dedicated functions (out of the terrifyingly long emit_for_draw monolith), cleaning them up as we go. The discovery triggering the cleanup is the format for including manual strides in the presence of mipmaps/cubemaps. Rather than placed at the end like previously assumed, they are interleaved after each address. This difference is relevant when handling NPOT linear mipmaps. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-07 14:25:28 -07:00
uint64_t stride_set = t->payload[i];
panfrost/decode: Stride decoding With a special flag, texture descriptors can include custom stride(s). We haven't seen a case of this used for mipmaps/cubemaps, so it's not clear how that will be encoded, but this dumps correctly for single one-level 2D textures. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-05-14 22:42:47 +00:00
uint32_t clamped_stride = stride_set;
int32_t stride = clamped_stride;
assert(stride_set == clamped_stride);
pandecode_log("%s(mali_ptr) %d /* stride */, \n", prefix, stride);
} else {
panfrost: Refactor texture/sampler upload We move some coding packing the texture/sampler descriptors into dedicated functions (out of the terrifyingly long emit_for_draw monolith), cleaning them up as we go. The discovery triggering the cleanup is the format for including manual strides in the presence of mipmaps/cubemaps. Rather than placed at the end like previously assumed, they are interleaved after each address. This difference is relevant when handling NPOT linear mipmaps. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-07 14:25:28 -07:00
char *a = pointer_as_memory_reference(t->payload[i]);
panfrost/decode: Stride decoding With a special flag, texture descriptors can include custom stride(s). We haven't seen a case of this used for mipmaps/cubemaps, so it's not clear how that will be encoded, but this dumps correctly for single one-level 2D textures. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-05-14 22:42:47 +00:00
pandecode_log("%s%s, \n", prefix, a);
free(a);
}
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--;
pandecode_log("},\n");
pandecode_indent--;
pandecode_log("};\n");
}
}
}
}
if (p->sampler_descriptor) {
struct pandecode_mapped_memory *smem = pandecode_find_mapped_gpu_mem_containing(p->sampler_descriptor);
if (smem) {
struct mali_sampler_descriptor *s;
mali_ptr d = p->sampler_descriptor;
for (int i = 0; i < sampler_count; ++i) {
s = pandecode_fetch_gpu_mem(smem, d + sizeof(*s) * i, sizeof(*s));
pandecode_log("struct mali_sampler_descriptor sampler_descriptor_%d_%d = {\n", job_no, i);
pandecode_indent++;
/* Only the lower two bits are understood right now; the rest we display as hex */
pandecode_log(".filter_mode = MALI_TEX_MIN(%s) | MALI_TEX_MAG(%s) | 0x%" PRIx32",\n",
MALI_FILTER_NAME(s->filter_mode & MALI_TEX_MIN_MASK),
MALI_FILTER_NAME(s->filter_mode & MALI_TEX_MAG_MASK),
s->filter_mode & ~3);
pandecode_prop("min_lod = FIXED_16(%f)", DECODE_FIXED_16(s->min_lod));
pandecode_prop("max_lod = FIXED_16(%f)", DECODE_FIXED_16(s->max_lod));
pandecode_prop("wrap_s = %s", pandecode_wrap_mode_name(s->wrap_s));
pandecode_prop("wrap_t = %s", pandecode_wrap_mode_name(s->wrap_t));
pandecode_prop("wrap_r = %s", pandecode_wrap_mode_name(s->wrap_r));
pandecode_prop("compare_func = %s", pandecode_alt_func_name(s->compare_func));
if (s->zero || s->zero2) {
pandecode_msg("Zero tripped\n");
pandecode_prop("zero = 0x%X, 0x%X\n", s->zero, s->zero2);
}
panfrost: Support (non-)seamless cube maps Identify the seamless cubemap bit and passthrough the Gallium state rather than setting unconditionally. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-24 09:16:11 -07:00
pandecode_prop("seamless_cube_map = %d", s->seamless_cube_map);
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_prop("border_color = { %f, %f, %f, %f }",
s->border_color[0],
s->border_color[1],
s->border_color[2],
s->border_color[3]);
pandecode_indent--;
pandecode_log("};\n");
}
}
}
}
static void
pandecode_replay_vertex_tiler_postfix(const struct mali_vertex_tiler_postfix *p, int job_no, bool is_bifrost)
{
pandecode_log_cont("{\n");
pandecode_indent++;
MEMORY_PROP(p, position_varying);
DYN_MEMORY_PROP(p, job_no, uniform_buffers);
DYN_MEMORY_PROP(p, job_no, texture_trampoline);
DYN_MEMORY_PROP(p, job_no, sampler_descriptor);
DYN_MEMORY_PROP(p, job_no, uniforms);
DYN_MEMORY_PROP(p, job_no, attributes);
DYN_MEMORY_PROP(p, job_no, attribute_meta);
DYN_MEMORY_PROP(p, job_no, varyings);
DYN_MEMORY_PROP(p, job_no, varying_meta);
DYN_MEMORY_PROP(p, job_no, viewport);
DYN_MEMORY_PROP(p, job_no, occlusion_counter);
if (is_bifrost)
pandecode_prop("framebuffer = scratchpad_%d_p", job_no);
else
pandecode_prop("framebuffer = framebuffer_%d_p | %s", job_no, p->framebuffer & MALI_MFBD ? "MALI_MFBD" : "0");
pandecode_prop("_shader_upper = (shader_meta_%d_p) >> 4", job_no);
pandecode_prop("flags = %d", p->flags);
pandecode_indent--;
pandecode_log("},\n");
}
static void
pandecode_replay_vertex_only_bfr(struct bifrost_vertex_only *v)
{
pandecode_log_cont("{\n");
pandecode_indent++;
pandecode_prop("unk2 = 0x%x", v->unk2);
if (v->zero0 || v->zero1) {
pandecode_msg("vertex only zero tripped");
pandecode_prop("zero0 = 0x%" PRIx32, v->zero0);
pandecode_prop("zero1 = 0x%" PRIx64, v->zero1);
}
pandecode_indent--;
pandecode_log("}\n");
}
static void
pandecode_replay_tiler_heap_meta(mali_ptr gpu_va, int job_no)
{
struct pandecode_mapped_memory *mem = pandecode_find_mapped_gpu_mem_containing(gpu_va);
const struct bifrost_tiler_heap_meta *PANDECODE_PTR_VAR(h, mem, gpu_va);
pandecode_log("struct mali_tiler_heap_meta tiler_heap_meta_%d = {\n", job_no);
pandecode_indent++;
if (h->zero) {
pandecode_msg("tiler heap zero tripped\n");
pandecode_prop("zero = 0x%x", h->zero);
}
for (int i = 0; i < 12; i++) {
if (h->zeros[i] != 0) {
pandecode_msg("tiler heap zero %d tripped, value %x\n",
i, h->zeros[i]);
}
}
pandecode_prop("heap_size = 0x%x", h->heap_size);
MEMORY_PROP(h, tiler_heap_start);
MEMORY_PROP(h, tiler_heap_free);
/* this might point to the beginning of another buffer, when it's
* really the end of the tiler heap buffer, so we have to be careful
* here.
*/
char *a = pointer_as_memory_reference(h->tiler_heap_end - 1);
pandecode_prop("tiler_heap_end = %s + 1", a);
free(a);
pandecode_indent--;
pandecode_log("};\n");
}
static void
pandecode_replay_tiler_meta(mali_ptr gpu_va, int job_no)
{
struct pandecode_mapped_memory *mem = pandecode_find_mapped_gpu_mem_containing(gpu_va);
const struct bifrost_tiler_meta *PANDECODE_PTR_VAR(t, mem, gpu_va);
pandecode_replay_tiler_heap_meta(t->tiler_heap_meta, job_no);
panfrost: Rename tiler fields per tiler research Following the research into Midgard's hierarchical tiling infrastructure, we now understand (in broad stokes) the purpose of each tiler field in the MFBD. Additionally, we understand more of the tiling fields in the SFBD and in Bifrost's structures, although this knowledge is still incomplete. Update the names, decoder, and comments to reflect this new understanding. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-13 10:25:32 -07:00
pandecode_log("struct bifrost_tiler_meta tiler_meta_%d = {\n", job_no);
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++;
if (t->zero0 || t->zero1) {
pandecode_msg("tiler meta zero tripped");
pandecode_prop("zero0 = 0x%" PRIx64, t->zero0);
pandecode_prop("zero1 = 0x%" PRIx64, t->zero1);
}
panfrost: Rename tiler fields per tiler research Following the research into Midgard's hierarchical tiling infrastructure, we now understand (in broad stokes) the purpose of each tiler field in the MFBD. Additionally, we understand more of the tiling fields in the SFBD and in Bifrost's structures, although this knowledge is still incomplete. Update the names, decoder, and comments to reflect this new understanding. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-13 10:25:32 -07:00
pandecode_prop("hierarchy_mask = 0x%" PRIx16, t->hierarchy_mask);
pandecode_prop("flags = 0x%" PRIx16, t->flags);
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_prop("width = MALI_POSITIVE(%d)", t->width + 1);
pandecode_prop("height = MALI_POSITIVE(%d)", t->height + 1);
DYN_MEMORY_PROP(t, job_no, tiler_heap_meta);
for (int i = 0; i < 12; i++) {
if (t->zeros[i] != 0) {
pandecode_msg("tiler heap zero %d tripped, value %" PRIx64 "\n",
i, t->zeros[i]);
}
}
pandecode_indent--;
pandecode_log("};\n");
}
static void
pandecode_replay_gl_enables(uint32_t gl_enables, int job_type)
{
pandecode_log(".gl_enables = ");
pandecode_log_decoded_flags(gl_enable_flag_info, gl_enables);
pandecode_log_cont(",\n");
}
static void
pandecode_replay_primitive_size(union midgard_primitive_size u, bool constant)
{
panfrost/decode: Elide more zero fields Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 09:35:57 -07:00
if (u.pointer == 0x0)
return;
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_log(".primitive_size = {\n");
pandecode_indent++;
panfrost/decode: Respect primitive size pointers Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-03-15 03:21:27 +00:00
if (constant) {
pandecode_prop("constant = %f", u.constant);
} else {
MEMORY_PROP((&u), 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
pandecode_indent--;
pandecode_log("},\n");
}
static void
pandecode_replay_tiler_only_bfr(const struct bifrost_tiler_only *t, int job_no)
{
pandecode_log_cont("{\n");
pandecode_indent++;
/* TODO: gl_PointSize on Bifrost */
pandecode_replay_primitive_size(t->primitive_size, true);
DYN_MEMORY_PROP(t, job_no, tiler_meta);
pandecode_replay_gl_enables(t->gl_enables, JOB_TYPE_TILER);
if (t->zero1 || t->zero2 || t->zero3 || t->zero4 || t->zero5
|| t->zero6 || t->zero7 || t->zero8) {
pandecode_msg("tiler only zero tripped");
pandecode_prop("zero1 = 0x%" PRIx64, t->zero1);
pandecode_prop("zero2 = 0x%" PRIx64, t->zero2);
pandecode_prop("zero3 = 0x%" PRIx64, t->zero3);
pandecode_prop("zero4 = 0x%" PRIx64, t->zero4);
pandecode_prop("zero5 = 0x%" PRIx64, t->zero5);
pandecode_prop("zero6 = 0x%" PRIx64, t->zero6);
pandecode_prop("zero7 = 0x%" PRIx32, t->zero7);
pandecode_prop("zero8 = 0x%" PRIx64, t->zero8);
}
pandecode_indent--;
pandecode_log("},\n");
}
static int
pandecode_replay_vertex_job_bfr(const struct mali_job_descriptor_header *h,
const struct pandecode_mapped_memory *mem,
mali_ptr payload, int job_no)
{
struct bifrost_payload_vertex *PANDECODE_PTR_VAR(v, mem, payload);
pandecode_replay_vertex_tiler_postfix_pre(&v->postfix, job_no, h->job_type, "", true);
pandecode_log("struct bifrost_payload_vertex payload_%d = {\n", job_no);
pandecode_indent++;
pandecode_log(".prefix = ");
pandecode_replay_vertex_tiler_prefix(&v->prefix, job_no);
pandecode_log(".vertex = ");
pandecode_replay_vertex_only_bfr(&v->vertex);
pandecode_log(".postfix = ");
pandecode_replay_vertex_tiler_postfix(&v->postfix, job_no, true);
pandecode_indent--;
pandecode_log("};\n");
return sizeof(*v);
}
static int
pandecode_replay_tiler_job_bfr(const struct mali_job_descriptor_header *h,
const struct pandecode_mapped_memory *mem,
mali_ptr payload, int job_no)
{
struct bifrost_payload_tiler *PANDECODE_PTR_VAR(t, mem, payload);
pandecode_replay_vertex_tiler_postfix_pre(&t->postfix, job_no, h->job_type, "", true);
pandecode_replay_indices(t->prefix.indices, t->prefix.index_count, job_no);
pandecode_replay_tiler_meta(t->tiler.tiler_meta, job_no);
pandecode_log("struct bifrost_payload_tiler payload_%d = {\n", job_no);
pandecode_indent++;
pandecode_log(".prefix = ");
pandecode_replay_vertex_tiler_prefix(&t->prefix, job_no);
pandecode_log(".tiler = ");
pandecode_replay_tiler_only_bfr(&t->tiler, job_no);
pandecode_log(".postfix = ");
pandecode_replay_vertex_tiler_postfix(&t->postfix, job_no, true);
pandecode_indent--;
pandecode_log("};\n");
return sizeof(*t);
}
static int
pandecode_replay_vertex_or_tiler_job_mdg(const struct mali_job_descriptor_header *h,
const struct pandecode_mapped_memory *mem,
mali_ptr payload, int job_no)
{
struct midgard_payload_vertex_tiler *PANDECODE_PTR_VAR(v, mem, payload);
pandecode_replay_vertex_tiler_postfix_pre(&v->postfix, job_no, h->job_type, "", false);
pandecode_replay_indices(v->prefix.indices, v->prefix.index_count, job_no);
pandecode_log("struct midgard_payload_vertex_tiler payload_%d = {\n", job_no);
pandecode_indent++;
panfrost/decode: Respect primitive size pointers Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-03-15 03:21:27 +00:00
bool has_primitive_pointer = v->prefix.unknown_draw & MALI_DRAW_VARYING_SIZE;
pandecode_replay_primitive_size(v->primitive_size, !has_primitive_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
pandecode_log(".prefix = ");
pandecode_replay_vertex_tiler_prefix(&v->prefix, job_no);
pandecode_replay_gl_enables(v->gl_enables, h->job_type);
panfrost/decode: Elide more zero fields Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-19 09:35:57 -07:00
if (v->draw_start)
pandecode_prop("draw_start = %d", v->draw_start);
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
#ifndef __LP64__
if (v->zero3) {
pandecode_msg("Zero tripped\n");
pandecode_prop("zero3 = 0x%" PRIx32, v->zero3);
}
#endif
if (v->zero5) {
pandecode_msg("Zero tripped\n");
pandecode_prop("zero5 = 0x%" PRIx64, v->zero5);
}
pandecode_log(".postfix = ");
pandecode_replay_vertex_tiler_postfix(&v->postfix, job_no, false);
pandecode_indent--;
pandecode_log("};\n");
return sizeof(*v);
}
static int
pandecode_replay_fragment_job(const struct pandecode_mapped_memory *mem,
mali_ptr payload, int job_no,
bool is_bifrost)
{
const struct mali_payload_fragment *PANDECODE_PTR_VAR(s, mem, payload);
bool fbd_dumped = false;
if (!is_bifrost && (s->framebuffer & FBD_TYPE) == MALI_SFBD) {
/* Only SFBDs are understood, not MFBDs. We're speculating,
* based on the versioning, kernel code, etc, that the
* difference is between Single FrameBuffer Descriptor and
* Multiple FrmaeBuffer Descriptor; the change apparently lines
* up with multi-framebuffer support being added (T7xx onwards,
* including Gxx). In any event, there's some field shuffling
* that we haven't looked into yet. */
pandecode_replay_sfbd(s->framebuffer & FBD_MASK, job_no);
fbd_dumped = true;
} else if ((s->framebuffer & FBD_TYPE) == MALI_MFBD) {
/* We don't know if Bifrost supports SFBD's at all, since the
* driver never uses them. And the format is different from
* Midgard anyways, due to the tiler heap and scratchpad being
* moved out into separate structures, so it's not clear what a
* Bifrost SFBD would even look like without getting an actual
* trace, which appears impossible.
*/
panfrost: Remove "vertex/tiler render target" silliness I don't think these are actual structures, just figments over cargoculting dumped memory without making any sense of it. Nothing seems to break if the region is zeroed out, anyway. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-11 14:56:30 -07:00
pandecode_replay_mfbd_bfr(s->framebuffer & FBD_MASK, job_no, true);
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
fbd_dumped = true;
}
uintptr_t p = (uintptr_t) s->framebuffer & FBD_MASK;
pandecode_log("struct mali_payload_fragment payload_%d = {\n", job_no);
pandecode_indent++;
/* See the comments by the macro definitions for mathematical context
* on why this is so weird */
if (MALI_TILE_COORD_FLAGS(s->max_tile_coord) || MALI_TILE_COORD_FLAGS(s->min_tile_coord))
pandecode_msg("Tile coordinate flag missed, replay wrong\n");
pandecode_prop("min_tile_coord = MALI_COORDINATE_TO_TILE_MIN(%d, %d)",
MALI_TILE_COORD_X(s->min_tile_coord) << MALI_TILE_SHIFT,
MALI_TILE_COORD_Y(s->min_tile_coord) << MALI_TILE_SHIFT);
pandecode_prop("max_tile_coord = MALI_COORDINATE_TO_TILE_MAX(%d, %d)",
(MALI_TILE_COORD_X(s->max_tile_coord) + 1) << MALI_TILE_SHIFT,
(MALI_TILE_COORD_Y(s->max_tile_coord) + 1) << MALI_TILE_SHIFT);
/* If the FBD was just decoded, we can refer to it by pointer. If not,
* we have to fallback on offsets. */
const char *fbd_type = s->framebuffer & MALI_MFBD ? "MALI_MFBD" : "MALI_SFBD";
if (fbd_dumped)
pandecode_prop("framebuffer = framebuffer_%d_p | %s", job_no, fbd_type);
else
pandecode_prop("framebuffer = %s | %s", pointer_as_memory_reference(p), fbd_type);
pandecode_indent--;
pandecode_log("};\n");
return sizeof(*s);
}
static int job_descriptor_number = 0;
int
pandecode_replay_jc(mali_ptr jc_gpu_va, bool bifrost)
{
struct mali_job_descriptor_header *h;
int start_number = 0;
bool first = true;
bool last_size;
do {
struct pandecode_mapped_memory *mem =
pandecode_find_mapped_gpu_mem_containing(jc_gpu_va);
void *payload;
h = PANDECODE_PTR(mem, jc_gpu_va, struct mali_job_descriptor_header);
/* On Midgard, for 32-bit jobs except for fragment jobs, the
* high 32-bits of the 64-bit pointer are reused to store
* something else.
*/
int offset = h->job_descriptor_size == MALI_JOB_32 &&
h->job_type != JOB_TYPE_FRAGMENT ? 4 : 0;
mali_ptr payload_ptr = jc_gpu_va + sizeof(*h) - offset;
payload = pandecode_fetch_gpu_mem(mem, payload_ptr,
MALI_PAYLOAD_SIZE);
int job_no = job_descriptor_number++;
if (first)
start_number = job_no;
pandecode_log("struct mali_job_descriptor_header job_%d = {\n", job_no);
pandecode_indent++;
pandecode_prop("job_type = %s", pandecode_job_type_name(h->job_type));
/* Save for next job fixing */
last_size = h->job_descriptor_size;
if (h->job_descriptor_size)
pandecode_prop("job_descriptor_size = %d", h->job_descriptor_size);
panfrost/decode: Decode exception status Arm's kernel driver mentions how to decode this field, which makes a bit clearer what had happened. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-06-25 08:22:30 +02:00
if (h->exception_status != 0x1)
pandecode_prop("exception_status = %x (source ID: 0x%x access: 0x%x exception: 0x%x)",
h->exception_status,
(h->exception_status >> 16) & 0xFFFF,
(h->exception_status >> 8) & 0x3,
h->exception_status & 0xFF);
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 (h->first_incomplete_task)
pandecode_prop("first_incomplete_task = %d", h->first_incomplete_task);
if (h->fault_pointer)
pandecode_prop("fault_pointer = 0x%" PRIx64, h->fault_pointer);
if (h->job_barrier)
pandecode_prop("job_barrier = %d", h->job_barrier);
pandecode_prop("job_index = %d", h->job_index);
if (h->unknown_flags)
pandecode_prop("unknown_flags = %d", h->unknown_flags);
if (h->job_dependency_index_1)
pandecode_prop("job_dependency_index_1 = %d", h->job_dependency_index_1);
if (h->job_dependency_index_2)
pandecode_prop("job_dependency_index_2 = %d", h->job_dependency_index_2);
pandecode_indent--;
pandecode_log("};\n");
/* Do not touch the field yet -- decode the payload first, and
* don't touch that either. This is essential for the uploads
* to occur in sequence and therefore be dynamically allocated
* correctly. Do note the size, however, for that related
* reason. */
switch (h->job_type) {
case JOB_TYPE_SET_VALUE: {
struct mali_payload_set_value *s = payload;
pandecode_log("struct mali_payload_set_value payload_%d = {\n", job_no);
pandecode_indent++;
MEMORY_PROP(s, out);
pandecode_prop("unknown = 0x%" PRIX64, s->unknown);
pandecode_indent--;
pandecode_log("};\n");
break;
}
case JOB_TYPE_TILER:
case JOB_TYPE_VERTEX:
case JOB_TYPE_COMPUTE:
if (bifrost) {
if (h->job_type == JOB_TYPE_TILER)
pandecode_replay_tiler_job_bfr(h, mem, payload_ptr, job_no);
else
pandecode_replay_vertex_job_bfr(h, mem, payload_ptr, job_no);
} else
pandecode_replay_vertex_or_tiler_job_mdg(h, mem, payload_ptr, job_no);
break;
case JOB_TYPE_FRAGMENT:
pandecode_replay_fragment_job(mem, payload_ptr, job_no, bifrost);
break;
default:
break;
}
/* Handle linkage */
if (!first) {
pandecode_log("((struct mali_job_descriptor_header *) (uintptr_t) job_%d_p)->", job_no - 1);
if (last_size)
pandecode_log_cont("next_job_64 = job_%d_p;\n\n", job_no);
else
pandecode_log_cont("next_job_32 = (u32) (uintptr_t) job_%d_p;\n\n", job_no);
}
first = false;
} while ((jc_gpu_va = h->job_descriptor_size ? h->next_job_64 : h->next_job_32));
return start_number;
}
Reference in a new issue Copy permalink