so we can gather_info later.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36265>
Correctly/optimally using nir_opt_varyings directly is pretty tricky. For GL, we
have all the right logic in the GLSL linker. for VK, we don't want to duplicate
this dance in every driver. Wrap it all up in a nir_opt_varyings_bulk helper
that operates on an entire pipeline of nir_shader's, following the GLSL linker's
logic. This is suitable for Vulkan drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36265>
Despite appearances, the current vk_pipeline implementation fails to link any
shaders, unless GPL is used or the link_geom_stages option is set (which no
drivers do). Notably monolithic pipelines don't get linked.
This patch attempts to fix our linking issues. Monolithic pipelines now get
linked, GPL optimized pipelines do too. GPL fast link is still not linked.
Geometry stages are now always linked because - despite the option - I think all
hardware wants this. Apps love writing random dead varyings for literally no
reason, which isn't free even on NVIDIA. This removes the option, effectively
setting it for all drivers, which in retrospect is the right decision.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36265>
vkd3d-proton sets this to the size of the backing memory which means we
will overwrite random buffer contents when performing acceleration
structure copies.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36197>
Sampling with layer!=0 from a non arrayed descriptor should return 0 and
sampling without an explicit array layer from and arrayed descriptor
should sample the first layer.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36197>
block->imm_dom is NULL for unreachable phis, so the dominance checks would crash.
These blocks should be removed by nir_opt_dead_cf, so don't bother optimizing
them here.
Fixes: 60776f87c3 ("nir/opt_remove_phis: rematerialize constants")
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35935>
f065c2f0ac actually always triggers the rule it adds because
that commit itself changes one of these files, so the case where none of
these files are changed was not actually tested.
The two options are to drop the `changes:` line from that commit, to
make every staging pipeline run that job, or to add the missing
"no changes" corresponding rule, which this commit does, which aligns
with the "run when files changed, don't run otherwise" behaviour of the
other rules above.
Fixes: f065c2f0ac ("ci: fix rustfmt job rules")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36306>
We avoid adding unconditionally the 64-bytes padding to all usages
of the vulkan memory allocations. The readahead padding is only added
for buffers/images with USAGE_TRANSFER_SRC_BIT usage enabled as this
is enough for having a full vk-cts without reported MMU TFU errors.
vk-cts doesn't exercise the added image memory requirements codepath to
handle this readahead. This is because the required 64-bytes image
alignments for images with flag VK_IMAGE_USAGE_TRANSFER_SRC_BIT.
But the alignment didn't cover when the image is already aligned to
64-bytes at the end of the memory page.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36159>
Most of it is tracking stuff that is ending synchronously anyways.
For example, in emit_barrier_insert_waits, cs_sync64_wait is sync and
therefore there is no need to defer the timestamp write on any SBs.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Olivia Lee <olivia.lee@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36161>
This is so that in subsequent commits the wait mask can be:
- set by the caller
- not provided at all -> synchronous ts write
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Olivia Lee <olivia.lee@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36161>
According to screen.rst, sample_count of 1 is the same as a sample_count
of 0, neither of which are multi-sampling. We only want to include
formats that support multi-sampling when calculating max samples,
otherwise we can't support the combination of floating-point textures
and multi-sampling on DX9-class GPUs.
...There's one special-case, though; FakeMSAA, which is implemented as
sample_count = 1. In that case, we actually need to check for a single
sample. So let's check for that first, to figure out what the actual
min value is. Ugh, this is hairy.
This brings back GL_EXT_framebuffer_multisample and
GL_EXT_framebuffer_multisample_blit_scaled on R300, and should get
Crocus back to GL 3.x as it was before.
Fixes: f56443ac ("st/mesa: search for smallest supported sample-count")
Acked-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36156>
When using vector parameter type in Rusticl with LLVMpipe backend, the
generated LLVM IR function definition part uses an Array of Vector
(correct type) LLVM type, but the caller generates a Vector of Vector
(invalid type). This mismatch causes three problems:
1. Type check fails in debug build;
2. The dumped LLVM BC cannot be disassembled due to Invalid Type;
3. Potential faulty JIT code.
This bugfix construct an Array of Vector for NIR function call by a new
`lp_build_gather_array` function. Special thanks to Zhichao Guan
<vbcpascal@outlook.com> for the joint effort in this bugfix, and
Jose Fonseca for sggestions.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36287>
This should work now that the pass returns progress and invalidates metadata.
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36291>
Tracking if we changed the shader is somewhat complicated, so assume
we always do.
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36291>
