Fixes the following building error:
external/mesa/src/egl/drivers/dri2/platform_android.c:1263:10: error: use of undeclared identifier 'FALLTHROUGH'
FALLTHROUGH; /* for pbuffers */
^
1 error generated.
Fixes: 2928c21eb7 ("Convert most remaining free-form fall-through comments to FALLTHROUGH")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10264>
(cherry picked from commit 0a71aaa29d)
Required to build Mesa on macOS with
-Dbuild-tests=true -Dglx=gallium-xlib
Without this change, the build fails with
In file included from ../src/gallium/targets/graw-xlib/graw_xlib.c:8:
../src/gallium/include/frontend/xlibsw_api.h:5:10: fatal error: 'X11/Xlib.h' file not found
#include <X11/Xlib.h>
With `brew sh` X11 is found but linking fails due to `llvm-ar` missing
in the path. That issue appears to be unrelated to this missing
dependency. X11 is installed via XQuartz, so Homebrew should not be
required.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12022>
(cherry picked from commit 061508d310)
This expands on commit c54c42321e. See the code comment for full
justifications. At the time of the previous commit Ian wanted to
limit the relaxing of the rule to GLSL 3.30 as that was the highest
version of shaders seen in the wild that were having trouble with
the stricter rules.
However since then I've found that the long standing issue with tess
shaders failing to compile in the game 'Layers Of Fear' is due to
this same issue. The game uses 4.10 shaders and also makes use of
explicit varying locations, so here we relax the rule to 4.20 and
make sure to apply the restriction to shaders using varyings with
explicit locations also.
Fixes: c54c42321e ("glsl: relax rule on varying matching for shaders older than 4.00")
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11873>
(cherry picked from commit 0e0633ca49)
Unfortunately I contacted the dev about this issue years ago and he
made a fix, but it has never been released after all these years.
This stops the screen from being completely black in game.
CC: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11941>
(cherry picked from commit f3ec4a934d)
Before commit f7e0cdcf1a, we tried these in order
- if (!ForceSoftware) surfaceless_probe_device(disp, false);
- surfaceless_probe_device(disp, true);
- surfaceless_probe_device_sw(disp);
The commit changed it to
- surfaceless_probe_device(disp, ForceSoftware);
- surfaceless_probe_device_sw(disp);
and broke 2D virtio-gpu and vgem when ForceSoftware is false. This
commit restores the old behavior.
Fixes: f7e0cdcf1a ("egl/surfaceless: simplify dri2_initialize_surfaceless()")
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11992>
(cherry picked from commit 384181921c)
With this pass enabled in Intel drivers, running shader-db on
shaders/unity/38.shader_test resulted in
Program received signal SIGSEGV, Segmentation fault.
gcm_schedule_early_src (src=0x555555d45348, void_state=0x7fffffffba40) at ../../SOURCE/master/src/compiler/nir/nir_opt_gcm.c:297
297 if (info->early_block->index < src_info->early_block->index)
(gdb) print src_info->early_block
$1 = (nir_block *) 0x0
I tracked this down to an early exit from gcm_schedule_early_instr on
the parent instruction because instr->pass_flags was 0x1c. That
should be an impossible value for this pass, so I inferred that
pass_flags must have dirt left from some previous pass.
Fixes: 8dfe6f672f ("nir/GCM: Use pass_flags instead of bitsets for tracking visited/pinned")
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/597>
(cherry picked from commit 436668874a)
Like in the case of emitting a block, process pending TMU operations
before a jump is executed.
Fixes dEQP-VK.graphicsfuzz.stable-binarysearch-tree-nested-if-and-conditional.
Fixes: 197090a3fc ("broadcom/compiler: implement pipelining for general
TMU operations")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11971>
(cherry picked from commit dc40157888)
The function radeonsi_screen_create_impl() tries to create the
aux_context but doesn't actually check for the returned value from
si_create_context().
Then, on si_destroy_screen() the aux_context is used without actually
checking whether it's a thing or not.
As a result, if for any reason si_create_context() failed, we shall
crash in si_destroy_screen() with a NULL pointer dereference trying to
access ((struct si_context *)sscreen->aux_context)->log.
Simply check for aux_context not being NULL to avoid that crash.
Cc: mesa-stable
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11948>
(cherry picked from commit 5bfd1a7e19)
Originally I fixed the case where the nir itself has a shared mem size of
0, but the frontend (e.g. clover) set it to some other value.
But st/mesa sets the shared mem size on the state object as well and we
end up actually doubling the value in the driver as we set smemSize to the
value from the state object before calling into the compiler.
So just max the value instead.
Fixes the compute_shader.shared-max CTS test.
Fixes: dc667b1f19 ("nv50/ir/nir: fix smem size")
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11047>
(cherry picked from commit ff55412f40)
This replaces some new/delete uses with malloc/free.
This is more consistent with most of the other glsl IR code but
more importantly it allows the game "Battle Block Theater" to
start working on some mesa drivers. The game overrides new and
ends up throwing an assert and crashing when it sees this
function calling new [0].
Note: The game still crashes with radeonsi due to similar conflicts
with LLVM.
CC: mesa-stable
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11907>
(cherry picked from commit 749251391d)
DRM_IOCTL_I915_QUERY is a multi-query. The most egregious errors are
returned via the usual ioctl error mechanism but there are also
per-query errors that are indicated by item.length < 0. We need to
handle those as well. While we're at it, scrape errno so we can return
a proper integer error.
Fixes: c0d07c838a "anv: Support i915 query (DRM_IOCTL_I915_QUERY)..."
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11770>
(cherry picked from commit b664481ba9)
Drops the vk_format_to_pipe (and it's outdated table) for vk_format_to_pipe_format, aswell as the duplicated vk_format_aspects function.
The old format table was missing USCALED and other values, causing incorrect rendering in many games.
Fixes rendering in Portal 1, Hat in Time, Half-Life 2 and pretty much every other D3D9 title with DXVK.
Fixes: b38879f8c5 ("vallium: initial import of the vulkan frontend")
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11863>
(cherry picked from commit 1744372714)
The Vulkan 1.2 specification, section 11.2.12 ("Host Access to Device
Memory Objects") say the following:
> memory must have been created with a memory type that reports
> VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
Since there's no guarantee that there's any memory that is *both*
device-local *and* host-visible, let's just use the latter requirement.
Fixes: 8af568e4ae ("vulkan: implement wsi_win32 backend")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11848>
(cherry picked from commit e3542b35a8)
The Vulkan 1.2 specification, section 11.2.12 ("Host Access to Device
Memory Objects") say the following:
> If size is not equal to VK_WHOLE_SIZE, size must be greater than 0
So, mapping a zero-sized range is illegal. Let's instead map the
reported size of the image, which we already know.
Fixes: 8af568e4ae ("vulkan: implement wsi_win32 backend")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11848>
(cherry picked from commit d0c7a2106b)
Doing *both* of thse ends up rewriting the previous mapping. Since this
doesn't seem to have lead to issues, it seems like the new mapping works
just as well.
Fixes: a22a1c0324 ("zink: Fix VK_FORMAT_A8B8G8R8_SRGB_PACK32 mapping on big-endian")
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11417>
(cherry picked from commit 4efbeafa44)
When we go to split e.g. a p0.x producer, the only other instructions
ready to schedule are often only p0.x producers. It could happen that
they all have a lower priority than the split instruction. Then we would
immediately schedule the split instruction again, then again try to
schedule one of the other producers, be blocked, and split it, around
and around again, leading to an infinite loop. The following commit
triggered this with
dEQP-GLES3.functional.shaders.discard.dynamic_loop_always on a3xx.
Fixes: d2f4d33 ("freedreno/ir3: new pre-RA scheduler")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6752>
(cherry picked from commit bb3212dd4d)
There is some hardware with num_render_backends == 1, but the number
of render backends in GB_ADDR_CFG > 1. Turns out this can be turned
off by making them rb unaligned which is valid with only 1 render
backend.
Fixes: 0833dd7d12 ("amd/common: Add support for modifiers.")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10575>
(cherry picked from commit e2e9dd44f4)
Per OpenGL Shading Language, section 8.11. "Atomic Memory Functions"
first argument "mem" of all atomicOP functions is inout.
The same is true for ARB_shader_storage_buffer_object and
GL_INTEL_shader_atomic_float_minmax
For implicit conversion of inout parameters it is required for type
to support bi-directional conversion, since there is no such types
in glsl - implicit conversion is effectively prohibited.
Alternatively we could have marked atomic_var parameter of built-in
atomicOP functions as inout, however it opens another can of worms
during NIR lowerings.
Fixes: ea0a1f5beb
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2837
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4887>
(cherry picked from commit c0f623e62f)
ifind_msb_rev was introduced in a5747f8ab3.
ifind_msb_rev guards against src0 being both 0 or -1 at the same time.
That is always true. This patch changes it to check for those values
individually.
Spotted from a compile warning.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Fixes: a5747f8ab3 (\"nir: add opcodes for *find_msb_rev and lowering\")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11630>
(cherry picked from commit ffea622604)
This should be a subtract, not an add. The comment's proof is correct,
but the (wrong) expression we actually use isn't what it's in the
comment! Correct the discrepancy.
The lowering in nir_opt_algebraic was correctly typed.
Fixes: 272e927d0e ("nir/spirv: initial handling of OpenCL.std extension opcodes")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11671>
(cherry picked from commit 3da23a9c7e)
If a shader has no defined version force_glsl_version was
previous ignored and the shader would default to 110. This updates
the code so that those shaders are forced to a new level also.
We reused the existing code to make sure a sensible value is set
for the version.
Cc: mesa-stable
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11602>
(cherry picked from commit e607205af0)
Avoids warning about the annotation with GCC 10:
../src/gallium/frontends/osmesa/osmesa.c: In function ‘osmesa_choose_format’:
../src/util/compiler.h:84:21: warning: attribute ‘fallthrough’ not preceding a case label or default label
84 | #define FALLTHROUGH __attribute__((fallthrough))
| ^~~~~~~~~~~~~
../src/gallium/frontends/osmesa/osmesa.c:316:7: note: in expansion of macro ‘FALLTHROUGH’
316 | FALLTHROUGH;
| ^~~~~~~~~~~
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10220>
(cherry picked from commit bf480cc9c2)
Compiling with clang warns about an unused variable in
nir_lower_packing.
Tracking progress was added to nir_lower_packing in
adb157ddfd but the function
will ignore the progress from impl calls and always return
false.
This patch changes it to return the progress. It fixes the
warning and should enable validation calls in NIR_PASS when
progress is made.
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Fixes: adb157ddfd "nir: Return progress from nir_lower_64bit_pack()"
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11615>
(cherry picked from commit ed530ac6c2)
This is the first time we see an application running out of mmap().
We essentially allocate too many batches (+65k) and end up not being
able to mmap them, at which point we can't mmap anything anymore and
things go sideways.
This change allocates bigger batch BOs as we grow an existing command
buffer. This drastically reduces the number of BOs we need to allocate
(the benchmark that reported the issue now reaches a max of ~630 BOs,
instead of reaching 65k and failing previously).
v2: Track the total batch size of command buffers (Jason)
Just give 0 for batch_len to i915 (Jason)
v3: Fix indentation (Jason)
v4: Drop uncessary reshuffling of error labels (Jason)
v5: Remove empty lines (Marcin)
v6: Limit BO growing to chunks of 16Mb (Jason)
v7: Add assert on initial size (Jason)
v8: Add define for max size (Jason)
v9: Fixup v7 assert for non softpin platforms (Lionel)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4956
Cc: mesa-stable
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11482>
(cherry picked from commit 40b67a2922)
Some infinite loop cases were already covered by other
restrictions (e.g. if the loop had a body), but the case with a single
block in the loop body wasn't yet.
This prevents an infinite loop when optimizing the shader in
dEQP-VK.reconvergence.subgroup_uniform_control_flow_ballot.compute.nesting2.3.2
and various others reconvergence tests.
Fixes: 0881e90c09 ("nir: Split ALU instructions in loops that read phis")
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> [v1]
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11476>
(cherry picked from commit b951929795)
The second argument to debug_get_bool_option is a boolean, not a
pointer. Passing a NULL-pointer there triggers a warning, which we treat
as an error on MSVC:
---8<---
../src/gallium/auxiliary/driver_trace/tr_screen.c(1071): error C2220:
the following warning is treated as an error
../src/gallium/auxiliary/driver_trace/tr_screen.c(1071): warning C4047:
'function': 'bool' differs in levels of indirection from 'void *'
../src/gallium/auxiliary/driver_trace/tr_screen.c(1071): error C4024:
'debug_get_bool_option': different types for formal and actual parameter 2
---8<---
Fixes: c1270d4845 ("aux/trace: add screen deduplication for zink+lavapipe tracing")
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11424>
(cherry picked from commit bae4dca8e4)
Right now the accumulator-clearing move emitted by the generator for
Wa_14010017096 inherits the SWSB field from the previous instruction.
This can lead to redundant synchronization, or possibly more serious
issues if the previous instruction had a TGL_SBID_SET SWSB
synchronization mode. Take the SWSB synchronization information from
the IR.
Fixes: a27542c5dd ("intel/compiler: Clear accumulator register before EOT")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11433>
(cherry picked from commit c19cfa9dc2)
This is unlikely to have had any negative side effect on the original
TGL, but will lead to issues on XeHP+ if the software scoreboard pass
isn't able to synchronize the accumulator writes.
Fixes: a27542c5dd ("intel/compiler: Clear accumulator register before EOT")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11433>
(cherry picked from commit 63abc083ce)
The Navi 1x NGG hardware can hang in certain conditions when
not every wave launched before s_sendmsg(GS_ALLOC_REQ).
As a workaround, to ensure this never happens, let's emit a
workgroup barrier at the beginning of NGG VS and TES.
Note that NGG GS already has a workgroup barrier so it doesn't
need this.
Cc: mesa-stable
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/10837>
(cherry picked from commit e6bf5cfe59)
Navi 1x GPUs have an issue: they can hang when the output vertex
and primitive counts are zero. The workaround is exporting a dummy
triangle.
This commit changes the dummy triangle's vertex so its positions
are all NaN. This should make sure the triangle is never rendered.
Cc: mesa-stable
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/10837>
(cherry picked from commit f9447abb36)
mesa/mesa@2dcc9c7f54 from mesa/mesa!6639 added a resource_get_param
hook for llvmpipe, which was nice since it gave lavapipe more features.
One of those features was not exporting llvmpipe textures, so those
parts were stubbed out and landed in an assert(0).
This completely broke kms_swrast (llvmpipe+GBM) on non-release builds,
since that definitely does need to export llvmpipe textures.
The query codepath which caused this explosion does fall back to
resource_get_handle() - which is how it worked previously - but not all
callers do this, so just do what all other drivers implementing
resource_get_param() do and open-code the translation.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reported-by: Jonas Ådahl <jadahl@gmail.com>
Tested-by: Jonas Ådahl <jadahl@gmail.com>
Fixes: 2dcc9c7f54 ("llvmpipe: add resource get param support.")
Ref: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6639
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11504>
(cherry picked from commit 9102921109)
This avoids all locks for reads and using lock only while actually
writing.
This is enabled by doing two things:
1) Reading the index incrementally. This way we get new entries
written by other processes and do not write duplicate entries.
2) Taking the lock only during writes, and applying the incremental
read while holding the lock so we always append to the actual end of the file.
Fixes: eca6bb9540 ("util/fossilize_db: add basic fossilize db util to read/write shader caches")
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11485>
(cherry picked from commit 4f0f8133a3)
If compressed rendering is only used for the depth aspect of a
depth/stencil image, stencil might also be compressed and it needs
to be decompressed. This only happens for non-TC compatible images.
As long as the driver needs to decompress the depth aspect, I don't
think that decompressing the stencil aspect introduces extra cost.
Fixes dEQP-VK.renderpass*late_fragment_tests*.d32_sfloat_s8_uint for
chips that don't support TC-compat HTILE.
Cc: 21.1 mesa-stable
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/11263>
(cherry picked from commit 213c4c5f44)
From the Vulkan spec 1.2.181:
"The difference of the size of memory and memoryOffset must be
greater than or equal to the size member of the
VkMemoryRequirements structure returned from a call to
vkGetImageMemoryRequirements with the same image"
This is invalid usage but adding a check in the driver is safe and
might avoid spurious failures.
This is a workaround for the inventory GPU hang with Cyberpunk 2077
which is actually a game bug. Luckily the game handles this error
gracefully.
Since the addrlib change from March, addrlib now selects a better
swizzle mode (4KB instead of 64KB) which reduces image size. Though,
the game assumes that an image with 2 mips is always smaller than the
same image but with 6 mips. This is not always true if the swizzle mode
is different. Then, it creates a D312 heap that is too small for the 2
mips image and the GPU hang with a memory violation, ugh...
Note that next vkd3d-proton release should also reject this but
fixing both sides is fine.
Cc: 21.1 mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4823
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4593
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/11448>
(cherry picked from commit 50233d0daa)
When an OpBranchConditional that had two equal branches was parsed, we
were treating it as a regular OpBranch. However this doesn't work
well when there's an associated OpSelectionMerge. We ended up
skipping marking the merge block as such, and depending on what was
inside the construct we would end up trying to process the block
twice.
Fix this by keeping the vtn_if around, but when emitting NIR identify
the two equal branch case.
Fixes: 9c2a11430e ("spirv: Rewrite CFG construction")
Closes: #3786, #4580
Reviewed-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9297>
(cherry picked from commit 64cb143b92)
Read directly from the instruction getting spilt. Otherwise a fill
will be inserted before the spill writing the value, so the
instruction reading the spilt value gets garbage data.
Use the bundle_id to check if the instructions are in the same bundle.
Insert a move instruction, as the spill needs the value in a LD/ST
register such as AL0, while the ALU instruction reading the value
needs it in a work register such as R0.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4857
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11212>
(cherry picked from commit 38e8d7afe3)
Commit 24342e499b changed how primitive
topology is handled on Gfx8+ but missed updating the Gfx7.x code.
As a result, tests which previously used topologies like PATCHLIST_3
instead started using bogus ones like LINESTRIP_ADJ. This caused a
GPU hangs in a bunch of Vulkan conformance tests involving tessellation.
This fixes those hangs.
Fixes: 24342e499b ("anv: fix dynamic primitive topology for tess")
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11434>
(cherry picked from commit 0510a947ba)
Buffers are created without a format in Vulkan, and we always pass in
R8_UNORM for them in Gallium. It's the view-formats we should have
checked, if anything.
But that's orthogonal to this. We shoudn't keep checking R8_UNORM
capabilities for buffers, all it's going to do is trigger asserts.
Fixes: 00dc0036b ("zink: flatten out buffer creation usage flags codepath")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11416>
(cherry picked from commit a8fc38b276)
With nir I encountered the case where the same value can be written to from
multiple surface operations. This caused some weird messups with the unions
as the def.rewrite operations caused unrelated instructions to get new their
value replaced as well.
In order to replace def.rewrite, we have to create a new temp value, write
to that one instead and move to the original value.
Fixes: 869e32593a ("gm107/ir: fix loading z offset for layered 3d image bindings")
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11053>
(cherry picked from commit c1f938b647)
In 2737abb44e, the handling of pixel-offsets and edge rules were
untangled, but one case was missed.
This fixes the following dEQP test-cases on VirGL + LLVMpipe
- dEQP-GLES2.functional.draw.random.10
- dEQP-GLES2.functional.draw.random.42
- dEQP-GLES3.functional.draw.random.105
- dEQP-GLES3.functional.draw.random.114
- dEQP-GLES3.functional.draw.random.135
- dEQP-GLES3.functional.draw.random.144
- dEQP-GLES3.functional.draw.random.155
- dEQP-GLES3.functional.draw.random.174
- dEQP-GLES3.functional.draw.random.206
- dEQP-GLES3.functional.draw.random.31
- dEQP-GLES3.functional.draw.random.43
- dEQP-GLES3.functional.draw.random.84
- dEQP-GLES31.functional.draw_indirect.random.20
...as well as these on Zink + Lavapipe:
- spec@nv_primitive_restart@primitive-restart-disable_vbo
- spec@nv_primitive_restart@primitive-restart-vbo_combined_vertex_and_index
- spec@nv_primitive_restart@primitive-restart-vbo_index_only
- spec@nv_primitive_restart@primitive-restart-vbo_separate_vertex_and_index
- spec@nv_primitive_restart@primitive-restart-vbo_vertex_only
Fixes: 2737abb44e ("gallium: Replace gl_rasterization_rules with lower_left_origin and half_pixel_center.")
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11183>
(cherry picked from commit 2812f030f1)
attempting to read the inlined uniforms directly after the variant key
using the size of the variant is not going to work since the variant union
is (sometimes) much larger than the size of the actual struct being used,
meaning that this would just copy a bunch of zeroes instead of the actual
inlined uniforms
Fixes: 7f28775edc ("zink: implement uniform inlining")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11003>
(cherry picked from commit eb12f7f11e)
using the stride to calculate the buffer map size here is not correct, as
the stride is not necessarily equal to the attribute size, it's only the distance
between elements. for the case of overlapping elements (cts does this), the result
is that the attribute conversion will read past the end of the mapped src region
this is usually fine for drivers when they directly map the vertex buffer, as the memory
past the requested region is usually made available, but in the case where the readback
occurs using a staging resource sized exactly to the map region, this overflows and fails
silently, not even triggering a valgrind error because gpu memory lol
instead, add the size of the largest possible element, which will automatically be clamped
and ensure any staging buffers are correctly sized
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10963>
(cherry picked from commit 3c5b7dca30)
When the offset is negative, reg() isn't 255. Fix this by splitting
SGPR and literal emission. While we are at it, adjust a comment
saying that literals are also accepted on GFX6 which is wrong.
Fixes another batch of robustness tests.
Cc: 21.1 mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11247>
(cherry picked from commit d169dad393)
If the tex/sfu ssa src is from a different block than the one currently
being scheduled, we do not have a valid sched-node. So fallback to
previous behavior rather than dereference an invalid ptr.
Fixes: 7821e5a3f8 ("ir3/sched: Don't penalize uses of already-waited tex/SFU")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10306>
(cherry picked from commit 09f64f74db)
We shouldn't be using RETURN_EGL_EVAL() for eglDupNativeFenceFDANDROID()
return, as (while perhaps unlikely) zero is a valid fd. The error case
for EGL_NO_NATIVE_FENCE_FD_ANDROID is already handled in egl_dri2.c
(dri2_dup_native_fence_fd()) so just use RETURN_EGL_SUCCESS() instead.
Also fix ret type.
Fixes: 0201f01dc4 ("egl: add EGL_ANDROID_native_fence_sync")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11202>
(cherry picked from commit bfeff2c687)
Otherwise the pb_slabs might be freed by another thread in between.
Valgrind example:
==676841== Invalid read of size 1
==676841== at 0x6B0A8B3: get_slab_wasted_size (amdgpu_bo.c:659)
==676841== by 0x6B0AD7D: amdgpu_bo_slab_destroy (amdgpu_bo.c:684)
==676841== by 0x6ACF94F: pb_destroy (pb_buffer.h:259)
==676841== by 0x6ACF94F: pb_reference_with_winsys (pb_buffer.h:282)
==676841== by 0x6ACF94F: radeon_bo_reference (radeon_winsys.h:754)
==676841== by 0x6ACF94F: si_replace_buffer_storage (si_buffer.c:274)
==676841== by 0x6957036: tc_call_replace_buffer_storage (u_threaded_context.c:1554)
[...]
==676841== by 0x4ECCDEE: clone (clone.S:95)
==676841== Address 0x27879945 is 5 bytes inside a block of size 208 free'd
==676841== at 0x48399AB: free (vg_replace_malloc.c:538)
==676841== by 0x6B0E8BD: amdgpu_bo_slab_free (amdgpu_bo.c:863)
==676841== by 0x6B89D4A: pb_slabs_reclaim_locked (pb_slab.c:84)
==676841== by 0x6B89D4A: pb_slab_alloc (pb_slab.c:130)
==676841== by 0x6B0EE7F: amdgpu_bo_create (amdgpu_bo.c:1429)
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4736
Fixes: 965c6445ad ("winsys/amdgpu,radeonsi: add HUD counters for how much memory is wasted by slabs")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11010>
(cherry picked from commit 1bd64d8cfb)
In 2db8867943, we introduced a new meta-op MOV_FOR_SCRATCH which is
identical to MOV except it lets us identify MOVs emitted during spilling
so we know not to re-spill those instructions. We emit them from
shuffle_for_64bit_data whenever the new for_scratch parameter is true.
Unfortunately, we missed the one used for resolving swizzles.
Fixes: 2db8867943 "intel/vec4: Don't spill fp64 registers more..."
Tested-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11155>
(cherry picked from commit 06ae2723d1)
If there is a preload job needing tiling, but no other jobs, then
first_tiler will be set but not tiler_dep.
Fixes faults when two depth-only (stencil is reloaded) clears are done
in a row.
panfrost ffa30000.gpu: Unhandled Page fault in AS1 at VA 0x0000000044870000
Reason: TODO
raw fault status: 0x49002C1
decoded fault status: SLAVE FAULT
exception type 0xC1: TRANSLATION_FAULT_LEVEL1
access type 0x2: READ
source id 0x490
panfrost ffa30000.gpu: gpu sched timeout, js=0, config=0x3301, status=0x8, head=0x608a300, tail=0x608a300, sched_job=f5b0862d
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11104>
(cherry picked from commit 956d961339)
On Wayland, if the wl_drm interface is not available, for example if the
compositor is using the proprietary NVIDIA driver along with their egl-wayland
library, the device_select layer will fail to initialize. However, the failure
path will unconditionally call wl_drm_destroy even though info.wl_drm would be
NULL in that case. This can cause a segfault in libwayland-client.so.
To fix this, check if info.wl_drm is NULL before calling wl_drm_destroy. This
way, initialization will fail gracefully even if that interface is not present.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10598>
(cherry picked from commit f4eb13dc55)
When drawing using util_translate_prim_restart_ib, zink explicitly
ignores pipe_draw_start_count_bias::start, because
util_translate_prim_restart_ib used to create a new index-buffer without
padding at the start.
This makes a lot of sense, because creating a padded index buffer is
just wasteful.
So let's walk back on the choice of starting to pad the output buffer.
Fixes: 1272c2e052 ("util/prim_restart: fix util_translate_prim_restart_ib")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4851
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11059>
(cherry picked from commit 05bb449610)
It is valid to not have a sampler view declaration for the corresponding
sampler in a TGSI shader, and hence we should not rely on the sampler view
declaration to determine if we need to adjust the unnormalized coordinates
for texture rectangle sampling.
This patch is to prep for tgsi shaders that are translated from nir which
in many cases do not issue sampler view declarations.
Fixes: 584b107037 ("st/mesa: Drop the TGSI paths for drawpixels and use nir-to-tgsi")
Reviewed-by: Neha Bhende <bhenden@vmware.com
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11011>
(cherry picked from commit fda4eaf5c4)
Sometimes, TGSI shader doesn't have SVIEW declaration if it is not
utilize in shader. In such cases, declare those resources with the
help of information stored in shader key.
Fixes: 584b107037 ("st/mesa: Drop the TGSI paths for drawpixels and use nir-to-tgsi")
Tested with piglit, gleretrace
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11011>
(cherry picked from commit fd98649091)
For fragment shaders that only contain a discard, the exec mask has
to be zero'd and everything discarded.
It seems unnecessary to emit an export here because if the FS has no
exports, the compiler already emits a null export at the end.
Fixes incorrect hair rendering in Detroit: Become Human.
fossil-db (Sienna Cichlid):
Totals from 3 (0.00% of 149839) affected shaders:
CodeSize: 2896 -> 2872 (-0.83%)
Instrs: 556 -> 553 (-0.54%)
Latency: 29266 -> 29214 (-0.18%)
InvThroughput: 3374 -> 3372 (-0.06%)
Cc: 21.1 mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10955>
(cherry picked from commit 729ebe4b17)
We previously allocated only 16MB, but this isn't always enough. Now
that we have growable (heap) on recent kernels, there's not much reason
to try to shrink this allocation.
Fixes OUT_OF_MEMORY fault on furmark trace.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10938>
(cherry picked from commit ac1ee2bebe)
this was broken for the indirect case if the indirect draw count or
firstIndex was nonzero and also would rewrite the index buffer onto the
wrong offset of the dst buffer
Fixes: 0c85d6c523 ("gallium/util: factor out primitive-restart rewriting logic")
Fixes: 330d0607ed ("gallium: remove pipe_index_buffer and set_index_buffer")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10909>
(cherry picked from commit 1272c2e052)
According to isl_gfx7.c:264, the display engine does not support Y
tiled buffers prior to Skylake. But we exposed I915_FORMAT_MOD_Y_TILED
even when querying for a list of modifiers with PIPE_BIND_SCANOUT set,
which we can't support. That led to crashes later when we tried to
create such an image, and isl rightly denied it.
Fixes crashes in wflinfo since c03e79d783, but the bug exists before
that and it's probably worth a stable backport even without that patch.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4815
Fixes: c03e79d783 ("loader/dri: hook up createImageWithModifiers2")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10907>
(cherry picked from commit dd508b2bed)
According to isl_gfx7.c:264, the display engine does not support Y
tiled buffers prior to Skylake. But we exposed I915_FORMAT_MOD_Y_TILED
even when querying for a list of modifiers with __DRI_IMAGE_USE_SCANOUT
set, which we can't support. That led to crashes later when we tried
to create such an image, and isl rightly denied it.
This duplicates a bit of code from ISL, but the isl_gfx6_filter_tiling
function that we ought to use to filter things relies on surf_info,
which we don't have at this stage. This is probably good enough.
Fixes crashes in wflinfo since c03e79d783, but the bug exists before
that and it's probably worth a stable backport even without that patch.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4815
Fixes: c03e79d783 ("loader/dri: hook up createImageWithModifiers2")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10907>
(cherry picked from commit e9e953ff94)
The 3D-pipeline fast clears try to emit FS constants before an FS is
necessarily bound, causing segfaults in dEQP. Plus it flushes the whole
batchbuffer so it'll probably be slower anyway.
Fixes: 6358e6371b ("i915g: implement hw clear")
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10874>
(cherry picked from commit 8509aceb74)
When most of these patterns were created, we believed, incorrectly, that
fsat(NaN) was NaN. We have since realized that fsat(NaN) is zero.
Originally, this changed the patterns to use is_a_number. This didn't
help any shaders, so it's easier to just drop the optimizations.
This commit crossed paths with 4c3ad4d065 ("nir/algebraic: mark more
optimization with fsat(NaN) as inexact") and bc123c396a
("nir/algebraic: mark some optimizations with fsat(NaN) as inexact").
Given that these don't impact very many shaders, it seems safer to just
remove them.
As discussed in
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8716, I tried
modifying these patterns to use !(b cmp a). Unfortunately, on Intel
GPUs, the results were much worse than just removing the patterns
altogether.
Some other related patterns will be addressed in later commits.
There are still a number of patterns that use the identity fsat(1-X) ==
1 - fsat(X). If X is NaN, the former is zero while the latter is 1.0.
I haven't evaluted these patterns yet. If changes are needed in these
patterns, it should be a separate commit anyway.
v2: Replace arrow `=>` with `->` in comments because the `=>` looks a
lot like `<=` comparison. Suggested by Rhys.
Fixes: 92b75c126b ("nir/algebraic: Replace checks that a value is between (or not) [0, 1]")
Fixes: a7f0c57673 ("nir/algebraic: Eliminate useless fsat() on operand of comparison w/value in (0, 1)")
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
All Intel hardware had similar results. (Ice Lake shown)
total instructions in shared programs: 20029060 -> 20029670 (<.01%)
instructions in affected programs: 69236 -> 69846 (0.88%)
helped: 0
HURT: 263
HURT stats (abs) min: 1 max: 20 x̄: 2.32 x̃: 1
HURT stats (rel) min: 0.30% max: 11.11% x̄: 1.35% x̃: 0.98%
95% mean confidence interval for instructions value: 1.86 2.78
95% mean confidence interval for instructions %-change: 1.18% 1.52%
Instructions are HURT.
total cycles in shared programs: 979821278 -> 979834425 (<.01%)
cycles in affected programs: 1476848 -> 1489995 (0.89%)
helped: 49
HURT: 204
helped stats (abs) min: 1 max: 812 x̄: 102.31 x̃: 20
helped stats (rel) min: 0.01% max: 21.43% x̄: 2.23% x̃: 0.52%
HURT stats (abs) min: 2 max: 2600 x̄: 89.02 x̃: 16
HURT stats (rel) min: 0.04% max: 27.27% x̄: 1.49% x̃: 0.72%
95% mean confidence interval for cycles value: 13.18 90.75
95% mean confidence interval for cycles %-change: 0.29% 1.25%
Cycles are HURT.
No fossil-db changes.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10012>
(cherry picked from commit d69ba58644)
Caught this with an LTO build:
[1465/1465] Linking target src/gallium/targets/dri/libgallium_dri.so
In function ‘spirv_shader_delete’,
inlined from ‘nir_to_spirv’ at ../src/gallium/drivers/zink/nir_to_spirv/nir_to_spirv.c:3907:7:
../src/gallium/drivers/zink/nir_to_spirv/nir_to_spirv.c:3916:4: warning: ‘free’ called on pointer ‘block_1394’ with nonzero offset 48 [-Wfree-nonheap-object]
3916 | FREE(s);
| ^
../src/gallium/drivers/zink/nir_to_spirv/nir_to_spirv.c: In function ‘nir_to_spirv’:
../src/util/ralloc.c:133:18: note: returned from ‘malloc’
133 | void *block = malloc(align64(size + sizeof(ralloc_header),
| ^
Since s->words is allocated on the same ralloc context we can simplify
further by freeing the context all at once.
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10754>
(cherry picked from commit 584145ea88)
The way we handle spilling for fp64 in vec4 is to emit a series of MOVs
which swizzles the data around and then a pair of 32-bit spills. This
works great except that the next time we go to pick a spill reg, the
compiler isn't smart enough to figure out that the register has already
been spilled. Normally we do this by looking at the sources of spill
instructions (or destinations of fills) but, because it's separated from
the actual value by a MOV, we can't see it. This commit adds a new
opcode VEC4_OPCODE_MOV_FOR_SCRATCH which is identical to MOV in
semantics except that it lets RA know not to spill again.
Fixes: 82c69426a5 "i965/vec4: support basic spilling of 64-bit registers"
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10571>
(cherry picked from commit 2db8867943)
If CRC data is currently invalid and the current batch will make it
valid, write even clean tiles to make sure CRC data is updated.
Fixes: 8ba2f9f698 ("panfrost: Create a blitter library to replace the existing preload helpers")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10566>
(cherry picked from commit e241ca6e9c)
There is a regression that made it impossible to export gem
handles with write access.
That is, a client may export gem handles of each buffer plane, then
export dmabuf fds using these handles, and mmap these dmabuf in
a different process (this is what Chromium does).
After https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4861,
it became impossible as mmap resulted in EACCESS error as slightly
different approach was taken for exporting these gem handles.
This CL fixes exporting gem handles (which are exported from dmabuf
fds) by adding the DRM_RDWR flag.
Cc: mesa-stable
Fixes#3119
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10850>
(cherry picked from commit 5eaf8b59c8)
There is a regression that made it impossible to export gem
handles with write access.
That is, a client may export gem handles of each buffer plane, then
export dmabuf fds using these handles, and mmap these dmabuf in
a different process (this is what Chromium does).
After https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4861,
it became impossible as mmap resulted in EACCESS error as slightly
different approach was taken for exporting these gem handles.
This CL fixes exporting gem handles (which are exported from dmabuf
fds) by adding the DRM_RDWR flag.
Cc: mesa-stable
Fixes#3119
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10851>
(cherry picked from commit b74898ef69)
It's perfectly legal to declare multiple SSBOs that point to the same
binding/descriptor_set with different access mask. Currently, it will
always get the first one in the list that matches binding/desc_set
regardless of the access mask, but other variables might have different
access mask.
Fix this by being conservative if another variable uses the same
binding/desc_set because we can't get it reliably without adding
a new field to vulkan_resource_index.
This fixes rendering issues in Resident Evil Village with vkd3d-proton.
This bug has been uncovered by ("spirv: Don't remove variables used by
resource indexing intrinsics") because variables are no longer removed
No fossils-db changes.
Cc: 21.1 mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10692>
(cherry picked from commit 1b1c726ca9)
Gallium wants the depth or stencil component replicated on all .XYZW.
That's easily done on pre-v7 since we can forge all the swizzles we
want, but Bifrost v7 only supports a few combinations, so we have to
combine the user swizzle with our own 'replicate' swizzle to make it
work. Note that v7 has a trick to make border color work when the GRBA
order is chosen: they apply the red border color to the green component.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10612>
(cherry picked from commit f08c14138a)
BOs in the cache are chronological, so we try oldest BOs first. That
means if we find the oldest BO is busy, likely every BO is busy, and we
should bail early. This dramatically reduces the useless cycles spent in
bo_wait.
I studied the BO cache of the following drivers, all of which handle
this correctly: iris, lima, etnaviv, freedreno, vc4, v3d, v3dv.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10794>
(cherry picked from commit 77d0498913)
The load-store vectorizer can create a large amount
of unnecessary nir_op_vec and nir_op_mov instructions.
This prevents nir_opt_move from stalling to much and
potentially also helps other passes.
Closes: #4778
Fixes: 1958381c9a ('radv: Reorder some NIR optimizations in preparation for the I/O changes.')
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10804>
(cherry picked from commit b3eb87aa65)
a fence applies to all the submitted cmdbufs, so it's necessary to do
the flush which creates the user fence after all the cmdbufs have been
processed in order to avoid creating a fence that only applies to the
first cmdbuf
Fixes: b38879f8c5 ("vallium: initial import of the vulkan frontend")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10795>
(cherry picked from commit cf3f17a643)
The initial value needs to be taken from the instruction that is being
moved over, not the one to be moved.
Additionally the parameter of this function was removed because it was
misleading. Setting it to any value other than source_idx would cause
register_demand to be initialized incorrectly. (Instead, the maximum
demand among the covered instructions would need to be determined.)
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10644>
(cherry picked from commit 50ba919d37)
From the ARB_enhanced_layouts spec:
"As with input layout qualifiers, all shaders except compute shaders
allow *location* layout qualifiers on output variable declarations,
output block declarations, and output block member declarations. Of
these, variables and block members (but not blocks) additionally
allow the *component* layout qualifier."
We previously had compile tests in piglit to make sure this was not a
compile error but no execution tests.
Fixes: d99a040bbf ("i965: enable ARB_enhanced_layouts for gen8+")
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10763>
(cherry picked from commit 5aabc91273)
this screen object can never, ever be accessed like this in a resource,
as it may have previously been replaced by a wrapper (e.g., driver trace)
which will then explode when it is accessed directly
instead, keep a separate screen ref on the resource which is known to be
the actual driver object and not a wrapper
Fixes: 0a497eb130 ("iris: make resources take a ref on the screen object")
Reviewed-by: Lionel Landwerlin lionel.g.landwerlin@intel.com
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10632>
(cherry picked from commit eb63c7dece)
When I last time fixed this, I missed that continuing here would make us
leak pointers in the translate state, which is what made this avoid a
crash in the first place.
That's not great, we need to set *some* pointer in this case. The
obvious option would be NULL, but that means that the translate-code
also needs to support NULL-pointers here.
Instead, let's point to a small, static buffer that contains enough
zero-data for the largest possible vertex attribute. This avoids having
to add more NULL-checks.
Fixes: a8e8204b18 ("gallium/u_vbuf: support NULL-resources")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7773>
(cherry picked from commit a2d091694f)
nir_intrinsic_memory_barrier has the same semantic as memoryBarrier()
in GLSL, which is:
GLSL 4.60, 4.10. "Memory Qualifiers":
"The built-in function memoryBarrier() can be used if needed to
guarantee the completion and relative ordering of memory accesses
performed by a single shader invocation."
GLSL 4.60, 8.17. "Shader Memory Control Functions":
"The built-in functions memoryBarrier() and groupMemoryBarrier() wait
for the completion of accesses to all of the above variable types."
Fixes tests:
dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.device.payload_local.image.guard_nonlocal.workgroup.comp
dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.device.payload_nonlocal.workgroup.guard_local.image.comp
Fixes: 819a613a ("freedreno/ir3: moar better scheduler")
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9054>
(cherry picked from commit cb8a00791c)
The build-finished event is also triggered when there's an error. I
somehow got the second argument wrong, and ended up ignoring the case.
This can lead to new exceptions being thrown due to missing files, that
ends up hiding the real problem.
Fixes: 64a4ba9e1c ("docs: add an extension to generate redirects")
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10407>
(cherry picked from commit 2736370294)
Move it out of the "cs" sub-struct, since the bit can be used for
other shader stages in the future.
This also removes a subtle issue in spirv_to_nir:
info.cs.shared_memory_explicit_layout was used without checking for
the CS shader stage. It ended up being "harmless" since the effects
also depended on presence of shared variables.
Fixes: 5de6c5973a ("spirv: Implement SPV_KHR_workgroup_memory_explicit_layout")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10529>
(cherry picked from commit dd48683cfd)
There's a recently discovered HW bug affecting hardware at least as far
back as Skylake where, if the LOD is out-of-bounds for any SIMD lane,
then garbage may be returned in all SIMD lanes. The easy solution is to
set lower_txs_lod so that we always have a constant LOD of 0 which we
know a priori is always in-bounds. Fortunately, not many shaders
actually use textureSize() with LOD.
Shader-db results on Ice Lake:
total instructions in shared programs: 19948537 -> 19948564 (<.01%)
instructions in affected programs: 3859 -> 3886 (0.70%)
helped: 0
HURT: 7
One of the shaders is in Civilization: Beyond Earth, and the rest are
all in Civilization VI.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Cc: mesa-stable@lists.freedesktop.org
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10538>
(cherry picked from commit 05a37e2422)
a0.x is written as a half-reg, but just interpreting it as "hr61.x" will
result in it overlapping with r30.z in merged mode, which is not what
the hardware does at all. This introduced a spurious dependency on
a write to r30.z which resulted in an assert tripping. Just pretend it's
a full reg instead.
This fixes
spec@arb_tessellation_shader@execution@variable-indexing@vs-output-array-vec3-index-wr-before-tcs
with the new RA.
Fixes: 0f78c32 ("freedreno/ir3: post-RA sched pass")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10591>
(cherry picked from commit e597f8b122)
The max values are inclusive, so add 1 before aligning. This means
that a max of 32 will be aligned up to 64 then be decremented to 63.
Add a comment to the pan_fb_info struct to document maxx and maxy as
inclusive.
Fixes: 8ba2f9f698 ("panfrost: Create a blitter library to replace the existing preload helpers")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10542>
(cherry picked from commit ab8e531cf0)
For non 64bit devices the key stored in hash_table_u64 is wrapped in
hash_key_u64 structure, which is never free.
This commit fixes this issue by just removing the user-defined
`delete_function` parameter in hash_table_u64_{destroy,clear} (which
nobody is using) and using instead a delete function to free this
structure.
Fixes: 608257cf82 ("i965: Fix INTEL_DEBUG=bat")
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10480>
(cherry picked from commit e532a47f76)
Conflicts:
src/microsoft/compiler/dxil_nir.c
The idea behind this assert is that if a buffer is in
bufmgr->handle_table it's because it has been shared from i965 to the
outside. This is when we add the drm FD associated to this BO to
bo->exports.
But we also import buffer from the outside into i965 and those buffers
don't have an associated drm FD added to bo->exports.
If you import the same buffer more than once, you'll run into this
assert.
v2: Also drop assert from brw_bo_gem_create_from_name() (Ian)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 57e4d0aa1c ("i965: fix export of GEM handles")
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10386>
(cherry picked from commit 03e97e94e7)
I mixed up the EXT and ARB version of the extensions; we actually do
require shaderStorageImageWriteWithoutFormat as well here.
Thanks to Ilia Mirkin for pointing this out.
It also seems I got really confused about what was required when writing
the docs, so let's fix that as well.
Fixes: 341332b23a ("zink: correct image cap checks")
Fixes: ecac7f3da1 ("docs: add missing zink-requirement")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10463>
(cherry picked from commit 4ec8533f69)
Conflicts:
docs/drivers/zink.rst
Since generated nir headers are included, it makes sense to include nir path
Fixes the following building error:
FAILED: out/target/product/x86_64/obj/STATIC_LIBRARIES/libmesa_pipe_radeonsi_intermediates/si_shader_nir.o
...
In file included from external/mesa/src/gallium/drivers/radeonsi/si_shader_nir.c:26:
external/mesa/src/amd/common/ac_nir.h:29:10: fatal error: 'nir.h' file not found
^~~~~~~
1 error generated.
Cc: 21.0 21.1 <mesa-stable@lists.freedesktop.org>
Fixes: 1c702a8239 ("ac: move ac_lower_indirect_derefs() outside of the LLVM dir")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10443>
(cherry picked from commit e213bfd330)
Don't setup inputs and outputs if we aren't using
load_input/store_output intrinsics. While it's mostly harmless, there
may be more outputs than expected which would lead to an oob write of
the outputs array when setting the register id to INVALID_REG.
Also be more paranoid with asserts to catch this.
Fixes: a6291b1 ("freedreno/ir3: rework setup_{input,output} to make struct varyings work")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7274>
(cherry picked from commit decfea2f4e)
This makes the vertex order of TRISTRIP and TRISTRIP_ADJ primitves
consistent between XFB output and GS input. Technically, the Vulkan
spec allows us to XFB out in whatever order we want but being consistent
with GS inputs is probably nicer to apps.
Fixes: 36ee2fd61c "anv: Implement the basic form of VK_EXT_transform_feedback"
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10460>
(cherry picked from commit 22b8bcda2c)
PIPE_CAP_IMAGE_LOAD_FORMATTED doesn't depend on
shaderStorageImageExtendedFormats or
shaderStorageImageWriteWithoutFormat.
PIPE_SHADER_CAP_MAX_SHADER_IMAGES enables
GL_EXT_shader_image_load_store, which *does* require
shaderStorageImageExtendedFormats. Having
shaderStorageImageWriteWithoutFormat and
shaderStorageImageReadWithoutFormat isn't enough to support this.
It *might* be possible to lower extended formats to format-less
reads or writes, but we don't currently do that, so we should
just correct the test for now.
Fixes: 3f9a6d333b ("zink: export shader image caps using features")
Fixes: 5282210c0b ("zink: check correct caps for PIPE_CAP_IMAGE_LOAD_FORMATTED")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10456>
(cherry picked from commit 341332b23a)
The claim that we require vulkan memory model's MakeAvailable and
MakeVisible semantics for image writes isn't accurate. This would be
required *if* we were already using the Vulkan memory model.
But we're using the GLSL450 memory model in those cases, which has no
such requirements.
This means that any problems on RADV due to the lack of these semantics
are RADV bugs, and should be fixed in RADV instead.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10345>
(cherry picked from commit 95d9d811c9)
Modern shader APIs, like DX10 and GLSL 1.30, want min() and max() to
"cleanse" NaN. If one source is NaN, the other value should be chosen.
If both sources are NaN, the result may be either.
There are many cases where TGSI is generate from NIR, and many
optimizations in NIR expect this behavior. Not meeting these
expectations can lead to unexpected results.
Reviewed-by: Eric Anholt <eric@anholt.net>
Fixes: ffe58739da ("Softpipe: import TGSI tree. Not hooked-up yet.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10419>
(cherry picked from commit 939bf7a419)
Modern shader APIs, like DX10 and GLSL 1.30, want saturate or
clamp(..., 0.0, 1.0) to "cleanse" NaN. If the source is NaN, the
result should be zero.
There are many cases where TGSI is generate from NIR, and many
optimizations in NIR expect this behavior. Not meeting these
expectations can lead to unexpected results.
Reviewed-by: Eric Anholt <eric@anholt.net>
Fixes: 56c30bf17b ("tgsi: Saturate modifier obeys ExecMask. Implement NVIDIA [-1;+1] saturate mode.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10419>
(cherry picked from commit d1c0f62b42)
Instead of using num_textures, determine the texture count from the
last bit set in textures_used.
Fixes ADDR_RANGE_FAULTs when draw_textured_quad writes only stencil.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10422>
(cherry picked from commit c7076e03e5)
If no slices were valid (the resource is uninitialized), we were reading
a bogus PIPE_FORMAT_NONE format from the blit.dst.format. Fix this --
and guard against scope similar issues -- by hoisting the blit
assignments out of the loop so they're valid.
Fixes: 9d0ad7fd2e ("panfrost: Patch the gallium driver to use pan_image_layout_init()")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10415>
(cherry picked from commit c220976fd0)
resetting a query pool+qbo dumpsters the existing qbo results,
so these need to be copied to the new qbo if they exist, and then the query
id needs to be updated to match the expected result offset so everything
keeps working as expected
Fixes: 00fc85a011 ("zink: reset queries when suspending if >50% of total pool is used")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10268>
(cherry picked from commit 79790e276f)
Otherwise the dual-source input load is moved further down in the
shader, so the registers can get clobbered before then.
Fixes text not being visible in Alacritty.
Fixes: 52863f2e60 ("pan/bi: Enable all nir_opt_move/sink optimizations")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10089>
(cherry picked from commit ab3a72cc20)
The bug #4657 mixed up which commit was actually responsible for
the regression, so re-apply this patch.
The indirect draw call already encodes the index bias so that no
additional encoding in the hardware is needed in this case.
This fixes a regression with a number of tests from
dEQP-GLES31.functional.draw_indirect.random.*
Fixes: c6c532faa8
"gallium/u_vbuf: use updated pipe_draw_start_count while using draw_vbo"
Closes#4671
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10388>
(cherry picked from commit 0cae8d372e)
Normally, we never see NULL in a source. However, starting with
eab1c55590, we can with a SHADER_OPCODE_SEND if it only has the first
payload. We were inserting barriers which adds unnecessary scheduling
dependencies and takes a lot of compile time because inserting a single
barrier is an O(n) operation.
All the extra O(n) can have a surprisingly large effect. This cuts the
runtime of dEQP-VK.binding_model.buffer_device_address.set3.depth3.
basessbo.convertcheckuv2.store.single.std140.frag by a factor of 20x for
a debug build.
Shader-db results on ICL:
total instructions in shared programs: 19918983 -> 19921610 (0.01%)
instructions in affected programs: 884074 -> 886701 (0.30%)
helped: 1688
HURT: 817
helped stats (abs) min: 1 max: 163 x̄: 4.23 x̃: 1
helped stats (rel) min: 0.02% max: 12.50% x̄: 1.08% x̃: 0.61%
HURT stats (abs) min: 1 max: 2674 x̄: 11.95 x̃: 2
HURT stats (rel) min: 0.11% max: 70.22% x̄: 1.71% x̃: 1.03%
95% mean confidence interval for instructions value: -1.97 4.06
95% mean confidence interval for instructions %-change: -0.28% -0.06%
Inconclusive result (value mean confidence interval includes 0).
total cycles in shared programs: 976503324 -> 975884809 (-0.06%)
cycles in affected programs: 82581703 -> 81963188 (-0.75%)
helped: 4144
HURT: 5010
helped stats (abs) min: 1 max: 79294 x̄: 311.31 x̃: 8
helped stats (rel) min: <.01% max: 53.69% x̄: 2.00% x̃: 0.51%
HURT stats (abs) min: 1 max: 92266 x̄: 134.04 x̃: 8
HURT stats (rel) min: <.01% max: 218.09% x̄: 3.25% x̃: 0.53%
95% mean confidence interval for cycles value: -119.85 -15.29
95% mean confidence interval for cycles %-change: 0.68% 1.07%
Inconclusive result (value mean confidence interval and %-change mean confidence interval disagree).
total spills in shared programs: 10659 -> 12014 (12.71%)
spills in affected programs: 441 -> 1796 (307.26%)
helped: 7
HURT: 12
total fills in shared programs: 11551 -> 14429 (24.92%)
fills in affected programs: 993 -> 3871 (289.83%)
helped: 8
HURT: 11
total sends in shared programs: 1025832 -> 1025353 (-0.05%)
sends in affected programs: 2241 -> 1762 (-21.37%)
helped: 105
HURT: 1
helped stats (abs) min: 1 max: 87 x̄: 4.57 x̃: 2
helped stats (rel) min: 5.56% max: 54.72% x̄: 11.37% x̃: 10.00%
HURT stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1
HURT stats (rel) min: 100.00% max: 100.00% x̄: 100.00% x̃: 100.00%
95% mean confidence interval for sends value: -7.39 -1.65
95% mean confidence interval for sends %-change: -12.95% -7.70%
Sends are helped.
LOST: 93
GAINED: 109
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4648
Fixes: eab1c55590 "intel/fs: Support SENDS in SHADER_OPCODE_SEND"
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10412>
(cherry picked from commit 134af5ada2)
we should probably trigger this any time a flush occurs just to avoid
doing too much (unexpected) cmdstream rewriting
both calls must be kept, however, as the one in the base flush hook will change
the behavior of flushing if no other work is queued
Fixes: 104603fa76 ("zink: create separate linear tiling image for scanout")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10358>
(cherry picked from commit 04241e826e)
this is called from the non-deferred flush path, which means it should always
be triggering work, which means it will always result in a queue submission
instead of relying on the pipe_context::flush hook to be triggered, which is
not a guarantee, do scanout sync during queue submission to ensure that scanout
objects are always in sync
Fixes: 104603fa76 ("zink: create separate linear tiling image for scanout")
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10358>
(cherry picked from commit dd8b15b2bb)
Turns out both kernel v5.10 and v5.11 have the same amdgpu driver
version and only one has modifiers ... In addition the version check
is kinda annoying for backports.
So lets use the cap. Since the cap is technically about ADDFB2 I
tested that this works on rendernodes (and reading the code there
is no distinction from what kind of node this is called).
Fixes: 9a937330ef ("radeonsi: Only set modifier creation function for GFX9+ & with kernel support.")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10337>
(cherry picked from commit 9da4590df8)
If depth bias is enabled but zero values used, they were never
emitted to the command buffer because they are equal to the default
values.
Previously, they were always emitted when the bound DS attachment
changed.
This should fix some sort of Z fighting with Dota2 on all GPUs.
This also fixes a different issue (ie. some occlusion queries failures)
on GFX6 because CLEAR_STATE is not used on that chip.
Fixes: 8a47422d97 ("radv: do not scale the depth bias for D16_UNORM depth surfaces")
Cc: 21.1 mesa-stable
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/10310>
(cherry picked from commit 1d3542694b)
Fixes piglit crashes doing glCopyTexSubImage from (for example)
PIPE_FORMAT_Z24_UNORM_S8_UINT to PIPE_FORMAT_Z32_FLOAT_S8X24_UINT where,
in addition to reading the source Z values incorrectly, we would try to
dereference the missing separate stencil of the Z24S8 buffer.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10328>
(cherry picked from commit ed04fd44ca)
tcs user vars are var_size[32], which isn't actually how many slots they need,
just how big the variable is (oops), so this needs to be divided
by MAX_PATCH_VERTICES to get the real slot count
slot mapping has always been broken for all tcs inputs, but this probably fixes
all of the related issues there, including unlimited crashes when playing Tomb Raider
Fixes: 2d98efd323 ("zink: pre-populate locations in variables")
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10269>
(cherry picked from commit 001c6f8201)
nir_convert_from_ssa and assign_io_locations both modify this unconditionally,
the latter of which possibly re-modifies variables in ways that can break the
slot map and cause stack overflows during vk driver pipeline compilation
Fixes: 2b4609b66c ("zink: run nir_convert_from_ssa last during compile")
Fixes: 2d98efd323 ("zink: pre-populate locations in variables")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10269>
(cherry picked from commit a1c7aff88a)
This cap should only ever be emitted for fragment-shaders, but we
accidentally emit it for all shaders. Let's tighten the check to avoid a
validator warning when emitting non-fragment shaders without support for
VK_EXT_shader_stencil_export.
Fixes: 8724d4fb36 ("zink: check shader stencil output")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10249>
(cherry picked from commit d09442461f)
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)
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)
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)
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)
# Bring artifacts back from the NFS dir to the build dir where gitlab-runner
# will look for them.
cp -Rp /nfs/results/. results/
if[ -f "${STRUCTURED_LOG_FILE}"];then
cp -p ${STRUCTURED_LOG_FILE} results/
echo"Structured log file is available at https://${CI_PROJECT_ROOT_NAMESPACE}.pages.freedesktop.org/-/${CI_PROJECT_NAME}/-/jobs/${CI_JOB_ID}/artifacts/results/${STRUCTURED_LOG_FILE}"
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
