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>
The idea of having a single file containing the ToC is not really how
things are done in Sphinx, and kinda makes it harder to structure
documentation more naturally. This was just something I did to mirror
what we used to do for the old HTML-only version of the docs, to ease
the transition and to de-clutter index.rst.
Now that the transition is far behind us, and index.rst is much cleaner,
we can finally start inlining this.
In the long run, I expect most of these to be moved to separate "chapter
articles" that summarize what these topics are, and thus disappear from
here.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7709>
There's no reason to explicitly call out GL ES versions here, as these
are all major versions there are, and it's very unlikely that more
versions will emerge.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7709>
The rST code here is much more to the point and easy to read if we
define the links as external link-references instead of inlining them.
This will make the next few patches much easier to grok.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7709>
The features added in each major version is also unlikely the first things
someone wants to know about Mesa. So let's move this into the
versions.rst article.
This documentation is severely out of date anyway, and as it doesn't
seem like anyone is interested in documenting this any more, we should
probably consider driopping versions.rst entirely in the longer run.
But for now, this makes the front-page much more approachable.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7709>
The project history isn't usually what a user wants to read first when
they read about a project, so let's remove it from the front-page of the
documentation.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7709>
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>
Samuel Pitoiset
Jason Ekstrand
Marek Olšák
Jordan Justen
Adam Jackson
Erik Faye-Lund