DXIL requires that each I/O variable has a unique semantic name, but when
dealing with semantics that take up multiple slots, that variable implicitly
takes up multiple names. So when assigning driver_location, we need to do
the same.
That means also updating outputs and patch constants to have a mapping from
driver_location to a compacted index, since the metadata arrays *can't* have
holes.
This would be simpler if we could hang it off the nir_variable but there's
not really any free fields to be able to do that. We only need this compacted
mapping inside the DXIL backend anyway so we can just store the array in the
module.
Tested-by: Benjamin Otte <otte@gnome.org>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12128
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32047>
It will be used to allow merging loads with a hole between them.
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29398>
The semantics of discard differ between GLSL and HLSL and
their various implementations. Subsequently, numerous application
bugs occurred and SPV_EXT_demote_to_helper_invocation was written
in order to clarify the behavior. In NIR, we now have 3 different
intrinsics for 2 things, and while demote and terminate have clear
semantics, discard still doesn't and can mean either of the two.
This patch entirely removes nir_intrinsic_discard and
nir_intrinsic_discard_if and replaces all occurences either with
nir_intrinsic_terminate{_if} or nir_intrinsic_demote{_if} in the
case that the NIR option 'discard_is_demote' is being set.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27617>
This removes the need for drivers to handle both versions. The base will
get added once in nir_lower_system_values when converting from deref to
intrinsic and will be replaced by a zero for users not supporting it.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26800>
This removes the need for drivers to handle both versions. The base will
get added once in nir_lower_system_values when converting from deref to
intrinsic and will be replaced by a zero for users not supporting it.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26800>
Ubo0 is tricky. It exists if there were any uniforms when
lower_uniforms_to_ubo was run. If we try to run that ourselves,
it might be too late and DCE/remove_dead_variables might've been run,
which removed the uniforms and their accesses, without decrementing
num_uniforms. So we have no good way of knowing whether to declare
ubos from [0, N] or [1, N]. In practice this probably doesn't make
much of a difference but the logic is there so ¯\_(ツ)_/¯
If we use the nir option, then dead code isn't run, and num_uniforms
is a true indicator of whether ubo0 exists or not.
Note that this means we are no longer running this pass for internal
shaders that don't come from the GLSL compiler, so various places are
updated to query the nir info bit that's set by running this pass.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28535>
These handles can be emitted in control flow, which means that the handle
might be in a block which does not dominate a block that's processed
later on, which results in incorrect DXIL if we try to reference it.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26803>
HLSL docs say WaveReadLaneAt is undefined if the target lane is inactive. This makes
sense since the target lane may need to *send* the data, rather than it being pulled
by the calling lane. So don't early-out on the loop, iterate through the whole wave
on all threads and read the cross-lane data before branching.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27624>
DXIL doesn't have instruction-level coherency. We have 3 options:
1. Promote the instruction to an atomic instruction. We can only do this
for 32-bit or 64-bit ops.
2. If using bindless, declare the local resource declaration as globally-coherent.
3. If not using bindless, add globally-coherent to the global resource declaration.
This pass does all 3 of these, stopping at the intrinsic level for supported types
of atomics, otherwise assigning to the global resource declaration, which will be
unused if we're doing bindless, where instead we'll get it from the instruction.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27348>
No driver supports urol/uror on all bit sizes. Intel gen11+ only for 16
and 32 bit, Nvidia GV100+ only for 32 bit. Etnaviv can support it on 8,
16 and 32 bit.
Also turn the `lower` into a `has` option as only two drivers actually
support `uror` and `urol` at this momemt.
Fixes crashes with CL integer_rotate on iris and nouveau since we emit
urol for `rotate`.
v2: always lower 64 bit
Fixes: fe0965afa6 ("spirv: Don't use libclc for rotate")
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by (Intel and nir): Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
Acked-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27090>
These are now covered by nir_opt_loop():
- opt_if_loop_last_continue()
- opt_merge_breaks()
- opt_if_loop_terminator()
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24940>
