Only internal compute shaders use DCC stores, so the TODOs are not
critical yet.
Fixes: 1d64a1045e - radeonsi: enable dcc image stores on gfx10+
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10261>
(cherry picked from commit a1653854f5)
The prog_to_nir->NIR-to-TGSI change ended up causing regressions on r300,
and svga against r300-class hardware, because nir_lower_uniforms_to_ubo()
introduced shifts that nir_lower_ubo_vec4() tried to reverse, but that NIR
couldn't prove are no-ops (since shifting up and back down may drop bits),
and the hardware can't do the integer ops.
Instead, make it so that nir_lower_uniforms_to_ubo can generate
nir_intrinsic_load_ubo_vec4 directly for !INTEGER hardware.
Fixes: cf3fc79cd0 ("st/mesa: Replace mesa_to_tgsi() with prog_to_nir() and nir_to_tgsi().")
Closes: #4602
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10194>
(cherry picked from commit 5de3cbbb2e)
Our "integer" index is stored as a float in this case, and we just need to
use teh right opcode for loading it, which will be the only one supported
by !native_integers hardware.
Fixes: cf3fc79cd0 ("st/mesa: Replace mesa_to_tgsi() with prog_to_nir() and nir_to_tgsi().")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10194>
(cherry picked from commit 71d6d1b1ab)
This has been confirmed to fix sporadic graphics corruption on Gen12
platforms for a number of workloads (including Heaven, Valley and
CS:GO among others). Corruption seems to occur during context switch
fairly consistently, but unfortunately this problem doesn't seem to be
documented. Until the hardware team comes up with a better
workaround, fix the problem by reemitting constants at the beginning
of each batch.
No corruption has been observed so far in GL due to preemption,
however this is a possibility to keep in mind, it may be necessary to
disable preemption in addition to this patch in order to fully address
this problem (see also 81201e4617).
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4412
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4454
Cc: mesa-stable
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 20e2c7308f)
In 27ee40f4c9 ("anv: Add support for sample locations") we
introduced the ability to emit sample locations baked in as part of
the pipeline or dynamically.
This is different from the previous dynamic states that were always
removed from the pipeline batch and instead emitted dynamically all
the time.
The mistake in 27ee40f4c9 is that sample locations are now emitted
all the time, leading to bigger command buffers for unnecessary
reasons.
This change introduces a bit fields of what is baked in the pipeline
and doesn't need to be dynamically emitted.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 4ad4cd8906 ("anv: Enabled the VK_EXT_sample_locations extension")
Cc: <mesa-stable>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10282>
(cherry picked from commit 505d176a8e)
When pipeline->dynamic_state.sample_locations.samples is not set
because the state is dynamic, we're currently calling
genX(emit_multisample) with a 0 samples value which is incorrect.
Found when using renderdoc with the drawing overlay.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 4ad4cd8906 ("anv: Enabled the VK_EXT_sample_locations extension")
Cc: <mesa-stable>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10282>
(cherry picked from commit 30bc562bda)
Fixes
dEQP-VK.api.image_clearing.core.clear_color_image.2d.optimal.single_layer.e5b9g9r9_ufloat_pack32_33x128
with RADV_DEBUG=forcecompress on GFX10.3.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Cc: 21.1 <mesa-stable>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10176>
(cherry picked from commit 86d903e88d)
Without image stores, DCC is always decompressed on compute.
Cc: 21.1 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10168>
(cherry picked from commit 66e1b42d06)
This was a placeholder for the XeHP cross-pipeline synchronization
code, bring it back.
This reverts commit a80e44902f.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10000>
(cherry picked from commit 78b643fb7f)
The parameters GL_TEXTURE_MIN_LOD, GL_TEXTURE_MAX_LOD,
GL_TEXTURE_MAX_ANISOTROPY_EXT, GL_TEXTURE_LOD_BIAS are stored as floats but
returned as integers. Setting their values outside of the integer range results
has undefined behaviour when the c-runtime method lroundf converts the value
back to an integer.
Fixes: 53c36dfc('replace IROUND with util functions')
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10244>
(cherry picked from commit 55fb9417a6)
We have to keep sampler uniforms around for later YUV lowering, and we
only need to remove uniforms that take up storage space. Code comes from
radeonsi.
Closes: #4644.
Fixes: de17b4aab5 ("freedreno: Remove uniform variables after finalizing NIR.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10246>
(cherry picked from commit 7d234da6ee)
We were never setting set->size, so we were always copying 0 bytes. But
as we only copy the contents when the layout and therefore the size is
the same, we don't have to take the old size into account anyway.
This fixes some VK_EXT_robustness2 tests that use push descriptors.
Fixes: 6d4f33e ("turnip: initial implementation of VK_KHR_push_descriptor")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7573>
(cherry picked from commit cb02a48f83)
We forgot to remove the instruction under consideration from instr_list
before inserting it into the block's list, which caused instr_list to
become corrupted. This happened to work but caused further corruption in
some rare scenarios.
Fixes: adf1659 ("freedreno/ir3: use standard list implementation")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7573>
(cherry picked from commit 8e11f0560e)
ACO doesn't create a waitcnt for barriers between texture samples and
image stores because texture samples are supposed to use read-only
memory. It could also schedule the barrier to above the texture sample.
We also have use a larger memory scope to avoid an ACO optimization.
Tested on GFX8 with Sachsa Willems deferred sample. With some DCC
decompressions and the compute path forced.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Cc: 21.1 <mesa-stable>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9496>
(cherry picked from commit ec70882238)
Allocating a descriptor set is aligned to 32 bytes, so just like the
other buffer types, bump the descriptor size to 32 bytes when allocating
MUTABLE descriptor types from a pool.
Fixes: 86644b84b9 ("radv: Implement VK_VALVE_mutable_descriptor_type.")
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10132>
(cherry picked from commit b60bc59180)
There were various issues here:
- MAX_DYNAMIC_UNIFORM_BUFFERS was larger than MAX_UNIFORM_BUFFERS.
- In some cases we were exposing more than the minimums required.
While that is not incorrect, it is not following what we have
been doing in general.
- The Vulkan spec states that some of the MaxDescriptorSet limits
need to be multipled by 6 to include all shader stages, even
if the implementation doesn't support all shader stages.
Fixes: cbd299b051 ('v3dv/device: do not compute per-pipeline limits multiplying per-stage')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10252>
(cherry picked from commit e7e8464d94)
On Bifrost, AFBC is not supported if the format has a non-identity
swizzle. For internal resources we fix the format at runtime, but this
fixup is not applicable when we export the resource. Don't advertise
AFBC modifiers on such formats.
Fixes: 44217be921 ("panfrost: Adjust the format for AFBC textures on Bifrost v7")
Cc: mesa-stable
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10233>
(cherry picked from commit 660b4d6e25)
Otherwise, handle_loop_phis() might pass it to handle_live_in() and then
we could have two phis for this variable.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Fixes: 7c64623e94 ("aco/ra: refactor SSA repairing during register allocation")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10236>
(cherry picked from commit 5b8a4516e6)
Prior to supporting VK_EXT_descriptor_indexing all of our descriptor
limits where below 64k which fitted a uint16_t. Now all of those can
go up to 2^20 entries so we need 32bits indexes to keep track of them.
This change leaves the dynamic indexes at 16bits. We could arguably
bump them too, up to the reviewer's taste.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 6e230d7607 ("anv: Implement VK_EXT_descriptor_indexing")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4636
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10228>
Consider a simple loop that does a series of texture instructions and
then reduces the results:
vec4 sum = vec4(0);
for (int i = 0; i < N; i++) {
sum += texture(...);
}
Assume that the loop is unrolled and we schedule the resulting basic
block. Right now, after we schedule the first texture instruction, the
only instructions available to schedule that don't incur a sync are the
instructions to setup the second texture instruction. So we keep picking
the texture instructions, no matter how large N is, resulting in a
pathological schedule for register pressure when N is very large:
sum1 = texture(...);
sum2 = texture(...);
sum3 = texture(...);
...
sum = sum1 + sum2 + sum3 + ...;
In particular this happens with some CTS tests for VK_EXT_robustness2,
where a loop like that with many iterations is marked as [[unroll]],
forcing NIR to unroll it.
This solution is a balance between the current approach and always
scheduling for register pressure (and ignoring sync's). We only allow a
certain number of texture fetches to be in flight before considering
textures to "sync", even though they don't really, both because they
likely *will* sync in reality (overflowing the internal queue of waiting
texture instructions) and because at some point we need the normal
algorithm to kick in and start lowering register pressure.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7571>
Once we insert a use of a given tex or SFU instruction, then we must
wait for that tex/SFU instruction (as well as all earlier ones) to
complete, so we shouldn't penalize further uses, even if a subsequent
tex/SFU instruction gets scheduled after the first use. This especially
matters after the next commit when we start forcibly breaking up long
sequences of texture instructions, since if we schedule a group of 8
texture instructions then we want to schedule the uses of those
instructions in parallel with the next 8 texture instructions to reduce
register pressure.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7571>
Similar to the previous commit, we should also verify that the
source-format support linear-filter if we try to blit with it.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10234>
Some Vulkan-drivers don't support blitting between all formats and
layouts. So let's verify this while blitting, and fall back to the
normal rendering code-path instead.
This fixes a crash on start-up in OpenArena on V3DV.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10234>
In most games I tested we use 32 MiB of cmdbuffers+cmd upload buffers
at most. Especially since we have mutable descriptors it seems
somewhat unlikely anything else will eat it up so be a bit more
aggressive allocating them in VRAM.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10198>
If first_frame_done isn't set, but fence is NULL, we end up dereferncing
that NULL-pointer.
This can happen in the case where the first submitted batch has no work,
and pfence was passed as a NULL-pointer.
While we're at it, simplify the check with the surrounding code, which
also checks for a NULL-pointer here.
Fixes: e93ca92d4a ("zink: force explicit fence only on first frame flush")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10235>
Late export is theoretically better if used with LATE_ALLOC,
but in practice, the early export has an advantage of
lower register usage, therefore more concurrent waves.
The idea of this commit is that "small" shaders benefit from early
primitive export more, due to being able to launch much more waves.
Let's consider a NIR shader "small" when it has only 1 block.
This yields both better performance, and better stats, than always
using late export.
Fossil DB on Sienna:
Totals from 12807 (8.76% of 146265) affected shaders:
VGPRs: 609128 -> 620216 (+1.82%); split: -0.01%, +1.83%
SpillSGPRs: 1458 -> 1538 (+5.49%)
CodeSize: 37028204 -> 37019320 (-0.02%); split: -0.17%, +0.14%
MaxWaves: 282902 -> 278516 (-1.55%)
Instrs: 7163142 -> 7162925 (-0.00%); split: -0.18%, +0.18%
VClause: 169285 -> 169547 (+0.15%); split: -1.15%, +1.30%
SClause: 267373 -> 267151 (-0.08%); split: -0.24%, +0.16%
Copies: 446442 -> 444567 (-0.42%); split: -2.68%, +2.26%
Branches: 156245 -> 156195 (-0.03%); split: -0.30%, +0.26%
PreSGPRs: 434701 -> 447396 (+2.92%)
PreVGPRs: 527783 -> 540527 (+2.41%)
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10106>
The user-set priority of shaders matters very little, but we hope
this might still help speed up VS input loads especially.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10106>
We learned that the gs_alloc_req is not actually when the export
space allocation happens. So it makes no sense to prioritize it.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10106>
