It is a bit annoying to have the resulting increased duplication, but
the table magic doesn't play nicely with variant regs.
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37009>
Registers declared as a "naked" array, ie:
<array offset="0x1234" name="SOME_REG" stride="1" .../>
were not getting register packers generated for them. Insert an
implicit <reg32> child for them, so the above would be equivalent
to:
<array offset="0x1234" name="SOME_REG" stride="1" .../>
<reg32 offset="0" name="REG"/>
</array>
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37009>
When we have a variant range, we need to test against the inclusive
range. Ie. if we have variants="A6XX-A7XX" we can't just test for
chip == A6XX.
So switch the variant key to preserve the range (ie. "A6XX-A7XX" instead
of just "A6XX"), add a helper to sanitize the range for symbol/#define
names, and handle the three possible cases when generating the if/else
ladder:
- single variant, ie. variants="A6XX", keeps the current logic
- open ended range, ie. variants="A6XX-", generates a >=
- closed ended range, ie. variants="A6XX-A7XX", generates a
(CHIP >= A6XX) && (CHIP <= A7XX)
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37009>
Even if there is only a single variant currently. This will allow
porting code to use the new builders independently from adding new
hw support. Basically avoiding churny conflicty changes on a branch
during bringup.
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37009>
Apparently the ignored bits have meaning.
- EOLM - Is set on a NOP after the last cat6 instruction.
Must be set outside of control flow including preambles.
Doesn't seem to affect correctness.
- EOGM - Is set on a NOP after the last cat5/cat6 instruction.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37009>
Fix the following warning, and others that are similar, as rustc
suggests:
warning: hiding a lifetime that's elided elsewhere is confusing
--> ../src/gallium/frontends/rusticl/mesa/compiler/nir.rs:282:22
|
282 | pub fn variables(&mut self) -> ExecListIter<nir_variable> {
| ^^^^^^^^^ -------------------------- the same lifetime is hidden here
| |
| the lifetime is elided here
= help: the same lifetime is referred to in inconsistent ways, making the signature confusing
= note: `#[warn(mismatched_lifetime_syntaxes)]` on by default
help: use `'_` for type paths
|
282 | pub fn variables(&mut self) -> ExecListIter<'_, nir_variable> {
| +++
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37059>
* immediately terminate renderpass after flushing
this otherwise could persist and trigger a bad state where the
zsbuf is eliminated
* no-op if already in renderpass
this function can be called from within a renderpass, at which time
it should do nothing because clears will be flushed automatically
Fixes: 5de34e47ad6 ("zink: unify/fix clear flushing")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37052>
Wine uses vkGetRandROutputDisplayEXT to query some GPU details on start
of a prefix that have to be exposed on the PE side.
Currently this causes minimum of 2 connector reprobes via
DRM_IOCTL_MODE_GETCONNECTOR. This can stall vblanks when timed just
right. In cases where prefixes are started over and over again (e.g.
Steam doing background processing) this causes periodic noticable
stutter.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37026>
Remove the cfg variables and use the shader pointers directly. Reset
the variant pointer if a shader failed or will not be used.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33541>
The brw_shader::uniforms now is derived from the nir_shader. The
only exception is compute shaders for older Gfx versions, so we
move the adjust logic for that.
The benefit here is untangling the code for compilation variants,
that before needed to keep track of the first that compiled to,
in most cases, copy an integer.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33541>
As we set prog_data->nr_params, allocate the array like elsewhere.
Current code is getting by because the logic for adding a new element
will realloc it. But later changes will make the array be accessed
before this reallocation.
This will make sure later patches won't cause tests like
dEQP-VK.query_pool.statistics_query.compute_shader_invocations.32bits_cmdcopyquerypoolresults_secondary
to fail in gfxver < 125. Note the bug appears when DRI option
to tweak the thresold to use these shaders is set to 0. This is
done by the GitLab CI, which allowed testing later patches to find
this issue.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33541>
And unify the initialization code for brw_shader. Avoid passing
brw_compile_params since for a single compilation we might have
multiple shaders (the case for BS stage).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33541>
