There might be cases where you describe an enum in isaspec and want it to use
for decoding but also for codegen with e.g. mako.
Lets have a look at the following exmaple:
<enum name="#cond">
<value val="0" display=""/> <!-- always: display nothing -->
<value val="1" display=".gt"/>
...
</enum>
In the decoding case we want that nothing gets displayed if #cond has the value of "0". For
codegen with mako this could result in the following C code:
enum PACKED cond {
COND_ = 0,
COND_GT = 1,
...
};
What you really want is this:
enum PACKED cond {
COND_ALWAYS = 0,
COND_GT = 1,
...
};
To make this possible introduce BitSetEnumValue class which represents
an isaspec xml enum. It holds the value, displayname and now a name.
With the __str__ method the old behaviour is still intact.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25451>
Allows every user of isaspec to add custom meta information
to any bitset. This can be quite handy if you want to know
how many sources your instruction have, if this instruction has
a dest or provide some names for sources that can be used
by some debug tools.
All you need is to sprinkle <meta> tags in the xml file and
provide custom attributes.
<meta has_dest="1" num_sources="3" .. />
With get_meta() method of any bitset you can get access to
the dict with all the attributes. get_meta() walks the whole
tree to collect all <meta> tags on the way to the root node.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25451>
The current regex misses the = sign and therefore fails to match
DST:align=16.
Fixes: 9e56f69edf ("isaspec: encode: handle special fieldname properties")
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25451>
If you have a repeating <display> substring you can replace this
substring with a template and reference the template name instead.
Saves from doing lot of copy&paste and makes general changes to the
substring much easier.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25451>
Comparing uint8_t max value 255 with devinfo->verx10 will work fine for
now but for future platforms, comparison will fail. To avoid this
let's switch the field data type from 8-bits to 16-bits.
v1: (Jordan)
- Use 16 bits instead of 32 and add assertion.
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25478>
Otherwise, DGC command buffers might not be correctly aligned.
This fixes a regression with the vkd3d-proton DGC tests.
Fixes: 4f660f9937 ("ac/gpu_info: pad IBs according to ib_size_alignment")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25500>
This is done in nir_opt_constant_folding now.
No fossil-db changes on navi31.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25477>
Having this pointer in the key is undesirable since it makes
copying keys difficult and error prone (as seen in previous
patches), also, it is only there for convenience and we don't
strictly need it (in fact the vulkan driver doesn't use it at
all), so let's just get rid of it so our v3d_key is fully
static.
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25418>
The RAM shader cache was using the v3d_key for hashes and
comparisons which is not correct. Particularly, this struct
has a void pointer where we store a reference to an uncompiled
shader with the NIR code, and that is of course not accounted
for when hashing and comparing keys, which can lead to bogus
cache hits.
This patch introduces a v3d_cache_key that has both the v3d key
and a sha1 of the uncompiled NIR. Now key hashing and comparison
is done on the static part of the v3d key (that is, excluding the
uncompiled shader pointer, which may be invalid in the cache if
the original shader was deleted) and taking the sha1 from the
uncompiled shader. This also makes sure the shader key we store
in the cache has a NULL shader_state pointer to make it more
clear that this field may not be used at all for caching purposes.
This fixes GPU hangs with some OpenCL tests (through Rusticl)
caused by incorrect RAM cache hits.
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25418>
Our shader key includes a void pointer that we can't just memcmp,
so add helpers that allow us toget the 'static' portion and size
of a key. We will use this to fix up the shader cache in v3d in
a later patch.
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25418>
This is to inform you of some planned downtime in the LAVA lab as follows:
* Start: 2023-10-02 08:00 BST (07:00 UTC)
* End: 2023-10-02 12:00 BST (11:00 UTC)
Signed-off-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25368>
To reduce shader variants, the tilebuffer lowering code does not know the
actual texture targets of the spilled render targets, only whether they are
layered or not. As such, all layered targets (3D, cube map, etc) get written out
uniformly as 2D Arrays. For that to work, the driver needs to do the
corresponding transform.
Regular imageStore() instructions are not affected by any of this.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Do not force a single-layer view, use an actual array attachment when there are
multiple layers, since this corresponds to a layered framebuffer that will write
to an array with the eMRT path.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
