When the auxiliary surface is handled by the hardware directly,
there's nothing to bind besides the main pixels, so we can allow
sparse without doing anything else. We can't do this in the exact same
way with DG2 (which has_flat_ccs) because it uses the
aux_state_tracking_buffer.
v2: Fix spelling (Nanley).
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37419>
The following Vulkan CTS tests that emit massive shaders were
regressing after "intel/brw/xe3+: Select scheduler heuristic with best
trade-off between register pressure and latency.":
dEQP-VK.graphicsfuzz.cov-nested-loops-set-struct-data-verify-in-function
dEQP-VK.graphicsfuzz.cov-dfdx-dfdy-after-nested-loops
The reason is that they have so many nested loops that they cause the
performance analysis utilization estimates to overflow the 32-bit
floating-point variables used to calculate them, which causes our
throughput estimate to underflow and equal zero for those shaders,
which breaks the logic introduced in brw_allocate_registers() to
select the scheduling variant with highest throughput, since none of
the scheduling modes tried has better throughput than the initial
value equal to zero of "best_perf". Instead use -INFINITY as initial
value for "best_perf" so we always select a scheduling mode.
This should have been caught by CI but oddly the tests above are
showing up as "not run" on my last baseline runs, so this wasn't
flagged as a regression for me.
v2: Use -INFINITY instead of previous approach that used NaN (Ian).
Fixes: 531a34c7dd ("intel/brw/xe3+: Select scheduler heuristic with best trade-off between register pressure and latency.")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13884
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13885
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (v1)
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37322>
When sparse binding functions submit batches, they may modify the
exec_obj_index field of anv_bo structs. This field is used to ensure a
unique list of buffers is sent to the kernel (i915). Add a lock in these
functions to prevent multiple threads from modifying this field during
the batch submission process. To avoid creating a deadlock, also rework
the locking done in anv_queue_submit().
When playing the Monster Hunter Wilds Benchmark on a mesa build which
enables slab allocation of batch buffers (6f7a32ec92), this avoids a
sporadic assert failure:
nsterHunterWilds.exe:
../../src/intel/vulkan/i915/anv_batch_chain.c:489:
setup_execbuf_for_cmd_buffers:
Assertion `execbuf->bos[idx] == first_batch_bo_real' failed.
This issue was seemingly first introduced in 04bfe828db
("anv/sparse: allow sparse resouces to use TR-TT as its backend")
Backport-to: 25.2
Ref: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12582
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37307>
Move from a single ralloc allocation per instruction to contiguous
blocks of allocations. Still use ralloc for those large blocks.
Each ralloc allocation has at least 5 pointers of overhead, which would
be about a third of the current brw_inst, and get worse as we try to
pack brw_inst better.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36730>
Move all the SEND specific fields from brw_inst into brw_send_inst.
This new instruction kind will contain all variants of SENDs plus the
virtual opcodes that were already relying on those SEND fields.
Use the `as_send()` helper to go from a brw_inst into the brw_send_inst
when applicable. Some of the code was changed to use the brw_send_inst
type directly.
Until other kinds are added, all the instructions are allocated the same
amount of space as brw_send_inst. This ensures that all
brw_transform_inst() calls are still valid. This will change after
a few patches so that BASE instructions can use less memory.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36730>
Prepare code for supporting subclasses of brw_inst for certain
specialized kinds of instructions. This will allow
- Move certain fields from brw_inst to the specialized one,
reducing its size and making it easy to understand what applies
to which instruction;
- Move certain control sources into the specialized inst type, which
currently take a full brw_reg to encode small integers. Reducing
the overall sources we walk and care also might help the code
in general.
Next commits will add the new instruction kinds.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36730>
Flatten all the work being done into brw_new_inst() and
brw_clone_inst() and allocate both the instruction and
the sources in one swoop.
For now we still keep a pointer to the array instead of
declaring an array as last element to still allow growing
the array -- which is used by the compiler in a few places.
This commit removes the constructors for brw_inst, the idea
is that the instructions are managed by the brw_shader, so
we always go through it for new ones.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36730>
In the few cases we have to _increase_ the number of sources, the new
code will not attempt to recollect the memory, i.e. it delays freeing
the old smaller one source array. For the instructions that may need
this (when making a SEND into a SEND_GATHER), this is not expected to
happen more than once.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36730>
These dependency hints were primarily useful for the vec4 backend, where
it was common to write subsets of a vec4's components across multiple
instructions. In the scalar backend, we rarely used them. They also no
longer exist on Tigerlake and later in favor of software scoreboarding.
Dropping this allows us to clean up the IR a bit.
We still use the hardware hints in the generator in a couple places:
- Gfx9-12.0 scratch headers
- Quad swizzles
- Indirect MOV lowering
In theory we might want them back if we moved that lowering to the IR.
For scratch at least, I suspect it won't have a huge impact, as we're
already incurring the cost of spills/fills. The others are fairly rare
as well, so it may not be worth keeping.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36730>
It doesn't make any sense ot have TCS but not TES (or vice versa), but
coverity doesn't realize that. Add an assertion that they are both
non-null before we start reading them.
Fixes: 50fd669294 ("anv: prep work for separate tessellation shaders")
CID: 1665360
CID: 1665327
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37266>
The intel_vue_map is only partially initialized before being used. All
used fields are initialized, but in debug paths the unitialzed fields
will also be read. To fix this initialize the struct to 0. In the brw
path this struct is part of the prog_data, and is rzalloc'd.
CID: 1665308
Reviewed-by: Iván Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37261>
