We were walking the instructions in the block for each
first-rpt-instruction in the block. Instead, on the first query per
block, make a set of all the rpts in the block, so we can O(1) check for
the remainder.
shader-db runtime for deadspace3 -7.60909% +/- 2.28996% (n=10) on a
debugoptimized build.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37625>
Due to the division of TU_DEBUG options into runtime and envvar
options, it limited where options could be set from when
TU_DEBUG_FILE was being used. This commit addresses that by allowing
the envvar to set runtime debug options even when TU_DEBUG_FILE is
active while also allowing the file to set non-runtime options if
the file included them at startup.
Signed-off-by: Dhruv Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37580>
The DUTs have been in use for over 2 weeks and the new jobs landed over
1 week ago, without new unknown problems cropping up (not bullet-proof
ethernet gadget).
Additionally, the high temperature (up to 95°C) was discussed with
@lumag and he is not concerned by it... so let's move the jobs to the
merge pipeline!
Reviewed-by: Eric Engestrom <eric@igalia.com>
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37612>
Xwayland seems to mix implicit and explicit sync, depending on client
app. This trips up the heuristic that disables implicit sync once it
starts seeing app using explicit sync. This is not typical behavior,
so add a driconf override to disable the heuristic.
Fixes: 137cd3b0fa ("freedreno/drm: Move no_implicit_sync accounting")
Cc: mesa-stable
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37703>
RD dump generation can be expensive and can only be desired for some
specific part of execution. Trigger file mechanism helps with this to a
certain degree but is still somewhat inexact.
FD_RD_DUMP_SUBMITS environment variable can be used to specify ranges of
submit indices for which RD dumps of command streams should be generated.
FD_RD_DUMP_FRAMES environment variable can similarly be used to specify
ranges of frames under which RD dumps for submitted command streams should
be generated. Frame ranges only really work with Turnip since the frame
count data is available there.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37499>
Labels set via VK_EXT_debug_utils are in a separate track due to the
following part of the spec:
"An application may open a debug label region in one command buffer and
close it in another, or otherwise split debug label regions across
multiple command buffers or multiple queue submissions."
This means labels can start in one renderpass and end in another command
buffer, which breaks our assumption that stages can be modeled as a stack.
While applications aren't expected to use labels in such extreme ways,
even simpler cases can break our assumptions.
Having annotations in a separate track prevents the main track(s) from
entering an invalid state.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37028>
This reduces duplication: we only need to distinguish between Windows
and Unix in one place.
The previous code was inconsistent about using either the `platforms`
option, or the `host_machine`. Following the logic described in
commit 94379377 "lavapipe: build "Windows" check should use the host machine, not the `platforms` option.",
I've assumed that checking the host machine is the more-correct version
and used that.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37576>
This consistently uses `NAME.dll` on Windows, `libNAME.dylib` on Darwin
derivatives such as macOS, and `libNAME.so` on Linux, *BSD and so on.
It's also consistent about using the local variable name `icd_file_name`
for this name in every Vulkan driver, which was already the case in many
but not all drivers.
Some of these drivers probably don't make sense (or don't work) on
Windows and/or macOS, but if this is kept consistent for all drivers,
it should avoid the need for driver-specific commits like
commit 611e9f29e "lavapipe: fix icd generation for windows",
commit 951f3287 "lavapipe: set empty dll prefix",
commit 13e7a39f "lavapipe: fixes for macOS support",
commit 7008e655 "radv: Update JSON generator if Windows" and so on,
each time a driver is found to be relevant on more platforms than
previously believed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37576>
When CPU clock is the same with the authoritative trace clock (normally
default to CLOCK_BOOTTIME), perfetto drops the non-monotonic snapshots
to ensure validity of the global source clock in the resolution graph.
When they are different, the clocks are marked invalid and the rest of
the clock syncs will fail during trace processing.
There's no central daemon emitting consistent snapshots for
synchronization between CPU and GPU clocks on behalf of renderstages and
counters producers. The sequence-scoped clock (64 <= ID < 128) is unique
per producer + writer pair within the tracing session.
Turnip is a bit tricky here, since clocks may be synchronized before
`tu_perfetto_end_submit` is called (in case of KGSL), but emission of
perfetto event has to happen on the same thread as other renderstage events.
To solve this I save the clocks in `tu_perfetto_state` and emit them in
`stage_end` when needed.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37465>
Use tile_max_w/h which is the HW bound for the tile width/height and is
much smaller than the theoretical maximum width/height with a lopsided
tile with just the depth attachment.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37513>
Unlike the store/resolve that uses A2D, The FDM load path uses the 3d
pipeline and is therefore affected by the hardware FDM offset registers.
The fallback sysmem clear path also uses the 3d pipeline. Subtract off
the HW offset from the destination coordinates, similar to how it is
subtracted from viewport and scissor.
Fixes: b34b089ca1 ("tu: Use GRAS bin offset registers")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37496>
In msm backend's has_set_iova codepath, mapping a BO into a lazy VMA will
require moving that VMA into the zombie VMA mechanism once the BO is
destroyed. That means tu_sparse_vma destruction should avoid freeing VMA if
BO was mapped into it and then zombified.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Fixes: 764b3d9161 ("tu: Implement transient attachments and lazily allocated memory")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37413>
For the fallback !has_set_iova codepath, util_vma_heap shouldn't be used
for freeing allocations since it's not initialized or used for allocations.
A helper tu_free_iova() function is added to complement tu_allocate_iova(),
handling the vma lock and freeing the allocation in the util_vma_heap when
appropriate.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Fixes: 93a80f4bb9 ("tu/drm: Split out iova allocation and BO allocation")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37413>
This commit keeps vkcts as a nightly job, but this puts us in shooting
distance to what we've been working for for the past 2.5 years!
We will flip the switch to making this job part of the merge pipeline
after a week of stress testing to make sure reliability issues,
especially around USB, don't come back to haunt my days and nights.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37367>
Again, instrs don't get freed as we go, so the linear gc context saves us
5 pointers per instr.
Fossil replay time for deadspace3 on a debugoptimized build -4.85258% +/-
3.04009% (n=10)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37316>
Since we don't free registers as we go, we can just allocate them in a
linear gc context that gets freed at ralloc destroy. Saves 5 pointers of
memory per register for the ralloc overhead.
Fossil replay time for deadspace3 on a debugoptimized build -4.30353% +/-
1.80078% (n=10).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37316>
Emma Anholt