Pull in all of $envytools/rnndb (including display, etc) from envytools
commit 6ccdda33ac4d88e19d2a70e1b4edaaab5ec4b026
This changes the directory structure to match the organization in the
envytools tree.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6070>
With the next commit, the xml files will be no longer be all in the same
directory. But checking up a single directory level to resolve import
will be sufficient.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6070>
Just noticed in passing that this looked extra complicated,
Bas said it was for legacy design reasons, so clean it up.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6099>
Unfortunately this doesn't map nicely to the existing instruction
classes, so we'll make a new one for now.
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>
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>
Since the bool representation is 0/~0, we can convert to int
just by &1.
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/6079>
The "d3d" variant uses ~0 as the true value. This is consistent
with NIR's nir_lower_bool_to_int32 pass.
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/6079>
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>
When changing the patch to use an offset instead of a bool, the type was
accidentally left as bool.
Fixes: f472c98443 ("freedreno/ir3: add support for a650 tess shared storage")
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5765>
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>
There might still be tex instructions with undef texture/sampler before
the first round of optimizations. No pipelinedb changes.
Fixes: 14a12b771d ('spirv: Rework our handling of images and samplers')
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6083>
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>
We are going to need this in Vulkan because the SPIR-V compiler
defines clip distances as a single compact array of scalars, so
our compiler needs to know what to do with them.
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>
Register set setup should be done once at backend
initializaion, as ra_set_finalize is O(r^2*c^2).
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5996>
This struct will be used to for state saved across compiler
invocations.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5996>
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>
I missed this if statement so atomic counters weren't getting bindings
and, when you have more than one of them, that meant they were all
getting combined into one.
Fixes: 3584cb09bc15 "spirv: Give atomic counters their own variable mode"
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6060>
Track them via pending_flush_bits. Previously WFI was only tracked in
flush_bits and WAIT_FOR_ME was emitted directly. This means that we don't
emit WAIT_FOR_ME or WAIT_FOR_IDLE if there wasn't a cache flush or other
write by the GPU. Also split up host writes from sysmem writes, as only
the former require WFI/WAIT_FOR_ME.
Along the way, I also realized that we were missing proper handling of
transform feedback counter writes which require WAIT_MEM_WRITES. Plumb
that through as well. And CmdDrawIndirectByteCountEXT needs a
WAIT_FOR_ME as it does not wait for WFI internally.
As an example of what this does, a typical barrier for transform
feedback with srcAccess = VK_TRANSFORM_FEEDBACK_WRITE_COUNTER_BIT_EXT
and dstAccess = VK_ACCESS_INDIRECT_COMMAND_READ_BIT used to emit on
A650:
- WAIT_FOR_IDLE
and now we emit:
- WAIT_MEM_WRITES
- WAIT_FOR_ME
So we've eliminated a useless WFI and added some necessary waits.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6007>
These have an indirect count which is loaded from an iova, and the
minimum is taken between the indirect and direct counts. Note, I also
had to fix gen_header.py to deal with the extra-long names we get.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6007>
Now that we clear the PITCHALIGN" field when filling GMEM input attachment
descriptors, we can get rid of the extra tile width alignment on a630/a640.
With the "block_align_shift" value change, this brings down the default
gmem_align from 16k to 4k on a630/a640 and down from 24k to 12k on a650,
to match the gallium driver.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5528>
No functional changes - fixes the following assert:
nir_lower_io_impl: Assertion `!(modes & ~supported_modes)' failed.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5997>
Rob Clark
Bas Nieuwenhuizen
Dave Airlie
Chris Forbes
Caio Marcelo de Oliveira Filho
Connor Abbott
Jonathan Marek
Daniel Schürmann
David McFarland
Iago Toral Quiroga
Karol Herbst
Christian Gmeiner
Jason Ekstrand
Samuel Pitoiset