../src/freedreno/decode/replay.c: In function ‘safe_ioctl’:
../src/freedreno/decode/replay.c:608:13: error: implicit declaration of function ‘ioctl’ [-Werror=implicit-function-declaration]
608 | ret = ioctl(fd, request, arg);
| ^~~~~
Fixes: e3bbd1688b ("freedreno/replay: Add limited support for KGSL")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25264>
These dependencies are required for building freedreno tools but on
platforms such as Android, these aren't included and would need to
be built from source. The easiest way to do this was using the
Meson WrapDB. Additionally, warnings were added when these deps are
missing as the decode tools will silently not be built otherwise.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25005>
As `freedreno_kmds` can contain both `msm` and `kgsl`, this case
would just produce a build with just KGSL due to the precedence of
the check which is inconsistent behavior. Now `replay` is built for
all active KMDs with a suffix for the KMD (eg: replay-kgsl/replay-msm).
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25005>
Could be used in shader assembly from rddecompiler when overriding
the cmdstream.
Usage:
print r1.x, r3.z
First arguments is three consecutive registers used for internal print
needs.
Second arg is register to print.
Output:
Shader Log Entries: 36
[0] 00000004 0.0000
[1] 00000000 0.0000
[2] 00000000 0.0000
[3] 00000000 0.0000
[4] beadc429 -0.3394
[5] beadc429 -0.3394
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25005>
KGSL doesn't support IOVAs being set form userspace, so as a workaround
we pre-allocate a single buffer and hope that it always starts from the
same address.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25005>
dEQP-GLES31.functional.image_load_store.buffer.image_size.writeonly_7
produces:
t7 opcode: CP_COMPUTE_CHECKPOINT (6e) (8 dwords)
{ ADDR_0_LO = 0x15000 }
{ ADDR_0_HI = 0x5 }
0x18
{ ADDR_1_LEN = 3 }
0xf
{ ADDR_1_LO = 0x2e010 }
{ ADDR_1_HI = 0x5 }
and it was asserting due to sizedwords==7. Without the assert, we were
dereffing a len past the end of the packet. This len value we were
loading is also suspiciously not the location of the ADDR_1_LEN field in
the packet's XML. But then, the command stream at ADDR_1 was clearly 0xf
long, and that puts ADDR_1_LEN at the spot we would expect compared to
SET_RENDER_MODE's ADDR_1.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24358>
gpu_id is not decodable from chip_id in general case,
so we should use chip_id to search for fd_dev_info and get
GPU generation from that.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23828>
```
../src/freedreno/decode/rddecompiler.c:242:65: error: 'sscanf' may overflow; destination buffer in argument 3 has size 32, but the corresponding specifier may require size 33 [-Werror,-Wfortify-source]
if (sscanf(info->name, "%32[A-Z0-6_][%32[x0-9]].%32s", reg_name,
^
../src/freedreno/decode/rddecompiler.c:243:21: error: 'sscanf' may overflow; destination buffer in argument 4 has size 32, but the corresponding specifier may require size 33 [-Werror,-Wfortify-source]
reg_idx, field_name) != 3) {
^
../src/freedreno/decode/rddecompiler.c:243:30: error: 'sscanf' may overflow; destination buffer in argument 5 has size 32, but the corresponding specifier may require size 33 [-Werror,-Wfortify-source]
reg_idx, field_name) != 3) {
^
```
Reviewed-by: Rob Clark <robclark@freedesktop.org>
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22015>
Add helper to scan the CP_INDIRECT_BUFFERs, and then work backwards
accounting for data buffered via ROQ prefetch to deduce the actual
SQE position at the time of the crash.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19551>
Constructed with an invalid packet (0xdeadd00d) so there is no ambiguity
in the crash location.
This is expected to fail until the next commit.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19551>
Add a crash where this was seen "in the wild" on a CTS test in
!17943 which requires handling multi-IB prefetching to correctly
location the crash location.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19551>
We were previously checking only every 8 dwords within the packet. We
should instead just check if the hang location comes within the packet.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19551>
This was causing us to use the size of the previous packet. Which just
happened to land on a valid packet because pkt2 only followed a
CP_INDIRECT_BUFFER.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19551>
I have multiple examples where this register is too large by one
when comparing to the ROQ read/write pointers in CP_ROQ_*_STAT and the
ROQ data itself, as if it includes the dword most recently read too. I
have an example where it's off by 2 compared to the read pointer, but
the read pointer is also off by 1 itself judging by the SQE program
counter, so that may just be them not getting synchronized. This
off-by-one was getting in the way of figuring out exactly IB2 was being
processed in the next commit.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19551>
These don't correspond to the a3xx *_STAT registers, which we're about
to add so we need to rename them. The closest analogue is CP_CSQ_AVAIL,
although the sense is inverted (and we're not sure what the low 16 bits
are about). Also, the a3xx distinction between CSQ and STQ doesn't exist
anymore so don't use these outdated terms.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19551>
The offsets table stores offsets of a buffer (such as cmdstream) that
we've already dumped. The suballoc pool results in more suballocated
cmdstream allocated from a single backing buffer, meaning that we need
to increase the size of this table.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20975>
We can end up logging both the buffer that the toplevel cmdstream is
allocated, as well as the sub-allocated part of that buffer. Possibly
the kernel could do better about this, but to avoid undecodeable
cmdstream dumps and devcores, detect this case and deal with it.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20496>
The source code for rddecompiler includes adreno_common.xml.h, which is
a generated header. In order to ensure that the header has been written
when compiling rddecompiler.c, we need a dependency here.
Fixes: 03d80e0a6d ("freedreno/decode: Add 'rddecompiler' tool")
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20003>
Fix defect reported by Coverity Scan.
Resource leak (RESOURCE_LEAK)
leaked_storage: Variable stream_data going out of scope leaks the storage it points to.
Fixes: a7773c3c4c ("freedreno/rddecompiler: Add shader disasm/asm support")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20028>
Decompiles a single cmdstream from .rd into compilable C source.
Given the address space bounds the generated program creates
a new .rd which could be used to override cmdstream with 'replay'.
Generated .rd is not replayable on its own and depends on buffers
provided by the source .rd.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19444>
This adds an option to override a single cmdstream while replaying
.rd capture. Cmdstream for override is stored in the same .rd format,
where there is only one RD_CMDSTREAM_ADDR section and any amount
of buffers.
Instead of using provided .rd file, 'replay' calls external program
to generate it first, in order to be able to pass the range of
GPU addresses available for the new buffers.
Usage example:
./replay --override=13 --generator=~/cmdstream_gen
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19444>
source_root() function is deprecated in Meson version 0.56.0 because
it returns the source root of the parent project if called from a
subproject.
Why would anyone need Mesa as a meson subproject?
It would be used as subproject in a project generated by command buffer
"decompiler" for Freedreno.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19901>
We want to encode special messages into the CS that can be printed
by cffdec, these messages have identifiers that describe their
usage (message, scope begin and scope end) which allow for an
improved trace navigation experience due to the additional
information.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18271>
Replay command stream obtained from:
- /sys/kernel/debug/dri/0/rd
- /sys/kernel/debug/dri/0/hangrd
!!! Command stream capture should be done with ALL buffers:
- echo 1 > /sys/module/msm/parameters/rd_full
Requires kernel with MSM_INFO_SET_IOVA support.
This tool is intended for reproduction of various GPU issues:
- GPU hangs, note that command stream obtained from hangrd
may not reproduce (rarely) the hang, since the buffers are
snapshotted at the moment of the hang and not at the start
of the hanging command stream.
- TODO: Misrendering, would require marking framebuffer images
at each renderpass in order to fetch and decode them.
Code from Freedreno/Turnip is not re-used here since the relevant
pieces may introduce additional allocations which cannot be allowed
during the replay.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19171>
