This is now done in NIR, with the exception of exclusive min/max/and/or scans.
But those are not really useful, and if we ever come across them we can
optimize them in NIR using write_invocation_amd.
No Foz-DB changes on Navi21.
Acked-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38902>
v3d_nir_lower_load_store_bitsize that uses nir_lower_mem_access_bit_sizes
already ensures that any writemask on store has consecutive bits set.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38921>
In case vk_color_attachment_location_state is in its default state, we
would end up with an identity mapping for color_map resulting in 8 RTs
being selected instead of what is really required.
This now use the rendering state attachment count to properly emit
SET_CT_SELECT.
Found while debugging MRT on
"dEQP-VK.shader_object.rendering.color_attachment_count_1.extra_attachment_after_1.none.none.same_color_formats.after.none.r16g16_sint_d32_sfloat_s8_uint"
and while comparing with the proprietary driver.
Signed-off-by: Mary Guillemard <mary@mary.zone>
Fixes: 84de6c12b2 ("nvk: Emit SET_CT_SELECT based on the dynamic color location map")
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38946>
This is required for upcoming resource barrier work to implement HDC
flush's.
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38707>
Gfx20+ doesn't do PIPELINE_SELECT, the assumption is that we can now
do any PIPE_CONTROL we want regardless of the pipeline mode.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38707>
We experimentally found that some fixed functions have apparently be
hooked up to the L3. So we can drop a some flushing.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38707>
Now that we track the stages, it's not required to add those bits
anymore.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38707>
Now that we have the stages accumulated, we can delay this at flushing
time.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38707>
For a bunch of workarounds and special cases we want PIPE_CONTROL not
RESOURCE_BARRIER. We want emit_apply_pipe_flushes() to be mostly for
application barriers.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38707>
This simplifies usage of estimate_variable_latency a little in that we
can just use it directly in our max() expressions instead of guarding it
with an if.
Reviewed-by: Mary Guillemard <mary@mary.zone>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38939>
This matches my current understanding of nir_opt_copy_prop, including that
nir_opt_copy_prop always replaces movs with vecN.
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38916>
Due to rebasing not recognizing it as a conflict, it ended up having
the same value as nir_io_assign_color_input_bases_after_all_other_inputs.
Fixes: 9a2f1be814 - nir: add FRAG_RESULT_DUAL_SRC_BLEND and an option to use it
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38916>
Keep only the metadata when initially parsing the files. Then re-load
the relevant archives again when necessary.
The old code was just keeping everything in memory, which was slow when
looking at a directory containing archives resulted from processing
a large fossil file.
Extra care is taken with `search` commands to ensure we don't keep
unnecessary contents around. At some point we could reorganize so
find_all is not used here, but for now this should be fine.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38228>
Instructions that calculate derivatives (whether implicitly or
explicitly) don't actually need helpers enabled as long as helpers were
enabled while their coordinates were calculated. We currently don't
track this and leave helpers enabled until the derivative instructions
themselves.
Improve this by adding a backwards data-flow analysis which tracks the
last instruction that wrote the coordinates so that helpers can be
disabled after that.
Totals from 38306 (23.26% of 164705) affected shaders:
Instrs: 19635952 -> 19647753 (+0.06%); split: -0.03%, +0.09%
CodeSize: 40465212 -> 40489860 (+0.06%); split: -0.03%, +0.09%
NOPs: 3493898 -> 3505699 (+0.34%); split: -0.16%, +0.49%
(ss)-stall: 1755983 -> 1755365 (-0.04%); split: -0.04%, +0.01%
(sy)-stall: 5345890 -> 5350570 (+0.09%); split: -0.03%, +0.12%
Last helper: 8754510 -> 6313744 (-27.88%); split: -27.89%, +0.01%
Cat0: 3821218 -> 3833019 (+0.31%); split: -0.14%, +0.45%
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36410>
Some expectation updates in the piglit uprev come from results we already see
in the nightly runs. Updating xfiles with those results before the uprev
commit, shows better the origin of the changes.
Signed-off-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38333>
With the default non-colored job status, all the listed non-colored job
statuses can be absorbed by the default behavior.
Signed-off-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38919>
When GitLab adds new job statuses, we need to upgrade the coloring dictionary.
By having a default value for non-colored output, we handle future unknown
status, and avoid crashes.
Signed-off-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38919>
