Instead of making it a fragment-specific thing based on uses_kill, track
whether or not we need one in fs_visitor and emit HALT_TARGET at the end
of emit_nir_code() if needed.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5071>
This means the pass has to walk all the instructions but it was doing
that in a bunch of cases anyway when it didn't have a HALT_TARGET.
However, removing HALT_TARGET frees up the scheduler a bit because
HALT_TARGET is considered a scheduling barrier. The shader-db results
are kind-of a wash but we're about to add HALT_TARGET unconditionally so
we want to be able to get rid of it.
Shader-db results on Ice Lake:
total instructions in shared programs: 19935623 -> 19935623 (0.00%)
instructions in affected programs: 0 -> 0
helped: 0
HURT: 0
total cycles in shared programs: 976758472 -> 976766135 (<.01%)
cycles in affected programs: 11097707 -> 11105370 (0.07%)
helped: 1750
HURT: 875
helped stats (abs) min: 1 max: 866 x̄: 26.39 x̃: 4
helped stats (rel) min: <.01% max: 39.24% x̄: 1.25% x̃: 0.46%
HURT stats (abs) min: 1 max: 1678 x̄: 61.54 x̃: 10
HURT stats (rel) min: <.01% max: 65.69% x̄: 1.86% x̃: 0.42%
95% mean confidence interval for cycles value: -2.48 8.32
95% mean confidence interval for cycles %-change: -0.40% -0.03%
Inconclusive result (value mean confidence interval includes 0).
LOST: 62
GAINED: 46
All of the lost/gained programs are SIMD32 fragment shaders.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5071>
We're about to start using it to implement nir_jump_halt which has
nothing inherently to do with fragment shaders or discards. May as well
name it for the HW instruction it generates.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5071>
invalidate_draw_sh_constants should invalidate only SGPRs.
invalidate_draw_constants invalidates SGPRs and NUM_INSTANCES.
u_blitter called invalidate_draw_sh_constants, which previously
invalidated NUM_INSTANCES as well. This commit fixes that.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7721>
I think that reducing the CU mask to 1 disabled CU per SA broke the WGP mode
on VanGogh, causing a hang. To be sure, disable it on all chips.
Fixes: 9538b9a68e - radeonsi: add support for Sienna Cichlid
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7721>
GL doesn't use it, so this change is not necessary, but it's better
this way.
There is also a small cleanup using si_unpack_param.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7721>
If you did:
si_pm4_set_reg(pm4, reg, val0);
si_pm4_cmd_add(pm4, val1);
si_pm4 set_reg(pm4, reg + 4, val1);
it wrote val0 to reg, val1 to reg + 4, and val2 to reg + 8.
This fixes it by clearing last_opcode in si_pm4_cmd_add, so that
si_pm4_set_reg doesn't try to combine set_reg calls across si_pm4_cmd_add.
Fixes: da78d50bc8 - radeonsi: make si_pm4_cmd_begin/end static and simplify all usages
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7721>
For the DRI backends we factor this out to a dri_common_create_context
method. Indirect gets the same transformation but doesn't use the common
method since it can't rely on DRI being built.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7660>
Most of the legacy CreateContext paths already did this, this is just
aligning the two so we can implement one in terms of the other.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7660>
It turns out, the load_ubo to load_ubo_vec4 implementation isn't quite
enough for us, for a few reasons:
1. We use a single array of uvec4s for our UBOs, and to handle 64-bit
values in UBOs, we need further lowering.
2. The whole vec4 stuff seems a bit hard to reconsile with glsl 4.3
packing as well as PackedDriverUniformStorage.
In addition to the above, this fixes several piglit tests that *aren't*
part of quick_gl, which is what I've been running. So this doesn't even
work correctly right now.
So let's go back to what we had before instead.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3643
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7858>
This is a loader that handles more cases than the current vec4-based
loader, that is a bit easier to extend to more features.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7858>
This used to not be a problem, because these mutexes were the first
members of this array, meaning that we ended up trying to lock/unlock
NULL mutexes. But this isn't guaranteed to be allowed, so we were
relying on luck here.
Recently, this changed. We introduced asserts for NULL-pointers, and
changed the behavior in a way that leads to crashes in release-builds.
This means we can't rely on luck any longer.
Fixes: e317103753 ("c11/threads: Remove Win32 null checks")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3903
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7853>
