Merge the extra tracking that is useful for generating stats from asm
(as opposed to ir), and for guestimating things like inputs and outputs
(mostly useful for r/e) into ir3's version and drop cffdec's version.
There is a small change in disasm output for the decode tools, in that
it no longer prints the used consts, but rather just the max accessed
const. This is the more useful piece of information, and avoids making
the shared regmask type big enough to deal with the const reg file.
Additional error checking for invalid regids causes crashdec to bail
out sooner when decoding memory that *might* hold valid instructions.
Also, crashdec no longer prints stats, because stats aren't very useful
when trying to decode random instruction memory (which might or might
not be valid instructions).
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6070>
To unify the ir3 disasm code, we need to add in the regmask based
register tracking from cffdec's version of the disassembler. Split
out regmask (or at least the part that doesn't depend on ir3) so
it can be shared.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6070>
This also tunes `.freedreno-rules` a bit so that it isn't triggered by
various tools that don't effect the driver build.
The .gitlab-ci directory is kept separate from the toplevel one so that
updates to (for example) reference decode output do not trigger all the
other-driver jobs to run.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6070>
Bifrost's bitwise ops include the shift capability. Previously we had
hardcoded the shift to zero in all cases.
There's room in future to emit slightly better code if a shift and a
bitwise operation can be folded together, but not going after that for
now.
This change also removes the separate BI_SHIFT instruction class as
BI_BITWISE can cover both cases.
Signed-off-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6091>
For convenience in e68871f6a4 ("spirv: Handle constants and types
before execution modes") we moved all execution mode parsing after the
constants and types, so that those using OpExecutionModeId could be
handled together.
Later in 84781e1f1d ("spirv/nir: keep track of SPV_KHR_float_controls
execution modes") we had to parse certain non-ID execution modes
before handling constants.
Instead of handling just the float controls related execution modes
early, handle all modes that don't need an ID. This is a more
"natural" split and will allow other type handling to rely on
execution mode in the future.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6062>
Found via
dEQP-VK.binding_model.descriptorset_random.sets4.noarray.ubolimitlow.sbolimitlow.sampledimglow.outimgonly.noiub.nouab.frag.ialimitlow.0
Fixes: 159a1300ce ("turnip: input attachment descriptor set rework")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6087>
dEQP-VK.wsi.xlib.surface.query_devgroup_present_modes with prime
fail when 0 rectangles are reported. While I believe that test
tests this unintentionally (trying to test the VK_INCOMPLETE return),
I believe it makes sense to always return a rectangle.
In particular we require the data from the given rectangle for
presentation even if we use prime and given that prime is completely
transparent for the app it still counts as local from the perspective
as the application.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6071>
Vulkan allows fragment shaders to read gl_ClipDistance[], in which case
the SPIR-V compiler will inject a compact array variable at
VARYING_SLOT_CLIP_DIST0. Request the lowering to always work in terms
of a compact array variable so we don't have to care about the API
in use.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6022>
Vulkan allows fragment shaders to read gl_ClipDistance[], in which
case the SPIR-V compiler inserts a single compact array variable for
VARYING_SLOW_CLIP_DIST0 and the lowering should not try to inject
its own variables, but instead work in terms of the existing one.
Vulkan drivers are expected to call this with use_clipdist_array set
to true to be consistent with this setup.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6022>
Fixes some dEQP-VK.renderpass2.* flakes. Valgrind:
Test case 'dEQP-VK.renderpass2.dedicated_allocation.attachment.8.724'..
==754520== Conditional jump or move depends on uninitialised value(s)
==754520== at 0x575B21C: radv_layout_is_htile_compressed (radv_image.c:1690)
==754520== by 0x572F470: radv_handle_depth_image_transition (radv_cmd_buffer.c:5855)
==754520== by 0x572F2F2: radv_handle_image_transition (radv_cmd_buffer.c:6123)
==754520== by 0x572EEC6: radv_handle_subpass_image_transition (radv_cmd_buffer.c:3385)
==754520== by 0x572A104: radv_cmd_buffer_begin_subpass (radv_cmd_buffer.c:4843)
==754520== by 0x572A007: radv_CmdBeginRenderPass (radv_cmd_buffer.c:4913)
==754520== by 0x572A197: radv_CmdBeginRenderPass2 (radv_cmd_buffer.c:4921)
Why false?
A renderloop happens when the same attachment is both used as input
attachment and output (color, ds) attachment in a subpass. Of course
this doesn't happen outside of a renderpass and hence we can initialize
it to false at the start of the renderpass.
Fixes: 66131ceb8b "radv: Pass through render loop detection to internal layout decisions."
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3074
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6068>
Note that there are some extra tess fails, but they're probably
unrelated to the actual feature. There were also some xfails that were
created as part of an earlier attempt to enable the feature which were
fixed in the meantime, so remove them.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5738>
