We're always storing it in a scratch register for register pressure
reasons anyway. We may as well just stash it there as a state reg and
we can avoid emitting it all over the place. This reduces each draw
call to nvk_flush_gfx_state() followed by the actual draw, which is now
independenty of any dynamic state.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30703>
mme_set_priv_reg() needs the first three registers to send data to/from
FALCON04. If we don't reserve these in the register space, it may stomp
other things. This only really matters pre-Volta where we need to use
privileged registers for conservative rasterization. However, it's a
good idea to reserve the space none the less.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30703>
Instead of the state part of the simulator being baked in, it's now
broken out into a pluggable component that the simulator talks to via a
function pointer interface. This will let us run the simulator without
the full state simulator under the hood.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30703>
out_args->scratch_offset and in_wg_id_x will alias on <gfx9.
To avoid the conversion code reading a garbage WG ID, move the
scratch/ring offset writing to the very end.
Fixes: 1e354172 ("radv,aco: Convert 1D ray launches to 2D")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30707>
Make sure to take new GRF size into consideration and adjust the
indirect offset according to new size so that when we do the indirect
load with address register, we load right values.
This helps pass the following tests:
- dEQP-VK.binding_model.descriptor_buffer.mutable_descriptor.*geom*
- dEQP-VK.ray_query.*geometry_shader.*
Backport-to: 24.2
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30679>
In !25925 I attempted to fix an error spam caused by the disk cache not
creating parent directories of the cache directory when needed,
resulting in failure to create the disk cache. Presumably that is bad
for performance.
Unfortunately I did a really bad job and only fixed the edge case where
the cache dir is given by $MESA_SHADER_CACHE_DIR rather than the general
case. Here I attempt to be more comprehensive.
Fixes#8294
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30160>
ir3_const_state is shared between the binning and non-binning variants.
The non-binning variant is compiled first and sets up ir3_const_state
after which the binning variant is not supposed to modify it anymore. If
it would, things may go haywire since the layout of the constant state
will change after the non-binning variant already finished compiling.
Currently, the ir3_const_state() accessor takes care of the sharing
(i.e., it returns the non-binning const state for the binning variant)
but nothing would be prevent the binning variant from accidentally
modifying the state. This is handled by restraint from its users.
This commit tries to make it more difficult to accidentally modify the
const state by the binning shader by making the following changes:
- ir3_const_state(): the same logic as before but now returns a const
pointer to prevent the binning variant from (accidentally) modifying
the const state.
- ir3_const_state_mut(): returns a non-const pointer but asserts that it
is not called by the binning variant.
As a corollary ir3_get_driver_ubo() also had to be split in two variants
(const and non-const) as it is called with a pointer to one of the
fields of ir3_const_state.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30256>
ir3_cp uses the const state to lower immediates. It doesn't take the
binning variant into account so in theory, it could add immediates to
the const state for the binning variant, modifying the state after its
layout had already been established for the non-binning variant.
In practice, this probably works fine as the immediates are the last
section of the const state so the layout wouldn't be changed by ir3_cp.
However, there is very little benefit in doing this (the chances for an
immediate being necessary in the binning variant but not in the
non-binning variant are small) so it's better to stick to the global
invariant of not changing the const state in the binning variant.
This commit makes sure that immediates are never added by ir3_cp for the
binning variant. Some refactoring was necessary, however, since the
lookup and modification of the const state were a bit intertwined. More
specifically, currently, the immediate storage in the const state would
always be enlarged by ir3_cp whenever its full, even when it might
actually contain the immediate. To fix this, the logic is split in two
functions: ir3_const_find_imm() for lookup (allowed to be called by the
binning variant), and ir3_const_add_imm for adding immediates (not
allowed to be called by the binning variant).
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30256>
We used to remove the unused outputs for the binning pass in ir3. Even
though DCE would be able to clean up most of the mess, there could still
be some left: most notably, unused control flow would not be cleaned up
(leaving some weird branches to empty blocks). Instead of teaching ir3
how to clean this up, it makes more sense to do this at the NIR level,
where we can also benefit from other optimizations.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30256>
Faith Ekstrand