The check in alloc_bo_from_cache() was skiping any try to get a bo
from cache but after use a protected bo was still being put in some
cache bucket and could be used for cases that don't require a
protected bo.
Using a protected bo in cases that don't require it can have
performance implications.
So here returning NULL when trying to get a cache bucket for a
protected bo, this will cause bo->real.reusable to be set to false
avoiding the bo to be reused.
Fixes: 9402ac8023 ("iris: handle protected BO creation")
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21824>
(cherry picked from commit 266d961fdc)
The previous solution breaks potential loop header phis.
Move the dummy-break to the bottom of the loop.
Fixes: dEQP-VK.reconvergence.subgroup_uniform_control_flow_ballot.*
Fixes: a9c4a31d8d ('aco: handle NIR loops without breaks')
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21736>
(cherry picked from commit cd1e5b1858)
the recording rp_info may be a pointer to a member of the array being
reallocated, so test for this and re-set it to avoid invalid memory
access
found with this caselist:
KHR-GL46.texture_gather.offset-gather-unorm-2darray
KHR-GL46.texture_view.view_sampling
cc: mesa-stable
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21729>
(cherry picked from commit 6ee5337d94)
Seems to fix a hang in the following titles :
- Age of Empire 4
- Monster Hunter Rise
where the HW is hung on a PIPE_CONTROL after a GPGPU_WALKER but no
MEDIA_INTERFACE_DESCRIPTOR_LOAD was emitted since the switch from 3D
to GPGPU.
This would happen in the following case :
vkCmdBindPipeline(COMPUTE, cs_pipeline);
vkCmdDispatch(...);
vkCmdBindPipeline(GRAPHICS, gfx_pipeline);
vkCmdDraw(...);
vkCmdDispatch(...);
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17247>
(cherry picked from commit 11bc2bde83)
Modifying pitch for all LINEAR surface isn't correct;
the original change that modified surf_pitch was only
intended for YUV textures.
This fixes vkGetImageSubresourceLayout rowPitch return value
for VK_FORMAT_BC3_UNORM_BLOCK + VK_IMAGE_TILING_LINEAR.
Fixes: fcc499d5 (ac/surface: adjust gfx9.pitch[*] based on surf->blk_w)
v2: add check for UYVY format (Pierre-Eric)
v3: move blk_w division to above if check (Pierre-Eric)
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21595>
(cherry picked from commit 347a5b79f9)
this otherwise may have been a surface that was never drawn to or
already had its layout corrected, in which case a deferred barrier
is not only unnecessary, it might be broken
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21739>
(cherry picked from commit e0dfe058c4)
reason:
some h264 streams have some strange pictures, from
vaapi input these pictures don't have a reference frame,
however, they are not intra only pictures, in MB layer
these pictures are looking for some references, if they
cannot find it. It could cause PF.
when reference pictures exist, it will need to set used_for
reference_flags, therefore if that is set, however the
number of reference frames is zero, which is odd, it
should be avoided.
solution:
In the above case, to scan the ref list so that it will
make at least one reference available to avoid crash, since
this is not accurate enough, it could cause some artifacts.
And in that case, it will need to be checked individually
for another solution.
closes: https://gitlab.freedesktop.org/drm/amd/-/issues/1462
closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8401
Cc: mesa-stable
Tested-by: llyyr <llyyr.public@gmail.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21732>
(cherry picked from commit 0f3370eede)
vulkancts test dEQP-VK.wsi.direct_drm.surface.create_simulate_oom is failing
because in wsi_display_alloc_connector() function memory allocation for
connector is not checked for return NULL. create_simulate_oom test simulates
out of memory, hence memory allocation fails for connector and later when
tried to dereference connector program will segfault.
This patch fixes the dEQP-VK.wsi.direct_drm.surface.create_simulate_oom test
segfault issue by checking if connector is NULL afer memory allocation.
Cc: mesa-stable
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21701>
(cherry picked from commit af953616a1)
The issue here is that for draw indirect count variants, we want to
jump after the last generated draw call to the next location where
commands are. But if we have more than 67M draws (8k * 8k chunks), we
only know the location once we've generated each of the 8k * 8k
chunks.
This change adds a CPU side pointer in the push constant struct so
that we can create a single linked list of chunks to edit and go
through to write the correct jump address after all the generated
space has been allocated.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: c950fe97a0 ("anv: implement generated (indexed) indirect draws")
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20497>
(cherry picked from commit 63fa6d9f49)
Using texelFetch to read samples from an 8xMSAA fast cleared image on
Haswell can read transparent black pixels around triangles from where
there should be none. This issue isn't present when using sample
shading, resolving the image using vkCmdResolveImage or in a copy the
image. The easiest way to fix this is by just disabling non-zero fast
clears for 8xMSAA images.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7587
Cc: mesa-stable
Reviewed-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21444>
(cherry picked from commit e509afacf3)
I'm not planning to stand mesa-swrast back up until we get Kata set up, so
turn the testing back on at a reduced fraction on so that
venus/llvmpipe/etc. dev can still get some coverage.
I haven't turned lavapipe back on, because it is now unstable in memory
model / atomics tests.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21880>
(cherry picked from commit 5bb9ab896c)
stable:
- add additional suites to the shared runner list
Register writes from the pre-header might not be correct for any but
the first loop iteration because they can be clobbered inside the loop.
Foz-DB Navi21:
Totals from 18 (0.01% of 134913) affected shaders:
CodeSize: 251384 -> 251508 (+0.05%)
Instrs: 47644 -> 47664 (+0.04%)
Latency: 801801 -> 801852 (+0.01%)
InvThroughput: 177579 -> 177593 (+0.01%)
Copies: 4752 -> 4771 (+0.40%)
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8376
Fixes: d3b0f78110 ("aco/optimizer_postRA: Initialize loop header with preheader information")
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21540>
(cherry picked from commit e1eabab6fe)
Now that all color blend bits are dynamic, emit_cb_state() is doing
almost nothing and half of that is wrong.
In the case that color write enable is dynamic, at the time the pipeline
state is emitted, it sees all the color attachments as having write
disabled and stores the WriteDisabled bit for each channel.
When all dynamic state is flushed, we have the right values already but
the values recorded into the command buffer get ORed with the ones
stored in the pipeline, and so WriteDisabled tag along when they
shouldn't.
Since all disabled color attachments are handled already when dynamic
state is flushed, there's no point in doing so at pipeline creation
time too. And since the only other thing done by emit_cb_state() is
writing three hardcoded values, they might as well be taken care of in
the same place as everything else.
Fixes CTS from the future:
dEQP-VK.pipeline.*.extended_dynamic_state.*.color_blend_equation_*dynamic*
dEQP-VK.pipeline.*.extended_dynamic_state.*.color_blend_all_*
Fixes: fc3fd7c69e (anv: dynamic color write mask)
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21509>
(cherry picked from commit b71957635f)
The workaround address is used as a source for push constants when
there's no resource available, that address must be 32B aligned.
This fixes invalid address being used for buffers in
3DSTATE_CONSTANT_* packets.
Now that intel_debug_write_identifiers() already add the padding,
there's no need to include extra "+ 8" to the offset.
Thanks to Xiaoming Wang that contributed to find and fix this issue.
Fixes: 2a4c361b06 ("iris: add identifier BO")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21479>
(cherry picked from commit a4a0417263)
Fixes: 5b205ef413
r600: Store nir shaders serialized to save memory
Direct leak of 4096 byte(s) in 1 object(s) allocated from:
#0 0x7faf89c3bb48 in __interceptor_realloc (/usr/lib64/libasan.so.6+0xb1b48)
#1 0x7faf7be5981d in grow_to_fit ../src/util/blob.c:67
#2 0x7faf7be5a538 in grow_to_fit ../src/util/blob.c:49
#3 0x7faf7be5a538 in blob_reserve_bytes ../src/util/blob.c:177
#4 0x7faf7be5a538 in blob_reserve_uint32 ../src/util/blob.c:190
#5 0x7faf7d248a8c in nir_serialize ../src/compiler/nir/nir_serialize.c:2109
#6 0x7faf7df4fdbb in r600_pipe_shader_create ../src/gallium/drivers/r600/r600_shader.c:401
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21443>
(cherry picked from commit 9b4eb73907)
This also removes the loop so opt_remove_cast_cast() will only optimize
cast(cast(x)) and not cast(cast(cast(x))). However, since nir_opt_deref
walks instructions top-down, there will almost never be a tripple cast
because the parent cast will have opt_remove_cast_cast() run on it.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
(cherry picked from commit af9212dd82)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21467>
When mesh shader is spawned on a different slice than the originating
task shader, then input task urb handle can come from a different
slice, so masking this information off will load data from the current
slice, instead of the one where real data are.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21007>
(cherry picked from commit dd9bf86725)
When establishing a texture transfer map, if there is any pending changes on the
texture, instead of trying direct map with DONTBLOCK first, just
use the upload buffer path.
Fixes piglit tests gen-teximages, arb_copy_images-formats
Cc: mesa-stable
Reviewed-by: Neha Bhende <bhenden@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21393>
(cherry picked from commit 1b9b060f0e)
When an EGLImage is created from a 2D texture and used for texture sharing,
the texture surface might not have been created with the SHARED bind flag.
To allow these surfaces for sharing, this patch sets the USAGE SHARED bit
for surfaces that can be potentially used for sharing even when the SHARED
bind flag is not originally set. Instead of unconditionally enabling the
SHARED bind flag for all surfaces and unnecessarily bypass the surface cache
optimization, this patch only enables the USAGE SHARED bit for surfaces
that also have the RENDER TARGET bind flag.
When the surface handle is inquired and if the surface is currently
marked as cachable, we will need to unset the cachable bit so
the surface handle will not be recycled again.
This patch fixes an assertion in svga_resource_get_handle() when the
EGL_MESA_image_dma_buf_export extension is used in webgl benchamrk running
from firefox in Fedora 37.
Cc: mesa-stable
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21393>
(cherry picked from commit 75b7296fc3)
This change is wrong for two reasons:
- it hangs most of the time maybe, because changing PSTATE when the
application is running is broken somehow
- it increases the time between triggering and generating the capture
considerably, because there is a delay for changing PSTATE
This restores previous logic where PSTATE is set to profile_peak at
logical device creation. Though, it also re-introduces an issue with
multiple logical devices (kernel returns -EBUSY) but this will be
fixed in the next commit.
This fixes GPU hangs when trying to record RGP captures on my NAVI21.
Note that profile_peak is only required for some RDNA2 chips (including
VanGogh).
Cc: mesa-stable
This reverts commit 923a864d94.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21222>
(cherry picked from commit 663877e894)
We loop, effectively, over two stacks: ready and to_do and finish only
when both are empty. In the case where ready is empty, we pull one off
of to_do, add a copy to a temporary, and push it onto the ready stack.
Previously, we assumed that we would never get to the temporary copy
case if to_do has exactly one entry because that would imply that there
was only one copy left which means there can't possibly be a cycle to
break. This was true until c7fc44f9eb ("nir/from_ssa: Respect and
populate divergence information") which changed things such that
temporary copies sometimes get added in the case where a convergent
value is copied both to convergent and divergent destinations.
This patch adjusts our loop iteration to always attempt to clear the
ready stack before checking if there's anything left on the to_do stack.
I also added an assert to make the exit condition more clear.
Fixes: c7fc44f9eb ("nir/from_ssa: Respect and populate divergence information")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8037
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21315>
(cherry picked from commit 4e09d37f3b)
There is an optimization in the parallel copy algorithm where, after a
copy has been performed, we can treat the destination as the new source
for future copies of the same source. In particular, consider the
following parallel copy: A -> B, C -> A, A -> C. In this case, after we
have done the A -> B copy, we can make note that the value in A is now
in B and emit the sequence: A -> B, C -> A, B -> C. This allows us to
resolve the swap cycle between A anc C without allocating a temporary
register because we know B is also a copy of A.
When one of the registers involved is convergent and the other is
divergent, this optimization is problematic because, while convergent to
divergent copies are fine, we can't re-use the divergent copy in later
copies if any of those copies are to a convergent variable. We could,
but it would require a read_first_invocation which would get messy. In
In c7fc44f9eb ("nir/from_ssa: Respect and populate divergence
information"), we attempted to deal with this by limiting the rename
optimization to the case where the divergence matched.
The problem is that we did the re-name part whenever the divergence
matched but only marked it as ready if the thing being copied was a
destination. (We actually left two instances of loc[a] = b, one which
always happened and one which only happened if we also wanted to flag
the source as being ready to use as a destination.) While this
technically doesn't cause any problems, it may result in more inter-mov
dependencies which hurts instruction scheduling. For example, if we had
the parallel copy A -> B, A -> C, A -> D, we now end up emitting the
sequence A -> B, B -> C, C -> D which has many more data hazards between
instructions caused by the constant shuffling.
This commit restores the original logic in which we only perform the
rename optimization if the rename would free up a register we will later
use as a destination. This isn't entirely optimal as it still doesn't
prove that there is a cycle involved first, but it should lead to a
reduction in unnecessary dependencies.
No shader-db changes on SKL or DG2
Fixes: c7fc44f9eb ("nir/from_ssa: Respect and populate divergence information")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21315>
(cherry picked from commit 5afba073c6)
This reverts commit 2dfebf3487.
It causes GPU hangs in piglit tests like
spec@glsl-1.20@execution@clipping@vs-clip-vertex-enables, for reasons I'm
totally unclear on. The commit was not necessary, because the frontend
lowering already handles disabled clip planes by storing 0.0 to the
corresponding clipdist array element in that shader variant. Add a note
to that effect.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21298>
(cherry picked from commit 5c246e21b7)
Conflicts:
src/freedreno/ci/freedreno-a530-fails.txt
base_mip_width is used in si_compute_copy_image when the
SI_IMAGE_ACCESS_BLOCK_FORMAT_AS_UINT flag is used.
width = tex->surface.u.gfx9.base_mip_width;
This will be incorrect if we don't adjust it. For instance,
with a 260x256 image, surf_pitch and base_mip_width are
320 before surf_pitch is updated to be 192.
Both need to match, or computing the width from base_mip_width
leads to incorrect result.
Cc: mesa-stable
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21253>
(cherry picked from commit affa8a9fb2)
Before dropping this function, handle the two callers of this function:
* The call in iris_blorp.c is redundant. The required cache flushes are
already handled by the callers of blorp functions. Delete this.
* The call in iris_resolve.c is still providing a benefit because it
calls iris_emit_buffer_barrier_for internally. Inline the needed
barrier.
Cc: 23.0 <mesa-stable>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21303>
(cherry picked from commit 5d24682aae)
Memory accesses can get corrupted when there's a disagreement between:
* the aux-mode of existing cache lines for a surface and
* the aux-usage in that surface's RENDER_SURFACE_STATE object
We have already prevented hardware from seeing this conflict for
rendering operations, but due to how the L3 is shared among multiple
clients in gfx12 (e.g., sampler engine, render engine, etc.), we need to
expand the scope of the existing solution. Now, before any access of a
compressible resource, we make sure to flush the prior aux-mode from the
caches.
The majority of changes here refactor things for use in a new function,
flush_previous_aux_mode. The remaining change calls that function from
within iris_resource_prepare_access.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6558
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7625
Cc: 23.0 <mesa-stable>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21303>
(cherry picked from commit 7c367bef0d)
Commit introduces a fix that allows for gbm to be built with an empty
backend. There are situation especially in a Yocto/OE cross compilation
environment where you want to build with an empty backend. The particular
situation is as such:
The mesa-gl recipe is the preferred provider for virtual/libgbm, virtual/libgl,
virtual/mesa, etc... But the x11 DISTRO_FEATURE in't included this leads to build
errors such as:
| /../../../ld: src/gbm/libgbm.so.1.0.0.p/main_backend.c.o: in function `find_backend':
| backend.c:(.text.find_backend+0xa4): undefined reference to `gbm_dri_backend'
| /../../../ld: src/gbm/libgbm.so.1.0.0.p/main_backend.c.o:(.data.rel.ro.builtin_backends+0x4):
undefined reference to `gbm_dri_backend'
| collect2: error: ld returned 1 exit status
Issue should be replicable by setting -Ddri3=disabled and -Dgbm=enabled
Add fix to bypasses compilation issue by excluding gbm dri backend. If
HAVE_DRI || HAVE_DRIX not specified.
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Signed-off-by: Vincent Davis Jr <vince@underview.tech>
(cherry picked from commit 842ca28465)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20821>
non-strictLine Vulkan drivers use either parallelogram or bresenham
rasterization for default line modes.
This method of rasterisation produces close enough results that it
in practice is GL/GLES spec compliant (at least cts wise).
Don't emit a feature missing warning for this case.
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20985>
(cherry picked from commit f7b2dbb2bd)
Pointed out by GCC:
In function ‘load_text_file’,
inlined from ‘standalone_compile_shader’ at ../src/compiler/glsl/standalone.cpp:491:38,
inlined from ‘main’ at ../src/compiler/glsl/main.cpp:98:45:
../src/compiler/glsl/standalone.cpp:358:17: error: ‘free’ called on pointer ‘block_195’ with nonzero offset 48 [-Werror=free-nonheap-object]
358 | free(text);
| ^
In function ‘ralloc_size’,
inlined from ‘load_text_file’ at ../src/compiler/glsl/standalone.cpp:352:31,
inlined from ‘standalone_compile_shader’ at ../src/compiler/glsl/standalone.cpp:491:38,
inlined from ‘main’ at ../src/compiler/glsl/main.cpp:98:45:
../src/util/ralloc.c:117:18: note: returned from ‘malloc’
117 | void *block = malloc(align64(size + sizeof(ralloc_header),
| ^
Fixes: a9696e79fb ("main: Close memory leak of shader string from load_text_file.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21215>
(cherry picked from commit 49a6bdde8e)
Drop the unused ctx parameter, to match the main Mesa code.
Fixes ODR violation flagged by -Wodr with LTO enabled:
../src/mesa/main/shaderobj.h:74:1: error: ‘_mesa_reference_shader_program_data’ violates the C++ One Definition Rule [-Werror=odr]
74 | _mesa_reference_shader_program_data(struct gl_shader_program_data **ptr,
| ^
../src/compiler/glsl/standalone_scaffolding.cpp:76:1: note: type mismatch in parameter 1
76 | _mesa_reference_shader_program_data(struct gl_context *ctx,
| ^
../src/compiler/glsl/standalone_scaffolding.cpp:76:1: note: ‘_mesa_reference_shader_program_data’ was previously declared here
../src/compiler/glsl/standalone_scaffolding.cpp:76:1: note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used
Fixes: 717a720e9c ("mesa: drop unused context parameter to shader program data reference.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21215>
(cherry picked from commit bf67f32d4b)
A stackless (or at least using allocated memory for stack) version
might be nice but for now this works around some games compiling
large shaders and hitting stack overflows.
CC: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21231>
(cherry picked from commit 0a17c3afc5)
Draw states were not disabled after a dynamic renderpass which
spans several command buffers, the next renderpass if started in
the same command buffer wouldn't emit the full draw state,
since TU_CMD_DIRTY_DRAW_STATE was not set by previous renderpass.
The issue could be observed when corrupting all regs at cmdbuf start in:
dEQP-VK.dynamic_rendering.primary_cmd_buff.random.seed7_geometry
Fixes: cb0f414b2a
("tu: Add support for suspending and resuming renderpasses")
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21148>
(cherry picked from commit 2d20564a6a)
Vulkan spec 18.8. Primitives Generated Queries:
When a generated primitive query for a vertex stream is active,
the primitives-generated count is incremented every time a
primitive emitted to that stream reaches the transform feedback
stage, whether or not transform feedback is active.
We can see the order of stages in chapter 27 Fixed-Function
Vertex Post-Processing, which shows that the transform feedback
stage is before rasterization (and therefore culling).
Conclusion is that culled primitives should be included
in the primitives generated query.
This commit makes sure to emit the primitives generated query
code before culling and uses the input primitive count passed
to the current wave instead of the exec mask after culling.
Cc: mesa-stable
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21037>
(cherry picked from commit 3a819bd22e)
(cherry picked from commit 18f0d33423)
Point sprite coordinates in general need to be inverted,
not just the texcoords converted to point sprite.
Move point coord y inversion out to its own pass.
Fixes GTF-GL46.gtf21.GL2FixedTests.point_sprites.point_sprites
with FBO dEQP surface.
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21050>
(cherry-picked from commit 782f1e9e01)
There was a VUID-VkImageViewCreateInfo-image-04739 in the Vulkan 1.3
spec that said:
If image was created with the
VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT flag and format is a
non-compressed format, viewType must not be VK_IMAGE_VIEW_TYPE_3D
That VUID has since been removed, and when a view of a 3D image is
created, with put the depth into the array_len, so it won't be always 1.
Reviewed-by: Mark Janes <markjanes@swizzler.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20803>
(cherry picked from commit 58ababdee6)
failing to set this yields patterns like
* bind fs
* bind samplerviews
* draw
* bind fs2
* ~~unbind samplerviews~~ (eliminated)
* draw
the eliminated unbinding of samplerviews between draws also eliminates a descriptor update,
triggering various artifacts in certain corner cases (like DOOM2016 shadows)
it's possible to manage the updating during shader binding, but the detection is a bit more
complex, and the cpu overhead from maintaining the current codepath with an
extra pipe_context::set_sampler_views (et al) isn't high enough to warrant further investigation
at this time
fixes#8252
Fixes: 153af03b94 ("gallium: Add cap to request state validation for all dirty state")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21176>
(cherry picked from commit b9181c3218)
A few lines earlier uni_offsets is accessed with ubo scaled by
PIPE_MAX_CONSTANT_BUFFERS:
if (uni_offsets[ubo * PIPE_MAX_CONSTANT_BUFFERS + i] == offset)
Found by inspection.
Looking at the before and after NIR code for
dEQP-VK.graphicsfuzz.cov-int-initialize-from-multiple-large-arrays,
using the correct indexing appears to enable the pass to inline an
additional uniform. My guess is that when a uniform is used more than
once, the first loop wouldn't find the offset recored in the table
because it was recorded at the wrong location.
Fixes: d23a9380dd ("lavapipe: implement extreme uniform inlining")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21144>
(cherry picked from commit a7696a4d98)
this was including the generated tcs bits, which was likely to be wrong
and thus break optimal key hashing, requiring more pipelines
it also wasn't setting the optimal key value correctly during precompile,
which meant the wrong hash value was used and the precompiled libs were never
actually accessible
cc: mesa-stable
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21169>
(cherry picked from commit 4cf54e2ed2)
GL Spec says that imageLoad from incomplete images must return 0.
This is not really spec compliant as for proper behavior nullDescriptor
and robustImageAccess2 is needed.
A workaround for lack of either of these requires a shader variant.
Clearing the null surface and hoping the app doesn't write to the image
is closer to spec, while avoiding a shader recompile.
KHR-GL46.shader_image_load_store.incomplete_textures tests this.
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21135>
(cherry picked from commit 22e91af1a7)
Conflicts:
src/gallium/drivers/zink/zink_context.c
u_vector_add() don't keep the returned pointers valid.
After the initial size allocated in u_vector_init() is reached it will
allocate a bigger buffer and copy data from older buffer to the new
one and free the old buffer, making all the previous pointers returned
by u_vector_add() invalid and crashing the application when trying to
access it.
This is reproduced when running
dEQP-VK.synchronization.signal_order.timeline_semaphore.* in DG2 SKUs
that has 4 CCS engines, INTEL_COMPUTE_CLASS=1 is set and of course
perfetto build is enabled.
To fix this issue here I'm moving the storage/allocation of
struct intel_ds_queue to struct anv_queue/iris_batch and using
struct list_head to maintain a chain of intel_ds_queue of the
intel_ds_device.
This allows us to append or remove queues dynamically in future if
necessary.
Fixes: e760c5b37b ("anv: add perfetto source")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20977>
(cherry picked from commit 8092bc2158)
Conflicts:
src/intel/ds/intel_driver_ds.cc
src/intel/vulkan/anv_utrace.c
src/intel/vulkan_hasvk/anv_utrace.c
Currently, we postpone binning syncs until we record draw calls
and can validate if any of them require accessing protected
resources in the binning stage, however, if the draw calls are
recorded in a secondary command buffer and the barriers have
been recorded in the primary command buffer, we won't apply the
binning sync in the secondary when we record the draw calls
and so we must apply it when we execute the secondary in the
primary.
Fixes flakyness in:
dEQP-VK.api.command_buffers.record_many_draws_secondary_2
cc: mesa-stable
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21162>
(cherry picked from commit fec15a225f)
The CLE parser in the sim will read this many bytes for each instruction
in a CL, so we should ensure we have at least that many bytes available
in the BO when reading the last instruction, otherwise we can trigger
a GMP violation. It is not clear whether this behavior applies to real
hardware too.
cc: mesa-stable
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21162>
(cherry picked from commit c2601f0690)
Fixes: 46b099e3
("meson: Ignore unused variables in release builds")
46b099e3 has some issues:
- it doesn't enable unused variables warning on release builds
with assertions enabled;
- it doesn't disable unused variables warning on debug builds
with assertions disabled;
- it doesn't disable unused variables warning when building
with MSVC and assertions are disabled regardless of buildtype,
see #8147. 3/4 regressions reported there have this limitation
alone as root cause.
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21154>
(cherry picked from commit 4347072443)
according to spec, the maximum number of acquired images can be calculated with
swapchain_size - VkSurfaceCapabilitiesKHR::minImageCount + 1
the previous calculation was both wrong and occurring in the wrong place,
so this corrects both issues
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21095>
(cherry picked from commit 89cf0a3bdc)
simple way to reproduce this is to run these 4 together:
KHR-GL46.gpu_shader5.images_array_indexing
KHR-GL46.shader_image_load_store.advanced-allMips
KHR-GL46.shader_image_load_store.advanced-sso-simple
KHR-GL46.shader_image_load_store.incomplete_textures
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21134>
(cherry picked from commit 104040b5c7)
apparently an actual null descriptor is illegal here, and it's wasted cpu
anyway, so just cache the dummy surface on init and use that data when
fbfetch isn't active but the layout requires it
Fixes: 7ab5c5d36d ("zink: use EXT_descriptor_buffer with ZINK_DESCRIPTORS=db")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21100>
(cherry picked from commit 813bb9e442)
We first do an incomplete check for whether the linker supports
--gc-sections, then potentially add C and C++ arguments assuming that it
works, then later do a complete check to see if it actually works and
use --gc-sections. This means we can end up putting functions and data
in separate sections when we can't gc them.
Combine the checks, do less work, and be more accurate.
fixes: f51ce21e4e
("meson: Drop adding -Wl,--gc-sections to project c/cpp arguments.")
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21083>
(cherry picked from commit fd9b50aa1c)
etna_resource_from_handle() is called for each plane of a multiplanar
resource, so there is no point in looping over all planes to do the
renderonly scanout import. In fact that will cause us to lose track
of the scanout imports from later planes when the earlier planes are
redoing the import, overwriting the pointer to the allocated
renderonly_scanout struct.
Drop the loop and just do the import for the current plane.
Fixes: 826f95778a ("etnaviv: always try to create KMS side handles for imported resources")
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20993>
(cherry picked from commit 175732bb51)
compute programs can be reused across contexts, which means storing any
pointers directly like this is going to lead to desync and crash
instead, make this like regular descriptor templates and calculate the offset
from the current context to ensure that everything works as it should
fixes#8201
Fixes: 7ab5c5d36d ("zink: use EXT_descriptor_buffer with ZINK_DESCRIPTORS=db")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21020>
(cherry picked from commit 68e914a4ca)
Complicated CFG and lots of SALU can cause this to take an extremely long
time to finish.
Fixes
dEQP-VK.graphicsfuzz.cov-value-tracking-selection-dag-negation-clamp-loop
and Monster Hunter Rise demo compile times.
fossil-db (gfx1100):
Totals from 57 (0.04% of 134574) affected shaders:
Instrs: 170919 -> 171165 (+0.14%)
CodeSize: 860144 -> 861128 (+0.11%)
Latency: 961466 -> 961505 (+0.00%)
InvThroughput: 127598 -> 127608 (+0.01%)
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8153
Fixes: 5806f0246f ("aco/gfx11: workaround VALUPartialForwardingHazard")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20941>
(cherry picked from commit bfd4ac4581)
To fix a hypothetical issue:
v0 = start_linear_vgpr
if (...) {
} else {
use_linear_vgpr(v0)
}
v0 = phi
We need a p_end_linear_vgpr to ensure that the phi does not use the same
VGPR as the linear VGPR.
This is also much simpler.
fossil-db (gfx1100):
Totals from 1195 (0.89% of 134574) affected shaders:
Instrs: 4123856 -> 4123826 (-0.00%); split: -0.00%, +0.00%
CodeSize: 21461256 -> 21461100 (-0.00%); split: -0.00%, +0.00%
Latency: 62816001 -> 62812999 (-0.00%); split: -0.00%, +0.00%
InvThroughput: 9339049 -> 9338564 (-0.01%); split: -0.01%, +0.00%
Copies: 304028 -> 304005 (-0.01%); split: -0.02%, +0.01%
PreVGPRs: 115761 -> 115762 (+0.00%)
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20621>
(cherry picked from commit bbc5247bf7)
ac/surface puts the raw pip_bank_xor there, which needs the extra
shift for the actual tile_swizzle.
(I think long term we should refactor this in ac/surface but for
now lets fix like radeonsi to avoid race conditions.)
CC: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20979>
(cherry picked from commit b0a9772cc6)
list_is_linked() isn't the right function to use in order to check if
the BO is on a cache bucket or the zombie list, as this checks if the
next pointer of the list isn't NULL. This is always the case with the
BO list item as it's always initialized, so the next pointer points to
the list head itself when the BO isn't on any list.
Use list_is_empty() to check if the BO is actually linked into one
of the deferred destroy lists.
Fixes: 1b1f8592c0 ("etnaviv: drm: properly handle reviving BOs via a lookup")
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20940>
(cherry picked from commit 196882a147)
This game seems to incorrectly set the render area and since we switched
to full dynamic rendering, the framebuffer dimensions is no longer used.
Forcing the render area to be the framebuffer dimensions restore the
previous logic and it fixes rendering issues.
Fixes: c7d0d328d5 ("radv: Set the window scissor to the render area, not framebuffer")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20900>
(cherry picked from commit 1a93cd1556)
The JIT generated FS shader has logic to obey sample mask when:
multisample is enabled, or multisample is disabled but FS writes sample
mask and pipe_rasterizer_state::no_ms_sample_mask_out.
However it did not handle the case where multisample was disabled, FS
did not write sample_mask, and sample mask was zero. Instead it relied
upon the setup to discard the primitives, but that went away with commit
da5840f3.
We could restore the discard on zero mask behavior, but we would again
blurring the semantics of rasterization discard. Instead this change
adds logic to primitive setup to cull the primitives when sample mask is
zero.
Fixes: da5840f3 ("llvmpipe: Faithfully honour pipe_rasterizer_state::rasterizer_discard flag")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20934>
(cherry picked from commit 77092ca8f4)
RRGetScreenInfo re-probes connector status, which may result in an EDID
transfer for every output, which according to Adam Jackson can be on the
order of 100ms for a single EDID block. So our previous implementation
of this eglGetMscRateANGLE was blocking for excessive periods of time
instead of being a quick query of the refresh rate like users expect.
This changes our eglGetMscRateANGLE implementation from using
RRGetScreenInfo to RRGetScreenResourcesCurrent and RRGetCrtcInfo.
This obtains the same monitor info without re-probing connectors.
Fixes a severe performance regression in Chromium WebGL performance.
While we're re-implementing the extension, we also implement proper
multi-monitor support: if there are multiple active CRTCs, we determine
which contains the largest portion of the surface, as specified in the
EGL_ANGLE_sync_control_rate extension.
We also now report fractional refresh rates correctly rather than
rounding to the nearest Hz.
Fixes: 4752655649 ("egl/x11: implement ANGLE_sync_control_rate")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6996
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7038
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20665>
(cherry picked from commit 41d5f0ee09)
add a special tracker here to set the state only when necessary
Fixes: 659c39fafb ("zink: rework primitive rasterization type logic")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20886>
(cherry picked from commit 06a125942b)
Conflicts:
src/gallium/drivers/zink/ci/zink-lvp-validation-settings.txt
Stable:
- removed CI file taht doesn't exist in 23.0 branch
The shifting was off-by-one compared to how it is done in the kernel. Also, excess_length needs to be casted to uint64_t to prevent zeroing everything except the 5 LSBs.
Fixes: abf3bcd6 ("radv: Add RMV resource tracking")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20820>
(cherry picked from commit e07729e8de)
The ACP entries created by copy propagation to track the implied
copies of LOAD_PAYLOAD instructions don't model the behavior of
LOAD_PAYLOAD correctly, since (as of 41868bb682) header
moves are implicitly retyped to UD and the destination of non-header
copies implicitly uses the same type as the corresponding source, even
though the ACP entries created for such copies could incorrectly
represent a type conversion, which can lead to mis-optimization of the
program.
According to Marcin, this fixes the func.mesh.ext.workgroup_id.task.q0
crucible test.
Fixes: 41868bb682 ("i965/fs: Rework the fs_visitor LOAD_PAYLOAD instruction")
Reported-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Tested-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18980>
(cherry picked from commit 7b5e933629)
ChromeOS still uses Python 3.6, but the glsl2spirv script uses module
'__future__.annotations', introduced in Python 3.7. Fix the build by
removing module, but otherwise preserve the type annotations.
Fixes: 949c3b55db ("util/glsl2spirv: add type annotations")
Acked-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20237>
(cherry picked from commit bca22a6578)
`count` should not be incremented before the check, because it causes
the modifiers array to be filled starting from position 1 instead of 0.
This bug causes one less format modifier to be available than would
otherwise be expected, which could then lead to a dmabuf query failing
in situations where a supported modifier wouldn't be advertised.
It also causes garbage data to be advertised as a modifier in position 0
of the array, although this is not very likely to cause issues.
Fixes: 2a1217513 ("panfrost: Implement panfrost_query_dmabuf_modifiers")
Cc: mesa-stable
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20879>
(cherry picked from commit 6c446377ff)
gfx11 renamed PRIM_GRP_SIZE to VERTS_PER_SUBGRP but another change was
was missed.
Update our code based on PAL's UniversalCmdBuffer::CalcGeCntl function
(especially useVgtOnchipCntlForTess being false for gfx11).
Fixes: 25a66477d0 ("radeonsi/gfx11: register changes")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20728>
(cherry picked from commit f73cdda983)
This is needed when switching away from GPGPU mode. See the previous
commit for anv. This is not likely to make a practical difference for
iris because it never switches back and forth between modes like anv.
Fixes: 172e0b0ebf ("iris: Update PIPELINE_CONTROL flush when switching pipeline mode in TGL+")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20774>
(cherry picked from commit bd8e8d204d)
See the comments in emit_apply_pipe_flushes(). Flushing HDC is not
sufficient in GPGPU mode, and we need to set the untyped data port flush
bit as well.
Fixes many dEQP-VK failures with INTEL_COMPUTE_CLASS=1 on Alchemist.
Fixes: 1067ec90a5 ("anv: Update PIPELINE_CONTROL flush when switching pipeline mode in TGL+")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20774>
(cherry picked from commit a8108f1d44)
Otherwise, the access chain you emitted last time may not dominate the
current use.
Fixes the following validation failure in
dEQP-GLES31.functional.shaders.sample_variables.sample_mask_in.bits_unique_per_sample.multisample_texture_2:
UNASSIGNED-CoreValidation-Shader-InconsistentSpirv(ERROR / SPEC):
msgNum: 7060244 - Validation Error: [
UNASSIGNED-CoreValidation-Shader-InconsistentSpirv ] Object 0: handle =
0x55cf3cea2c60, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x6bbb14 |
SPIR-V module not valid: ID '67[%67]' defined in block '23[%23]' does
not dominate its use in block '31[%31]'
Fixes: 8899f6a198 ("zink: fix gl_SampleMaskIn spirv generation")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20756>
(cherry picked from commit 4286633eec)
Fixes validation failures:
Test case 'dEQP-GLES31.functional.android_extension_pack.shaders.es32.extension_directive.oes_sample_variables'..
MESA: error: Validation Error: [
UNASSIGNED-CoreValidation-Shader-InconsistentSpirv ] Object 0: handle =
0x563a1838b790, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x6bbb14 |
SPIR-V module not valid: [VUID-StandaloneSpirv-Flat-04744] Fragment
OpEntryPoint operand 31 with Input interfaces with integer or float type
must have a Flat decoration for Entry Point id 4.
%gl_SampleId = OpVariable %_ptr_Input_uint Input
Test case 'KHR-GL46.shader_ballot_tests.ShaderBallotAvailability'..
MESA: error: Validation Error: [ UNASSIGNED-CoreValidation-Shader-InconsistentSpirv ] Object 0: handle = 0x5558e12f17e0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x6bbb14 | SPIR-V module not valid: [VUID-StandaloneSpirv-Flat-04744] Fragment OpEntryPoint operand 28 with Input interfaces with integer or float type must have a Flat decoration for Entry Point id 4.
%gl_SubgroupLocalInvocationId = OpVariable %_ptr_Input_uint Input
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20756>
(cherry picked from commit 2a33d509ca)
I've been running into failures with tests like :
dEQP-VK.robustness.robustness2.bind.notemplate.rgba32i.unroll.nonvolatile.uniform_buffer_dynamic.no_fmt_qual.len_4.samples_1.1d.frag
With the load_global_const_block_intel NIR intrinsic, you can load a
vec8/vec16 with a predicate. The predicate is correctly uniformized to
feed into the SEND instruction's flag register.
The problem is that a series of optimization first remove the
find_live_channel and then changes the broadcast into a simple MOV
instruction, on the assumption that the first channel is always active
if there is not control flow. This is correct.
But after that the cmod optimzation will remove this instruction :
mov.nz.f0.0(16) null:D, vgrf16+0.0<0>:D NoMask
because it seems to be equivalent to :
cmp.g.f0.0(16) vgrf16:D, vgrf12:D, 63d
In this case vgrf16 is the predicate to the load block SEND
instruction. Since the execution mask is different between both, some
of the channels of the SEND instruction end up not being loaded or
loaded with the wrong predication and we end up with incorrect UBO
data.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20852>
(cherry picked from commit a50d2fdb46)
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT = 0x01 has been incidently the
correct memory type index, but isn't guaranteed to be, which is why it
hasn't caused issues yet
Fixes: f9515d93 ("zink: allocate/place memory using memoryTypeIndex directly")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20264>
(cherry picked from commit c71287e70c)
When this was last changed, the smoothing_enabled flag seems to have
been forgotten about, breaking line-smoothing (and probably also polygon
smoothing).
Fixes: 4147add280 ("radeonsi: update db_eqaa even if msaa is disabled")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20810>
(cherry picked from commit 9f4f131f2e)
Conflicts:
src/amd/ci/radeonsi-raven-fails.txt
src/amd/ci/radeonsi-stoney-fails.txt
unlocks were incorrectly added to paths using dri2_egl_display() as
well as those using dri2_egl_display_lock()
pthread_mutex_unlock() when unlocked is documented by posix as
being undefined behaviour. On OpenBSD pthread_mutex_unlock() will call
abort(3) if this happens.
Fixes: f1efe037df ("egl/dri2: Add display lock")
Reviewed-by: Rob Clark <robclark@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20712>
(cherry picked from commit 0594b3c143)
It was wrong. For example, if the draw vertex count was 10 and the upload
vertex count was 150, u_vbuf wouldn't unroll the draw and would instead
memcpy 150 vertices. This fixes that case.
Fixes: 068a3bf0d7 - util: move and adjust the vertex upload heuristic equation from u_vbuf
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20824>
(cherry picked from commit 4f6e785876)
this is an artifact of very old code before the dynamic state was set
for all graphics pipelines
now the checks only cause blend constants to not be updated, which triggers
bugs and validation failures
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20799>
(cherry picked from commit b4d18f2ad1)
offset field in kgsl_command_object is NOT used by KGSL, so
we should offset directly to iova.
Fixes weird hangs on KGSL. E.g. fixes the hang in:
dEQP-VK.memory.pipeline_barrier.transfer_dst_storage_texel_buffer.1024
cc: mesa-stable
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20795>
(cherry picked from commit 926f626b95)
For a depth-only-with-discard pipeline, spi_shader_col_format needs to be
fixed up to a single channel export, or otherwise discard will not work.
Since col_format can change depending on the dynamic state, precompute the
need for this workaround on pipeline creation and apply it when emitting
prolog states.
Fixes: eb07a11b8f ("radv: add support for compiling PS epilogs on-demand")
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20704>
(cherry picked from commit 1617dac6c3)
Because anv_execbuf_add_bo_bitset() calls anv_execbuf_add_bo(), which
can fail if its memory allocations fail.
I have seen dEQP tests exercising memory allocation failures during
anv_execbuf_add_bo(), but I don't think the path coming from
add_bo_biset() was specifically exercised. Anyway, add the error check
just in case.
v2: Rebase.
Cc: mesa-stable
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20703>
stable:
reapplied to src/intel/vulkan/anv_batch_chain.c, as it has not been
moved to src/intel/vulkan/i915/ in 23.0
In anv_execbuf_add_syncobj(), we try to not create or use
exec->syncobj_values if we don't need to. But when we figure we're
going to need it (i.e., when timeline_value is not zero), then we
create exec->syncobj_values with vk_zalloc, which means every previous
value is set to zero, as it should be. This is all correct.
The problem starts when we add a 16th element. In this case we double
exec->syncobj_array_length and realloc the buffer by using vk_alloc
and copying the old array to the new one. After that, we write the
timeline_value to the array only if it's not zero, and that's the
problem: since we just used vkalloc and memcpy, we don't have any
guarantees that the new array will be zero after the 16th element, and
if timeline_value is zero we write nothing to that position.
Once we start using exec->syncobj_values we have to commit to using
it, so the "if (timeline_value)" check near the end of the function
has to be changed to "if (exec->syncobj_values)", so we actually set
elements after the 16th to zero when they need to be zero. Another
approach to fix this would be to memset the new elements once we
double syncobj_array_length.
In practice, I couldn't find any application or deqp test that used
more than 3 elements in exec->syncobj_array_length, and we need more
than 16 elements in order to be able to reproduce the bug, so I'm not
aware of any real-world bug that goes away with this patch. This issue
was found while reading code.
If we craft a little Vulkan program that submits a ton of timeline and
binary semaphores on vkQueueSubmit, then waits for them, we get the
following error without this patch:
MESA: error: ../../src/intel/vulkan/anv_batch_chain.c:1910: execbuf2 failed: Invalid argument (VK_ERROR_DEVICE_LOST)
v2: Rebase.
Cc: mesa-stable
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20703>
(cherry picked from commit ad6a036a68)
Conflicts:
src/intel/vulkan/i915/anv_batch_chain.c
Stable:
reapplied to src/intel/vulkan/anv_batch_chain.c, as this hasn't been
moved in the staging branch.
internal_format is the "real" format of a resource, and the "real" format
of imported resources is the external-facing format, not the pipe format
this ensures the correct format is available for internal ops, such as nplanes queries
Fixes: 2e2775c11b ("zink: fix PIPE_RESOURCE_PARAM_NPLANES with format modifier")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20753>
(cherry picked from commit 072e29a22e)
When the base array layer of the image view is > 0, addrlib computes
the offset (in HwlComputeSubResourceOffsetForSwizzlePattern) which is
then added to the base VA in RADV. But if the driver doesn't reset
the base array layer, the hw will compute incorrect addressing
(ie. base array will be added twice). This also matches AMDVLK.
This fixes a VM fault followed by a GPU hang on RDNA2 when trying
to join a multiplayer game with medium settings in Halo Infinite.
Fixes: 98ba1e0d81 ("radv: Fix mipmap views on GFX10+")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20761>
(cherry picked from commit 8d191b2cfb)
The ideal case for performance is to have a single buffer for
all display list. The caveat is that large buffers are less
likely to be freed because they're refcounted: it only takes
1 user (diplay list) to keep it in VRAM.
This lowers VRAM usage when replaying the trace attached
of the trace attached to !6140 from 5.5 GB to about 1.8 GB.
Viewperf snx performance isn't affected.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6140
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20748>
(cherry picked from commit 0f5c8c3dc3)
grow_vertex_storage may call wrap_filled_vertex, which will
trigger the assert incorrectly because the new size will be
smaller than 'new_size' but it's correct because
'vertex_store->used' has been reset to 0.
Fixes: a08baaff97 ("vbo/dlist: fix indentation in vbo_save_api.c")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20748>
(cherry picked from commit 491f6b138e)
This avoids a violation of the Vulkan memory model that was leading to
intermittent failures of at least 8k test-cases of the Vulkan CTS
(within the group dEQP-VK.memory_model.*) on TGL and DG2 platforms.
In theory the issue may be reproducible on earlier platforms like IVB
and ICL, but the SYNC.ALLWR instruction is not available on those
platforms so a different (likely costlier) fix will be needed.
The issue occurs within the sequence we emit for a NIR memory barrier
with acquire semantics requiring the synchronization of multiple
caches, e.g. in pseudocode for a barrier involving the TGM and UGM
caches on DG2:
x <- load.ugm // Atomic read sequenced-before the barrier
y <- fence.ugm
z <- fence.tgm
wait(y, z)
w <- load.tgm // Read sequenced-after the barrier
In the example we must provide the guarantee that the memory load for
x is completed before the one for w, however this ordering can be
reversed with the intervention of a concurrent thread, since the UGM
fence will block on the prior UGM load and potentially take a long
time, while the TGM fence may complete and invalidate the TGM cache
immediately, so a concurrent thread could pollute the TGM cache with
stale contents for the w location *before* the UGM load has completed,
leading to an inversion of the expected memory ordering.
v2: Apply the workaround regardless of whether the NIR barrier
intrinsic specifies multiple storage classes or a single one,
since an acquire barrier is required to order subsequent requests
relative to previous atomic requests of unknown storage class not
necessarily specified by the memory scope information of the
intrinsic.
Cc: mesa-stable
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20690>
(cherry picked from commit 4a2e7306dd)
Commit e07c5467 ("v3dv/format: use XYZ1 swizzle for three-component formats")
removes the only code that handled the clamp_to_transparent_black_border
variable. Therefore, the variable can be deleted, as it is not currently
being used.
Fixes: e07c5467 ("v3dv/format: use XYZ1 swizzle for three-component formats")
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20746>
(cherry picked from commit 86c9bdcd9a)
We don't use a base workgroup ID for BLOCS. It needs to be lowered, or
else we'll assert fail when compiling the compute shader.
(Note for stable: this patch doesn't fix a bug in 4abdecce22
specifically, but rather is a missing patch that needed to go along with
the rest of MR 20068, on whichever branches it exists on.)
Fixes: 4abdecce22 ("iris: Lower load_base_workgroup_id to zero")
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20750>
(cherry picked from commit a6c6a4ad04)
We cannot change this, as it has already been communicated to app
partners. Also this breaks chrome's GPU quirk matching (which in some
cases is non-gpu-related, but when all you have is a hammer, everything
looks like a nail).
Fixes: 9c1fbc076a ("Return 'Mesa' for GL_VENDOR for community drivers")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20757>
(cherry picked from commit 6f91a5ab07)
In the original change I noticed that missing robustness on swkms seemed
to be an oversight, since it was enabled on sw-non-kms, so I exposed the
ext based on the underlying pipe query. However it turns out that there
is a dri_screen flag for allowing robust contexts that exists to do error
checking for GLX, which was under an !swkms check. So we would expose the
ext, but then throw an error if you tried to create one.
Fixes: e6285ea55f ("egl: Replace the robustness DRI2 ext check with a pipe cap query.")
Closes: #8066
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20679>
(cherry picked from commit 6b0db6bf8b)
opaque should not be set when logicops are enabled, that needs blending
even on Bifrost. Fixes is for when I believe the bug became possible to hit.
The logical error is older.
Fixes Piglit logicop tests again.
Fixes: d849d9779a ("panfrost: Avoid blend shader when not blending")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20685>
(cherry picked from commit 41d99c10d1)
Unlike literally every other mesa/st emulation, for some inexplicable reason we
need to pretend to support the CAP and then set a different EMULATE cap instead
of the emulation keying off the lack of support for the CAP. Set the CAPs
accordingly so we get NV_primitive_restart (with emulation of non-fixed
indices).
This gets Mesa to advertise GL 3.1 on Mali-G57 as intended.
Fixes: 30c14f54cf ("panfrost: Disable PIPE_CAP_PRIMITIVE_RESTART on v9")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20702>
(cherry picked from commit fe4dc59e99)
Future changes to nir_lower_blend cause fsat(reg.yx) instructions to be
generated, which correspond to "FCLAMP.v2f16 x.h10" pseudoinstructions. These
get their swizzles lowered, but we forgot to clear the swizzle out, so we end up
with extra swap (cancelling out the intended swizzle).
Fix the lowering logic.
Fixes: ac636f5adb ("pan/bi: Use FCLAMP pseudo op for clamp prop")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20683>
(cherry picked from commit ed46c617b0)
We set the different data being freed to NULL after freeing it, and
checks for NULL before freeing it.
This fixes several double free crash with v3dv, when running OOM wsi
tests, like for example:
dEQP-VK.wsi.xlib.swapchain.simulate_oom.composite_alpha
Although note that only one person got those on a new fresh install of
the Raspbian OS, so this problem was rare.
Fixes: 5b13d74583 ("vulkan/wsi/drm: Break create_native_image in pieces")
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20695>
(cherry picked from commit b27e42dcb5)
This isn't allowed for the same reason that AFBC of regular luminance-alpha
isn't allowed (and will raise DATA_INVALID_FAULTs). Reorder the checks to
ensure these formats are checked.
Fixes Piglit texwrap GL_EXT_texture_sRGB-s3tc.
Fixes: 476be5cb27 ("panfrost: Don't use texture format swizzles on v7")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20686>
(cherry picked from commit 5fdfd8044d)
If we pass a physical 2D texture descriptor we should also pass 2
coords. Otherwise it just uses the random content in the second
register which ends up funny sometimes.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20696>
(cherry picked from commit edca10e9c9)
If the previously emitted graphics pipeline uses the value A for
col_format_non_compacted and the new bound graphics pipeline uses B.
At bind time, radv_cmd_state::col_format_non_compacted will be set to
B and the rbplus flag will be dirtied. But if there is no draws and a
new graphics pipeline is bound with the same value as A, the next
draw will emit the rbplus state with B instead of A.
This can be basically triggered with meta operations after drawing
because the driver saves/restores the bound pipeline.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8073
Fixes: 11469f7553 ("radv: copy the non-compacted color format at pipeline bind time")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20692>
(cherry picked from commit 5b3fb44ecc)
I looked through the changes to features.txt since the 22.3 branchpoint
and added those to the new_features list as well. It was pointed out
that VK_KHR_present_wait wasn't in the list of new features.
This is a global register which isn't settable by userspace contexts.
It also shouldn't appear in any of our aubinator decodes from error
states or aub dumps, as no userspace batch should be setting it.
So it's not very valuable to have here. Just makes us think we can
set it. Plus, a lot of the field definitions changed a bunch, and
would need updating.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20627>
Some format modifiers change the number of planes used by an image.
For instance AMD DCC modifiers uses 2 or 3 planes. However the
format modifier was ignored in the PIPE_RESOURCE_PARAM_NPLANES
get_param hook.
Fix this by using get_dmabuf_modifier_planes() instead of
util_format_get_num_planes().
This fixes wlroots-based compositors under zink.
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: c025cb9ee9 ("zink: fix dmabuf plane returns")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20395>
With aaa4b0e6 state validation is no longer called for all changed states,
but only for states that will be active with a new shader program.
Not all drivers support this and might prefer if the state validation
is emitted for all states that might be changed. So add a cap that the
driver can signal one or the other preference, and default to the new
behavior.
Fixes: aaa4b0e6
st/mesa: move check_program_state code into _mesa_update_state
v2: - Rename cap and and invert its meaning, query the cap
only once and store it in st, handle the mask update
when updating the shader i.e. not in st_validate_state (Marek)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20493>
This was always meant to be at the bottom of the page. To reduce the
risk of more driver-specific environment variables being added below,
let's add a horizontal rule to mark the difference. This should make it
more clear that this paragraph doesn't belong to the previous heading.
Fixes: c70c5ecd2e ("docs: move generic gallium envvars to root doc")
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20644>
If the blit formats match and the resource formats match, then that's a
memcpy whether or not the blit's view of the resource matches the
resource's format.
Improves perf of portal-2-v2's last frame on zink+anv by 1.33212% +/-
0.302829% (n=5), where there's a blit that is viewing the RGBA8_UNORM
src/dst resources as RGBA8_SRGB.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20594>
Fixes assertion fails in piglit isinf-and-isnan, which uses a constant infinity,
which has an out-of-bounds mantissa (but the function contract says that's
fine and we just return something undefined.)
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20563>
This acts as a depth/stencil write. The AGX compiler checks outputs_written to
determine what conservative depth settings the driver needs. Nominally, this
should work: the original store_output(FRAG_RESULT_DEPTH) intrinsic causes the
DEPTH outputs_written bit to be set, so the metadata is still correct after
lowering store_output to store_zs_agx. However, there are a handful of places
that call nir_gather_info late, which *resets* the existing outputs_written
value and regathers, causing Asahi to use the wrong conservative depth settings
when shuffling NIR pass order and breaking gl_FragDepth.
To fix, handle store_zs_agx conservatively when gathering info so we don't have
to play games with the pass order or stashing info in a sideband.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20563>
Use the new get_decoder_fence vfunc to implement
vaQuerySurfaceStatus and vaSyncSurface in the va state tracker.
A pointer to the surface's fence is passed to the codecs before the
end_frame vfunc and the codec is responsible for allocating a fence on
command stream submission.
This fence is then queried on vaQuerySurfaceStatus and waited on in
vaSyncSurface.
Notably both functions were not implemented as per the VA-API docs for
PIPE_VIDEO_ENTRYPOINT_BITSTREAM.
Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Sil Vilerino <sivileri@microsoft.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Boyuan Zhang <Boyuan.Zhang@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20133>
Add a get_decoder_fence vfunc that can be used to query the status
of the previous decode job denoted by 'fence' given 'timeout'.
A pointer to a fence pointer can be passed to the codecs before the
end_frame vfunc and the codec should then be responsible for allocating
a fence on command stream submission.
Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Boyuan Zhang <Boyuan.Zhang@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20133>
A pretty significant amount of time spent in fd6_draw_vbo is calling
memset to zero init the on-stack struct. And a big part of the size
of the struct is fd6_state, of which we only need to initialize
num_groups to zero. This is worth a 15% improvement in drawoverhead
test 0 ("no state change").
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20572>
Split out the build-up of CP_SET_DRAW_STATE packet, as we are going to
want to re-use this for compute state later when we switch to bindless
IBO descriptors.
While we are at it, drop the enable_mask param, as this is determined
solely by the group_id, and it is easier to maintain a table for the
handful of exceptions to ENABLE_ALL. The compiler should be able to
optimize away the table lookup.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20572>
Same thing as https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20530:
newly added `src/vulkan/util/rmv/vk_rmv_tokens.h` (see !17331) includes
`src/util/` files, so anything that includes it needs `idep_mesautil`.
In file included from ../src/vulkan/util/rmv/vk_rmv_common.h:29,
from ../src/vulkan/runtime/vk_device.h:26,
from ../src/vulkan/wsi/wsi_common.c:31:
../src/util/simple_mtx.h:34:12: fatal error: valgrind.h: No such file or directory
34 | # include <valgrind.h>
| ^~~~~~~~~~~~
compilation terminated.
Fixes: 5f30a7538b ("vulkan: Add RMV token definitions")
Signed-off-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Friedrich Vock <friedrich.vock@gmx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20642>
NIR will automatically lower all of these opcodes unless the driver
specifies that it can handle them natively. We don't have any hardware
support for any of these opcodes though, so we just let NIR lower
all of them.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20639>
Particularly, this makes compilation stop as soon as we get a
valid shader and doesn't try to optimize spilling by trying
fallback strategies.
Might come in handy to reduce CTS execution time, for example,
dEQP-VK.ssbo.layout.random.8bit.all_per_block_buffers.6 goes from
43m46.715s down to 15m15.068s.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20601>
The CPU copy is horribly slow, so let's hook-up DXGI swapchains. Note
that we're still limited in term of features. For instance, we can't
support more than 2 images per swapchain because of the DXGI present
ordering constraint. We also have to do an extra copy, because DXGI
only allows rendering to a resource on the queue that the swapchain
was created against, but swapchains in Vulkan don't have a queue.
The swapchain is bound to the window using DirectComposition aka
DComp. The DComp infrastructure is set up in the surface, and is
transitioned from one swapchain to the next when the new swapchain
begins presenting.
Unlike Wayland and X, there's no requirement that the compositor has
to release a surface before you can start rendering against it. However,
since we're now supporting the non-sw path, we do need to prevent apps
from rendering to a resource *while* the blit is occurring. We do this
by blocking for a fence while acquiring an image.
Co-authored-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Acked-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16200>
The win32 swapchain can be backed by a DXGI swapchain, but such swapchains
are incompatible with STORAGE images (AKA UNORDERED_ACCESS usage in
DXGI). So, we need to allocate an intermediate image that will serve as
a render-target, and copy this image to the WSI image when QueuePresent()
is called. That's pretty similar to what we do for the buffer blit case,
except the image -> buffer copy is replaced by an image -> image copy.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16200>
Right now, the WSI core supports copying WSI images to a linear buffer
for implementations that want the result in this form. This being said,
most of the blit logic can be re-used for image to image copies, and that's
exactly what we'll need if we want to hook-up DXGI swapchains in the
win32 WSI implementation. So let's rename a few fields so we no longer
imply that images are copied to a buffer, and the use_buffer_blit boolean
an enum so we can extend the implementation to support image -> image
copies.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16200>
If a shader's sampler state is dirty often, the sampler descriptor heap
can get used up quickly, forcing flushing. If that happens quickly, we
run out of batches and have to wait for batches to finish on the GPU.
When this happens, it is often because the sampler state is switching,
not because it's truly unique. This change hashes and saves sampler
descriptor tables that can be reused in subsequent draws in the same
batch, instead of re-copying the same descriptors and consuming the
heap.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20618>
The maximum number of mipmap levels supported for cubemap can be
determined from the maximum 2D texture size. There is no need
to limit the max to 12.
This fixes a regression in creating GL4.1 and up context since
commit 2658d02516 is now explicitly checking for
MaxCubeTextureLevels >= 15 for GL4.1 context.
Reviewed-by: Neha Bhende <bhenden@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20600>
We are now extremelly careful when copy propagating a mov that uses
relative addressing. The search for readers will trigger abort when it
sees any other instruction using a relative addressing, irrespective of
the actual used registers or whether an address register load was seen.
Additionally, since ntt switch all movs using the relative addressing are
actually used only once right on the next line, and are result of ntt converting
vec4 32 ssa_10 = intrinsic load_ubo_vec4 (ssa_0, ssa_9) (access=0, base=11, component=0)
into
5: ARL ADDR[0].x, TEMP[0].xxxx
6: MOV TEMP[2], CONST[0][ADDR[0].x+11]
RV530 shader-db:
total instructions in shared programs: 132966 -> 131904 (-0.80%)
instructions in affected programs: 29896 -> 28834 (-3.55%)
helped: 234
HURT: 2
total temps in shared programs: 16969 -> 16905 (-0.38%)
temps in affected programs: 604 -> 540 (-10.60%)
helped: 68
HURT: 12
Partial fix for: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7723
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20577>
When computing line smoothing, we can also do something similar to
compute the line stippling. This can be useful for some drivers, who
can't easily split the lines before rasterizing them.
This does lead to slightly inaccurate stippling, because the
line-smoothing extends the line-length by a small amount. That leads to
the line-stippling pattern being over-stretched over the line-segment by
a fraction of a pixel in lenght. For short lines, this can be quite a
lot of error.
Reviewed-by: Soroush Kashani <soroush.kashani@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20134>
I'm convinced that u_blitter interactions with fbfetch can't be handled
in si_update_ps_colorbuf0_slot alone, so it has to be force-disabled
by si_blitter_begin. Another reason why it has to be disabled for u_blitter
and not ignored is because FBFETCH with MSAA enables sample shading
regardless of context states, and we don't want that for u_blitter.
Also, si_update_ps_colorbuf0_slot now disables FBFETCH explicitly before
its own DCC and CMASK decompression because even though u_blitter can't do
anything (due to blitter_running), si_blitter_end calls it too.
The result is that no recursion can occur thanks to the blitter_running
and suppress_update_ps_colorbuf0_slot flags, and FBFETCH is always
force-disabled before those flags are set, which is the state we want
to be in.
Fixes: bc6d22b920 ("radeonsi: fix ps_uses_fbfetch value")
Acked-by: Yogesh Mohan Marimuthu <yogesh.mohanmarimuthu@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20318>
From cc29b940 according to Jonathan Marek using 2 immediates in a cat2
instruction is only "correct" if they are both equal.
They were not equal after reassigning of packed inlocks.
flat.b seemed to work fine even with imm values being different,
but better not to risk.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20533>
tu6_vpc_varying_mode returned how many bits are consumed IF they are
non-zero, for SMOOTH mode nothing is written and it was treated like
no bits were consumed.
When input with smooth interpolation was the last one and straddled
the VPC_VARYING_INTERP_MODE regs, the last interp mode were not written.
Fixes misrendering in "Psychonauts 2".
Cc: mesa-stable
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20533>
draw->cur_num_back is no longer used for immediately reducing the number
of allocated back buffers. It just reflects how many of them are
currently allocated, and is used to prevent allocating more if the
current maximum is already reached.
This fixes an issue where the current in-progress back buffer could get
freed, which would result in visible artifacts.
Unused buffers are freed once they exceed buffer age 200. This ensures
we do not keep around more buffers than necessary in the long run.
v2:
* Drop buffer age threshold to 200. This will free unused buffers more
quickly, and seems enough to avoid doing so prematurely even with
"glxgears -fullscreen" running at thousands of frames per second.
* Use "buf_id != LOADER_DRI3_FRONT_ID". (Pierre-Eric Pelloux-Prayer)
* Simplify loader_dri3_get_buffers changes slightly.
* We can now use any unallocated back buffer slot in dri3_find_back.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20385>
Align the sampler view creation condition with the image and buffer
creation usage which maps to PIPE_BIND_SAMPLER_VIEW, which fixes the spam
of "Illegal sampler view creation without bind flag". Also fix the
PIPE_BIND_SHADER_IMAGE assignment for image usage bits and avoid setting
the image view struct if without PIPE_BIND_SHADER_IMAGE.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20580>
When combining of ro+rw caches is enabled, at first the ro cache should be
looked up and if data isn't found there then rw cache should be checked.
The rw cache checking got lost by accident after the code rebase and there
was no unit test covering this condition. Fix the rw cache looking up and
add the unit test case.
Fixes: 32fe60e8c4 ("util/disk_cache: Support combined foz ro and non-foz rw caches")
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Juston Li <justonli@google.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20595>
Since we don't support wide points, this isn't a useful feature, but the CTS
requires a particular point coord value for the single rasterized pixel, based
on where the original point coord fell within the pixel. Since we're not doing
a quad, we don't get free interpolation like the GL driver does, so split the
logic between vertex (transform point center into screen space) and pixel
(compute delta between current pixel/sample and point center).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20400>
Rather than a grab-bag of random values, return 'Mesa' as the GL_VENDOR
string for all community-supported drivers.
Drivers which are primarily developed/maintained by the hardware vendor
retain that vendor's name as the GL_VENDOR string.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16064>
Patch sets memory object external format (which is otherwise
PIPE_FORMAT_NONE for memory objects) before main surface gets
configured. With this we can add a check that when dealing
with external resource that has no modifier set, we let isl
figure out the tiling mode.
Fixes memobj tests on DG2:
piglit.spec.ext_external_objects.vk-image-display-muliple-textures
piglit.spec.ext_external_objects.vk-image-display-overwrite
piglit.spec.ext_external_objects.vk-depth-display
piglit.spec.ext_external_objects.vk-image-display
piglit.spec.ext_external_objects.vk-stencil-display
v2: add assert and comment on tiling decision (Ken)
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7684
Cc: mesa-stable
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Simon Zeni <simon@bl4ckb0ne.ca>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20473>
zink_prep_fb_attachment() calls acquire internally, which means it's theoretically
possible that fixups are required very late in this function
never seen it happen, but who knows
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20584>
if the clear region is oob, this is illegal and may crash some drivers
fixes (lavapipe):
dEQP-EGL.functional.swap_buffers_with_damage.resize_before_swap.buffer_age_clear_render
dEQP-EGL.functional.swap_buffers_with_damage.resize_before_swap.buffer_age_render_clear
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20584>
Use gpr_map to determine how many cycles each dependency of the
s_delay_alu needs. This information helps the pass avoid further
s_delay_alu instructions.
fossil-db (gfx1100):
Totals from 13097 (9.73% of 134574) affected shaders:
Instrs: 30711894 -> 30702692 (-0.03%)
CodeSize: 153462500 -> 153425692 (-0.02%)
Latency: 372758612 -> 372741922 (-0.00%)
InvThroughput: 50164111 -> 50160717 (-0.01%); split: -0.01%, +0.00%
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20512>
This 2 PIPELINE_CONTROL flushes are not necessary for TGL and newer
and also it have different requirements of flush, so here doing
this two changes at the same time.
As no ANV_PIPE_INVALIDATE_BITS is set as parameter of
anv_add_pending_pipe_bits(),
genX(cmd_buffer_apply_pipe_flushes)(cmd_buffer) will only emit one
PIPELINE_CONTROL.
BSpec: 44505
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20501>
Mesa utilizes only one type of cache at a time. This patch enables support
for combined reading from read-only Fossilize cache + non-foz read-write
caches.
From now on, a non-foz read-write caches will first try to retrieve data
from a read-only foz cache if new MESA_DISK_CACHE_COMBINE_RW_WITH_RO_FOZ
environment variable is set to true, otherwise the caching behaviour is
unchanged. The new flag has no effect when MESA_DISK_CACHE_SINGLE_FILE=1,
i.e. when the single-file foz cache is used.
This change allows us to ship a prebuilt RO caches for a certain
applications, while the rest of applications will benefit from the
regular RW caching that supports cache-size limitation. This feature
will be used by ChromeOS.
Usage example #1:
MESA_DISK_CACHE_DATABASE=0
MESA_DISK_CACHE_SINGLE_FILE=0
MESA_DISK_CACHE_COMBINE_RW_WITH_RO_FOZ=1
MESA_DISK_CACHE_READ_ONLY_FOZ_DBS=rocache1,rocache2
Usage example #2:
MESA_DISK_CACHE_DATABASE=1
MESA_DISK_CACHE_SINGLE_FILE=0
MESA_DISK_CACHE_COMBINE_RW_WITH_RO_FOZ=1
MESA_DISK_CACHE_READ_ONLY_FOZ_DBS=rocache1,rocache2
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18551>
The foz_prepare() doesn't perform cleanup on failure and then foz_destroy()
is never invoked for the foz_db, causing minor memory and FD leaks. Add the
cleanup to foz_prepare() error code paths. Make foz_destroy() to clear the
foz_db struct for consistency, right now the destroying is invoked only once,
but Mesa cache error code paths aren't trivial and may change in the future.
Suggested-by: Timothy Arceri <tarceri@itsqueeze.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18551>
This can be used instead of HWCI_START_XORG to provide X in CI.
It will only be actually used if HWCI_START_XORG is not set in the same
job.
It is particularly useful as weston has the explicit headless backend
which is more straightforward to use in the headless systems in CI.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20393>
The ordering of enum pipe_shader_type changed, but not all locations where
the host uses the original ordering were changed to translate to the new
ordering, namely reading the shader caps was not fixed up so do this now.
v2: - inline virgl_shader_stage_convert (Corentin)
- encapuslate use of host shader stage when reading array elements
of host caps
Fixes: a26543f636
gallium: reorder the shader stage enum to match Mesa
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8023
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20544>
The paths were mostly the same, except that in-place was missing the
appropriate layering for MSAA helper re-mapping. We can instead share
more code, making the differences between the interleave packing clear,
and have the MSAA resolve blit happen once before we do the split
mappings.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20523>
The function was static and only used from this caller, and the only
difference was that the interleaved case didn't handle trans->ss (which
will always be unset for an interleaved mapping since interleaving splits
the underlying map of the MSAA resource into trans->trans and
trans->trans2).
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20523>
Review feedback requested a change that was incorrect, causing Xorg to
start to fail, but I forgot to retest the manual -full jobs that relied on
it.
Fixes: 99a6f2a186 ("ci: Set the path to the VK drivers during HWCI_START_XORG/WESTON.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20523>
Now that renderonly.h includes util/simple_mtx.h, which itself includes
valgrind.h, dep_valgrind is required by any module that includes
renderonly.h.
In file included from ../src/gallium/auxiliary/renderonly/renderonly.h:33,
from ../src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c:39:
../src/util/simple_mtx.h:34:12: fatal error: valgrind.h: No such file or directory
34 | # include <valgrind.h>
| ^~~~~~~~~~~~
compilation terminated.
dep_valgrind is part of idep_mesautil, which should be used instead of
copying the list of deps for each util header included (which would
have to be updated every time a util header changes its own includes),
so let's add idep_mesautil everywhere that includes renderonly.h.
Fixes: ad4d7ca833 ("kmsro: Fix renderonly_scanout BO aliasing")
Tested-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20530>
This was added ~4 years ago for very little performance improvements
(likely < 1%) and this is only supported on GFX8 and GFX9.
Since, the number of dynamic states increased and this is likely
disabled most of the time, and given the maintainability cost, it looks
like it's time to remove it completely.
Applications can still enable it with VK_AMD_rasterization_order.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20514>
Because these are being included across subdir boundaries, the name
"decode" is potentially pretty overloaded. Instead, prefix them with
"isaspec_". Also, since they're both weird includes now and not really
complete files in their own right, give them a descriptive suffix.
Acked-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20525>
The way the isaspec decoder used to work was that it would generate a
header and a C file, each with ISA-specific stuff in it. Then that would
get built together with a stand-alone decode.c file which lives in the
isaspec folder, not the driver's folder. In order for decode.c to find
the ISA-specific headers, it would also generate a glue header which had
to be named isaspec-isa.h. This effectively meant that you can't have
multiple isaspec definitions in the same folder.
To solve this, we make do it the other way around and make the generated
header and C files include the stand-alone files. This is a bit awkward
because it means including a C file from another C file but it's better
for the build system.
Acked-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20525>
Must be used at the end of a vertex shader that does NOT write any varyings, has
rasterizer discard enabled, and is run only for its side effects.
The encoding looks like st_var, but I don't know what this actually *does*. I
just know that the GPU faults if this is omitted.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20446>
Prior to this change, agx_opt_cse is our most expensive backend pass, due to the
time spent hashing instructions. hash_instr was calling into XXH32 a massive
number of times, often to hash only a single bit. It's much faster to hash
entire blocks of memory at a time. Optimize to do just that.
With this change, agx_opt_cse is now cheaper than instruction selection as
it should be.
No shader-db changes (except CPU time decrease).
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20446>
If a render target isn't written to, we don't use the sample mask. Avoid
generating the intermediate instructions, common with gl_FragColor. It will get
DCE'd, but this means less work for DCE, which should help for shader jank since
this pass gets called per-variant.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20446>
We can end up logging both the buffer that the toplevel cmdstream is
allocated, as well as the sub-allocated part of that buffer. Possibly
the kernel could do better about this, but to avoid undecodeable
cmdstream dumps and devcores, detect this case and deal with it.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20496>
Some CTS tests enable all extensions ... , which combined with having
no shader cache on some platforms results in some CTS tests timing
out (in particular tests recreating the device all the time).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20422>
Nothing significant in shader-db on RV530:
total instructions in shared programs: 134963 -> 134957 (<.01%)
instructions in affected programs: 1108 -> 1102 (-0.54%)
helped: 7
HURT: 1
total temps in shared programs: 17153 -> 17154 (<.01%)
temps in affected programs: 38 -> 39 (2.63%)
helped: 2
HURT: 3
Just some fluctuations from pair scheduling due to different code order.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Acked-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20208>
Negligible amount of instructions saved on RV530:
total instructions in shared programs: 134970 -> 134963 (<.01%)
instructions in affected programs: 2273 -> 2266 (-0.31%)
helped: 9
HURT: 1
The one hurt shader is when we fail to recognize the x - ffract(x)
pattern and skip the don't emit ftrunc optimization as implemented
in the previous patch due to some non-trivial swizzles going on.
Signed-off-by: Pavel Ondračka <pave.ondracka@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Acked-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20208>
We already skip emitting ftrunc in nir_lower_int_to_float when there is
ffloor, fround or any other integer-making opcode preceding f2i32. However
if lower_ffloor is set for driver that doesn't support integers, the lowered
x - ffract(x) patterns would not be recognized and extra ftruct would be
emitted, doing unnecessary rounding.
This optimization only works if there is no non-trivial swizzling used for
the fadd, fneg and ffract involved, which seems to be 99% of the cases according
to my testing.
This is needed to enable nir ffloor lowering on r300 driver without regressions.
I'm not sure if this helps anybody else, the only hardware which sets
lower_ffloor and converts ints to floats (and can't do trunc) are some old
etnaviv cards, so maybe it will help there a bit.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20208>
dangling_attr_ref=true can be set when the following happens:
glBegin(GL_TRIANGLES)
glVertex(...)
glVertex(...)
glColor4(...)
glVertex(...)
When glColor4 is hit, the first 2 vertices are copied to the vertex_store
by upgrade_vertex, but since this is done before glColor4 new values are
copied, we make a note to fixup these attribute laters using dangling_attr_ref.
This causes very slow rendering. What this commit does instead, is in this
situation, the new attribute value are backported to the vertex store for the
copied vertices after upgrade_vertex is done updating the layout.
This avoids the slow corner case.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7912
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20495>
Currently, process_singlesync_signals() checks if fd == -1 to handle
possible errors in the drmSyncobjExportSyncFile function. But, fd is not
initialized, which means that drmSyncobjExportSyncFile might fail and
the error will not be handled as fd might not be equal to -1.
Therefore, initialize the fd variable with value -1 to ensure proper
error handling.
cc: mesa-stable
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20475>
A new container registry was added recently in the fd.o infrastructure.
It is located in a datacenter that does not charge for bandwidth usage,
and aims to become the canonical registry in the future. It is however
currently configured to be a partial mirror of registry.fd.o, where
only the most-downloaded container images can be found.
The address of the new registry is specified in mesa/mesa's CI
variables, which means forks will default to registry.fd.o. However,
Valve Infra DUTs do not have access to the internet, and instead use
another cache proxy hosted locally on the CI gateways. This forced
Benjamin to overwrite the registry URL from harbor.freedesktop.org to
registry.freedesktop.org in 0bd9a062e1 ("CI: Overwrite valve infra's
registry").
After adding support for the new registry in valve infra, then
deploying the update, we are now able to make use of the new container
registry. This commit simply rewrites the URL harbor.freedesktop.org
into `{{ harbor_fdo_registry }}`. This variable is set in the valve
infra to point to the `host:ip` of the service, which means changes to
the way we deploy this service can be done on the valve-infra side
without needing to make changes to every project that makes use of our
machines.
Related: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7913
Acked-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20450>
For INTEL_MEASURE, ensure all prior instructions completed before
timestamp taken. Continue to support no CS flush case for Perfetto.
CS stall was dropped from pipecontrol when adding u_trace support.
Fixes: cc5843a573 ("anv: implement u_trace support")
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20502>
For now the restricted traces aren't available to the intel devs, so it
won't actually run for them, but I can manage that part for a bit until we
get the policy updated on the minio side (issue filed to do so).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20503>
This allows us to *much* more accurately express the app's barrier
requests. Unfortunately, there's still a few mismatches, so in those
cases we'll end up conservatively over-synchronizing/flushing.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20324>
While enhanced barriers is a *much* closer model to Vulkan's, there's
still one big mismatch: Vulkan's "transfer" concept supports clears,
copies, and resolves, while D3D's closest match only supports copies.
So when doing clears and resolves, we need to transition from the copy
layout to the correct layout, and then back.
Internal barriers are done for some meta scenarios as well as render
pass initial layout transitions. These look more or less the same as
non-enhanced, we just want to avoid mixing the two paradigms if possible.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20324>
As far as I can tell, every driver that supports GLSL 1.30 or
GL_EXT_gpu_shader4 (and therefore also enables support for
GL_MESA_shader_integer_functions) also sets some subset of the various
NIR lower_bitfield_extract and lower_bitfield_insert flags.
v2: Declaration of 'result' still needs to be added to the IR. Noticed
by marge.
v3: Fix 'git rebase --autosquash' putting the v2 fix in the wrong
place. I've never seen that happen before. :(
Reviewed-by: Emma Anholt <emma@anholt.net> [v1]
Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20323>
GLSL IR opcodes generated for bitfieldExtract and bitfieldInsert are
lowered by lower_instructions. 4dff3ff005 ("nir/opt_algebraic:
Optimize open coded bfm.") adds an optimization that can rematerialize
nir_op_bfm that was prevented by the GLSL IR lowering.
It appears that every piece of hardware, except older Intel GPUS, that
has real integers (i.e., lower_bitops is not set) also sets
lower_bitfield_extract_to_shifts and lower_bitfield_insert_to_shifts.
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Fixes: 4dff3ff005 ("nir/opt_algebraic: Optimize open coded bfm.")
Closes: #7874
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20323>
We have both PACKED and ENUM_PACKED macros which expand to the same
thing. PACKED was based on a meson check for function attributes while
ENUM_PACKED appears to be a legacy gallium thing which was based on
defined(__GCC__). This changes the one use of ENUM_PACKED to PACKED and
deletes ENUM_PACKED.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20412>
The skqp runner gets us parallel execution, automatic caselist handling
(which would have prevented a recent regression due to some skqp tests
having been forgotten in the checked in caselists), nice reports, and the
same xfail/flake handling you know and love from deqp and piglit.
Reviewed-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20070>
Some GL entrypoints would be aliased in an API sense but have different
GLX protocol. The only one that matters to us is EXT_texture_object,
which is the pre-GL-1.1 API. We're just going to drop support for that
and assume you have 1.1 or better, since 1.0 + EXT_texture_object is a
vanishingly rare combo at this point.
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20300>
This is sort of a spiky way to do it, but the effect is to send the
appropriate SetClientInfo twice for indirect screens, where the second
one fills in the GL extensions. We can get away with this because the
only place the string is used is when the server computes the reply for
glGetString(GL_EXTENSIONS), which never matters for direct contexts.
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20300>
GLX is a means to the end of direct rendered GL, really. Our indirect
protocol support has been largely untouched forever, anyone who wants it
can find it in amber. We're not going to drop or intentionally break it
(indirect support), but we're also not going to try super hard to
preserve its quirks anymore.
xserver has typically supported GLX 1.4 since 2009 (xserver 1.8, ad5c0d9e)
and unconditionally since 2016 (xserver 1.19, 36bcbf76). Assuming GLX
1.3 internally will let us fix some GLX drawable lifetime issues.
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20300>
We currently convert it twice for unknown reasons, first when
translating from TGSI and later in constant folding. Not only is this
unnecessary, the first translation doesn't check for non-native
swizzles, so removing it actually saves few instructions and gains
a single Unigine shader for R300 at the expense of few more constant
loads and temps.
Also fixes few dEQPs because we could previously generate code like
TEX temp[1], none.01__, 2D[0];
and the native swizzle rewrite pass was not ready for it.
RV370 shader-db:
total instructions in shared programs: 84441 -> 84436 (<.01%)
instructions in affected programs: 63 -> 58 (-7.94%)
helped: 4
HURT: 0
total temps in shared programs: 12398 -> 12400 (0.02%)
temps in affected programs: 10 -> 12 (20.00%)
helped: 1
HURT: 3
total consts in shared programs: 79081 -> 79090 (0.01%)
consts in affected programs: 12 -> 21 (75.00%)
helped: 0
HURT: 7
GAINED: shaders/tropics/465.shader_test FS
No shader-db change with RV530.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Tested-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20484>
Texturing instructions can't read from constant sources, however this
can work when the constant was transformed to constant swizzles and
hence RC_FILE_NONE.
Prevents a regression in single Unigine Tropics shader that uses
constant (0.5,0.5) as a TEX coordinate in a next patch. We now
convert to constant swizzles twice, first when translating from TGSI
and than in constant folding. If we disable the first conversion
rc_transform_tex will emit a mov from constant to temporary. With this
patch, copy propagate will clean it up later.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Tested-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20484>
This was found while debugging venus-lavapipe ci failure. It's a real
bug though no tests have caught this yet, but fixing this would regress
venus-lavapipe non-templated push tests if without the dependent lvp
fix. The sampler in the descriptor write can be garbled if the binding
has immutable samplers.
cc: mesa-stable
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Corentin Noël <corentin.noel@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20471>
The issue is hidden due to a overly relaxed cts:
dEQP-VK.binding_model.shader_access.primary_cmd_buf.with_push*
that doesn't scrub the sampler from descriptor writes for immutable
samplers. The issue is exposed via venus-lavapipe ci because venus must
ignore the potentially garbled sampler. This change aligns the
VK_DESCRIPTOR_TYPE_SAMPLER path with the
VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER path by removing a false check
against the provided sampler from push since the sampler can be null. An
alternative is to also check against !binding->immutable_samplers there.
Test: venus-lavapipe with venus push descriptor support
cc: mesa-stable
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20471>
This probably could/should be split up into multiple commits, but
it's simpler to make this a monolithic change.
This change inlines a bunch of logic from spirv_to_dxil into the
spirv2dxil tool so that linking can be done on the nir shaders.
Probably the linking functionality should be exposed in the lib/dll
form too, which means that a helper for freeing intermediate nir
would be needed too. That's TODO for now.
The tool now requires arguments to be in-order, and once a filename
is encountered, will use the previous arguments to compile the shader.
If multiple graphics shaders are passed, they're linked as if they
were forming a pipeline together.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20440>
Specifically when shrinking load_const with number of components
> 5, if the final number of components is not allowed (for example 8->6)
it would report false for progress even if we actually did some
reshuffling and also it would skip on the rewrite of the readers.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20213>
This will clean code like:
vec3 32 ssa_8 = frcp ssa_7.www
vec3 32 ssa_9 = fmul ssa_7.xyz, ssa_8
into
vec1 32 ssa_8 = frcp ssa_7.w
vec3 32 ssa_9 = fmul ssa_7.xyz, ssa_8.xxx
This helps r300 driver because we can only do single channel for math
ops at a time, so the first version would result in three frcp
instructions. The nir_opt_shrink_vectors comments even claim the pass
should be doing this, however it actually does it only for nir_op_vecx
instructions, so extend this for generic alu instructions.
RV530 shader-db:
total instructions in shared programs: 135032 -> 133707 (-0.98%)
instructions in affected programs: 46121 -> 44796 (-2.87%)
helped: 452
HURT: 26
total temps in shared programs: 17051 -> 17033 (-0.11%)
temps in affected programs: 1509 -> 1491 (-1.19%)
helped: 91
HURT: 30
12.02->12.08 (+0.5%) fps gain in Unigine Sanctuary (n=5) with RV530
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7051
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reiewed-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20213>
The goal is to make files at the root of src/compiler/ apply to both Bifrost and
Valhall, while ISA-specific code (e.g. instruction packing) code goes in
compiler/bifrost/ or compiler/valhall/. This is what Valhall is already doing,
the Bifrost specific stuff was just grandfathered in.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20455>
This functionality is now available on Linux with drm-shim + shader-db, and I
suspect the version bundled here is broken anyway. Strictly this drops
Windows/macOS support for the known-broken frontend to the shader compiler but I
can't say I'm terribly worried about that.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20455>
This is the compiler for both Bifrost and Valhall, and presumably future
Mali GPUs too. Give it a more generic name so we can use the bifrost/ path for
something a bit more specific.
For historical reasons the compiler's name is still "bifrost" and uses the
prefix `bi_`. I think that's ok in the same way that i915 in the kernel supports
way more than just i915.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20455>
Since the variable length dot must stay in its slot configuration
do not try to merge the group with the previous group when an op may be
moved to the t slot, because this may lead to breaking the multi-slot
operation.
Fixes: 357e5fac99
r600/sfn: Use variable length DOT on Evergreen and Cayman
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20451>
76 out of 86 piglits pass.
Some fail because SSBOs are only supported for FS and CS on r600, but
the piglits try to use SSBOs with VS, and there are piglits that try to
bind SSBO at 8, and only 0-7 is supported as binding point.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20451>
On drivers that do not set PIPE_CAP_SHAREABLE_SHADERS,
st_destroy_program_variants() may reach st_save_zombie_shader()
which accesses st->zombie_shaders.mutex.
Destroying st->zombie_shaders.mutex before destroying program variants
may result in an invalid access in a multiple context scenario for
those drivers.
Move the mutex destroy call to after program variants destroy so that
it doesn't hit a deadlock on context destroy.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20458>
radv_before_taskmesh_draw will no longer call radv_before_draw and
instead implement the necessary functionality on its own.
radv_before_draw will no longer have to emit mesh shader descriptors.
As a result, both functions should have a lower CPU overhead now.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18829>
Any unused split_vector definition can always use the same register
as the operand. This avoids creating unnecessary copies.
Fossil DB stats on Rembrandt (RDNA2):
Totals from 3904 (2.89% of 134906) affected shaders:
CodeSize: 18326692 -> 18271688 (-0.30%)
Instrs: 3386632 -> 3372888 (-0.41%)
Latency: 42337481 -> 42330085 (-0.02%); split: -0.02%, +0.00%
InvThroughput: 6566731 -> 6566424 (-0.00%); split: -0.01%, +0.00%
Copies: 224301 -> 210559 (-6.13%)
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16161>
Eliminate unnecessary copies when the operand registers of a
p_split_vector instruction are not clobbered between the p_split_vector
and the user of its definitions.
This happens when p_split_vector doesn't kill its operand and its
definitions have a shorter lifespan that the operand. It affects every
NGG culling shader among other things.
This optimization exists because it's too difficult to solve it
in RA, and should be removed after we solved this in RA.
v2 by Daniel Schürmann:
- Rearrange and simplify conditions for the new optimization
- Fix a few bugs
v3 by Daniel Schürmann:
- Check number of encoded ALU operands
Fossil DB stats on Rembrandt (RDNA2):
Totals from 64896 (48.10% of 134906) affected shaders:
CodeSize: 175693348 -> 175434944 (-0.15%)
Instrs: 33333912 -> 33269388 (-0.19%)
Latency: 183766084 -> 183763432 (-0.00%); split: -0.00%, +0.00%
InvThroughput: 28589651 -> 28589340 (-0.00%); split: -0.00%, +0.00%
Copies: 2806550 -> 2742038 (-2.30%)
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16161>
This allows is_overwritten_since to return false when the last
writer instruction of a register can't be tracked but we know it wasn't
written in the current block.
Fossil DB stats on Rembrandt (RDNA2):
Totals from 1163 (0.86% of 134906) affected shaders:
CodeSize: 9815920 -> 9805016 (-0.11%)
Instrs: 1843688 -> 1840962 (-0.15%)
Latency: 19219153 -> 19209171 (-0.05%)
InvThroughput: 3354375 -> 3353852 (-0.02%)
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16161>
There is only one special case (a3xx/a4xx queries) were a pipe_resource
is allocated without a backing buffer (because we don't know the needed
size until we know the # of bins). But those will never end up as an
a6xx render target!
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20465>
Sometimes a tag "Closes:" in a commit may refer to a merge request
instead of an issue. Examples of such commits:
34319c7d84 "ci/freedreno: disable antichambers trace"
998122d9c2 "mesa: fix GL_INVALID_OPERATION in glEGLImageTargetTexStorageEXT"
Avoid failing on these by explicitly checking that the URL refers to an
issue
Cc: mesa-stable
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20241>
A commit may refer to an issue marked as confidential. That will look
like a 404 page for outside users. One example of such commit is:
369c12e5be "anv: clear descriptorsets if AllocateDescriptorSets fails"
Let's handle that case.
Cc: mesa-stable
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20241>
Currently, the "New features" list unconditionally ends with a "None"
point, which makes no sense. The original author probably meant to check
whether the file is empty, so remove the else clause, and add the check
for emptiness.
Cc: mesa-stable
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20241>
This change copies the string once.
Direct leak of 196 byte(s) in 14 object(s) allocated from:
#0 0x7f71598ec7a7 in strdup (/usr/lib64/libasan.so.6+0x5c7a7)
#1 0x7f70a56ff942 in driParseOptionInfo ../src/util/xmlconfig.c:357
#2 0x7f70a56f0565 in pipe_loader_load_options ../src/gallium/auxiliary/pipe-loader/pipe_loader.c:126
#3 0x7f70a56f0565 in pipe_loader_create_screen_vk ../src/gallium/auxiliary/pipe-loader/pipe_loader.c:167
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20026>
See 0afd691f29 ("panfrost: clang-format the tree") for why I'm doing this.
Asahi already mostly follows Mesa style so this doesn't do much. But this means
we can all stop thinking about formatting and trust the robot poets to do that
for us.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20434>
There are no outstanding commits to these files in any branch, so they don't
need to be considered for the rebasing script. That said, they are massive and
bottleneck the rebasing script, so we'll want to split them out to keep rebasing
efficient.
(Nominally I should make the rebasing script less stupid but with these files
ignored it works pretty well.)
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20434>
When importing a BO, if it is already imported, then the handle will
alias an existing BO instance. It is possible for the existing owner to
free the BO after the import and leave a dangling handle before we get a
chance to increase the refcount, so we need to lock the BO table mutex
before importing, to make sure nobody else goes through the free path
during that window.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20403>
When importing a BO, if it is already imported, then the handle will
alias an existing BO instance. It is possible for the existing owner to
free the BO after the import and leave a dangling handle before we get a
chance to increase the refcount, so we need to lock the BO table mutex
before importing, to make sure nobody else goes through the free path
during that window.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20403>
When importing a BO, if it is already imported, then the handle will
alias an existing BO instance. It is possible for the existing owner to
free the BO after the import and leave a dangling handle before we get a
chance to increase the refcount, so we need to lock the BO table mutex
before importing, to make sure nobody else goes through the free path
during that window.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20403>
BOs can only have one handle. If renderonly_create_gpu_import_for_resource
ends up importing a BO that was already mapped for scanout, it will get
the same handle. This leaves us with two renderonly_scanout objects for
one handle, and the first one to be destroyed will free it.
Import the BO map tracking logic from asahi, to avoid aliasing
renderonly_scanout objects. Each actual BO now is only represented by a
single object instance, which is reference counted.
Fixes KWin full-screen PipeWire capture breaking scanout entirely.
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20397>
This switches us over to Mesa's code style [1], normalizing us within the tree.
The results aren't perfect, but they bring us a hell of a lot closer to the rest
of the tree. Panfrost doesn't feel so foreign relative to Mesa with this, which
I think (in retrospect after a bunch of years of being "different") is the right
call.
I skipped PanVK because that's paused right now.
find panfrost/ -type f -name '*.h' | grep -v vulkan | xargs clang-format -i;
find panfrost/ -type f -name '*.c' | grep -v vulkan | xargs clang-format -i;
clang-format -i gallium/drivers/panfrost/*.c gallium/drivers/panfrost/*.h ; find
panfrost/ -type f -name '*.cpp' | grep -v vulkan | xargs clang-format -i
[1] https://docs.mesa3d.org/codingstyle.html
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20425>
The issue we're addressing here is that we have 2 batches and the both
grow at different rate. We want to keep doubling the main batch size
as the application writes more and more commands to limit the number
of GEM BOs. But we don't want to have the generation batch size to be
linked to the main batch.
v2: remove gfx7 code
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15642>
I noticed a sequence like the following in a scheduled SuperTuxKart shader:
TEX_SINGLE.slot0 @r0:r1, ..
LD_VAR.wait0 @r2, ...
FMA r1, ...
Why do we stall waiting for the TEX_SINGLE instruction when it's not actually
read? Because its upper channels are *never* read, leading to a
write-after-write dependency when the register allocator puts some unrelated ALU
destination in there. By appropriately masking the texture instruction's write,
that false dependency disappears, avoiding the stall.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20426>
There are too many problems with indirect draws on v7 that we never got this
code path to the finish line, and none of us have a good plan (or reason) to fix
this. Proper indirect draws are only possible since v10 on Mali.
There was interest in using this path to implement indexed draws in PanVK, that
MR is stalled and it's not clear how much sense it makes to do Vulkan on
anything older than v9 or v10 at this point. This code isn't *gone*, it'll still
be in git history, but I don't see a lot of reason in keeping it in tree if it's
unused and complicating e.g. the sysval upload path of the driver.
Indirect dispatch remains supported on v7, as that path *is* working and flipped
on for end users. Indirect dispatch on v7 is considerably less complicated than
indirect draws.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20420>
Folding signed or unsigned i32 -> i16 conversion into sampling
instruction causes it to behave differently with out-of-bounds
values. The conversion expects higher bits being masked, however
folded variant does clamp the value.
A concrete example is that:
isaml.base0 (u16)(x)hr0.x
is not equal this:
isaml.base0 (u32)(x)r0.w
(sy)cov.u32u16 hr0.x, r0.w
Fixes misrendering in "Injustice 2".
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7869
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20396>
Linear PE causes a lot of issues in the ZS stage. While some of those issues
can be worked around on newer GPU cores by doing all ZS operations in the
late stage, GC600 r4653 exhibits spurious Z fails when linear PE is active
even though this GPU does not even have a early Z stage.
Disable linear PE for now, until the issue can be analyzed further. Leave the
debug option in place to allow to enable linear PE for testing.
Fixes: 43eb5e777e ("etnaviv: add debug option to disable linear PE feature")
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20405>
Because commit b9403b1c47 moved dispatch enable handling away from the
compiler, the drivers must ensure correct dispatch enable values. This
is handled by the intel_set_ps_dispatch_state function.
v2: Fix gfx6 build and use brw_fs_get_dispatch_enables for gfx6 in
crocus
v3: Rebase, use intel_set_ps_dispatch_state, drop gfx6 handling
Fixes: b9403b1c47 ("intel: factor out dispatch PS enabling logic")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20267>
To debug the LAVA jobs locally, we have an option in the
lava_job_submitter script to ignore the JWT token to make it possible to
retry jobs without the need to get an unexpired token.
But this trick needs to modify the overlayed directory so that we would
need to download and extract it earlier in the run.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20051>
LAVA uses XMLRPC to send jobs information and control, more specifically
it sends device logs via YAML dumps encoded in UTF-8 bytes.
In Python, we have xmlrpc.client.Binary class as the serializer
protocol, we get the logs wrapped by this class, which encodes the data
as UTF-8 bytes data.
We were converting the encoded data to a string via the `str` function,
but this led the loaded YAML data to use single quotes instead of double
quotes for string values that made special characters, such as `\x1b` to
be escaped as `\\x1b`.
With this fix, we can now drop one of the hacks that fixed the bash
colors.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20051>
Only enable mesh+task shaders when IBs and gang submit are enabled.
We won't support gang submit with noibs.
Also remove the RADV_PERFTEST=ext_ms option.
Side note, GFX11 task/mesh support is still a TODO.
Don't skip the CTS tests which require GFX->ACE synchronization.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20010>
Add new preambles and postambles for synchronizing gang members in a
gang submission using semaphores.
These semaphores are both located in a small BO.
Gang wait preambles:
- gang leader writes 1 to a semaphore
- gang member waits for it to be written
When task shaders are used, make sure ACE waits until GFX starts to execute.
Userspace is required to emit this wait to make sure it behaves correctly
in a multi-process environment, because task shader dispatches are not
meant to be executed on multiple compute engines at the same time.
Gang wait postambles:
- gang member writes 1 to a semaphore
- gang leader waits for it to be written
This ensures that the gang leader waits for the whole gang,
which is necessary because the kernel signals the userspace fence
as soon as the gang leader is done, which may lead to bugs because the
same command buffers could be submitted again while still being executed.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20010>
This is necessary for supporting gang submit.
With gang submit, the kernel now allows us to submit multiple IBs
with different IP types. Therefore, RADV will also need to group
various CSs with different IP types together and remember the IP
type of each CS.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20010>
nir_lower_is_helper_invocation should be after nir_lower_system_values
to handle possible nir_intrinsic_is_helper_invocation which may be
produced by nir_lower_system_values.
Happens with SPIR-V 1.6 for which gl_HelperInvocation is translated into
"BuiltIn HelperInvocation" + "Volatile", which nir_lower_system_values
translates into is_helper_invocation.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19677>
nir_lower_is_helper_invocation should be after nir_lower_system_values
to handle possible nir_intrinsic_is_helper_invocation which may be
produced by nir_lower_system_values.
Happens with SPIR-V 1.6 for which gl_HelperInvocation is translated into
"BuiltIn HelperInvocation" + "Volatile", which nir_lower_system_values
translates into is_helper_invocation.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19677>
nir_lower_is_helper_invocation lowers intrinsic_is_helper_invocation
and uses load_helper_invocation (which is lowered by nir_lower_system_values).
While nir_lower_system_values may lower SYSTEM_VALUE_HELPER_INVOCATION
into intrinsic_is_helper_invocation.
So they depend on each other. Break the dependency by making
nir_lower_is_helper_invocation aware of lower_helper_invocation option
and emitting lowered load_helper_invocation when required.
Happens with SPIR-V 1.6 for which gl_HelperInvocation is translated into
"BuiltIn HelperInvocation" + "Volatile", which nir_lower_system_values
translates into is_helper_invocation.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19677>
Before, when an application called into d3d12_query_result, and
the results were not ready to be read, a flush-and-wait would
be attempted via synchronized mapping of the query result resource.
This can end up calling close/execute on the command list while it is
already being executed by the driver thread.
With the current fence value attached to the query, we now wait
for completion if necessary and then map the resource unsynchronized, or
return false if the result is not ready and wait == false.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20217>
The latest includes/registry have some pNext structs that need
guarding spearately to their initial structs, so we have to track
the define guards better and use them in the generated code
For example:
VkVideoEncodeRateControlInfoKHR extends VkVideoCodingControlInfoKHR
However the first struct is protected by BETA, but the second isn't
the generator was always generating unguarded code for all structs
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Acked-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20384>
This lets us batch up the state changes from multiple
vkCmdBindDescriptorSets, which ANGLE and zink will both do in a single
draw.
Improves ANGLE (sysmem) driver_overhead perf by 5.18806% +/- 1.03444% (n=5).
Improves ANGLE aztec_ruins_high perf by ~.3%. (clear result in the graph,
but the screen went to sleep mid way through and so it was high variance)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20084>
We had iris_bo_alloc() call with the wrong flags value, it was
mistaken by aligment, see commit 68652dca0c.
To avoid such mistakes in future here adding BO_ALLOC_PLAIN so
iris_bo_alloc() calls have a more descriptive flag parameter when
there is no special allocation request.
While at it, also standardizing unsigned as the type for this flag.
No behavior changes here.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19857>
RADV use dri option to enabled this for some apps, but it's
done in nir lower currently. I'm afraid it still needs this
option to handle the non-uniform case as desc is loaded in
llvm.
radeonsi always enable this for bind-textures.
radeonsi will lower all bind-textures to bindless-textures,
and only bind-textures use desc index, so add this abi for
bindless desc index path.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18666>
Like nir_texop_fragment_mask_fetch_amd, this is used to load multi
sample image fmask data for AMD GPU.
We will lower multi sample image load and samples_identical intrinsics
to use it latter for radeonsi. RADV does not need this because it
always expand fmask images before dispatch compute shader.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18666>
Commit d08bd9a8d8 ("etnaviv: don't expose array and 3D texture support on pre-halti GPUs")
started returning 0 from PIPE_CAP_MAX_TEXTURE_2D_SIZE as well due to switch
case fallthrough. Reinstate the behavior of PIPE_CAP_MAX_TEXTURE_2D_SIZE,
while at the same time, retain the new behavior introduced by commit
d08bd9a8d8 , Otherwise not even kmscube displays the spinning cube,
weston does not display desktop and so on.
Triggered on "Vivante GC600 rev 4653" , i.MX8M Mini .
Fixes: d08bd9a8d8 ("etnaviv: don't expose array and 3D texture support on pre-halti GPUs")
Closes: #7898
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20373>
Add the GenXML hardware description for Mali architecture v10, as implemented in
Mali-G610. This is not 100% complete but it should be good enough for parity
with v9.
The XML itself is forked off of v9, with all Job Managerisms replaced with
CSFisms. This notably includes a large number of new structures defining the
instructions that run on the Command Execution Unit (CEU).
This is the first step towards supporting Mali-G610 (i.e. RK3588) upstream. Next
up will be pandecode support.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20360>
WC is fine for staging upload buffers, and will let us hit the default
heap. Probably introducing a separate cached-coherent heap is overkill,
and given that staging uploads are common (but downloads uncommon, out-
side of dEQP/piglit), it is better to just ask for WC.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20263>
Add a heap that we can use for allocations of small mappable buffers.
This avoids the churn of mmap/unmap, which is especially expensive in
a VM. It also allows packing more smaller allocations together in a
page, which is useful for PIPE_BUFFERs (which are also mappable).
This avoid jank caused by the overhead of setting up or tearing down
guest mappings when running in a VM. And also significantly reduces
the # of BOs referenced on a submit.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20263>
This moves away from embedding the submit fence inside the pipe fence,
which lets us start refcnt'ing the fence. This will enable several
cleanups and improvements:
1. Get rid of fd_bo_fence, and just have fd_bo hold pending fd_fence
refs instead, which will be needed for cpu_prep implementation of
sub-allocated buffers.
2. For merged submits, we can just return a new reference to an
existing fence.
Note that this temporarily defeats submit-merging, which will be
fixed (and improved) in a following commit.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20263>
These are redundent with the alloc_flags. A following commit will map
alloc_flags directly to bo heap that should be used, and adding the
FD_BO_SHARED bit when a BO is exported neatly avoids returning it to
the pool to be potentially erroneously reused.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20263>
Sub-alloc'd heap BOs will need to do something a bit more special, ie.
not immediately cleanup fences (because those will be needed to know
when the BO is actually idle and vma node can be released), not tear
down the mmap (because the BO doesn't own it), and not close the handle
(also because the BO doesn't own it).
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20263>
Get rid of the per-device table of deferred handles, and instead keep
this on the stack so that no additional locking is needed. This will
simplify getting rid of table_lock in the bo delete path. For the BO
cache, add fd_bo_del_list_nocache() which works like fd_bo_del_array()
except that it bypasses returning BOs to the cache. This gets rid of
the BO cache calls to private fd_bo fxns (which is useful now that the
bo_del/close_handles() dance has become a bit more complicated).
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20263>
We want to get back to the point where table_lock is only doing what
it's named for (ie. protecting handle/name tables). This is the first
step. Add new locks to protect fencing and the bo caches. A single
global lock for fences, to avoid atomic instructions in the loop per
submit bo attaching fences.
This couldn't be broken appart into different commits, otherwise there
would have been an ABBA deadlock in BO cache's call to fd_bo_state()
to check if a BO is idle.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20263>
To prepare for moving fence state out from under table_lock, simplify
cleanup_fences() and stop trying to re-use it in the bo destruction
path (which otherwise wouldn't need the fence lock, since there is
no other owner of the bo ref at that point, and simply needs to drop
pipe refs).
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20263>
Fixes
dEQP-GLES2.functional.texture.mipmap.cube.basic.linear_nearest
when run with a GLES2 version.
We wire up seamless cube maps for GLES3+ only, working around an obscure
mesa/st limitation. See 6148e3aae7 ("mesa: Fix
ctx->Texture.CubeMapSeamless") for the full context.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20365>
For gl_FragDepth, passes dEQP-GLES3.functional.shaders.fragdepth.* and piglit
fragdepth_gles2.
For stencil export, passes piglit glsl-fs-shader-stencil-export.
For gl_FragDepth together with stencil export, passes
dEQP-GLES3.functional.fbo.blit.*
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20365>
The hash table needs a key pointer with at least the lifetime of the
hash entry, which the key pointer we get does not have (since it is
stack-allocated by agx_build_meta). Copy it into the shader struct
itself and use that for the hash table.
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20365>
It seems triangle merging is incompatible with calculating derivatives
along primitive edges correctly. Take the appropriate NIR shader info
flags in the compiler and pass them down as a flag to the driver, so it
can set the disable triangle merging flag (formerly called "lines or
points").
TODO: Is this what macOS does when you set a sample mask there (which
apparently fixes the same bug on the Darwinia Metal backend)? Do we
also need to set this when sample masks are used?
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Fixes Darwinia and dEQP2 projected tests.
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20365>
Shared resources are in an unknown state, so we have to assume they
may contain valid data.
Fixes Xorg+Kwin random full-screen garbage on mouse cursor present.
However, we still get black flashing in some circumstances (that was
garbage flashing before this commit), which indicates that something
is reading an uninitialized/fresh shared framebuffer and expecting
valid data (prior screen contents?) TBD.
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20365>
We were only dereferencing the resource in the PIPE_MAP_WRITE path of
agx_transfer_unmap, which means that read-only transfers leaked the
staging resource/BO. Always free the staging resource unconditionally.
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20365>
Without globalFencing, exportable fences and semaphores must instead
have their proxy vn_renderer_sync installed in the same renderer
ring_idx as ther last queue submissions to ensure they signal after
all work previously submitted to the same ring_idx. Exportable
fences/semaphores with a temporary (imported) payload don't need a proxy
vn_renderer_sync, since they already have a `poll()`able fd available.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19691>
With implicit fencing, the image has a fence that blocks scanout until
rendering is complete. virtgpu doesn't support implicit fencing yet, but
Sommelier (a VM Wayland compositor) does the wait by exposing the bo as
a GEM handle and waiting on all fences in userspace with a
DRM_IOCTL_VIRTGPU_WAIT before issuing the wl_surface commit.
During vkQueueSubmit involving wsi images, we follow with an empty
renderer submission on the corresonding ring_idx to install a fence
on the appropriate virtgpu fence context after the last rendering
submission.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19691>
For submissions to renderers that support multiple timelines, put
them on the virtgpu fencing timeline (dma fence context) specified by
the VkQueue's bound ring_idx. CPU-sync'd renderer submissions
can be sent in the same manner by using ring_idx = 0.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19691>
Pick DEBUG_GET_ONCE_BOOL_OPTION as a example:
The intention of DEBUG_GET_ONCE_BOOL_OPTION are returned the same value across
thread, before this commit, on different thread call the function generated by
DEBUG_GET_ONCE_BOOL_OPTION may return different value if called setenv in the
middle of debug_get_bool_option, so use debug_get_option_cached along with
new exposed function debug_parse_bool_option to solve this issue
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19554>
struct hash_table is not thread-safety, need guard by mutex,
but with thread local storage, we can simplify the code and also
got the thread safety without the need of mutex.
Another advantage is by using thread local storage, os_get_android_option
will have the same actions like getenv does, that it's not cached the
value, each call will access the property_get, like getenv will be affected
by putenv
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19554>
Getting debug_get_num_option to return int64_t, as long under 64 bit Linux are 64 bit size,
so using fixed int64_t for cross platform consistence, as long under win32 is 32 bit size.
Getting DEBUG_GET_ONCE_FLAGS_OPTION to return uint64_t to getting it to be
consistence with debug_get_flags_option.
DEBUG_GET_ONCE_NUM_OPTION is not accessed in codebase, so add unittest for it, it maybe
used in future, remove it is not consistence
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19554>
error messages:
src/compiler/glsl/glcpp/glcpp-parse.c:1691:9: error: variable 'glcpp_parser_nerrs' set but not used [-Werror,-Wunused-but-set-variable]
int yynerrs = 0;
^
src/compiler/glsl/glsl_parser.cpp:2370:9: error: variable '_mesa_glsl_nerrs' set but not used [-Werror,-Wunused-but-set-variable]
int yynerrs = 0;
^
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19875>
There are multiple error messages, show one of them:
../../src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c:219:54: error: passing arguments to a function without a prototype is deprecated in
all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
sdev->ws = sdev->dd->winsys[i].create_winsys(drisw_lf);
^
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19875>
For cases where both clip and cull are used, and a shader has both
inputs and outputs that can contain them, we need metadata to tell
us where the clip array ends and the cull array begins, since they
get combined into CLIP location registers. For outputs, this is in
the nir info, but for input we pass it in a sideband channel.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20346>
User varyings are linked by both name and register. The name is based
on how many *variables* are before it in final driver_location sort
order, not necessarily how many registers are before it.
In some cases where clip/cull distance are involved, it's possible
for one shader to write into a part of the cull distance that's
ignored by a downstream shader, but because linking is done by
*whole* register locations, and clip/cull can be combined using
*fractional* register locations, this is hard to detect. Since no
non-sysvals end up using fractional locations, just put all non-sysvals
first so they always generate the same semantic names for the same
register locations.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20346>
They're too restricted for AFBC. Fix up instead. There are two problems at play:
1. We can't just map the format swizzle to the pixel format ordering on v7,
because the "reordered" values aren't allowed with compression.
2. We can't just compose the format swizzle with the API swizzle, because the
composed swizzle is applied to the border colour, so we need to be able to
apply an inverted swizzle to the border colour. That only works for bijective
format swizzles.
Fortunately, there's a neat solution: decompose the format's swizzle into two
swizzles, the first mapping to a reordering that IS allowed for compression, and
the second a bijection. Then we use the allowed reordering when texturing, apply
the bijective swizzle to the API swizzle, and apply the inverse of the bijective
swizzle to the border colour. When we're sampling a border colour, what's now
happening mathematically is:
(API swizzle o bijective swizzle)((bijective swizzle^-1)(border colour)) =
(API swizzle o (bijective swizzle o bijective swizzle^-1))(border colour) =
API swizzle(border colour)
which is exactly what we wanted.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20311>
On v6 and earlier, the hardware supports arbitrary format swizzles for AFBC, so
there's no restriction on AFBC. On v8 and newer, the format swizzle gets applied
to the *decompressed* interchange format, so we can effectively support BGRA of
AFBC images without any special handling. (Confirmed working on v9. Obviously I
can't test on v8 but the expression is cleaner if we assume optimistically it's
like v9. Without hardware, we get to make that assumption :-p)
That just leaves v7 as the only architecture where format swizzles are
restricted for compression but there are no plane descriptor. Don't apply the
restriction to the newer parts.
This gets us AFBC of window surfaces on v9+. As the limiting case, fullscreen
glmark2-es2-wayland -btexture (1080p) in sway on Mali-G57 from 1300fps to
2353fps.
45% reduction in frame time is nothing to sneeze at.
Achoo.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20311>
Introduce an enum to represent an AFBC compression mode. These modes are not
formats, on Valhall they are decoupled from the format. As such, it does not
make sense to use a pipe_format to represent them. Add an enum that we can use
in a straightforward way on Midgard and Bifrost to fallback for texture views,
and can map 1:1 to the Valhall hardware enum.
In addition to being less overloaded semantically, this lets -Wswitch kick in to
ensure that we handle all enums when translating. The straightforward
translation raises the following warnings:
../src/panfrost/lib/pan_cs.c:437:9: warning: enumeration value ‘PAN_AFBC_MODE_R5G5B5A1’ not handled in switch [-Wswitch]
437 | switch (panfrost_afbc_format(PAN_ARCH, format)) {
| ^~~~~~
...indicating that some formats were missed, leading to assertion fails "unknown
canonical AFBC format" when rendering RGB5A1, which dEQP-GLES31 does. Fixes
regressions in
dEQP-GLES31.functional.draw_buffers_indexed.random.max_required_draw_buffers.*
on Valhall.
Given how scarce v9 hardware is, that v10 isn't upstream yet, and the offending
code was merged a week ago, this should not have actually affected anyone. At
any rate, it's a good reminder we really do need CI for v9...
Fixes: 8e125b6c15 ("panfrost: Enable AFBC of more formats")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20311>
When calculating legacy WSI strides for tiled AFBC, we need to account for the
greater alignment requirement of tiled AFBC, or importing resources will fail
later.
Since tiled AFBC is only supported on v7 and later, and AFBC of window surfaces
isn't being used on Linux on v7 and later, this probably hasn't been hit in
practice. Probably.
We're about to fix AFBC of window surfaces so we need to fix this side first.
Fixes: 0255f554f3 ("panfrost: Advertise 16x16 tiled AFBC")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20311>
When VK_PIPELINE_CREATE_LINK_TIME_OPTIMIZATION_BIT_EXT is used, the
pipeline includes a complete set of state specified entirely by
libraries. That means that we should skip using compiled binaries
(including PS epilogs) and we should create an optimized pipeline.
Found this with Zink because RADV was creating two pipelines with the
same PS epilog, while the optimized one shouldn't use any PS epilog.
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/20202>
Extending the lines by half a pixel in each direction without doing
anything about the varyings makes the varyings interpolate over a
distance than intended. While this can be negligeble for long lines,
it can lead to big error for short lines.
Let's instead add extra geometry for each of the line-caps, so we can
make sure the varyings stay constant for the whole cap, and interpolate
over the intended distance instead.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19847>
This implements line-smoothing the same way as the draw-module does,
except using a geometry shader instead of a CPU pass.
Ideally, this should be enabled either by checking for the various
smooth-line caps, or by a DRIconf setting.
Unfortunately, RADV doesn't support he smooth-lines features, and we
don't want to force it down a pessimistic shader-key code-path. So that
plan is out the window for now.
While DRIconf is also neat, it's a bit of work to wire up, and we don't
really know of any real-world applications who would need this yet. So,
for now, let's just unconditionally enable is on the IMG proprietary
driver, which is going to need this for sure.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19847>
This was really derpy. There's two things wrong; first of all, we should
pick at LEAST VARYING_SLOT_VAR0, second, util_last_bit64 returns one
more than the index of the bit already, so we don't want to add twice
here.
Fixes: 4b17c099ca ("zink: add line-stippling lowering passes")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19847>
So far we have been only restoring dirty dynamic states used by meta
pipelines however, static state from meta pipelines will also clear
dirty flags, preventing follow-up draw calls in the command buffer
to honor these if they are flagged as dynamic states in their
pipelines. Fix this by always resetting all dirty state flags after
a meta operation so we re-emit all the state we need with the next draw
call.
Fixes:
dEQP-VK.dynamic_state.monolithic.image.clear
cc: mesa-stable
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20356>
Nothing in the spec seems to require that the number of stages for
which creation feedback is requested must match the number of stages
available in the pipeline. In fact, the spec explicitly mentions
that this number could be 0:
"If pipelineStageCreationFeedbackCount is not 0,
pPipelineStageCreationFeedbacks must be a valid pointer to an
array of pipelineStageCreationFeedbackCount
VkPipelineCreationFeedback structures"
Fixes an assert crash in:
dEQP-VK.pipeline.monolithic.creation_feedback.graphics_tests.vertex_stage_fragment_stage_no_cache_zero_out_feedback_cout
cc: mesa-stable
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20352>
This may allow applications making use of buffer age to save some effort
in some cases.
v2: (Simon Ser)
* Add space between struct member and "<" operator.
* Remove break statement which prevented the change from working as
intended in swrast_update_buffers.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18269>
If we can't use the TLB to do a subpass resolve we have a fallaback
that emits separate image resolves, but this fallback was only
handling color resolves. This adds depth/stencil as well.
Fixes some of the issues we have with CTS 1.3.4 in:
dEQP-VK.pipeline.monolithic.multisample.misc.*
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20331>
For these we always want to use sample_0, averaging is reserved for
color formats. We were already doing this correctly for depth/stencil
resolved in render passes, but not for those happening through
vkCmdResolveImage.
Fixes some of the issues we have with CTS 1.3.4 in:
dEQP-VK.pipeline.monolithic.multisample.misc.*
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20331>
attachment state is only relevant during render passes, however,
there is a corner case: if we can't resolve an attachment in a
subpass using the hardware, we emit a manual image resolve in the
driver which can trigger a meta operation via blit. In this case,
we pretend we are not in a render pass (since vulkan disallows
blits/resolves in a render pass) but we really want to keep the
attachment state after the meta operation.
Fixes some of the issues we have with CTS 1.3.4 in:
dEQP-VK.pipeline.monolithic.multisample.misc.*
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20331>
Pre-patch, anv_descriptor_pool used a free list for host allocations
that never merged adjacent free blocks. If the pool only allocated
fixed-sized blocks, then this would not be a problem. But the pool
allocations are variable-sized, and this caused over half of the pool's
memory to be consumed by unusable free blocks in some workloads, causing
unnecessary memory footprint.
Replacing the free list with util_vma_heap, which does merge adjacent
free blocks, fixes the memory explosion in the target workload.
Disdavantges of util_vma_heap compared to the free list:
- The heap calls malloc() when a new hole is created.
- The heap calls free() when a hole disappears or is merged with an
adjacent hole.
- The Vulkan spec expects descriptor set creation/destruction to be
thread-local lockless in the common case. For workloads that
create/destroy with high frequency, malloc/free may cause overhead.
Profiling is needed.
Tested with a ChromeOS internal TensorFlow benchmark, provided by
package 'tensorflow', running with its OpenCL backend on clvk.
cmdline: benchmark_model --graph=mn2.tflite --use_gpu=true --min_secs=60
gpu: adl
memory footprint from start of benchmark:
before: init=132.691MB max=227.684MB
after: init=134.988MB max=134.988MB
Reported-by: Romaric Jodin <rjodin@google.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20289>
This reverts commit b1126abb38.
This breaks all hell at least on DG2, as there are several cases left
where current_pipeline gets checked against GPGPU to decide what to do,
and the value doesn't match that of ANV_HW_PIPELINE_STATE_COMPUTE.
On top of that, it also misses checking for
ANV_HW_PIPELINE_STATE_RAYTRACING.
Then there's the fact that in some cases, current_pipeline will be
UINT32_MAX, because it's the original undefined state and also used
after executing a secondary command buffer because we are not tracking
on which pipeline did the secondary left us.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7910
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20349>
Buffer maps that don't invalidate their destination range work better
as direct CPU maps than staging blits. The application may write only
part of the range, effectively combining the new data with existing
data. So even if the map would stall, the staging blit path won't help
us, as we have to read the existing data to populate the staging buffer
before returning it. This incurs a stall anyway - plus a read and copy.
In contrast, a direct map doesn't need to read any data - it can just
write the destination and the existing data will still be there.
Fixes excessive blits for stalling buffer writes that don't invalidate
the buffer since my recent map heuristic rework.
Fixes: bec68a85a2 ("iris: Improve direct CPU map heuristics")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7895
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20330>
Based on Jianxun's ("iris: don't get format bits in AUX tables").
With gfx12.5+, the compression format is once again coming from the
surface state programming. MTL once again uses an aux-map, but it
ignores the format bits within the the aux-map metadata.
Ref: Bspec 44930: "Compression format from AUX page walk is ignored.
Instead compression format from Surface State is used."
gfx12.5+ also uses tile-4 rather than y-tiling, so if we don't see
y-tiling, we can return 0 from intel_aux_map_format_bits() for the
ignored format bits.
Rework:
* Just return 0 if not using y-tiling as suggested by Nanley.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jianxun Zhang <jianxun.zhang@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20322>
Direct leak of 3912 byte(s) in 2 object(s) allocated from:
#0 0x7fbd4641b0 in __interceptor_malloc (/usr/lib64/libasan.so.6+0xa41b0)
#1 0x7f74413518 in parse_and_validate_cache_item ../src/util/disk_cache_os.c:549
#2 0x7f74414b84 in disk_cache_load_item ../src/util/disk_cache_os.c:599
#3 0x7f74410364 in disk_cache_get ../src/util/disk_cache.c:551
#4 0x7f775695ac in panfrost_disk_cache_retrieve ../src/gallium/drivers/panfrost/pan_disk_cache.c:125
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20336>
A bit count of es_accepted works for both when ngg is and isn't
dynamically enabled. Unlike the other sequence, this should only be a
single SALU instruction.
fossil-db (gfx1100, nggc):
Totals from 41388 (30.75% of 134574) affected shaders:
Instrs: 25783544 -> 25432959 (-1.36%); split: -1.36%, +0.00%
CodeSize: 127281160 -> 125878820 (-1.10%); split: -1.10%, +0.00%
Latency: 92849566 -> 92723047 (-0.14%); split: -0.14%, +0.00%
InvThroughput: 9542194 -> 9485012 (-0.60%); split: -0.60%, +0.00%
Copies: 2031074 -> 1928796 (-5.04%); split: -5.04%, +0.00%
Branches: 642407 -> 642409 (+0.00%)
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20321>
This replaces brw_fs_get_dispatch_enables(), which was added in
b9403b1c47 ("intel: factor out dispatch PS enabling logic"), but this
function will not work well for future changes to 3DSTATE_PS.
So, instead, this moves the related code into a "genX" file which can
directly update 3DSTATE_PS for the given platform.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20329>
Some GPUs are able to render more efficiently when all channels of a
color attachment are written, since whole pixels are being overwritten,
rather than hitting a read-modify-write cycle where newly written data
has to be combined with existing unmodified image data.
When faking GL_RGB as RGBA (in case RGB/RGBX isn't color renderable),
we introduce an extra channel that doesn't exist from the application
point of view. With such a format, a color mask of 0x7 (RGB) would mean
to write all channels. But because we've added an alpha channel behind
their back, this becomes a partial write. We are free to write whatever
garbage we want to the alpha channel, however. So we can enable alpha
writes, making this a more efficient full pixel write again.
This is done unconditionally as it's expected to address a problem
common to many drivers and isn't expected to be harmful, even on GPUs
where it may not help much.
Improves WebGL Aquarium performance on Alderlake GT1 by around 2.4x, in
the Chromium, using Wayland (the --enable-features=UseOzonePlatform and
--ozone-platform=wayland flags).
v2: Don't require PIPE_CAP_RGB_OVERRIDE_DST_ALPHA_BLEND (Marek)
v3: Fix independent blending enables (Emma) - now set when needed,
skipped when not needed, and PIPE_CAP_INDEP_BLEND_ENABLE is no
longer a requirement. We just optimize where we can.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7864
Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
Reviewed-by: Marek Olšák <marek.olsak@amd.com> [v2]
Reviewed-by: Emma Anholt <emma@anholt.net> [v3]
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20290>
While all Panfrost-supported Mali GPUs support all the compressed texture
formats architecturally, the system integrator decides which formats will
actually be wired up in the production system-on-chip. In the past there may
have been legal considerations, I'm neither a lawyer nor a system integrator so
couldn't say.
It's useful for users to know which compressed texture formats are supported by
their hardware, to understand its performance characteristics (and perhaps to
buy systems that support their needs, especially if they need BCn formats which
are omitted in many Mali implementations).
To help with that, this commit adds a small standalone tool that prints which
formats are supported. It is tested so far on Mali-T860 and Mali-G57.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Tested-by: Chris Healy <healych@amazon.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20086>
This removes the ALU-only restriction on the "weak" GVN introduced by
the previous commit. This makes it slightly more aggressive, allowing
it to coalesce things like UBO loads (still within sister then/else
blocks). This also can have surprisingly large cascading effects.
I was concerned that this might increase register pressure, but
shader-db and fossil-db show effectively no change in spills/fills,
so it seems to be fine.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19823>
Full global value numbering (GVN) can be pretty aggressive, moving
values far away from their original locations, even out of loops,
and can extend their live ranges a lot. So we've left it disabled.
This patch introduces a weaker form of GVN: we only allow coalescing
identical values when they appear on either side of the same if/else
construct. For now, we also only allow ALU instructions.
This allows nir_opt_gcm to clean up identical instructions appearing
on both sides of if/then/else control flow. But it avoids aggressively
combining every other occurrence of a value in the program.
This can still have surprisingly large cascading effects, as simple
constructs are cleaned up, leading to more opportunities to do the
same clean up, up a chain of nested ifs. It also enables greater use
of the select peephole as ifs are cleaned up.
shader-db and fossil-db results show a reduction in spills/fills on
Icelake, so it doesn't seem to be hurting register pressure.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19823>
There are only a few places in the code where num_relocs gets set:
- During anv_reloc_list_init() where it gets memset() to 0.
- At anv_reloc_list_init_clone() where it gets set with the value of
another anv_reloc_list->num_relocs.
- During anv_reloc_list_clear(), where it gets set to 0.
- During anv_reloc_list_append(), where it gets added with the value
of another anv_reloc_list->num_relocs.
As you can see, either we explicitly set the value to 0 or we copy the
value that's present in another anv_reloc_list, which should be 0. The
one place where we used to increment num_relocs was in
anv_reloc_list_add(), but that was deleted by:
7b7381e8d7 ("anv: Delete anv_reloc_list_add()")
So in this commit we delete the num_relocs field from struct
anv_reloc_list and we also delete some lines where, if the value is 0,
nothing will happen.
There's more we could be deleting here, but I wanted this commit to be
minimal so it's very clear that num_relocs can't be non-zero. We were
having some speculation that anv_reloc_list may still be important for
actually adding BOs to the batch and building the validation list, so
let's go slowly with the removal to make everything more easily
reviewable.
The one possibility I could be missing here is another situation like
the memset() we have at anv_reloc_list_init() or some other crazy
indirect overwrite, but as far as I have checked, that is not the
case.
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20309>
gitlab-runner reuses containers, and since we don't pull git, the working
directory doesn't get cleaned automatically. You don't want to have stale
files from previous builds, particularly if someone's testing changes of
build options that might disable a driver.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20302>
With the introduction of locks around the XCB polling mechanism,
a possible deadlock was introduced.
If all 5 images were rapidly acquired and presented before the
FIFO thread had the chance to submit a present,
we would deadlock.
Before the lock however, it was still buggy since the two threads would
race to poll events and update internal state.
The fix is to just ensure that there are pending presentation requests
in flight, so that forward progress is guaranteed before we take the
poll lock.
Also, use a timedlock for acquire next image.
Similar as WaitForPresentKHR.
Also need to make the busy flag atomic to actually allow acquire thread
and present threads to access the busy flag.
Take advantage of busy flag being atomic so that we can gracefully handle
timeout == 0 scenarios where there actually are images available.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Fixes: 8fc7927787 ("wsi/x11: Implement VK_KHR_present_wait on X11.)
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19990>
We were calling iris_resource_texture_aux_usage here, which disables
auxiliary support if color happens to already be resolved. This makes
sense for read only images, where if we know ahead of time that aux
doesn't contain any useful information, we can just tell the hardware
to not bother looking at it. However, it makes no sense for mutable
images, as even if the aux currently has no useful data, we want to
produce that data when doing our image writes.
Import the bits of logic we need from there and shed the rest. We don't
need to consider HiZ, MCS, or MC, nor do we need to do format-based
CCS compatibility checks on Gfx12+, so it's actually very little code.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19060>
While I haven't found documentation saying definitively that HDC
supports fast clear blocks, it seems to work just fine, even on
Tigerlake. I have found several issues (atomics and HDC support
for linear compression) that both call out fast clears as an issue
in those corner cases, which suggests that fast clears do actually
work outside of those corners (which we already disable).
The previous commit implemented actual aux state updates for image
views. With ISL_AUX_USAGE_GFX12_CCS_E, this means that we update
the aux state to COMPRESSED_CLEAR after writes. But because we
weren't supporting fast clears, this meant that any such images
would need partial resolves to remove the clear color on next use.
Supporting fast clears allows us to drop all these resolves.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19060>
On Tigerlake and later, we enable compression for image views. However,
we never actually added any code to update the aux state, which meant
that if it ever changed, things would break, badly.
We managed to avoid catastrophic effects in most cases because of
two other issues which papered over the problem: if compression wasn't
already enabled for an image, we'd leave it disabled. And, we avoided
writing via the CPU to buffers with auxiliary. So in most cases, CCS
remained disabled, or got enabled (say by glTexImage()) then stayed on
permanently. There were still issues, but they managed to remain more
hidden than one would expect given the severity of the bug.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19060>
The goal here is to support OpenGL 4.6 section 9.3, "Feedback Loops
Between Textures and the Framebuffer" (from GL_ARB_texture_barrier)
where you can bind an image as both a framebuffer attachment and a
texture, and simultaneously sample-from and render-to it.
I'm not aware of any spec language that requires us to handle
simultaneously accessing something as a framebuffer attachment and an
image load/store resource. GL_ARB_shader_image_load_store tends to
make flushing and synchronization something the app has to handle
explicitly rather than something the driver needs to do implicitly.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19060>
Every time I see this function I think it's part of isl. But it's not,
it's just a static function in an iris file. The point of the name was
that the function checks two isl_format enums...but the prefix is just
confusing. Just drop the prefix as it's a static function.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19060>
Images with the RC_CCS modifier store the clear color in a separate BO,
which we also need to pin when using an image view.
Most images store the clear color in the same BO so it works anyway.
Thanks to Nanley Chery for catching this!
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19060>
There are a lot of optimizations in opt_algebraic that match ('ine', a,
0), but there are almost none that match i2b. Instead of adding a huge
pile of additional patterns (including variations that include both ine
and i2b), always lower i2b to a != 0.
At this point in the series, it should be impossible for anything to
generate i2b, so there /should not/ be any changes.
The failing test on d3d12 is a pre-existing bug that is triggered by
this change. I talked to Jesse about it, and, after some analysis, he
suggested just adding it to the list of known failures.
v2: Don't rematerialize i2b instructions in dxil_nir_lower_x2b.
v3: Don't rematerialize i2b instructions in zink_nir_algebraic.py.
v4: Fix zink-on-TGL CI failures by calling nir_opt_algebraic after
nir_lower_doubles makes progress. The latter can generate b2i
instructions, but nir_lower_int64 can't handle them (anymore).
v5: Add back most of the hunk at line 2125 of nir_opt_algebraic.py. I
had accidentally removed the f2b(bf2(x)) optimization.
v6: Just eliminate the i2b instruction.
v7: Remove missed i2b32 in midgard_compile.c. Remove (now unused)
emit_alu_i2orf2_b1 function from sfn_instr_alu.cpp. Previously this
function was still used. 🤷
No shader-db changes on any Intel platform.
All Intel platforms had similar results. (Ice Lake shown)
Instructions in all programs: 141165875 -> 141165873 (-0.0%)
Instructions helped: 2
Cycles in all programs: 9098956382 -> 9098956350 (-0.0%)
Cycles helped: 2
The two Vulkan shaders are helped because of the "new" (('b2i32',
('ine', ('ubfe', a, b, 1), 0)), ('ubfe', a, b, 1)) algebraic pattern.
Acked-by: Jesse Natalie <jenatali@microsoft.com> [earlier version]
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Tested-by: Daniel Schürmann <daniel@schuermann.dev> [earlier version]
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15121>
The shaders affected here are ones that were previously affected when
i2b was unconditionally lowered in opt_algebraic. There are a few places
where some transformations happen in a different order, so some
algebraic patterns are missed.
All Broadwell and newer Intel platforms had similar results. (Ice Lake shown)
total instructions in shared programs: 19914369 -> 19914566 (<.01%)
instructions in affected programs: 92375 -> 92572 (0.21%)
helped: 0 / HURT: 90
total cycles in shared programs: 853851470 -> 853867215 (<.01%)
cycles in affected programs: 12400663 -> 12416408 (0.13%)
helped: 28 / HURT: 69
Haswell and Ivy Bridge had similar results. (Haswell shown)
total instructions in shared programs: 16710721 -> 16710700 (<.01%)
instructions in affected programs: 108010 -> 107989 (-0.02%)
helped: 57 / HURT: 103
total cycles in shared programs: 884299412 -> 884306546 (<.01%)
cycles in affected programs: 12986423 -> 12993557 (0.05%)
helped: 87 / HURT: 102
total spills in shared programs: 14937 -> 14925 (-0.08%)
spills in affected programs: 12 -> 0
helped: 9 / HURT: 0
total fills in shared programs: 17569 -> 17557 (-0.07%)
fills in affected programs: 12 -> 0
helped: 9 / HURT: 0
Sandy Bridge
total instructions in shared programs: 13902341 -> 13902347 (<.01%)
instructions in affected programs: 7311 -> 7317 (0.08%)
helped: 3 / HURT: 8
total cycles in shared programs: 741795500 -> 741792266 (<.01%)
cycles in affected programs: 273308 -> 270074 (-1.18%)
helped: 9 / HURT: 2
No shader-db changes on any other Intel platform.
No fossil-db changes on any Intel platform.
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15121>
In a future commit, nit_type_conversion_op won't be able to handle i2b
(and in a much later commit f2b), so switch many users to the fully
featured function.
No shader-db or fossil-db changes on any Intel platform.
v2: Use the actual bit size of the source to determine the conversion
op. With mediump, the "planned" bit size and the actual bit size might
be different. Fixes many, many Vulkan CTS assertion failures on any
platform that sets mediump_16bit_alu (e.g., Freedreno).
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> [v1]
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15121>
In a future commit, nit_type_conversion_op won't be able to handle i2b
(and in a much later commit f2b), so switch many users to the fully
featured function.
In gl_nir_lower_packed_varyings, all of the type conversions are between
int32 and uint32 types. In NIR, those are just moves, so elide them.
No shader-db or fossil-db changes on any Intel platform.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15121>
Previously these would return result->bit_size of 32 even though the
type might have been int16_t or uint16_t. This prevents many assertion
failures in "glsl: Use nir_type_convert instead of
nir_type_conversion_op" on zink.
Fixes: 5e922fbc16 ("glsl_to_nir: fix bitfield_extract with 16-bit operands")
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15121>
It is invalid to have Boolean variables as either shader inputs or
outputs, so there is no point to try to lower them in general. The only
use for this was some two-phase lowering of
nir_intrinsic_load_front_face that could be done in a single phase.
Create the SYSTEM_VALUE_FRONT_FACE as a uint and compare it with zero at
the same time.
No shader-db or fossil-db changes on any Intel platform.
v2: Remove dxil_nir_lower_bool_input from dxil_nir.h and drop it from
the other caller in the spirv_to_dxil codepath. Noticed by Jesse. Fix
setting bit size when loading SYSTEM_VALUE_FRONT_FACE. Caught by CI.
v3: Use nir_ine_imm. Change type of gl_FrontFacing GS output in
d3d12_nir_passes from Boolean to integer. Both suggested by Jesse.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15121>
There are a lot of optimizations in opt_algebraic that match ('ine', a,
0), but there are almost none that match i2b. Instead of adding a huge
pile of additional patterns (including variation that include both ine
and i2b), just emit a != 0 instead of i2b(a).
I think that the changes to the unit tests weaken them slightly, but
perhaps that's okay?
No shader-db changes on any Intel platform. The GLSL paths use other
means to generate i2b operations, but the SPIR-V paths use nir_i2b.
Presumably since 4676b3d3dd (nir: Use nir_test_mask instead of
i2b(iand)), no fossil-db changes either.
v2: Use nir_ine_imm. Suggested by Jesse.
Acked-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Tested-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15121>
v2: Remove the ineg from the b2i in the ior pattern. Suggested by
Jason.
All Ivy Bridge and newer Intel platforms had similar results. (Ice Lake shown)
total instructions in shared programs: 19914441 -> 19914369 (<.01%)
instructions in affected programs: 63507 -> 63435 (-0.11%)
helped: 24 / HURT: 0
total cycles in shared programs: 853869766 -> 853851470 (<.01%)
cycles in affected programs: 10551542 -> 10533246 (-0.17%)
helped: 24 / HURT: 0
All Intel platforms had similar results. (Ice Lake shown)
Instructions in all programs: 141163061 -> 141092683 (-0.0%)
Instructions helped: 14103
Instructions hurt: 55
Cycles in all programs: 9132376195 -> 9133183045 (+0.0%)
Cycles helped: 13775
Cycles hurt: 380
Spills in all programs: 18286 -> 18284 (-0.0%)
Spills helped: 1
Fills in all programs: 30647 -> 30643 (-0.0%)
Fills helped: 1
Gained: 133
Lost: 130
Acked-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Tested-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15121>
This helps because it enables cmod propagation to do more.
The removed patterns involving b2i will be handled by other existing
patterns after the unary operations are removed.
All Intel platforms had similar results. (Ice Lake shown)
total instructions in shared programs: 19914458 -> 19914441 (<.01%)
instructions in affected programs: 5456 -> 5439 (-0.31%)
helped: 17 / HURT: 0
total cycles in shared programs: 855302118 -> 853869766 (-0.17%)
cycles in affected programs: 327354347 -> 325921995 (-0.44%)
helped: 291 / HURT: 81
All Intel platforms had similar results. (Ice Lake shown)
Instructions in all programs: 141205979 -> 141205961 (-0.0%)
Instructions helped: 4
Instructions hurt: 3
SENDs in all programs: 7466919 -> 7466913 (-0.0%)
SENDs helped: 1
Cycles in all programs: 9133387327 -> 9133384475 (-0.0%)
Cycles helped: 3
Cycles hurt: 12
In the shader that was helped for sends, it appears that a NIR pass that
moves code out of loops was able to move 3 send operations outside a
loop after this change. I did not investigate further.
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Acked-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Tested-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15121>
This prevents ~400 shader-db regresssions and a handful of fossil-db
regressions after i2b is always lowered.
All Ivy Bridge and newer Intel platforms had similar results. (Ice Lake shown)
total cycles in shared programs: 855301494 -> 855302118 (<.01%)
cycles in affected programs: 52787 -> 53411 (1.18%)
helped: 4 / HURT: 5
All Intel platforms had similar results. (Ice Lake shown)
Instructions in all programs: 141206055 -> 141205979 (-0.0%)
Instructions helped: 14
Cycles in all programs: 9133376616 -> 9133387327 (+0.0%)
Cycles helped: 13
Cycles hurt: 3
Acked-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Tested-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15121>
No shader-db changes on any Intel platform.
All of the helped shaders were presumably regressed by 4676b3d3dd (nir:
Use nir_test_mask instead of i2b(iand)).
v2: Add some comments explaining why specific replacements are used. In
the umin pattern, only markup the first usage of 'b' in the source
pattern.
Tiger Lake, Ice Lake, and Skylake had similar results. (Ice Lake shown)
Instructions in all programs: 141384970 -> 141200966 (-0.1%)
Instructions helped: 45842
Cycles in all programs: 9133648977 -> 9133282672 (-0.0%)
Cycles helped: 26812
Cycles hurt: 6025
Gained: 23
Lost: 135
Acked-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Tested-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15121>
A later commit adds a pattern
(('umin', ('iand', a, '#b(is_pos_power_of_two)'),
('iand', c, '#b(is_pos_power_of_two)')),
('iand', ('iand', a, b), ('iand', c, b))),
When I originally made that pattern, I copied and pasted the search to
the replacement as
(('umin', ('iand', a, '#b(is_pos_power_of_two)'),
('iand', c, '#b(is_pos_power_of_two)')),
('iand', ('iand', a, '#b(is_pos_power_of_two)'),
('iand', c, '#b(is_pos_power_of_two)'))),
The caused the variables in the replacement to be marked is_constant,
and that resulted in an assertion failure deep inside nir_search.
src/compiler/nir/nir_search.c:530: construct_value: Assertion `!var->is_constant' failed.
These extra validation rules catch this kind of error at compile time
rather than at run time.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Acked-by: Jesse Natalie <jenatali@microsoft.com>
Tested-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15121>
Gen11 added a nifty feature where we have three custom system-generated
values called extended parameters that we can set to any 32-bit values
we want. These work just like vertex and instance ID and are controlled
in the pipeline by the 3DSTATE_SGVS_2 packet. They are provided to the
draw call either by extra DWORDs on the end of 3DSTATE_PRIMITIVE or by
storing values to more state registers.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20295>
On Gen11 and above, the 3DPRIMITIVE command takes an optional additional
three DWORDs of data as "extended parameters". These extended
parameters only exist in the packet if "Extended Parameters Present" is
set. Because our packing code doesn't handle variable-length commands
well, this commit adds a second version of the command which isn't real
but is just a copy of 3DPRIMITIVE with the additional dwords where the
"Extended Parameters Present" defaults to true and "DWord Length" is
adjusted by 3 as needed. The 3DPRIMITIVE command is then the gen4-9
version which still works fine but doesn't have the new parameters.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20295>
1. Old approach did not support unbind (set to NULL) samplers because
it only copied memory if sampler is not empty. New approach checks
if sampler is empty - it will set NULL.
2. Old approach just set sampler_count to 0 if sampler is empty.
That's wrong and we need to find highest non-null samplers[] entry.
It was done in new approach.
3. Gallium dosc says:
```
NOTE: at this time, start is always zero ...
This may change in the future.
```
It's better to take into consideration start parameter in new approach.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20285>
- yuv422 decode was blocked in 12acee17fa, enable it back.
- nv12 yuv422 and grayscale decode is supported on all versions.
- JPEG2 and higher versions supports 444p decode.
- add l8_unorm to supported formats, can be used for grayscale.
Fixes: 12acee17fa (frontends/va: reallocate surface for yuv400/yuv444 picture)
v2: indent the switch case correctly (Thong Thai)
Signed-off-by: Sathishkumar S <sathishkumar.sundararaju@amd.com>
Reviewed-by: Thong Thai <thong.thai@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20165>
I did not properly understood that we cannot access the views written
to the descriptor sets because they might have been destroyed after
the write operation and the copy operation is allowed to copy what is
invalid data. The shader just can't access it.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 03e1e19246 ("anv: Refactor descriptor copy")
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20222>
To be shared by NGG GS and legacy GS. Legacy GS need this when
GFX10 which mix use NGG and legacy GS. For example when streamout
is enabled, it uses legacy GS, otherwise uses NGG GS. So legacy
GS also need to update query emulation which is a sum of NGG and
legacy GS results.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20158>
Based on f129db911b ("radeonsi/gfx11: use a better workaround for the export conflict bug")
which claims better performance.
I couldn't be bothered to do the refactor to check the sample count with
dynamic sample counts, so this is just conservative there.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20273>
This can just be computed where it's used.
Now the non-glDraw paths like glRasterPos, glBegin/End, and the slow
display list path have to save and restore _VPModeInputFilter, which
is the only field that's different from the glDraw* path.
_VPModeInputFilter is a bitmask of VP inputs that might have to be bound.
The only difference with glBegin/End and the slow display list path is
that they also add VERT_BIT_MAT_ALL to the bitmask, whereas the glDraw* path
doesn't have that.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19953>
This removes setting _DrawVAO from all glDraw* functions that draw
primitives because now _DrawVAO is always equal to the current VAO.
glEnd, glRasterPos, and the slow display list path now have to save
_DrawVAO before changing it, and restore it after they are done.
This also removes _EmptyVAO, which becomes unused because we no longer
bind "no VAO" into _DrawVAO.
Rules:
- only glBindVertexArray and non-glDraw* paths should call
_mesa_set_draw_vao, other places shouldn't
- only draws should call _mesa_update_vao_state, other places shouldn't
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19953>
Drivers implementing descriptor buffers will want to allocate and free
descriptors with the layout for embedded samplers, so we need a hook to
allow them to free any GPU buffers.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19849>
With descriptor buffers, we have no way to know how big the descriptor
set actually is, so we have no idea how many constants we can safely
push. If we use a UBO then it will still get pushed, because we normally
assume that we can freely access UBOs without any fear of faults due to
the range checking. This does the easiest thing of using raw pointer
loads, although performance will fall off a cliff, because we don't have
many better options.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19849>
The immediate offset is in units of bytes, whereas the register offset
is in dwords. We need to compensate for that.
Also, fix an off-by-one when checking the range - the offset field is 13
bits, but the sign bit means we can only represent up to 1 << 12 in
bytes or 1 << 10 in dwords.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19849>
All of the full runtime+compiler stacks reassign these driver_location
values to compact them and sort between shader stages, but for the
spirv2dxil tool, we leave the original shader's "location" intact. That
means that there can be holes in the driver_location space, and simply
counting how many inputs there are can lead to collisions. So instead
place all sysvals after the last-used driver_location.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7811
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20253>
FS inputs are not directly loaded into regs, but require additional
instruction to do so. So in order to print in which reg the input
is loaded we have to scan the shader for the instruction
which loads the input.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20247>
The previous check assumed the stack starts at offset=0, which isn't
necessarily true for ray queries.
Note that this didn't cause correctness issues, just made an optimization
not apply. Found when I accidentally made this load-bearing in a
refactor.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20265>
Instead of calling like this:
st_draw_gallium -> cso_draw_vbo -> driver_draw_vbo
Do it like this:
st_draw_gallium -> driver_draw_vbo
OR
st_draw_gallium -> u_vbuf_draw_vbo
It's accomplished by adding a draw_vbo function pointer into cso_context.
The pointer is equal to pipe_context::draw_vbo when needed, so there is
no call overhead from this if cso's draw_vbo callback is indeed equal to
driver_draw_vbo. We just call cso_context_base::draw_vbo to jump into
the driver directly, or u_vbuf if needed.
The cso function with the indirect function call is inlined, so draws
don't actually visit any cso_context function.
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20025>
While the hardware supports both counter and boolean occlusion queries, the
programming model is quite different from OpenGL. In AGX (and in Metal),
there is a single "visibility result buffer" associated with the render pass.
Each draw that uses occlusion queries writes into this render pass global
visibility result buffer at a particular index. By contrast, the OpenGL
occlusion query model supposes that each query has independent state that can be
mixed and matched within a render pass. We can't simply allocate backing memory
for a query and write to it from a job. We can't allocate visibility result
buffers for each batch up front and statically assign OpenGL queries to indices,
because the OpenGL query can span multiple batches. Finally we can't use a
global visibility result buffer without introducing additional synchronization,
given that we now support multiple batches in-flight at once.
In this patch, I've elected to use a simple solution: allocate visibility result
buffers and indices on the fly as needed, and accumulate the results on the CPU
at the end of the render pass. When we have proper synchronization we'll want to
revisit this, but as everything is stalling at submit time now, I'm not inclined
to "optimize" something I can't test.
Passes dEQP-GLES3.functional.occlusion_query.* and the relevant piglit tests.
The piglits are considerably more thorough, checking lots of "we hate tilers"
conditions that dEQP skips over.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20123>
First remove agx_shader_key from asahi_shader_key. It's trivial. agx_shader_key
is going to go away soon now that we lower everything in NIR.
Then everything else is mutually exclusive between stages. That means much
less to hash. drawoverhead test 1 from 2331 to 3443.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20123>
From Panfrost. This lets us avoid storing depth/stencil attachments at the end
of the frame in GLES.
On my 4K monitor, glmark2 -btexture at fullscreen goes from 705fps to 1150fps. I
assume gains on real workloads will be smaller.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20123>
Unusual hardware features that require special hanlding usually get a
devinfo field, so do this for MTL's unordered DF types. This will
guarantee that any platform based on MTL (thus inheriting from
MTL_FEATURES) will automatically be handled in these special cases.
v2: s/has_unordered_64bit_float/has_64bit_float_via_math_pipe/ (Curro).
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20072>
In the previous patch we adjusted the scoreboard pass to take into
consideration a new case of unordered operations for TGL. Fix the
decoding as well.
v2: use intel_device_info_is_mtl() (Curro, Jordan)
v3: the part where we export num_sources_from_inst() is now a separate patch
(Curro).
v4: Work around false positive maybe-unitialized warning since Marge
uses -Werror=maybe-uninitialized (Marge).
Reviewed-by: Francisco Jerez <currojerez@riseup.net> (v3)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20072>
On MTL, instructions with DF type are unordered, executed in the math
pipe. This means that they require different SWSB dependency handling,
and also that in some cases such as MOVs it's generally faster to
simply use 2 smaller ordered moves than a single unordered MOV.
One problem we have with the current code is that generate_code() is
not setting the proper SWSB dependencies for the generated DF MOVs,
causing some tests to fail.
One solution would be to fix generate_code() by making it set the
appropriate dependencies. This was the first patch I wrote. Another
solution to this problem, pointed to us by Curro, is to change
required_exec_type() so we use UD instructions instead of DF, just
like we do with platforms that don't have 64 bit instructions, which
means there won't be anything to fix in generate_code(). The second
solution is what this patch implements.
This fixes at least:
- dEQP-VK.subgroups.arithmetic.framebuffer.subgroupmin_double_vertex
Thanks to Francisco Jerez for all the major help provided with this
problem.
Credits-to: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20072>
When we use this form there's no way to specify which pipe RegDist
refers to, so there are a few rules to figure this out, which is what
inferred_sync_pipe() implements. But for MTL there's no long pipe and
the documentation does not explicitly explain what should be the
inferred type for its long (DF) instructions - which are out-of-order,
by the way. One way to interpret this is that such case should be
avoided. So add the extra check to entirely avoid this case.
Notice that this is not actually fixing any bug, since returning
TGL_PIPE_LONG (what we do today) will actually make these DF
instructions incompatible with every in-order instruction, so we'll
never opt to use the (RegDist, SBID) form anyway. But still, it's
better to have this case explicitly documented instead of having it
covered by a semi coincidence.
v2: use intel_device_info_is_mtl() (Curro, Jordan)
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20072>
Adjust the scoreboard code to take that into account.
Fixes at least:
- dEQP-VK.glsl.builtin.precision_double.refract.compute.vec3
- dEQP-VK.glsl.builtin.precision_double.matrixcompmult.compute.mat4
v2: use intel_device_info_is_mtl() (Curro, Jordan)
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20072>
Fix all_mrt_write_mask when independent_blend_enable is false.
Otherwise, lrz write is always diabled with MRT when
independent_blend_enable is false. This fixes a 2% perf regression for
multiple gfxbench benchmarks.
Fixes: 0132c22de7 ("freedreno/a6xx: Don't disable LRZ for invalid channels")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20254>
We were promoting reads with a valid primary to direct CPU maps even
if the mmap mode was IRIS_MMAP_WC, which would mean uncached reads from
VRAM. In that case, GPU blits are in fact useful!
We were also only checking for !DISCARD_RANGE rather than MAP_READ,
which isn't a great idea for image maps, given the discussion in the
previous commit about image map semantics.
The original code was also just confusingly structured. Make a helper
function with clearly defined cases where we want to bail on CPU maps.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19209>
When performing transfer maps on images that require staging buffers
(say, for presenting a linear view of tiled memory), we were reading
the existing contents of the buffer into the staging resource on map
unless PIPE_MAP_DISCARD_RANGE was set.
The thinking was to support partial writes. If you map a subrectangle
of an image, but then only write selective pixels - should it preserve
the existing contents of the mapped region? I believed that it should,
unless you pass PIPE_MAP_DISCARD_RANGE to explicitly say that that it's
okay to invalidate the destination region.
However, that does not appear to be the interpretation favored by other
Mesa developers (in particular Michel Dänzer and Marek Olšák). The
radeonsi driver does not do this readback from the destination region
to the staging buffer unless you pass PIPE_MAP_READ. If you want to
do a partial write and preserve contents, you need to pass both flags:
(PIPE_MAP_READ | PIPE_MAP_WRITE). Passing READ is expected to come
with an associated cost.
OpenGL defines GL_MAP_INVALIDATE_RANGE_BIT for mapping buffer objects,
which is translated to PIPE_MAP_DISCARD_RANGE. However, unextended
OpenGL doesn't define mapping textures. There are two main sources of
image maps: our internal MapTextureImage() hook, and gbm_bo_map().
I've audited our internal MapTextureImage() calls, and while some do
pass PIPE_MAP_DISCARD_RANGE, almost all of them wholly overwrite the
mapped region, and those that care about combining with existing image
contents all pass PIPE_MAP_READ. So this should work there.
GBM defines three flags: GBM_BO_TRANSFER_READ, WRITE, and READ_WRITE.
There is no defined "invalidate range" bit. In issue #6020, Matthias
Treydte notes that this extra readback can cause performance problems,
and with iris's current interpretation, there's no way to avoid it.
During that discussion, Michel and Matthias both argued that
GBM_BO_TRANSFER_WRITE should invalidate the destination contents and
avoid the readback, while GBM_BO_TRANSFER_READ_WRITE would preserve it.
This patch makes iris follow that model for image mappings, removing
readback on staging maps for both detiling and stall avoidance, unless
PIPE_MAP_READ is passed. I believe we can change this with impunity.
For buffer objects, Ian Romanick and I both agree that partial writes
should be supported, and GL_MAP_INVALIDATE_RANGE_BIT exists precisely
to indicate that you should spend effort preserving existing contents.
So we continue doing readback for buffers unless PIPE_MAP_DISCARD_RANGE
is flagged, for now. While I think this is work, it also seems to be
undertested in the CTS and Piglit.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6020
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19209>
problem:
when doing "gst-launch-1.0 -v videotestsrc num-buffer=10 !
vaapih264enc ! fakeink"
The command will fail due to gst will fetch the first
available supported format in the list, it becomes P010_LE
due to the commit in
[0b02db3007]
frontends/va: fixed av1 decoding 10bit ffmpeg output YUV issue
fix:
move the P010_LE code block to the end of the function, the sequence
of the supported formats restored to its original.
cc: mesa-stable
Reviewed-by: Boyuan Zhang <Boyuan.Zhang@amd.com>
Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20242>
Also rename:
iface -> drawable
stfb -> drawable (where it means dri_drawable and not st_framebuffer)
stfbi -> drawable or pdrawable (if drawable exists)
pipe_frontend_drawable* is really just dri_drawable* for DRI, and WGL/GLX
have their own variants. This makes it easier to understand what kind of
object is being used.
I always wondered what st_framebuffer_iface, iface, stfbi, iface_stamp,
and iface_ID actually mean. Now those terms are gone forever.
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20027>
This used to not matter, but since we started emitting shader-temps
properly, this causes issues where we end up with samplers and images as
shader-temps. That causes asserts while emitting them.
So let's remove the unused vars as well.
This fixes a piglit regression that somehow went unnoticed on CI.
Fixes: 85964945e7 ("zink: emit vars with nir_var_shader_temp mode")
Tested-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20227>
This will result in us using the TXF_CMS_W message rather than the
TXF_CMS message on Skylake through Tigerlake for 2/4/8x MSAA blits,
which is technically slightly worse. However, it shouldn't be that
much worse: the TXF_CMS message was removed altogether on Alchemist.
iris and anv set key->msaa_16 unconditionally, to avoid paying the
cost of shader recompiles for a miniscule gain. crocus and hasvk
don't need to set it as they don't support 16x MSAA. BLORP already
recompiles based on the sample count, so it could easily keep doing
this for the minor benefit. But avoiding it will let us drop the
entire msaa_16 key field out of the compiler, which is nice.
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20223>
The compiler looks at this key field to determine whether to perform
an MCS fetch for a txf_ms or samples_identical texture message, if a
nir_tex_src_ms_mcs_intel source wasn't provided. If it isn't set,
it instead uses constant 0 (nothing is compressed).
All of the drivers (iris, crocus, anv, hasvk) unconditionally set this
to ~0 because we don't want to pay for costly shader recompiles (which
can cause nasty stuttering). Most textures are compressed anyway, and
the hardware ignores the l2dms MCS parameter if MCS is disabled.
The only user was BLORP, which sets the key field based on whether the
texture's aux usage has MCS. But if it has MCS, it also does the MCS
fetch itself and supplies it directly. Otherwise, it relies on the
compiler to fill in the 0 value. But it could easily just provide the
0 value itself in that case and not rely on the compiler at all.
With that fixed, we can just drop the key fields entirely. We leave
them as padding for now to avoid repacking structures; we won't need
to after the next commits anyway.
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20223>
Texcoords may be 1-5 components in length. We initialize the
unused components with an LLVMGetUndef(). But we were using
an int vec type rather than a float vec type.
This eventually led to a failed assertion in lp_build_clamp()
where 'a' was a vec of int[8] but 'min' and 'max' were float[8]
in a trace of the game Tom Clancy's Splinter Cell: Blacklist.
The game seems to have a bug where a texture sampler mistakenly has
shadow comparison turned on, but the shader's tex sample instructions
are sampling a 2D R8G8B8A8_UNORM texture. The instruction has a
2-component texcoord so when we do the sampler comparison operation
we're using the undefined 5th coordinate component.
Signed-off-by: Brian Paul <brianp@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20233>
The hardware requires depth/stencil attachments to be size-aligned to
the zls tile size (as defined by rogue_get_zls_tile_size_xy()).
In practice however, this is a tiny edge case. The restriction only
applies during some operations, and any attachment larger than the tile
size will be twiddled and over-allocated into alignment beforehand.
This commit also adds the mentioned rogue_get_zls_tile_size_xy()
function. These values differ from the regular tile_size_{x,y} feature
values in some cases. Instead of including them as features as well, we
compute them directly.
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
Reviewed-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20160>
The use of std::optional simplifies expressions and would be useful for some
upcoming RA tweaks.
C++17 has been available since the merge of rusticl and should be safe to use as
far as packaging is concerned.
A few style choices are:
- Testing for emptiness uses implicit bool conversion.
- Constructing an empty value uses {}.
- Constructing a filled value uses the implicit conversion constructor.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20125>
This is trying to clear a bit in the control register. However, it's
executing with whatever channel mask happens to be active. Typically
this is the one at the start of the program, so at least some channels
will be active. Typically the first channel will be active due to
packed dispatch, but that's not always guaranteed. Without NoMask,
the float controls writes may randomly not happen.
Recent GPUs also seem to have a hang issue when the first instruction in
the shader doesn't have any active channels. Having an instruction with
NoMask at the start of the program works around the issue. See HSD bug
14017989577. In our case, the float controls preamble was breaking that
restriction every time, causing us to run into this problem frequently.
Thanks to Tapani Pälli for finding this hang issue, and Francisco
Jerez and Lionel Landwerlin for helping pinpoint this issue during
review of a workaround patch in !20194.
Fixes GPU hangs in Elder Scrolls Online, Witcher 3, and likely more.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7639
Fixes: 9da56ffc52 ("i965/fs: add emit_shader_float_controls_execution_mode() and aux functions")
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20214>
On the host we emit this as separate ops anyway, so avoid
wired optimizations in the guest that might introduce
difficult to optimize dependencies.
v2: update trace expectations - some minor accuracy changes
are to be expected when fma is handled differently
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20182>
It's not valid to be copying input variables to temps when
inlining atomic memory, interpolateAt functions, etc. We got away
with this previously because tree grafting would clean up the
mess but we shouldn't depend on an optimisation to clean up
invalid IR. Also I hope to remove tree grafting in a follow up
merge request.
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19890>
This allows us to drop some duplicate code that is already in the
ir_rvalue_visitor. It also allows us to better replace rvalues
and handle swizzle in the following patch without having to add
even more duplicate code.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19890>
In a tesselation control shader where an input array is accessed using
the index gl_InvocationID, we can end up accessing elements beyond the
number of input vertices specified in the shader key.
This happens because of the lowering in nir_lower_indirect_derefs().
This lowering will affect compact variables which happens in this
case :
in gl_PerVertex {
vec4 gl_Position;
float gl_ClipDistance[1];
} gl_in[gl_MaxPatchVertices];
The lowered code produced by NIR is somewhat ineffecient (implements a
binary seach) :
if (gl_InvocationID < 16) {
if (gl_InvocationID < 8) {
if (gl_InvocationID < 4) {
vec4 vals = load_at_offset(0);
value = bcsel(vals, gl_InvocationID);
} else {
vec4 vals = load_at_offset(4);
value = bcsel(vals, gl_InvocationID - 4);
}
} else {
if (gl_InvocationID < 12) {
vec4 vals = load_at_offset(8);
value = bcsel(vals, gl_InvocationID - 8);
} else {
vec4 vals = load_at_offset(12);
value = bcsel(vals, gl_InvocationID - 12);
}
}
} else {
if (gl_InvocationID < 24) {
...
} else {
...
}
}
By default the gl_MaxPatchVertices must be set at 32 items and that's
what the lowering code will use to divide the access into chunks of 4.
But when running with 3 input vertices, this means we'll pull one more
item than what was delivered in the shader payload.
This triggers issues further down the register scheduling where the
g5UD (register for the 4th item) is overwritten by a previous SEND,
leading the URB read to use an invalid handle.
This pass clamps any access load_per_vertex_input intrinsic vertex
indice to (input_vertices - 1).
Fixes issues with tests like :
dEQP-VK.clipping.user_defined.clip_distance.vert_tess.*
Also fixes a hang with zink/anv on :
KHR-GL46.draw_elements_base_vertex_tests.AEP_shader_stages
v2: Don't replace source register
v3: Implement in NIR
v4: Clamp per vertex array sizes in NIR (Jason)
v5: Move the clamping on the intel compiler
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9749>
While running VK-CTS with valgrind, the application hit the max
thread count of 500. After further investigation, this was due to
multiple instances being created with the disk cache spinning up
worker threads which wouldn't be cleaned as disk_cache_destroy
wasn't being called.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20178>
The `coord_offset` pass is responsible for upgrading any eligible
texture loads into prefetches, but a texture prefetch's capabilities
are limited and cannot handle any interpolation modes aside from
`smooth`.
An exception is carved out for `flat` interpolation modes, but this
doesn't exclude upgrading `noperspective` texture loads and results
in perspective-corrected samples being provided that can severely
break applications depending on this behaviour.
Fixes incorrect lighting projection on Super Mario Odyssey on
Skyline Emulator.
Fixes incorrect dirt texture mapping on Portal 2 trace on Turnip and
Zink on Turnip.
Fixes incorrect lighter shadowing on Half Life 2 trace on Turnip.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19842>
`coord_offset` is called on the source of `alu` instructions and
it returns -1 for failures, this not explicitly checked for and
as a result the fetch can incorrectly be upgraded to a prefetch
when it isn't appropriate to do so.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19842>
Otherwise, making a CS using the memory will use the uninitialized .map
value (when checking the size of the CS in in begin's tu_cs_is_empty()
check), causing valgrind noise in
dEQP-VK.binding_model.descriptorset_random.sets4.dynindexed.ubolimitlow.sbolimitlow.sampledimghigh.lowimgsingletex.iublimitlow.nouab.vert.noia.0
(thanks to vi_info->vertexBindingDescriptionCount==0).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20173>
Death stranding does scratch_arr[80-idx]. This doesn't seem to work if we
try to combine the subtraction into the access.
fossil-db (navi21):
Totals from 52 (0.04% of 135636) affected shaders:
Instrs: 78560 -> 79036 (+0.61%)
CodeSize: 427940 -> 431188 (+0.76%)
Latency: 1313809 -> 1318142 (+0.33%)
InvThroughput: 292833 -> 293842 (+0.34%)
VClause: 2361 -> 2555 (+8.22%); split: -0.51%, +8.73%
Copies: 8767 -> 8746 (-0.24%); split: -0.35%, +0.11%
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Fixes: 0e783d687a ("aco: use scratch_* for scratch load/store on GFX9+")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7735
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20117>
D3D10 established that rasterization should be discarded when a null PS was
bound, and depth/stencil state was disabled, and llvmpipe followed those
semantics. Nowadays all APIs have explicit rasterization discard flag,
and so does Gallium, so it's better for llvmpipe to faithfully follow
that flag, and trust the state tracker to follow the right semantics.
Second guessing pipe_rasterizer_state::rasterizer_discard actually
causes problems, specially when no depth-stencil surface is bound, as
D3D10 mandates rasterization should still happen, yet among all the
translation layers it often happens depth-stencil enablement is
optimized away when no depth-stencil is bound, which in turn was causing
llvmpipe to disable rasterization when it shouldn't.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20155>
When a null PS is bound, the
pipe_query_data_pipeline_statistics::ps_invocations counter should not
be incremented.
However llvmpipe can't cope with a null PS bound, requiring the state
tracker to bind an empty pixel shader instead. llvmpipe infers empty
TGSI pixel shaders by looking tgsi_shader_info::num_instructions, as an
empty shader should have a single END instruction, but this logic wasn't
working for NIR shaders.
I mulled over the possibility of making llvmpipe handle null pixel
shaders. Spreading null checks everywhere would be invasive and error
prone, but it would be quite simple if llvmpipe simply created a dummy
PS internally, to be used as a replacement whenever a null PS was bound.
That said, I'm not sure if other gallium drivers can cope with a null PS
neither, and if nought, might as well keep using an empty PS in lavapipe
state tracker. An any rate, this change makes sense on its own.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20155>
link_varyings ignores precisions and can assign the same location to
variables with different precisions. nir_link_varying_precision should
check location_frac as well.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20113>
When a pipeline has dynamic logicop state or blend state, we defer lrz
write decision to tu6_calculate_lrz_state. As such,
tu6_calculate_lrz_state should look at both states when either of them
is dynamic.
Fixes dEQP-GLES2.functional.fragment_ops.interaction.basic_shader.21 on
angle, which uses dynamic logicop state and static blend state with
blending enabled.
Fixes: c8c7154c2e ("tu: Implement extendedDynamicState3ColorBlendEnable")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20136>
For Tiger Lake and onward, we generally don't need to ambiguate the CCS
before accessing it. This is safe for two reasons:
- Tiger Lake and onward treat all CCS values as legal.
- We enable compression on all writable image layouts. The CCS will
receive all writes and will therefore always be valid.
When dealing with modifiers, we continue to allow ambiguates in some
instances.
Before this patch, I found ~19.5k ambiguates in Wolfenstein:
Youngblood's Riverside benchmark (note that this includes manually
entering the benchmark and exiting the app). With this patch, the number
of ambiguates goes down to zero.
Improves performance of Fallout 4 at 1080p/High settings on Arc A380 by
around 22%.
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20118>
Whether or not CCS can be used without initialization depends on the
platform:
- On gfx7-8, each CCS element is 1-bit and encodes "fast-cleared" or
"pass-through". So, those platforms have no illegal values.
- On gfx9-11, each CCS element is 2-bits and some bit combinations
are invalid.
- On gfx12+, each CCS element is 4-bits but they have no truly illegal
values. Unused encodings are interpreted as "pass-through".
Refer to the "MCS/CCS Buffers for Render Target(s)" sections of the
PRMs for more info.
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20118>
When INTEL_DEBUG=pc is set and a CCS operation is being performed, the
driver reports that flushes are happing before and after the operation.
It also reports that the operation is a fast clear, but that's not
always the case. We could be resolving for example.
Reporting the specific operation can help avoid confusion.
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20118>
Return VA_STATUS_ERROR_UNSUPPORTED_PROFILE if given profile is not
supported for both decode and encode.
Return VA_STATUS_ERROR_UNSUPPORTED_ENTRYPOINT if given profile is
supported (for at lease one of decode or encode), but current given
entrypoint is not supported.
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20082>
This was a bad idea because:
- it diverges too much with the fragment shader epilog
- it doesn't allow to implement alpha-to-coverage via MRTZ correctly
- it was supposed to be used by LLVM but this never happened
Reverting this back allows us to fix alpha-to-coverage via MRTZ
on GFX11 easily, including for fragment shader epilogs.
fossils-db (NAVI21):
Totals from 20411 (15.13% of 134913) affected shaders:
VGPRs: 972056 -> 971400 (-0.07%); split: -0.08%, +0.01%
CodeSize: 92284804 -> 92295392 (+0.01%); split: -0.05%, +0.06%
MaxWaves: 465010 -> 465166 (+0.03%); split: +0.03%, -0.00%
Instrs: 17034162 -> 17034963 (+0.00%); split: -0.00%, +0.01%
Latency: 252013190 -> 251971764 (-0.02%); split: -0.03%, +0.02%
InvThroughput: 45859625 -> 45842556 (-0.04%); split: -0.04%, +0.01%
VClause: 324627 -> 324629 (+0.00%); split: -0.03%, +0.03%
SClause: 672918 -> 672826 (-0.01%); split: -0.05%, +0.04%
Copies: 1172126 -> 1158152 (-1.19%); split: -1.20%, +0.01%
Branches: 420602 -> 420604 (+0.00%); split: -0.00%, +0.00%
PreSGPRs: 1025441 -> 1025481 (+0.00%)
PreVGPRs: 861787 -> 860650 (-0.13%); split: -0.17%, +0.03%
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/20126>
Don't add extra movs to construct the swizzles, but just split the
instruction into separate channels, if possible. Idea by Filip Gawin.
shader-db for RV370:
total instructions in shared programs: 84632 -> 83565 (-1.26%)
instructions in affected programs: 12613 -> 11546 (-8.46%)
helped: 295
HURT: 8
total temps in shared programs: 12437 -> 12237 (-1.61%)
temps in affected programs: 1807 -> 1607 (-11.07%)
helped: 153
HURT: 20
LOST: 1
GAINED: 19
The HURT instructions and the single lost shaders are some fluctuations
from pair scheduling. The number of instructions before pair scheduling
is always lower or equivalent.
Partial fix for: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6339
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Tested-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20009>
For any instruction that can be reasonably converted to alpha we check
all of its readers to see if the conversion is possible (including check
for at least one free alpha source) at the beginning of pair scheduling.
However, if the reader instruction has multiples sources that could be
converted to alpha and multiple indeed are, than we could run of of the
alpha sources eventually. So recheck just before converting that there
are still some unused sources left.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Tested-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20009>
`dzn_instance_create` will call `dzn_instance_destroy` when the d3d12
library fails to load. Just like the issue in `d3d12_screen`, this will
lead to a crash because `d3d12_mod` is NULL.
To fix this, only close the library after if it was actually opened.
Cc: mesa-stable
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20145>
`d3d12_destroy_screen` is called by `d3d12_create_dxcore_screen` after
`d3d12_init_screen_base` fails and attempts to call `util_dl_close` on
a NULL pointer, leading to an abort.
To fix this, only close the library after if it was actually opened.
Cc: mesa-stable
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20145>
This change should avoid any accidental rounding issues because of
border colors getting stored in a float in dxil_wrap_sampler_state. It
also switches us to using the correct helpers for nir_const_value so we
can avoid any weird uninitialized data failures that can be caused by
filling out the fields in the struct directly.
Fixes: b9c61379ab ("microsoft/compiler: translate nir to dxil")
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19689>
There were a couple of issues here:
1. We should be using nir_const_value_for_uint instead of setting the
union fields directly to ensure the rest of the union is zeroed.
2. It was always filling out the first two components of val even if
the incoming constant had 2 64-bit components.
Fixes: 165fb5117b ("r600/sfn: add lowering passes to get 64 bit ops lowered to 32 bit vec2")
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19689>
Such cursed behavior is almost non existent in practise. When capturing
a Doom Eternal, this warning spams the output for no reason.
The warning is also unnecessary since we copy acceleration structures
right after building them now.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20047>
In try_fold_load_store when trying to extract const addition from
non-const offset source, we should take into account that there is
already a constant base offset, which should count towards the limit.
The issue was found in "Monster Hunter: World" running on Turnip.
Fixes: cac6f633b2
("nir/opt_offsets: Use nir_ssa_scalar to chase offset additions.")
Well, the issue was present before this commit but it made a lot
of changes in surrounding code.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20099>
Looking at VOPD things, shifts are not very likely to get dual issued
but plain moves are. Looking at RDNA2 v_lshrrev_b64 are half the perf
of v_mov_b32 (but you need twice as many moves), so on GFX11 this likely
reaches the threshold where moves are faster.
Totals from 68400 (50.70% of 134906) affected shaders:
CodeSize: 275489516 -> 275459536 (-0.01%); split: -0.01%, +0.00%
Instrs: 51775474 -> 51991286 (+0.42%)
Latency: 589884847 -> 589066439 (-0.14%); split: -0.15%, +0.01%
InvThroughput: 127154986 -> 126037619 (-0.88%); split: -0.88%, +0.00%
Copies: 3756157 -> 3976193 (+5.86%)
Branches: 1259604 -> 1260072 (+0.04%)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19633>
Oh, for the days of Broadwell and earlier where compression was called
fast-clear. That was a simpler time. The birds sang in the trees, the
oceans weren't brown from oil spills, and Intel surface compression was
actually comprehendable by humans. To help the reviewer, keep the
following in mind:
1. CCS_E is SKL+
2. Implicit CCS is TGL+
3. The AUX TT (AKA aux map) is TGL+
4. HIZ+CCS, stencil CCS, and CCS for storage images are all TGL+
4. CCS_D surfaces only ever get full resolves and MCS surfaces only
ever get partial resolves
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19852>
The hardware only supports aligned loads and stores. That applies to vertex
buffer loads as well. As such, we need to ensure that the base address of vertex
buffers, the stride, and the offset are all aligned to the vertex buffer format,
ensuring that the load itself is aligned. Mesa has a CAP for that,
PIPE_CAP_VERTEX_ATTRIB_ELEMENT_ALIGNED_ONLY, which ensures that these conditions
are met and will rewrite a vertex buffer on the CPU in the off chance that
they're not.
This is a bug fix compared to the old code, because it requires that offsets and
base addresses are aligned (not just the strides like before). It's also an
optimization compared to the old code, because it does not require 4 byte
alignment for 8-bit and 16-bit formats. In fact, it doesn't require any
alignment for 8-bit formats. This will avoid needless CPU work for smaller
formats.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19996>
Now we support all the vertex formats! This means we don't hit u_vbuf for format
translation, which helps performance in lots of applications. By doing the
lowering in NIR, the vertex fetch code itself can be optimized by NIR (e.g.
nir_opt_algebraic) which can improve generated code quality.
In my first implementation of this, I had a big switch statement mapping format
enums to interchange formats and post-processing code. This ends up being really
unwieldly, the combinatorics of bit packing + conversion + swizzles is
enormous and for performance we want to support everything (no u_vbuf
fallbacks). To keep the combinatorics in check, we rely on parsing the
util_format_description to separate out the issues of bit packing, conversion,
and swizzling, allowing us to handle bizarro formats like B10G10R10A2_SNORM with
no special casing.
In an effort to support everything in one shot, this handles all the formats
needed for the extensions EXT_vertex_array_bgra, ARB_vertex_type_2_10_10_10_rev,
and ARB_vertex_type_10f_11f_11f_rev.
Passes dEQP-GLES3.functional.vertex_arrays.*
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19996>
We'll use formatted loads and some system values to lower UBOs and VBOs to
global memory in NIR, using the AGX-specific format support and addressing
arithmetic to optimize the emitted code.
Add the intrinsics and teach nir_opt_preamble how to move them so we don't
regress UBO pushing.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19996>
STL/LDL have 13 bits to store imm offset. However the most significant
bit in the offset is a sign bit, so the positive offset is limited by
12 bits.
nir_opt_offsets only has the upper limit and doesn't deal with
negative offsets, so shared_max should be changed to `(1 << 12) - 1`.
The issue was found in "Monster Hunter: World".
Fixes: 0b2da9d795
("ir3: Limit the maximum imm offset in nir_opt_offset for shared vars")
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20100>
This could result in hangs if the entire descriptor set was inline
uniforms. Fixes
dEQP-VK.binding_model.descriptorset_random.sets4.dynindexed.ubolimitlow.nosbo.nosampledimg.outimgonly.iublimitlow.nouab.comp.noia.0
after 0a0a04bd made us prefetch descriptors again and uncovered this.
Fixes: 37cde2c6 ("tu: Rewrite inline uniform implementation")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20101>
Contains the following enhancements & fixes:
- Increase (decrease?) the granularity to single bytes rather than
using an arbitrary word size,
- Remove some spurious semicolons at the end of macros, and
- Do not collapse sections of zero bytes that consist of only a single
line.
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
Reviewed-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20040>
This commit remove:
- PVR_SUB_COMMAND_FLAG_TRANSFER_SERIALIZE_WITH_FRAG.
- PVR_SUB_COMMAND_FLAG_OCCLUSION_QUERY.
The first flag was specific to transfer sub commands and the last
one, for graphics ones. Now we just have a bool in the transfer
sub_cmd, and one in the graphics sub_cmd.
Signed-off-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19957>
The idea in the single sync path is that we serialize any job that
needs to wait, however, our ANY queue syncobj only tracks the last job
submitted to any hardware queue, so in practice when we wait on this
we are only serializing against the queue to which we have submitted
the last job, which is not correct.
Fix that by accumulating the last job sync into the ANY queue synbcobj
to ensure that waiting on this syncobj effectively waits on all
hardware queues.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20078>
This lowers line-stippling to a combination of geometry and fragment
shaders:
- The geometry shader computes the length of each line-segment, and
outputs a varying that produces the stipple position.
- The fragment shader looks up the stipple position in the
stipple-pattern once per sample, and updates the sample mask
accordingly.
In case there's no geometry shader in place, we create a new
pass-through shader.
We should probably not declare the the push-constants in the pipeline
layout unless they're actually needed. But we already do this
unconditionally for the vertex shader and tesselation push-constants, so
let's do it unconditionally for these as well for now.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19117>
Right now, it's only the vertex-shader that needs special handling for
non-optimal keys. That makes it possible to use fallthrough to always
end up in the last-vertex-stage conditional.
But we're about to add special handling for the geometry stage as well,
so let's prepare by splitting the switch-statement in two; one that only
happens for non-optimal keys, and does all the needed processing there,
and one that deals with the rest.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19117>
Line-stipple lowering is going to need some geometry-shader specific
lowering, so lets give the GS its own shader-key struct.
The GS variant only needs a non-optimal variant, so let's assert that to
be sure.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19117>
There's two notable limitations here:
- This will viewport-map to viewport #0 only. This is because we need
the viewport-scale factors, which we'll be uploading using
push-constants. And we don't want to waste too many of those...
- It's missing a "global" stipple-counter. It doesn't seem like there's
a portable way of implementing this, so this is going to require a VK
extension that can be implemented in a hardware-specific way in the
long run. For now, let's just ignore the global stipple counter.
These two limitations don't seem viable to overcome for now, so but this
is better than nothing.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19117>
This is not ideal, but at least it should work. In the long run, we
might want to store a bit per mode we're missing, so we can do this
conditionally. But that's quite a bit more complicated, so let's go with
this for now.
The line-stippling logic needs non-optimal shader-keys. So let's drop
some perf on the floor here.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19117>
This probably wasn't noticed earlier because tests using sRGB storage
images didn't exist, and we didn't know whether this works, but this
fixes dEQP-VK.image.store.without_format.2d.*_srgb which also proves
that the bit works.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20060>
We can implement glPolygonMode(GL_FRONT_AND_BACK, ...) natively. What we can't
implement natively are two-sided polygon modes. For that Apple has a nontrivial
lowering which I don't feel the need to implement unless someone actually hits a
workload other than Piglit that uses it.
Vulkan requires only one-sided polygon modes (so this is sufficient there), and
GLES doesn't have polygon modes at all. If an app hits the unimplemented case,
throw a warning like Zink does.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20017>
This option didn't exist half a decade ago when I first implemented base
workgroup support in ANV. It's cleaner to just have split system values
like all the other zero_base+base things do.
We currently only do this for COMPUTE and not KERNEL because it lets us
avoid changing intel_clc for now. We can add KERNEL later if needed.
We also don't do this lowering for task/mesh.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20068>
AFBC of sRGB formats should just work. We just need to flip it on and enjoy
the improved performance.
In particular, this means that RGBA8 UNORM and RGBA8 sRGB UNORM are now
considered compatible formats for AFBC. That's a bug fix, because
GALLIUM_HUD use will act like a texture view between sRGB and linear
views. For FBOs, that will "just" result in a decompression, hurting
performance. For window system rendering with AFBC, that will cause an
assertion failure, as we cannot decompress SHARED resources.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19758>
In our handling of load_deref, we were calling builder helpers to create
conversions and then adjusting the destination bit size of the load. We
should adjust the bit size first because the builder sometimes looks at
the bit sizes of SSA values passed in as arguments.
Even though it's not strictly necessary, adjust the store_deref case as
well to make it fully symmetric with the load_deref case.
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20067>
We don't care to support i8vec16, we just need a bit of 8-bit support to
implement format packing/unpacking in blend shaders. We're already doing
this by using the 16-bit pipe, we just need to commit to it all the way
-- reporting the correct sizes in max_bitsize_for_alu so the mask
packing logic works as intended -- and dropping the imov-specific hack
that was introduced to workaround a similar class of bugs.
With the previous patch, fixes:
dEQP-GLES31.functional.draw_buffers_indexed.random.max_required_draw_buffers.1
Fixes: 39e4b7279d ("pan/midg: Fix swizzling on 8-bit sources")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19763>
Even if we only mask a single component from the result of CSEL.vector,
in our IR we treat its semantics as vector which causes trouble with
when scheduled to a scalar unit.
The problematic bundle looks like this:
vmul.MOV.i32 R31, TMP0.xxxx, R0.yzww
sadd.MAX.i32 TMP0.y, R0.y, #65408
smul.CSEL.vector.i32 R0.y, TMP0.y, #127
As the comment in midgard.h illuminates, these CSEL instructions are
actually operating per-bit, lining up with the all-1's booleans in
Midgard. The Bifrost analogue is MUX.i32.bit, not CSEL.i32. We should
probably rename the Midgard instruction to make that clear.
Anyhoo, on the scalar unit, CSEL/MUX operates on the bottom 32-bits of
its source. That's ok for the usual r31.w case, because that's secretly
replicating to its nonexistent register, I think? But that doesn't work
with the CSEL.vector (MUX.vector) form, because the condition it's
actually muxing on is r31.x, which here is R0.y, not the intended R0.x.
Rather than adding more special cases to the already overcomplicated
scheduler (for the dubious benefit of avoiding a small shaderdb
regression), just avoid scheduling CSEL.vector to smul.
With the next patch, fixes:
dEQP-GLES31.functional.draw_buffers_indexed.random.max_required_draw_buffers.1
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19763>
We've recently rebalanced our lab devices to get a fewer number of
grunts. Switch to scheduling only on the newer shinier ones, running
fewer tests. We'll evaluate the runtime, and if they're quick enough
then we can increase the amount of testing we do.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20081>
Instead of keeping a free list of "event descriptors" which are
just the offsets in the BO state that are available, pre-allocate
the events. This is simpler as it doesn't require to allocate these
event descriptors at all.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20053>
It's not in the key, so it randomly may or may not be present, and if it
is present then we don't actually save/restore the contents, so we will
save/restore random pointer values from the last run. Turnip already
disables searching the shader cache when assembly is requested, but
still wrote the final ir3_shader_variant which resulted in trying to
save random stale pointers when saving off the executable if a
subsequent compile hit that cache entry.
This fixes flakes in
dEQP-VK.pipeline.pipeline_library.shader_module_identifier.pipeline_from_id.*
for me.
Fixes: 56909868cd ("turnip: implement VK_KHR_pipeline_executable_properties")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20056>
We cannot fully use the vectorizer outside of this pass because once
stack load/store operations have been lower to global load/store, the
robustness rule applies to those as they would to application
load/store.
But this is all internal and we know it doesn't require out of bound
checking. So doing the vectorizing here is the best solution. We just
have to teach the vectorizer about our intrinsics.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20058>
Using a designated initializer like this leaves padding bits, which form
part of the aliasing u64/f64 member of the union, uninitialised, but a
nir_const_value must always have the unused bits zeroed out. Thus, use
the nir_const_value_for_float helper instead like everywhere else which
will do a memset 0 for us first.
Without this, using the pan_blend shader in a build with validation
enabled fails with:
NIR validation failed after nir_lower_vars_to_ssa
...
vec4 32 ssa_58 = load_const (0x3f7cfcfd /* 0.988235 */, 0x3f7cfcfd /* 0.988235 */, 0x3f7cfcfd /* 0.988235 */, 0x3f800000 /* 1.000000 */)
error: memcmp(val, &cmp_val, sizeof(cmp_val)) == 0 (../src/compiler/nir/nir_validate.c:976)
Fixes: 1378c67bcf ("panfrost/blend: Inline blend constants")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20071>
Starting with !19748 lowered 64 bit shifts were showing wrong results for
shifts with insignificant bits set.
nir shifts are defined to only look at the least significant bits. The
lowering has take this into account.
So there are two things going on:
1. the `ieq` and `uge` further down depend on `y` being masked.
2. the calculation of `reverse_count` actually depends on a masked `y` as
well, due to the `(iabs (iadd y -32))` giving a different result for
shifts > 31;
Fixes: 41f3e9e5f5 ("nir: Implement lowering of 64-bit shift operations")
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19995>
OpenGL 4.1 also increased the minimum 3D and cube texture size as
well as the minimum number of texture-array layers. Let's also
verify these to prevent enbaling too recent GL versions on layered
drivers link Zink, VirGL etc.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19780>
We're reporting 2048 for VkPhysicalDeviceLimits::maxImageArrayLayers on
Turnip, so we should be able to use 2048 for OpenGL as well. And that's
the minimum required value for OpenGL 4.1 support.
According to http://vulkan.gpuinfo.org/, it seems like values of 2048
should be possible for at least as low as some Adreno 4xx GPUs. But
since we don't support recent GL versions on those, we this won't make a
big difference. So let's leave that up to someone who actually knows
what they're doing!
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19780>
D3D12_REQ_TEXTURE3D_U_V_OR_W_DIMENSION is 2^11, not 2^10 like the
comment said, and the code assumed. We need to add one to account for
the base-level.
Let's add a static_assert here to prove that this is the right value.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19780>
This seems to have been triggered by some recent CTS changes which
changed the random number generation. I'm seeing context faults in
dEQP-VK.binding_model.descriptorset_random.sets4.dynindexed.ubolimitlow.sbolimitlow.sampledimghigh.lowimgnotex.iublimitlow.nouab.comp.noia.0
that are fixed by this.
Fixes: 37cde2c634 ("tu: Rewrite inline uniform implementation")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20039>
Although the metadata is possibly one byte per 8x4 block, the
logical block size for compression/allocation is a 16x16 block,
so align to that. Also align the initial dimensions to that size,
and change the minification to a simple DIV_ROUND_UP.
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20031>
It's possible that undef is written to clip/cull distance outputs and
they're eliminated, and we never set any position export to done=1 because
outinfo->pos_exports was calculated with the expectation that clip/cull is
exported.
Eliminating the export and fixing the done=1 bit hangs because the
hardware is still expecting clip/cull distances.
Fixes dEQP-VK.rasterization.provoking_vertex.transform_feedback.first.line_list
hang with LLVM.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19200>
We can reallocate to avoid a flush.
Scrolling rosenzweig.io in Firefox with WebRender enabled is now vsyncing at
60fps instead of being capped around 50fps. SuperTuxKart is noticeably faster as
well, though this was prompted by WebRender.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20013>
The source code for rddecompiler includes adreno_common.xml.h, which is
a generated header. In order to ensure that the header has been written
when compiling rddecompiler.c, we need a dependency here.
Fixes: 03d80e0a6d ("freedreno/decode: Add 'rddecompiler' tool")
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20003>
This cleanup removes the dri_util structure __DRIscreen(Rec) that is
difficult to follow, and switches all code to using dri_screen directly.
It also inlines kopper_screen in dri_screen because I don't see any
other way to do this cleanup.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19741>
Tested that a q2rtx gfxr capture replays correctly and without the
capture/replay feature warning.
I ran the CTS too, but it seems to be just giving out a pass without
testing the code path.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19949>
Fixes following leak:
==7520== 48 bytes in 1 blocks are definitely lost in loss record 1,597 of 2,016
==7520== at 0x484486F: malloc (vg_replace_malloc.c:381)
==7520== by 0x5314A4E: ralloc_size (ralloc.c:117)
==7520== by 0x5314A1F: ralloc_context (ralloc.c:104)
==7520== by 0x6A95D68: nir_opt_ray_query_ranges (nir_opt_ray_queries.c:235)
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: f5b6576585 ("nir: Add a pass for combining ray queries")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20002>
Keeping a full copy of the resource level around in the surface is
confusing and this confusion has caused real bugs already. Get rid
of the copy by retrieving most of the information directly from the
etna_resource_level pointed at from the surface. Only the precomputed
offsets into the target and TS BOs need to be kept in the surface.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19814>
Clearing ts_size - ts_offset bytes in a level means we are clearing the
TS region of all layers in the level starting from the surface layer, so
clearing one surface might corrupt all other layers of a resource level.
Use the correct size to clear only the requested TS region.
Cc: mesa-stable
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19814>
If stencil operations are enabled, we either need the full early or
late ZS stage, even if Z writes are disabled. Empirically the early
stage properly supports stencil operations, just need to be careful to
not mix early tests with late writes when stencil operations modify
the depth buffer.
Fixes piglit tests:
spec@!opengl 1.1@depthstencil-default_fb-copypixels
spec@!opengl 1.1@depthstencil-default_fb-readpixels
spec@!opengl 1.1@depthstencil-default_fb-blit
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19958>
Up-aligning the blit height does not always work, as some blit targets
have a smaller padded height. Fall back to single pipe operation if
increasing the height alignment fails. Still try to do it opportunistically
as it improves performance when resolving MSAA targets.
Fixes: 0ff96aaef3 ("etnaviv: rs: fix MSAA alignment adjustment")
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19991>
The main buffer is twiddled as before, but there's now also an auxiliary
compression buffer that we need to reserve space for.
With compression, the main buffer is aligned less. The macOS logic seems to be
to align to the page size only if the texture is both 3D and mipmapped, *and*
the layer stride is greater than the page size.
That's gated on compression being enabled. Page alignment seems to be needed for
uncompressed twiddled cube maps.
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19999>
bind_sampler_states doesn't zero [nr_samplers, PIPE_MAX_SAMPLERS) so can get
non-null garbage samplers leading to a use-after-free (segfault derefencing
sampler) or a buffer overflow (writing samplers[] out).
Fixes crashes in Xonotic.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reported-by: dcow
Tested-by: dcow
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19994>
Better occupancy, which is especially important when the background shader
does memory access (for reloads). On my 4K monitor, glmark2 -bdesktop fullscreen
from 95fps to 133fps.
At default settings, glmark2 -bterrain from 63fps to 71fps.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19997>
When HAVE_VALGRIND is set, vbits of the CPU mapping are stored when
pvr_bo_cpu_unmap() is called. They can be reloaded by calling
pvr_bo_cpu_map_unchanged() instead of pvr_bo_cpu_map(). The vbits are
not loaded by default on every map, since they could easily have been
changed by the device between the unmap/map calls. Only use
pvr_bo_cpu_map_unchanged() when you can safely assume that nothing has
changed in the underlying memory.
When HAVE_VALGRIND is not set, pvr_bo_cpu_map_unchanged() just inlines
to pvr_bo_cpu_map().
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
Reviewed-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18948>
NIR shifts are defined to truncate the shift amount to the number of bits
needed to represent the bit-size of the value shifted. LLVM treats large
shifts as poison. This fix achieves NIR semantics for shifts.
As an example, a|(b << 32), where "a" is 32bits, should produce a|b
according to NIR (because 32&31 == 0).
This caused LLVM to incorrectly optimize "(a >> c) | (b << (32 - c))" to a
u2u32(pack_64_2x32(a, b) >> c) (v_alignbit_b32), when the original NIR
should have returned "a | b" if c==0.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Mihai Preda <mhpreda@gmail.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19966>
We only copy two components, we have to use the complete original source,
and we should rewrite the new source from scratch to avoid incorrect
dimension and indirect handling.
Fixes: 036d7172c (virgl: Move double operands to a temp to avoid double-swizzling bugs)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19975>
Instead of creating all 8 pipeline combinations when we initialize
the device we create the pipelines when we need to use them. This
is probably better because applications are likely to always use
the same flags for the copy command, which means that only one
pipeline may be required.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19981>
The OpenGL specifications explicitly calls out these queries as allowing
zero bits, so these features aren't actually required to bump the OpenGL
version.
While we could in theory also enable the corresponding extensions
unconditionally, this risks breaking applications that assume that the
presence of the extensions are sufficient to use meaningfully use them,
like is the case with most other OpenGL extensions.
However, blocking more recent GL versions due to this seems like a bit
of an overreaction. So let's allow new OpenGL versions, but not the
extensions themselves.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Soroush Kashani <soroush.kashani@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19750>
Similar to ARB_occlusion_query / ARB_occlusion_query2, this extension
allows zero bits for the queries, meaning there's no actual hardware
requirements here.
So let's just report zero bits if the driver doesn't support the CAP,
and treat these queries as dummies like we already do for occlusion
queries.
We still don't expose the extension, this is just to make it possible to
allow the core OpenGL functionality without exposing the extension.
Reviewed-by: Soroush Kashani <soroush.kashani@imgtec.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19750>
It's legal in OpenGL to start a query even if the result will have zero
valid bits. It's not enough to just report zero bits, We need to also
prevent calling down into the driver with these invalid queries.
Because ARB_ES3_compatibility adds ANY_SAMPLES_PASSED and
ANY_SAMPLES_PASSED_CONSERVATIVE to the set of queries that support zero
bits, we also need to check for the corresponding indices.
Fixes: 0186e9e1c5 ("mesa: always support occlusion queries")
Reviewed-by: Soroush Kashani <soroush.kashani@imgtec.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19750>
UBSan complains otherwise:
../src/asahi/compiler/agx_pack.c:701:21: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
../src/asahi/compiler/agx_pack.c:534:18: runtime error: left shift of 8 by 28 places cannot be represented in type 'int'
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19971>
r5 and r6 are always getting lowered. Will prevent a regression with VBO
lowering on a shader which has stride=0 and hence gets the vertex ID read
optimized out with NIR:
dEQP-GLES2.functional.draw.random.50
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19971>
Don't waste 1MB per batch for descriptors that may be completely unused.
Instead, upload the scissor and depth bias arrays at submit time. This is a
simple solution to a silly problem: we can't grow the scissor/depth bias arrays,
and we don't know how big they will be at draw time. We could...
1. Statically allocate large buffers? Waste lots of memory.
2. Statically allocate small buffers? Forces too much flushing.
3. Dynamically allocate a growable GPU buffer? Requires either reading
back write-combined memory contents, or maintaining a CPU copy in
addition to extra GPU copies, or doing complicated MMU shenanigans.
The first two options are slow and the last is complicated.
Instead, we upload these descriptors to a dynamically allocated CPU-side which
gets copied just once to the GPU at submit-time when the exact size is known,
minimizing wasted memory and copies and avoiding any unnecessary flushing or WC
memory reads.
In addition, this patch makes sure we flush if we would overflow with more than
65535 scissor descriptors in a batch. This is a (minor) bug fix.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19971>
Rather than hanging onto them across batches. This lets us free these BOs if the
number of batches shrinks, which is pretty common if all 32 batches are used
during a loading screen for glGenerateMipmap() and then the in-game portion
drops to 1 or 2 batches only. Now that we have the BO cache wired up, this
should not adversely affect performance.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19971>
Massive performance gains, some fps before/after numbers from glmark2:
[shading] 1486 -> 2391
[refract] 87 -> 127
[terrain] 32 -> 56
...and it's basically for free with enough copy/paste, so thank you to Boris
Brezillon for an excellent Asahi patch, the LRU cache seems to work great on M1
:-p
There are a few minor changes I made from panfrost, notably adjusting the
constants to account for 16KiB pages and switching from pthread_mutex to
simple_mtx to be less weird in Mesa.
For context on the design, the following commits evolved it in Panfrost and
their commit messages may be useful... The logic in this module is the product
of years of mistakes and correcting course :-)
f06809cdca ("panfrost: Evict the BO cache when allocation fails")
77d0498913 ("panfrost: Fix major flaw in BO cache")
ee82f9f07e ("panfrost: Try to evict unused BOs from the cache")
2225383af8 ("panfrost: Make sure the BO is 'ready' when picked from the cache")
9af4aeaaf7 ("panfrost: Don't return imported/exported BOs to the cache")
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19971>
The mesa state-tracker can now emulate all formats indicated by this
feature-flag, so we don't require this for OpenGL 4.2 any more.
It's however a good idea to support for power-usage and performance
reasons, saving on memory bandwidth. So let's move it to the
gl46_optimal block instead.
Fixes: e4ff42684b ("mesa/st: enable bptc extension with fallback")
Fixes: 2ea481b2f0 ("Zink: add Zink profiles file")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19779>
We never required the uniform texel buffer bit for more than
bufferFeatures for a bunch of these formats.
Similarly, we *don't* need the uniform texel buffer bit for sampled
image access.
For the image-dimensions, the Mesa frontend doesn't validate the max 1D,
3D or Cube sizes, nor the max texture layers. So we'll expose GL 4.1
without these, even if that's not conformant.
Finally, we don't require robustImageAccess2 for OpenGL 4.3 at all. All
we need is the robustBufferAccess feature.
Fixes: 2ea481b2f0 ("Zink: add Zink profiles file")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19779>
Instead of having one shader that checks the various flags and emits
conditional code, create specialized pipelines for each relevant
combination of flags values so we can produce more optimized
pipelines with less conditional code for each scenario.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19770>
Our implementation was mostly CPU-based, with things such as query
resets and result copying handled in the CPU, as well as some aspects
of query availability tracking.
This new implementation handles all GPU-side query functions by
dispatching compute shaders to push the work to the GPU. This
involves query availability, reset and result copying.
For now, only occlusion queries are managed this way. Performance
queries can also be implemented in a similar fashion in the future
with some additional work, however, for timestamp queries our only
option to improve this would be to execute the actual timestamp in the
kernel, since we can't take a timestamp from a shader.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19770>
If we don't use xmlconfig, expat becomes an optional dependency on
Linux/BSD, which may be convenient for embedded systems that do not
otherwise need expat. (expat is so ubiquitous that this
probably doesn't matter a ton in practice, but fewer required Mesa deps
is probably nice anyway.)
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Suggested-by: Dylan Baker <dylan.c.baker@intel.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19626>
On embedded Linux, we can hardcode the driconf file (00-mesa-defaults.conf) with
no possibility of the file changing after the build. The static driconf
implementation, used on Windows and Android, suffices for that use case. It is
undesireable for these platforms to depend on expat or to spend time during app
start-up parsing driconf XML.
We already have the static driconf implemented, all we need is a meson option to
opt-out of runtime xmlconfig on Linux and use the static version instead.
To opt-out of runtime xmlconfig, build Mesa with -Dxmlconfig=disabled.
v2: Expand out feature.require() since it was only added in meson 0.59.0.
v3: Use more concise Meson syntax (Dylan)
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com> [v2]
Reviewed-by: Eric Engestrom <eric@igalia.com> [v2]
Reviewed-by: Emma Anholt <emma@anholt.net>
Tested-by: Chris Healy <healych@amazon.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19626>
It's not necessary -- no other driver does this despite most drivers having a
driconf check like Zink does -- and it adds a problematic cross-tree dependency.
This was been a relic from when xmlconfig didn't work at all on Windows, added
in commit 834b69d1ef ("zink: fix win32 build"). That has been replaced the
"static" xmlconfig only, which is good for almost everyone enough in practice.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19626>
We support a good chunk of GL 3.x now ... let's get us on the board so that
Mesamatrix can get onto solving the challenging problem of deciding what colour
to use for Asahi ;-)
Table filled out to the best of my abilities, there may be inaccuracies or
omissions.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19944>
Hopefully this doesn't break anything.
There are a lot of places that invalidate drawables, but no place attempted
to call the context directly like this. A few places don't even have
the context.
Explanation:
The DRI frontend uses a global atomic counter per drawable that is
incremented when that drawable changed buffers.
st_manager_validate_framebuffers checks for that atomic counter and
updates the framebuffer state if there is any change. This was called at
every state update, so likely before almost every draw (!!!).
This commit changes that. Everything is the same except that the change
of buffers will not be noticed until the beginning of the next frame or
when the framebuffer state update is triggered by something else.
The effect is that we don't waste time calling
st_manager_validate_framebuffers a million times per frame.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19775>
Decompiles a single cmdstream from .rd into compilable C source.
Given the address space bounds the generated program creates
a new .rd which could be used to override cmdstream with 'replay'.
Generated .rd is not replayable on its own and depends on buffers
provided by the source .rd.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19444>
This adds an option to override a single cmdstream while replaying
.rd capture. Cmdstream for override is stored in the same .rd format,
where there is only one RD_CMDSTREAM_ADDR section and any amount
of buffers.
Instead of using provided .rd file, 'replay' calls external program
to generate it first, in order to be able to pass the range of
GPU addresses available for the new buffers.
Usage example:
./replay --override=13 --generator=~/cmdstream_gen
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19444>
When we need to poll the XCB connection with a non-trivial timeout,
be very careful to not hit an XCB bug where a poll() may hang for too
long even if an event is ready in the special event queue.
This is a pragmatic workaround, a wait_for_special_event_with_timeout()
is the only proper solution here.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19279>
These extensions are flawed and do not support the concept of
per-surface queries. For the time being we cannot guarantee that we are
able to implement it on all surfaces, but the feature is useful enough
to make available as an opt-in feature for the time being, so hide it
behind an driconf until we have a better mechanism in place.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Reviewed-by: Joshua Ashton <joshua@froggi.es>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19279>
When vkWaitForPresentKHR succeeds, we are guaranteed
that any dependent semaphores have been unsignalled.
In an explicit sync world, we are guaranteed this automatically by
having a present complete, since that event must follow a semaphore wait
completion.
However, if the swapchain image is implicitly
synchronized, the semaphore might technically not have been unsignaled
before the present complete event triggers.
Present IDs must be signalled in monotonic order, same as timeline
semaphores.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Reviewed-by: Joshua Ashton <joshua@froggi.es>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19279>
GCC 12.2.0 warns:
../src/intel/compiler/brw_fs.cpp: In member function ‘bool fs_visitor::
split_virtual_grfs()’:
../src/intel/compiler/brw_fs.cpp:2199:10: warning: ‘void* memset(void*, int,
size_t)’ specified size between 18446744071562067968 and 18446744073709551615
exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
2199 | memset(vgrf_has_split, 0, num_vars * sizeof(*vgrf_has_split));
`num_vars` is an `int` but gets assigned the value of `this->alloc.count`,
which is an `unsigned int`. Thus, `num_vars` will be negative if
`this->alloc.count` is larger than int max value. Converting that negative
`int` to a `size_t`, which `memset` expects, then blows it up to a huge
positive value.
Simply turning `num_vars` into an `unsigned int` would be enough to fix this
specific problem, but there are many other instances where an `unsigned int`
gets assigned to an `int` for no good reason in this function. Some of which
the compiler warns about now, some of which it doesn't warn about.
This turns all variables in `fs_visitor::split_virtual_grfs`, which should
reasonably be unsigned, into `unsigned int`s. While at it, a few now pointless
casts are removed.
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19423>
This is meant to remove any integrated GPU only code paths that can't
be compiled in CPU architectures different than x86.
Discrete GPUS don't have need_clflush set to true so it was just
matter of remove some code blocks around need_clflush but was left a
check in anv_physical_device_init_heaps() to fail physical device
initialization if it ever became false.
Signed-off-by: Philippe Lecluse <philippe.lecluse@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19812>
Fixes a number of CTS patterns on DG2 :
- dEQP-VK.dynamic_rendering.primary_cmd_buff.random*
- dEQP-VK.draw.*secondary_cmd*
- dEQP-VK.dynamic_rendering.*secondary_cmd*
- dEQP-VK.geometry.*secondary_cmd_buffer
- dEQP-VK.multiview.*secondary_cmd*
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 9c1c1888d9 ("intel/fs: put scratch surface in the surface state heap")
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19946>
The fix we used to have for short smooth lines were incorrect, and
here's the real fix:
For lines shorter than one pixel, we need to clamp the length-wise
coverage to the line-length. That produces results that are consistent
with our approximation for longer lines.
Because we pass (length / 2) + 0.5 to the fragment shader instead of
the unmodified length, we need to spend a few instructions to
reconstruct the original width.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19899>
From the Vulkan spec:
"If the VK_AMD_mixed_attachment_samples extension is enabled and
the subpass uses color attachments, the samples value used to
create each color attachment is used instead of
rasterizationSamples."
Found by inspection, though I don't think this extension is widely
used.
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/19907>
Every barebone arm or aarch64 job depends on these.
When experimenting with CI, this job drags both kernel+rootfs_arm64 and armhf,
even when the latter is not used.
This should speed up development and relieve one instance for about 30 minutes
and overlap between finishing kernel+rootfs_arm64 and armhf jobs per change.
Here are some size stats:
old arm_test 904M (32+64)
new arm64_test 579M (64bit)
new armhf_test 402M (32bit)
---
both ~ 981M (overhead is 81M overall, but never used together so it's only cost "at rest")
Runtime of the arm*_test jobs is ~ 2 minutes.
Acked-by: Martin Roukala <martin.roukala@mupuf.org>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: "Sergi Blanch Torné" <sergi.blanch.torne@collabora.com>
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19550>
It is still marked as a flake (along with other copyteximage cases) on all
these boards, so this will reduce the CI IRC channel noise given that we
actually expect a Pass. I haven't found where exactly in history we went
from generally-fail to generally-pass, but it looks like around Feb 2022.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19912>
static constexpr const 'value' is replaced by static function
in all type_char template specializations
to avoid the following building errors happening with clang 6
/home/utente/pie-x86_kernel/prebuilts/clang/host/linux-x86/clang-4691093/bin/ld.lld: error: undefined symbol: r600::type_char<r600::ExportInstr>::value
>>> referenced by sfn_scheduler.cpp
>>> sfn_sfn_scheduler.cpp.o:(bool r600::BlockSheduler::collect_ready_type<r600::ExportInstr>(std::__1::list<r600::ExportInstr*, std::__1::allocator<r600::ExportInstr*> >&, std::__1::list<r600::ExportInstr*, std::__1::allocator<r600::ExportInstr*> >&)) in archive src/gallium/drivers/r600/libr600.a
...
/home/utente/pie-x86_kernel/prebuilts/clang/host/linux-x86/clang-4691093/bin/ld.lld: error: undefined symbol: r600::type_char<r600::RatInstr>::value
>>> referenced by sfn_scheduler.cpp
>>> sfn_sfn_scheduler.cpp.o:(bool r600::BlockSheduler::collect_ready_type<r600::RatInstr>(std::__1::list<r600::RatInstr*, std::__1::allocator<r600::RatInstr*> >&, std::__1::list<r600::RatInstr*, std::__1::allocator<r600::RatInstr*> >&)) in archive src/gallium/drivers/r600/libr600.a
clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation)
Cc: "22.2" "22.3" mesa-stable
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19873>
If a shader has XFB outputs but the application never enables
streamout in runtime (no buffers bound and no begin/end pair), we
have to disable it in the shader by emitting buffer size as 0. It's
also still needed to remember that the cmdbuf needs GDS/GDS OA BOs,
so move this at pipeline bind time instead.
Cc: 22.3 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/19801>
The NGG streamout lowering pass allocates space for all outputs which
means we have to align our computation. Otherwise, the maximum number
of vertices is incorrect and we end up by reaching the maximum allowed
LDS size. This code could be shared instead of being duplicated but
that's for later.
Fixes some transform feedback tests with Zink and
RADV_PERFTEST=ngg_streamout on GFX10.3.
Cc: 22.3 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/19801>
Commit c2b06e1a38 ("etnaviv: add support for sharing the TS buffer")
introduced a problem similar to the one fixed in 3b3cd51286 ("etnaviv:
fix renderonly check in etna_resource_alloc") in a different code path.
This causes a NULL pointer dereference when the screen is instanciated
on the render node. Fix it in the same way by just checking for a valid
pointer.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19923>
The flush_seqno is only to be used/updated when a dirty tile status has
been written back to the resource. Using it as a marker to trigger a
texture cache invalidation is bogus and not actually needed. When the
texture resource is updated via a mapping or blit the texture cache
invalidation is already triggered by marking the caches as dirty. If the
resource is updated by fragment output, OpenGL explicitly defines the
result of a later texture read as undefined unless a TextureBarrier is
inserted, which also properly triggers the texture cache invalidate.
Also the current check is bogus as it doesn't handle seqno wraparound.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19800>
This fixes a longstanding bug in the interaction between TS and a write
mapping. The write does not update TS regardless of the way the update
is done. Update via etna_copy_resource would just set the target ts_valid
to false without actually writing back any dirty TS to the resource.
Writes via the CPU would update the resource, but keep ts_valid at true
even if the tile status may now not match the actually written tiles of
the resource anymore.
Fix this by writing back a dirty TS to the target resource if needed
before updating the level with the write data. Always invalidate TS,
even when the update is done by the CPU.
Cc: mesa-stable
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19846>
radeonsi use packed location base while radv use un-packed location.
So we adjust instance_rate_inputs in each driver to hide the difference.
Note the attribute slot number is less than 16, so we can shift
instance_rate_inputs in radv by VERT_ATTRIB_GENERIC0 which is 16.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19868>
Consider the loop:
float i = 0.0;
while (true) {
if (i != 0.0)
break;
i = i + 1.0;
}
This loop clearly executes exactly one time.
Some trickery is necessary to handle cases where the initial loop value
is very large and the increment is, by comparison, very small. From the
fenu_once test case,
float i = -604462909807314587353088.0;
while (true) {
if (i != -604462909807314587353088.0)
break;
i = i + 36028797018963968.0;
}
This loop should also execute exactly once, but this is much more
challenging to calculate due to precision issues.
Going towards smaller magnitude (i.e., adding a small positive value to
a large negative value) requires a smaller delta to make a difference
than going towards a larger magnitude. For this reason,
-604462909807314587353088.0 + 36028797018963968.0 !=
-604462909807314587353088.0, but -604462909807314587353088.0 +
-36028797018963968.0 == -604462909807314587353088.0. Math class is
tough.
No changes in shader-db or fossil-db.
v2: Fix major bug in checking result of the eval_const_binop(nir_op_feq,
...) discovered while developing fneu_once_easy unit test. Fix a typo in
the comment just above that. Add fneu_once_easy test.
v3: Skip the iteration count adjustment tests for nir_op_fenu and
nir_op_ine. Since the iteration count is either 1 or unknown, all this
function can do is add numerical error. Add fenu_once tests.
v4: Change the initial value in the fneu_once test from large positive
to large negative. Change check in get_iteration from nir_op_fsub to
nir_op_fadd. Both changes from discussion with M Henning. Also add some
more explanation in fneu_once.
v5: Rename test cases.
Fixes: 6772a17acc ("nir: Add a loop analysis pass")
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19732>
I discovered this problem because adding an algebraic transformation to
convert some uge and ult to ieq or ine caused a couple loops to stop
unrolling. Consider the loop:
uint i = 0;
while (true) {
if (i >= 1)
break;
i++;
}
This loop clearly executes exactly one time. Note that uge(x, 1) is
equivalent to ine(x, 0). Changing the condition to 'if (i != 0)' will
also execute exactly one time.
In the added test cases, uge_once correctly get an exact loop trip count
of 1. Without the changes to nir_loop_analyze.c, the ine_once case
detects a maximum loop trip count of zero and does not get an exact loop
trip count.
No changes in shader-db or fossil-db.
v2: Move nir_op_fneu changes to a separate commit.
v3: Rename test cases.
Fixes: 6772a17acc ("nir: Add a loop analysis pass")
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19732>
This test comes from a comment in the loop analysis code.
The ine_zero test checks that zero iteration loops involving ine are
correctly identified.
v2: Add ine_zero test. Suggested by Tim.
v3: Rename test cases.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19732>
Fedora's gcc 12.2.1 says:
../src/egl/main/eglapi.c: In function ‘eglDupNativeFenceFDANDROID’:
../src/egl/main/eglapi.c:2268:11: warning: ‘ret’ may be used uninitialized [-Wmaybe-uninitialized]
2268 | EGLint ret;
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19913>
Regalloc can sort it out later. No significant change is shader-db, the
one instruction reduction is likely because some optimize pass can
actually work better when we are closer to ssa-like form.
RV530:
total instructions in shared programs: 133718 -> 133717 (<.01%)
instructions in affected programs: 47 -> 46 (-2.13%)
helped: 1
HURT: 0
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Tested-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19853>
Back when we had a stupid register allocator we did a lot of tricks to
optimize the register usage. The old version of rc_find_free_temporary
did a full program search each time it was called to find out what
registers and channels are actually used and than used that info to give
us the first free register to use.
Now that we have a proper register allocator both for vertex and
fragment shaders, this is no longer needed. Just scan the program when
called for the first time to find the first unused temporary index and
than increment by one everytime. Regalloc can sort it out later.
No change in shader-db confirms this assumption is sound.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Tested-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19853>
There seems to be a problem with running firefox by using Xwayland that
results in a shared resources being not always tagged as using staging.
As a result one process tries to map the resource that was allocated as
one that uses staging without actually using the staging resource, and
hence the mapped range only accounts for the small region that we have
to allocated because a zero-allocation doesn't work, but the application
mapping the resource assumes that a properly sized range is mapped, and
consequently this results in invalid memory access.
To work around this issue disable creating staging for resources that
are created by using shared binding. It is not clear to me whether this
is the best fix, but it seems to quell the issue.
Fixes: c9d99b7eec
virgl: Fix texture transfers by using a staging resource
Related: https://gitlab.freedesktop.org/virgl/virglrenderer/-/issues/291
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19655>
R300/R400 GPUs can't do it in hardware and all the lowering should have
happened in NIR already, there is no point in wasting CPU time, just to
abort later when emitting.
Reduces CPU time for dEQP run by ~25% for RV370. The wallclock time is
now just slighly above 1 minute at 10 threads, mostly determined by the
long-running dEQP-GLES2.functional.flush_finish.* tests.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Tested-by: Filip Gawin <filip@gawin.net>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19766>
Previously only 'decode_vs_state' would dump the referenced shader,
which meant we completely ignored every other shader when decoding
the '3DSTATE_PIPELINED_POINTERS' command.
Move the program disassembly logic from 'decode_vs_state' into a
common 'disasm_program_from_group' helper and call it from every
other decode_*_state function, too.
Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19880>
* load_uniform for sand8_stride is uint32 instead of int32 and its range
is 4 instead of 1 as it is counted in bytes.
* Now we save and restore constant buffer 1 properly for the ubo used
in the blit. We need to take into account that in V3D the first UBO
with index 0 is stored on constant buffer 1, because gallium uses
internally contant buffer 0 (See for reference commit c8212731e7)
* Removed not needed return.
* Added shader information about uniforms, ubos, inputs and outputs.
* Fixed typos in the comments.
Fixes: 95c4f0f910 "v3d: Enables DRM_FORMAT_MOD_BROADCOM_SAND128 support"
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19639>
Implements the support to blit SAND modifier with columns 128-bytes-wide
support for P030 format to P010 with UIF layout. This allows sampling
from H265 10-bit frames exported by the video decoder on the Raspberry
Pi 4 devices.
When a DRM_FORMAT_MOD_BROADCOM_SAND128 is enabled with an imported P030
texture. The sand30 blit converts the Luma and Chroma planes to
a tiled P010 format that can be sampled using gallium YUV lowerings
without the interleaved 128-bytes-wide-columns.
This patch follows a similar approach to SAND8 blit but extracting luma
and chroma components from the DRM_FORMAT_P030 format. P030 is a two
plane YCbCr420 format where 3 10 bit components with 2 padding bits are
packed in 4 bytes.
index 0 = Y plane, [31:0] x:Y2:Y1:Y0 2:10:10:10 little endian
index 1 = Cr:Cb plane, [63:0] x:Cr2:Cb2:Cr1:x:Cb1:Cr0:Cb0
[2:10:10:10:2:10:10:10] little endian
After the sand30_blit is done, the shadow texture is an UIF tiled texture
with an R16_UNORM format for luma and R16G16_UNORM for chroma.
To reduce the number of texture-fetch operations during the blit, we
read pairs of 32-bit dwords. They include 6 10-bit unorm components.
And then we write 4 UNORM16 components from an uvec4 because our render
targets do not support writing to UNORM16 formats.
As sampling will be done using 16bpp (luma) and 32bpp (chroma), the
sand30_blit writes consider the different microtile layouts of UIF
format between 64, 32 and 16 bpp.
v2: Fixes save and recovery of constant buffers (Iago)
Typo corrections. (Iago)
Removed not needed return. (Iago)
Added shader information about uniforms, ubos, inputs and outputs.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19639>
The address itself was already stable assuming that the memory itself was
allocated with capture/replay. Enable the feature flag and add an equality
check to return VK_ERROR_INVALID_OPAQUE_CAPTURE_ADDRESS_KHR on mismatch.
Tested with:
- dEQP-VK.ray_tracing_pipeline.capture_replay.*
- q2rtx gfxrecon replays correctly without major errors.
* There are debug logs about VkBuffers missing opaque address
for unknown reason, however the AS part is confirmed to be correctly
captured.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19841>
Found when 16bit vec3 varying with llvm14 (not found
when llvm15), one 32bit vec4 slot is filled like this:
vec3[0] | undef
vec3[1] | undef
vec3[2] | undef
undef | undef
LLVM error is for the elements with undef:
%287 = insertelement float %280, half %279, i64 0
After this change, we get:
%287 = insertelement <2 x half> %280, half %279, i64 0
Fixes: 279eea5bda ("amd/llvm: Transition to LLVM "opaque pointers"")
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19848>
Flag day change to replace the previous hardcoded background/end-of-tile shaders
and the API-style load/store_output in fragment shaders with the generated
shaders and lowered *_agx intrinsics. This gets us working non-UNORM8 render
targets and working MRT. It's also a step in the direction of working MSAA but
that needs a lot more work, since the multisampling programming model on AGX is
quite different from any of the APIs (including Metal).
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19871>
With multiple render targets, it's not practical to generate all
variants of the background and end-of-tile programs at start up. Rather
than trying, add a hash table of meta program keys to background
programs, and compile variants as they're needed.
With the new infrastructure, it's sensible to handle clears with the
same code path as reloads. In addition to getting us closer to multiple
render target support, this gets us support for non-RGBA8 render
targets, as the u8norm tilebuffer format was baked into the hardcoded
clear shader and store shaders used before.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19871>
Multisampling uses different values of the dimension enum in tandem with a new
samples field. Handle this in agx_pack_texture (split off here) so we can use
the new functionality for texture descriptors in reloads too.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19871>
This hw instruction writes out an entire block from the tilebuffer to an
attached render target (PBE descriptor). It is used (only?) in end-of-tile
shaders to implement write out. We need to handle it in the compiler as a
prerequisite to compiling end-of-tile shaders ourselves, instead of hardcoding.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19871>
Mutlisampled texture fetch (txf_ms) is encoded like regular txf. However, we now
need to pack the multisample index in the right place, which we do by extending
our existing NIR texture source lowering pass. 2D MS arrays use a new value of
dim which requires tweaking the encoding slightly. Otherwise, everything is
bog standard.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19871>
The track_alloc and track_free symbols are used, we need to link them in.
Depending on build flags / environment / etc, fixes the potential build error
hit by a CI job:
mold: error: undefined symbol: agxdecode_track_alloc
>>> referenced by agx_device.c
>>> src/asahi/lib/libasahi_lib.a(src/asahi/lib/libasahi_lib.a.p/agx_device.c.o):(agx_shmem_alloc)>>> referenced by agx_device.c
>>> src/asahi/lib/libasahi_lib.a(src/asahi/lib/libasahi_lib.a.p/agx_device.c.o):(agx_bo_create)
mold: error: undefined symbol: agxdecode_track_free
>>> referenced by agx_device.c
>>> src/asahi/lib/libasahi_lib.a(src/asahi/lib/libasahi_lib.a.p/agx_device.c.o):(agx_bo_unreference)
...when trying to link with libasahi_lib without libasahi_decode for unit tests.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19871>
This avoids exposing the ISA-internal agx_format to the driver, instead hiding
it behind a real PIPE_FORMAT. This lets us use real pipe formats in formatted
intrinsics in NIR, which is convenient; it will allow us to simplify the
compiler/driver ABI; and it lets us use common format helpers (e.g.
util_format_get_blocksize) for the internal formats in driver lowering.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19871>
On blob v512.490, using WRAP_GPU_ID to fake GPU versions, I see 0x41 used
everywhere, except for BLIT_OP_SCALE on a630. Define the magic number in
dev info so it can be reused in the two places that set the
non-BLIT_OP_SCALE value.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19794>
Freeing BOs tends to be bursty (ie. when a submit is retired, or
expiring entries from BO cache). Sending lots of small SET_IOVA
messages to the host can quickly eat up the available virtqueue
slots, resulting in (eventually) starving the guest waiting for
free virtqueue space. By batching, we can avoid this and handle
things more efficiently on the host (ie. in a single wakeup rather
than many).
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19832>
We already have the notion of an agx_batch, which encapsulates a render
pass. Extend the logic to allow multiple in-flight batches per context, avoiding
a flush in set_framebuffer_state and improving performance for certain
applications designed for IMRs that ping-pong unnecessarily between FBOs. I
don't have such an application immediately in mind, but I wanted to get this
flag-day out of the way while the driver is still small and flexible.
The driver was written from day 1 with batch tracking in mind, so this is a
relatively small change to actually wire it up, but there are lots of little
details to get right.
The code itself is mostly a copy/paste of panfrost, which in turn draws
inspiration from freedreno and v3d.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19865>
In 4ceaed7839 we made scratch surface state allocations part of the
internal heap (mapped to STATE_BASE_ADDRESS::SurfaceStateBaseAddress)
so that it doesn't uses slots in the application's expected 1M
descriptors (especially with vkd3d-proton).
But all our compiler code relies on BSS
(STATE_BASE_ADDRESS::BindlessSurfaceStateBaseAddress).
The additional issue is that there is only 26bits of surface offset
available in CS instruction (CFE_STATE, 3DSTATE_VS, etc...) for
scratch surfaces. So we need the drivers to put the scratch surfaces
in the first chunk of STATE_BASE_ADDRESS::SurfaceStateBaseAddress
(hence all the driver changes).
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 4ceaed7839 ("anv: split internal surface states from descriptors")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7687
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19727>
We're about to make scratch surface states part of the surface state
heap. Because those are required to be in the low 26bits parts surface
state heap (we're limited in bits handed in the CFE_STATE, 3DSTATE_VS,
etc... instructions), this change splits the 32bit surface state heap
as follow:
- 8Mb of surface states for scratch
- 1Gb - 8Mb of binding tables
- 3Gb of surface states
That way all of the surfaces are located within a 4Gb region visible
from STATE_BASE_ADDRESS::SurfaceStateBaseAddress
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19727>
So we don't have to do it in the traversal loop. Should 2 and
instructions and a 64-bit shift, so 4/8 cycles per instance node
visit.
Totals from 7 (0.01% of 134913) affected shaders:
CodeSize: 208460 -> 208292 (-0.08%)
Instrs: 38276 -> 38248 (-0.07%)
Latency: 803181 -> 803142 (-0.00%)
InvThroughput: 165384 -> 165376 (-0.00%)
Copies: 4912 -> 4905 (-0.14%)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19706>
Moving entire chunks of code into a dummy if block is causing issues
in some situations. To work around the issue that we tried to fix in
35d82ecf1e ("nir/lower_shader_calls: put inserted instructions into a
dummy block") which is that we cannot cut and past a block of
instruction that ends with a jump if there are more instruction behind
where we're going to past. We can instead just wraps the jumps into
dummy if blocks.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19820>
Obviously there can't *actually* be memoryless render targets, because
how would partial renders work? The control stream with memoryless looks
like everything would if it went to memory (e.g. full 2D MSAA
attachments for the partial loads/stores even if only a resolved
2D image for the final store). Except the memoryless attachments all
load from the same address 0xeeee0000. Clearly that's not actually what
happens, so what gives? Unclear... but I see the magic bits mentioned
here set, and I assume there are some firmware (or kernel) shenanigans
used to JIT allocate the backing storage for partial renders.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19811>
Stencil texturing is easy: S8_UINT is textured like R8_UINT (with a
little swizzle fixup), and stencil is always S8_UINT thanks to
u_transfer_helper. So we just need to do some fixups to make
u_transfer_helper's seperate_stencil work and everything will work out.
Passes dEQP-GLES31.functional.stencil_texturing.*
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19811>
error message:
In file included from ../../src/gallium/drivers/llvmpipe/lp_test_blend.c:44:
../../src/gallium/drivers/llvmpipe/lp_bld_blend.h:47:21: error: ‘enum pipe_blendfactor’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
47 | enum pipe_blendfactor factor_src,
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19676>
error message:
../../src/gallium/auxiliary/tgsi/tgsi_info.h:92:30: error: ‘enum pipe_shader_type’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
92 | tgsi_get_processor_name(enum pipe_shader_type processor);
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19676>
This syncs all our headers with their canonical versions from Khronos.
Of particular note, CL headers repo does not have cl.hpp and cl2.hpp has
been depricated all in favor of opencl.hpp which is the new canonical
header. Fortunately, nothing in Mesa uses any of the C++ headers so
this shouldn't break anything.
Acked-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19816>
Now we always push the inline uniforms, using an indirect CP_LOAD_STATE.
There is just enough space to be able to always push them if we expose
the minimum possible per-stage limits. This aligns us with Qualcomm and
removes the need to setup a uniform descriptor which will be
problematic.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18703>
In the comments we claimed to handle vecN instructions, for the case
where an offset is trimmed from the descriptor, but we didn't ignore the
offset itself and in effect only handled identity vecN's (which copy
propagation would normally remove already!), so the handling of vecN was
useless and this relied on copy propagation cleaning things up. Fix it
to ignore everything except the components in the original source.
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18703>
This case was missed in
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18826 ,
resulting in native Wayland apps failing with
../src/vulkan/wsi/wsi_common_drm.c:452: wsi_configure_native_image: Assertion `!"Failed to find a supported modifier! This should never " "happen because LINEAR should always be available"' failed.
if the Wayland compositor advertises only the INVALID modifier.
Fixes: c315e20d61 ("vulkan/wsi/wayland: Configure images via params passed to wsi_swapchain_init()")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19795>
Set ycbcr feature bits only for ycbcr formats. Besides, we can control
chroma locations only for planar formats and we support
VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_SEPARATE_RECONSTRUCTION_FILTER_BIT
on newer gens.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19609>
The blob driver does not support
VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_SEPARATE_RECONSTRUCTION_FILTER_BIT
before a6xx_gen3. It still sets CHROMA_LINEAR bit according to
chromaFilter, but the bit has no effect before a6xx_gen3 (confirmed on
a618 with blob version 512.490.0).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19609>
iris_bufmgr_init_global_vm() was getting the VM id from the callers
fd not the iris_bufmgr's duplicated fd.
If i915 driver decides to always return unique vm ids, like a counter
that is initialized per device. So fd0 would have vm id = 0 by
default, fd1(dup of fd0) would have vm id = 1... in this scenario it
would cause a mismatch. But it is not the current i915 implementation.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19467>
The intel_perf_counter_pass::pass field is actually useless and
invalid.
Once you have mapped all the counters to all the metrics, the order of
the metrics capture is dictated by intel_perf_get_n_passes().
When reading values that is the order we should follow.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 2001a80d4a ("anv: Implement VK_KHR_performance_query")
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18893>
The 'wget' package was in the list of ephemeral packages used only during the
build. 'Wget' installation comes from the build for the 'x86_build-base', and
the inclusion on this list only affects its purge. Jobs that use this image,
like 'venus-lavapipe' in 'virglrenderer', cannot use it as other GL jobs can.
So, please don't consider this package ephemeral when it comes from the upper
layer builder.
This 'wget' package is a known dependency on a job that uses this image. So,
even if this package is installed in the base image, it is good to have it
explicitly mentioned in the packages to install.
Signed-off-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com>
Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19784>
Using the variable DEBIAN_X86_TEST_IMAGE_PATH in a Vulkan test, we realize the
reference to the Vulkan one is missing. Even more, hardcoded within mesa. With
this, a variable for Vulkan image has a reference VK on it, as well as the GL
one. But the old variable is still there, pointing to the value that can be
expected to avoid any brake on other CI elements.
Also, updated the build tag to regenerate the image.
Signed-off-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com>
Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19784>
__builtin_clz(value - 1) is undefined for with value=1 (because
__builtin_clz(0) is undefined).
Because we set rt_pipeline->stack_size = 1 when a ray tracing pipeline
doesn't need any stack allocation to differentiate from a dynamic size
(rt_pipeline->stack_size = 0) we can run into this undefinied behavior
issue.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: f68d64dac0 ("anv: Add support for vkCmdSetRayTracingPipelineStackSizeKHR")
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19781>
We need to flush the appropriate batch(es in the future) before a synchronized
transfer for correct results. To do so without major performance regressions, we
need to do extra bookkeeping about which batches write which resources. We
already know about reads via the BO list.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19606>
We don't need to do the command list destroy/re-create dance if the
only reference to an allocator is a *closed* command list. Using
CreateCommandList1 gives us a closed command list to start with,
which better matches the semantics of Vulkan's begin/end for
command buffers.
Now that dzn's cmdbuf reset logic puts the cmdbuf back to the
*initial* state, move the command list reset to BeginCommandBuffer.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19537>
It is not possible to rewrite it to a native swizzle later on R300/R400.
The way the native rewrite currently works, it will create bunch of
movs with the given presubtract and partial swizzles, however no
constant swizzle for presubtract source exists so it is just not
possible to rewrite it.
This prevents an infinite loop in supertuxkart shader when we really
start enforcing the presubtract swizzle limitations during native
swizzle rewrite in the next commit.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Tested-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19764>
The problematic scenario is when we have the same source used by both
normal and presubtract argument. We check that case currently and count
the source only once. However if one of the arguments uses a non-native
swizzle, we have to rewrite it later and the source changes. Therefore
we end with too many sources and fail later during pair translation.
Example:
ADD temp[21].xy, temp[20].xy__, temp[17].xy__;
MAD temp[22].xy, temp[17].zw__, temp[11].xy__, temp[21].xy__;
will get converted to
MAD temp[22].xy, temp[17].zw__, temp[11].xy__, (temp[17] + temp[20]).xy__;
however after dataflow swizzles pass we end with
MOV temp[3].x, temp[17].z___;
MOV temp[3].y, temp[17]._w__;
MAD temp[22].xy, temp[3].xy__, temp[11].xy__, (temp[17] + temp[20]).xy__;
Just skip the "don't count the same source twice" optimization when a
non-native swizzle is used to fix 2 dEQP atan2 tests.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Tested-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19764>
Refactor accesses to batch->resources to happen through safe helpers
that update the appropriate bookkeeping. This makes it obvious that (in
particular) reference counts are updated when they should be.
The functional change is that we are now correctly unreferencing
resources during shadowing, fixing a leak of shadowed resources.
Closes: #7362
Fixes: 2d8f28df73 ("panfrost: Replace resource shadowing flush")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reported-by: Mastodon, apparently
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19753>
From the Vulkan spec:
"Sample shading is enabled if at least one of the following
conditions is true:
- VkPipelineMultisampleStateCreateInfo::sampleShadingEnable is
set to VK_TRUE, or
- the fragment shader’s entry point interface includes input
variables decorated with a BuiltIn of SampleId or SamplePosition
built-ins."
We don't need to pass the number of rasterization samples, checking
for sample shading is enough. This will help for dynamic rasterization
samples.
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/19654>
Similar idea to commit ("c9db71c8ba1 turnip: Don't disable LRZ for color
write mask channels beyond the format's"), but different implementation.
If the blend state masks writes to a color channel that doesn't exist,
that doesn't mean we need to disable LRZ write. In particular, this
scenario will come up with z-prepasses (doh!)
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19710>
Unconditionally lowering prevents GL drivers from natively
implementing these ops. Drivers that need lowering should set
lower_uadd_carry and lower_usub_borrow on nir_shader_compiler_options to
get the nir lowerings.
Tested with dEQP-GLES31.functional.shaders.builtin_functions.integer.*
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19704>
Calling sched_setscheduler twice every sample period has high CPU
overhead. For intel and panfrost, their dump_perfcnt is preemptible and
they don't need the scheduler change.
For freedreno, simply makes the main thread RT at all time. This solves
most of the cpu overhead issue.
v2: removed pthread_t param and just change the scheduler for the
calling thread
Acked-by: Rob Clark <robdclark@chromium.org> (v1)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19668>
Even though the defines in p_config.h are stared with PIPE_, they are indeed
are generic detecting mechanics, we will rename them to DETECT_* in latter MR
We rename src/gallium/include/pipe/p_config.h src/util/detect_arch.h because
the detect code in src/gallium/include/pipe/p_config.h are most about
processor architecture detecting.
The file util/detect.h is added to replace functional of src/gallium/include/pipe/p_config.h
So we replace of #include "pipe/p_config.h" with #include "util/detect.h"
The file util/detect_cc.h is added as a placeholder for moving compiler related macro defines
from p_config.h into it in following commits
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19674>
Use the optimization pass to try to remove them, and if that fails,
at least use the core nir lowering pass which is better about fixed-
size memcpys compared to the one we wrote for DXIL.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19752>
It makes little sense to document the gallium envvars in multiple
places. Let's merge them all into the root envvar document.
This also moves GALLIUM_OVERRIDE_CPU_CAPS to toe root envvars doc, as
it's more generic than just LLVMpipe.
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19593>
Sphinx thinks the equals sign and the stuff that follows are parts of
the role, leading to warnings in nit-picky mode, as well as missing
links in the rendered result. Let's fix that by inserting some
whitespace.
While we're at it, fixup an incorrectly quoted literal.
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19593>
The custom envvar directive is strange. It overloads the global
namespace, where there's already a well-known envvar directive, but the
envvar role won't resolve to envvars defined using the custom directive.
It's not really critical to declare the type and default value here, and
many descriptions already include this. Let's just use the plain one,
and let the description take care of the details where needed.
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19593>
Since b29fe26d43 ("etnaviv: rework ZSA into a derived state") the PE
depth config is adjusted by etna_update_zsa() when the shader is changed.
When the PE depth config is actually changing as a result of this
adjustment the ZSA state is dirtied, so there is no need to emit the
state unconditionally when the shader is changed.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19686>
In linear PE mode the early and late depth stage do not only disagree
about the cache layout, but they seem to fundamentally disagree about
the buffer layout. When Z was written via the late stage, early tests
always show spurious zfails, even if they are not in the same draw
call. Cache flushing and pipe stalls don't help in that case.
The only option to get reliable Z tests with linear render targets is
to move all Z handling into the PE stage. Even when early Z writes
are possible, we don't know if any other draw to the same surface
needs late Z handling, so we must never use the early stage.
Fixes: 53445284a4 ("etnaviv: add linear PE support")
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19686>
Apparently MSAA doesn't only add another input, but it also increases
required temporaries by one. Simple programs where the register demand
is given by the number of inputs did work fine, while more complex ones,
where register demand is given by the number of temporaries exhibit
rendering issues without this fix.
Cc: 22.3 mesa-stable
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19582>
reserve() in rtasm_x86sse compares a pointer difference with some
integers to check if reallocation is needed.
It unfortunately groups the first pointer with an int, which makes it
possible to hit nullptr-with-nonzero-offset under Undefined Behavior
Sanitizer.
This patch suggests a reordering of the arithmetic expression so that
first the pointer difference is computed, and from that on it's just a
usual integer arithmetic, avoiding nullptr-with-nonzero-offset.
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18522>
We should not use "nuw" here as negative add positive may wrap
around (negative is 0xffffff??).
This problem can be observed with LLVM15 (I can't see when LLVM14):
%.neg = mul nsw i32 %31, -4
%163 = add nuw nsw i32 %.neg, 16
%164 = lshr i32 257, %.neg
%165 = lshr i32 %164, %163
LLVM just assume %.neg is possitive, so pre-shift 0x01010101 by 16.
This get wrong value because we can't get back the shifted bits with
a negative shift right.
Fixes: 75dbb40439 ("ac/nir: Remove byte permute from prefix sum of the repack sequence.")
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19718>
In 23c7142cd6 ("anv: disable SIMD16 for RT shaders") we were forcing the SIMD8
using the mechanism for subgroup size control, which is problematic since it has
other effects on the shader behavior.
The code was changed to select the SIMD in a different way in the previous patches,
so we can revert the behavior to the original semantics.
Fixes dEQP-VK.subgroups.builtin_var.ray_tracing.subgroupsize.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19601>
This fixes GALLIVM_DEBUG=asm for compute shaders, changing
the hooks after dumping causes a segfault because the
memory has already been finalised. Just add the hooks always,
and before dumping anything.
Fixes: f511d2a553 ("gallivm: rework coroutine malloc/free callouts.")
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19714>
Direct3D and Vulkan's robustBufferAccess2 feature mandate that index
buffer out-of-bounds reads should return a zero index (ie, vertex at
index zero, not to be confused with a vertex with zero attributes, as
the kind resulting in vertex buffer out-of-bounds read.)
lavapipe was adding index_offset and start index together without
overflow checks, and if start index was sufficient large (as is the case
with WHCK wgf11draw which sets start index to (UINT)-5) it would cause
to wrap around causing fetches that should be out of bounds wrap around
and fetch inside bounds.
This change fixes this by doing a clamped add. This ensures start index
is set to UINT32_MAX on overflow, which is sufficient in practice to
trigger draw index OOB code-paths, yield zero index to be returned.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19683>
The code builds up the dynamic array of objects (spirv_objs) and
collect pointers to each of them into another dynamic
array (spirv_ptr_objs).
If the growth of the first array cause a reallocation, it is
possible that the previous pointers end up invalid.
Fixes: 77e929a527 ("intel/clc: allow multiple CL files to be compiled together")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19730>
After 'v3dv: fix debug dump on BO free' we changed the order, and this
lead to the following test
dEQP-VK.api.object_management.multithreaded_per_thread_resources.device_memory_small
v2: Expanded comment just before the reset, explaining that we need to
do the reset before we free the BO from the kernel (Iago)
Raising this assertion:
deqp-vk: ../src/broadcom/vulkan/v3dv_bo.c:281: v3dv_bo_alloc: Assertion `bo && bo->handle == 0' failed.
Fixes: 2c44597181 ('v3dv: fix debug dump on BO free')
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19693>
This reverts commit cb02cf464c.
There are 3 reported flakes over a period of a month, and we have been
unable to reproduce it even once. It clearly doesn't happen often enough
to warrant disabling our vulkan CI, so let's restore it while we
continue to try to reproduce the issue on our side.
Signed-off-by: Eric Engestrom <eric@igalia.com>
Acked-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19720>
We only support lazy descriptors these days, so having the
infrastructure around to support automatic selection of that one mode is
kinda silly.
And it's not like setting an environment variable that is never read is
going to cause any issues, so we don't even need this to avoid breaking
existing setups.
Let's just rip it out. We can reintroduce it again on the off-chance
that someone has a new clever descriptor mode they want to experiment
with.
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19670>
This is a port of the fp pair regalloc. It is however much simpler as
contrary to the fp, we don't have to care about texturing, we can use
any swizzle we want and we don't have to track the inputs. Using the
register class machinery might actually be a slight overkill right now,
however the infrastructure will hopefully come in handy if someone
decides to implement the vp pair scheduling eventually.
Shader-db stats:
RV530:
total temps in shared programs: 18594 -> 17000 (-8.57%)
temps in affected programs: 5753 -> 4159 (-27.71%)
helped: 665
HURT: 0
RV370:
total temps in shared programs: 13555 -> 12181 (-10.14%)
temps in affected programs: 5116 -> 3742 (-26.86%)
helped: 633
HURT: 0
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5972
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Tested-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19618>
This function is used by rc_variable_change_dst when rewriting variables
and even though we don't need to rewrite the index for RC_FILE_NONE, we
still need to properly reswizzle.
All other users of the function are properly checking for RC_FILE_NONE
later.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Tested-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19618>
The SPIR-V parser catches its failures and failed assertions, clean up
and return a failure to the caller. This is a good default behavior, but
when debugging sometimes is useful to hook the debugger right in the
failed assertion.
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19663>
Fixes the following error I noticed when building against aarch64 with
musl libc:
In file included from ../src/freedreno/decode/crashdec.h:38,
from ../src/freedreno/decode/crashdec.c:40:
../src/freedreno/common/freedreno_pm4.h:104:15: error: unknown type name 'uint'
104 | static inline uint
| ^~~~
../src/freedreno/common/freedreno_pm4.h:105:25: error: unknown type name 'uint'; did you mean 'int'?
105 | pm4_calc_odd_parity_bit(uint val)
| ^~~~
| int
Signed-off-by: Jami Kettunen <jami.kettunen@protonmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19665>
In a lot of situations the previous exec value was already copied from the
same registers that exec should be saved to. In that case we don't have to
insert an extra copy to save exec.
This breaks ssa but this pass is going out of ssa anyway.
Foz-DB Navi21:
Totals from 16129 (11.96% of 134913) affected shaders:
CodeSize: 128184044 -> 128054468 (-0.10%)
Instrs: 23902694 -> 23870325 (-0.14%)
Latency: 387124324 -> 387095955 (-0.01%); split: -0.01%, +0.00%
InvThroughput: 79949118 -> 79945859 (-0.00%); split: -0.01%, +0.00%
Copies: 1620768 -> 1588752 (-1.98%); split: -1.99%, +0.01%
Foz-DB Vega10:
Totals from 15546 (11.51% of 135041) affected shaders:
CodeSize: 120322524 -> 120200568 (-0.10%)
Instrs: 23448344 -> 23417855 (-0.13%)
Latency: 414018749 -> 413639289 (-0.09%); split: -0.09%, +0.00%
InvThroughput: 183819363 -> 183726539 (-0.05%); split: -0.05%, +0.00%
Copies: 2194937 -> 2164448 (-1.39%)
Signed-off-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18528>
We want to encode special messages into the CS that can be printed
by cffdec, these messages have identifiers that describe their
usage (message, scope begin and scope end) which allow for an
improved trace navigation experience due to the additional
information.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18271>
Viewing CS traces retrieved from the driver is common practice to
determine driver bugs but there is no way to determine what
function a certain part of the CS was emitted by. This is crucial
information to determine what function is responsible for emitting
broken CS packets and to help with navigation of the CS trace.
Signed-off-by: Mark Collins <mark@igalia.com>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Ack-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18271>
All environment variables involved in utrace usage were very
fragmented and convoluted to decode the meaning of, this commit has
simplified them down into easier to understand flags which directly
indicate the resulting behavior (such as `perfetto` enabling queued
logs rather than needing to set a `queued` flag) while combining
them into a single envvar `GPU_TRACES` and updating existing
terminology in utrace to match up with the new options.
Signed-off-by: Mark Collins <mark@igalia.com>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Ack-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18271>
All arguments in Turnip code are fit to be moved to the start
event where they fit better as any sequential logging should print
the arguments with the scope start as it makes more sense than
printing arguments with the end of a scope.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18271>
This prevents segfaults running wgf11draw DrawMethod=DrawIndexed tests
cases.
This change is not, however, sufficient to pass all tests. That is,
there must remain code paths where indices read beyond the end of the
index buffer do not return zero index.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19648>
On Intel HW we use the same mechanism for internal operations surfaces
as well as application surfaces (VkDescriptor).
This change splits the surface pool in 2, one part dedicated to
internal allocations, the other to application VkDescriptors.
To do so, the STATE_BASE_ADDRESS::SurfaceStateBaseAddress points to a
4Gb area, with the following layout :
- 1Gb of binding table pool
- 2Gb of internal surface states
- 1Gb of bindless surface states
That way any entry from the binding table can refer to both internal &
bindless surface states but none of the driver allocations interfere
with the allocation of the application.
Based off a change from Sviatoslav Peleshko.
v2: Allocate image view null surface state from bindless heap (Sviatoslav)
Removed debug stuff (Sviatoslav)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7110
Cc: mesa-stable
Tested-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19275>
For drivers already using vk_common_ResetCommandBuffer(), it now only
calls the driver's reset hook if the command buffer is not in the
INITIAL state. Pulled this trick from the PowerVR driver.
v2 (Jason Ekstrand):
- Rename from "status" to "state" since that's what's in the spec
- Add vk_command_buffer_begin/end instead of drivers setting it all
manually
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16922>
We know cmdstream buffers are immediately mmap'd, which is both
expensive on the host, and breaks the pipelining as guest is forced
to stall waiting for the host. So pre-allocate some cmdestream
buffers, so that we have something that is (hopefully) already
allocated and mapped to guest's physical memory before we need it.
The older buffer from the head of the prealloc list replaces the
newly allocated buffer which is pushed to the tail of the prealloc
list.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19656>
Since we're not doing anything fancy, we can just use `subprocess.run`.
I've also removed the custom error class, we're not going to catch it,
so just printing and exiting is fine.
v2:
- Print stdout as well as stderr in case of a glslang failure
Reviewed-by: Luis Felipe Strano Moraes <luis.strano@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19449>
I'm not 100% sure whether it's right to make --vn required, or to avoid
the static conversion, but this seems correct. Mypy (type checking
coming soon) points out that if --vn is None then the
convert_to_static_variable function will fail. Our one use of this sets
--vn, so there is no change there. Making --vn required
ensures that it will never be None, avoiding the problem.
Reviewed-by: Luis Felipe Strano Moraes <luis.strano@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19449>
aztec_ruins under ANGLE was getting LRZ writes disabled because 0xf out of
the 0x3 mask was enabled. The goal was to see if there are partial writes
being done, though. This caused a 2-3% performance regression.
Fixes: 85d0205db1 ("tu: Implement extendedDynamicState3ColorWriteMask")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19635>
The nir_opt_algebraic() call to clean up nir_lower_imul's split up mul
operations (stuff like "the top 16 bits were 0, no need to mul and add
that part") would trigger the options->fuse_ffma_* early ffma splitting,
so you need to call nir_opt_algebraic_late() again after that (which, in
turn, requires a DCE).
Gets us a lot more ffmas in Aztec Ruins high under zink/angle, but doesn't
seem to change perf.
shader-db highlights:
total instructions in shared programs: 11574843 -> 10999629 (-4.97%)
instructions in affected programs: 3308870 -> 2733656 (-17.38%)
total dwords in shared programs: 24344722 -> 23230122 (-4.58%)
dwords in affected programs: 6569568 -> 5454968 (-16.97%)
total full in shared programs: 762616 -> 762224 (-0.05%)
full in affected programs: 15505 -> 15113 (-2.53%)
total stp in shared programs: 4046 -> 4050 (0.10%)
stp in affected programs: 3372 -> 3376 (0.12%)
total ldp in shared programs: 2166 -> 2170 (0.18%)
ldp in affected programs: 1716 -> 1720 (0.23%)
total (ss) in shared programs: 219541 -> 216261 (-1.49%)
(ss) in affected programs: 23227 -> 19947 (-14.12%)
total (sy) in shared programs: 101633 -> 101927 (0.29%)
(sy) in affected programs: 8611 -> 8905 (3.41%)
total waves in shared programs: 1501942 -> 1501772 (-0.01%)
waves in affected programs: 1880 -> 1710 (-9.04%)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18946>
If we're in handle_collect()'s dst allocation and are part of a merge set
near the end of the file, our check for reg_elem_size(reg) would let us
use the preferred reg when that would immediately lead to
allocate_dst_fixed() creating an interval extending thruogh reg_size(reg)
that overflows the file.
Avoids a regression on gfxbench5/gl_5_high_off/17.shader_test in the next
commit. No change on shader-db.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18946>
This should make it easier to keep links in our docs up-to-date.
But, because links can die behind our backs, we can't really enable this
all over the place, or we'll risk blocking merge-requests due to
unrelated changes.
So let's just make this a periodic job on the main branch instead.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19574>
There's a *lot* of relnotes, and we don't really actively maintain them.
Let's drop linkchecking them to speed things up a bit.
This does a whole lot of nothing unless you have Sphinx 4.4 or newer.
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19574>
The use of a hash symbol in a URI is an anchor, not to indicate an IRC
channel name. This confuses the Sphinx linkchecker.
Dropping the hash here still makes the link work fine, so let's just do
that.
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19574>
Here's a few redirects that we should apply, in case the redirects
gets removed in the future.
These are mostly of the 301 (moved permanently) kind, but also a
few where the site probably *should* have used the permanent
error-code.
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19574>
Sphinx can be a bit overly eager at interpreting text with colons in it
as URLs. There's a few cases in our older relnotes where this happens, so
let's escape them to avoid strange, broken links in the rendered output.
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19574>
While Panfrost allocates linear images with strides that are a multiple of 64
bytes, other dma-buf producers on the system may not satisfy this requirement.
However, at least on v7 and newer, any image with a regular format must have a
stride that is a multiple of 64 bytes.
This fixes a real bug in an application that created a linear R8_UNORM image
with stride 480 bytes, imported it as an EGL_image, and then tried to texture
from it with the GPU. Previously, the driver allowed this situation but it
resulted in an imprecise fault from the GPU. This patch corrects the driver to
reject the import as invalid due to the unaligned stride, ensuring we never
attempt to texture from such a resource.
To implement, we add some new layout queries to centralize knowledge about the
stride alignment requirements, and we sprinkle in asserts to show how the
invariant is upheld throughout the lifecycle of image creation to texturing.
Cc: mesa-stable
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19620>
For 2D UI workloads and even most 3D workloads, the indirect dispatch shader
won't actually be needed, but we currently compile it during eglInitialize() on
every v7 application. That hurts app start-up time, especially given that this
shader doesn't hit the disk cache. We can instead defer compiling this shader
until it's actually needed, when glDispatchComputeIndirect() gets called.
The tradeoff is that the first glDispatchComputeIndirect() call will be (much)
slower than successive calls, since we need to build and compile this internal
shader. I'm unconvinced that's a problem in practice.
An app would need to call glDispatchComputeIndirect for the first time in the
middle of a scene. 2D apps never would call that, OpenCL doesn't have that, and
GL compute will have the same costs just moved around. So it's down to a 3D
GLES3.1 app that indirectly dispatches compute for the first time time in the
middle of a scene. Which, meh? It's not entirely implausible but we have bigger
fish to fry, and this fixes a real problem (about 5% of eglInitialize time spent
building this shader that won't actually get used).
es2_info starts slightly faster with this change.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19622>
* The pvr_finishme() in pvr_CreateImage() was added before vk_image_create() was
being used and is no longer relevant.
* There's nothing special we need to do for the graphics pipeline flags and
we don't currently store anything in the pipeline cache, so there's nothing
to finish here.
* The firmware interface now uses fixed sized structures, so remove related
FIXME.
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19578>
This mirrors all the other *_FARM variables, and allows developers to
quickly disable all the jobs that would otherwise run on Valve's CI
infrastructure by setting it to the 'offline' value.
To this end, .radv_rules gets split into .radv-collabora-rules and
.radv-valve-rules, since the driver will be testable in two different
test farms. Every radv job is then made to inherit from the right farm.
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19556>
With support for MRT in the driver (not included here), passes:
dEQP-GLES31.functional.shaders.builtin_functions.integer.imulextended.int_highp_fragment
dEQP-GLES31.functional.shaders.builtin_functions.integer.umulextended.int_highp_fragment
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19590>
Otherwise the registers "leak", bloating register pressure by
arbitrarily large amounts. This is easy to handle in DCE by rewriting to
a null destination, though we could use a sideband channel if we didn't
want null destinations in the IR.
glmark2 subset of shader-db is much improved:
total instructions in shared programs: 7324 -> 7313 (-0.15%)
instructions in affected programs: 483 -> 472 (-2.28%)
helped: 5
HURT: 2
total bytes in shared programs: 42788 -> 42722 (-0.15%)
bytes in affected programs: 2808 -> 2742 (-2.35%)
helped: 5
HURT: 2
total halfregs in shared programs: 2421 -> 2058 (-14.99%)
halfregs in affected programs: 1235 -> 872 (-29.39%)
helped: 28
HURT: 0
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19590>
Some review feedback of an earlier commit caused me to rearrange some
code quite a bit. I wasn't paying enough attention while applying the
later commits, and these breaks should have been returns. As it is, the
result of the imin or imax analysis is overwritten by the default case
handling... effectively the original commit does nothing. :(
Tiger Lake and Ice Lake had similar results. (Ice Lake shown)
total instructions in shared programs: 19914090 -> 19904772 (-0.05%)
instructions in affected programs: 121258 -> 111940 (-7.68%)
helped: 445 / HURT: 0
total cycles in shared programs: 855291535 -> 855266659 (<.01%)
cycles in affected programs: 2737005 -> 2712129 (-0.91%)
helped: 426 / HURT: 17
LOST: 0
GAINED: 3
Skylake and Broadwell had similar results. (Skylake shown)
total cycles in shared programs: 842395356 -> 842338259 (<.01%)
cycles in affected programs: 5460985 -> 5403888 (-1.05%)
helped: 458 / HURT: 0
Haswell and Ivy Bridge had similar results. (Haswell shown)
total instructions in shared programs: 16710449 -> 16708449 (-0.01%)
instructions in affected programs: 44101 -> 42101 (-4.54%)
helped: 75 / HURT: 0
total cycles in shared programs: 882760230 -> 882727923 (<.01%)
cycles in affected programs: 2867797 -> 2835490 (-1.13%)
helped: 62 / HURT: 10
No shader-db change on any other Intel platform.
No fossil-db changes on any Intel platform.
Fixes: 5ec75ca10d ("intel/compiler: Teach signed integer range analysis about imax and imin")
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19602>
Important for upcoming kernel changes to more correctly manage the CE
context on Volta and newer, or the channel will be killed in response
to a CTXNOTVALID error from the GPU.
The kernel will have a workaround for Volta and Turing GPUs to preserve
ABI, but will require userspace to behave correctly on Ampere and newer.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Acked-by: M Henning <drawoc@darkrefraction.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17633>
This can cause us to stomp the contents of r5 before we have a chance to read
it, like this:
0x3d103186bb800000 nop ; nop ; ldvary.r0
0x3d105686bbf40000 nop ; mov rf26, r5 ; ldvary.r1
0x020000ef0000d000 bu.allna 232, r:unif (0x0000001c / 0.000000)
0x3d1096c6bbf40000 nop ; mov rf27, r5 ; ldvary.r2
Here, the MOV in the last instruction is supposed to read r5 produced from
ldvary.r0, but because we have inserted the bu instruction in between now
that read happens at the same time that ldvary.r1 updates r5, stomping the
value we were supposed to read.
Fix this by disallowing injection of a branch instruction in between an ldvary
instruction and its write to the r5 register 2 instructions later.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7062
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19616>
This prevents nir_lower_io_to_temporaries from emitting new writes to the
old globals that we meant to have disappear through
DCE/remove_unused_variables. If you don't do this, then unless you call
nir_opt_undef() and it successfully catches io_to_temps' new writes of
undefs to the scalar components, the scalar vars will stick around and
have stores that conflict with the real vector vars.
This hasn't been a problem for the end result of codegen because
nir_opt_undef() did succeed. However, things went south with vars_to_ssa
mediump lowering, which obscured the result from opt_undef. And, it's
really mind-bending to see undef writes to the outputs for a chunk of the
shader compiler pipeline anyway.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18218>
The back-end swizzles dwords so that our indirect scratch messages match
the memory layout of spill/fill messages for better cache coherency.
The swizzle happens at a DWORD granularity. If a read or write crosses
a DWORD boundary, the first bit will get correctly swizzled but whatever
piece lands in the next dword will not because the scatter instructions
assume sequential addresses for all bytes. For DWORD writes, this is
handled naturally as part of scalarizing. For smaller writes, we need
to be sure that a single write never escapes a dword.
Fixes: fd04f858b0 ("intel/nir: Don't try to emit vector load_scratch instructions")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7364
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19580>
Because dup_mem_intrinsic() retains the SSA offset from the original
intrinsic and only modifies it by adding a constant, we can compute the
alignment based on the original alignment and the constant offset. This
is both easier and more accurate.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19580>
If an application was transitioning out of fullscreen exclusive
display mode, the wsi_display_connector->active state was not
reset in vkReleaseDisplay() from fullscreen. When the app then
later tried to go to fullscreen display mode again on the same
display output with the same video mode, this caused
_wsi_display_queue_next() to skip a required drmModeSetCrtc()
during the first vkQueuePresent() after entering direct display
mode.
While this often worked by pure luck on a single-display setup,
it goes sideways on a multi-display setup where the viewport
of the associated crtc does not have a (x,y) offset of (0,0).
E.g., XOrg/X11 RandR output leasing of an output whose viewport
starts at x = 1920:
1. X-Server has RandR outputs viewport at x = 1920, in a shared
framebuffer, shared across all crtc's on a X-Screen.
2. Application leases that output for direct display mode,
1st vkQueuePresent() triggers drmModeSetCrtc() of output
to (x,y) = 0,0, as required for Vulkan/wsi/direct framebuffer
setup.
3. Application does rendering and presenting.
4. Application vkReleaseDisplay() the output, terminates the
RandR lease. X-Server takes over again.
5. X-Server modesets to reconfigure output back to viewport
with (x,y) = 1920, 0.
6. Application leases same output again later on, and tries
vkQueuePresent() again. Because of the bug fixed in this
commit, the required drmModeSetCrtc() to (x,y) = 0,0 is
erroneously skipped due to the stale cached connector state.
7. drmModePageflip() fails due to the wrong crtc viewport
(x,y) = 1920, 0, mismatched for the need of the Vulkan
framebuffer of (x,y) = 0,0. Kernel returns -ENOSPACE,
Swapchain goes into permanent VK_ERROR_SURFACE_LOST state.
Destroying and recreating the swapchain, as recommended
by the Vulkan spec for error handling won't help. Game over!
Resetting wsi_display_connector->active = false; fixes the
problem of wrong / stale connector state and Vulkan/wsi/display
clients are happy on multi-display setups again, as tested
in various single- and multi-display configurations.
This bug affects all Mesa releases with Vulkan/WSI/Display
support and should therefore be backported.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Fixes: 352d320a07 ("vulkan: Add EXT_direct_mode_display [v2]")
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19484>
Without additional signalling of modifiers, CRCs cannot possibly in a correct
way work across process boundaries. Since we don't do that signalling, we should
not be allocating private CRCs for imported resources, and we should not be
using our own private CRCs for internal resources.
The entire out-of-bands CRC infrastructure is a hack to let us do CRCs even for
imported/exported BOs, but that can't possibly work. Remove it, and remove a
pile of special cases across the driver.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19576>
If the map doesn't set MAP_DISCARD_RANGE, we do have to copy the existing
contents over. MAP_WRITE on its only gives permission to replace the contents,
unfortunately it does not require that the application actually do so.
Closes: #7640
Fixes: 0b26a9f773 ("panfrost: Don't copy resources if replaced")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reported-by: Roman Elshin
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19576>
Vulkan has VkChromaLocation and all drivers suggest
VK_CHROMA_LOCATION_MIDPOINT on Android. The blob also uses MIDPOINT.
Based on my limited tests, the image quality is higher with MIDPOINT.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19514>
This seems to have no effect on a618, but restores linear filtering on
a635 when the texture is yuv. The blob sets it on a635 as well (but not
on a618).
Fixed android.media.cts.DecodeAccuracyTest#* on a635.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19514>
Since we expect a limited # of unique border-color entry states, we can
use a global table of border-color entries, rather than constructing the
state at draw time. This shifts all the border-color overhead from draw
time to sampler state CSO creation time. And it's less code!
A hashtable is used to map unique border-color table value to entry so
multiple usages of what maps to the same table entry all re-use a single
slot in the table. This puts an upper bound on the # of unique border-
color plus format value. In practice this shouldn't be a problem, we'll
just size the table to be large enough to not run into problems with
CTS. Note that the border-color table entry is not completely format
dependent (mostly just integer vs float dependent), so for example a
single color with different float formats can map to a single table
entry.
This also fixes the problem that we completely ignored border-color for
GS/tess stages.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7518
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19561>
With the current scheme, looking at game startup which should be the
worst case (most heavily loaded) time for the compiler threads, and they
seem to be ~10% busy. Furthermore we typically have a mix of "big" and
"LITTLE" cores.. with about half being "big". So sizing the thread pool
to the half the # of CPU cores seems reasonable.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19387>
Android's implementation of the blob-cache get/put funcs do not
implement any compression. And the default cache size is rather small,
at 2MB (!!) per app (although I assume everyone patches android to
increase the size limit).
We don't bother compressing the has_key/put_key path, since that path is
only storing a uint32_t.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19387>
It turns out that this actually is supported. GMEM can hold multiple
layers which are cleared, loaded, and resolved separately. The stride
between layers seems to be implicitly calculated based on the tile size,
and we have to match it when blitting to/from GMEM. One tricky thing is
that now we may realize that we don't have enough space for GMEM only
when computing the tiling config, because we may not know the number of
framebuffer layers until we have the framebuffer and too many
framebuffer layers will exhaust GMEM.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19505>
Many Intel platforms can only perform 32x16 bit multiplication. The
straightforward way to implement 32x32 bit multiplications is by
splitting one of the operands into high and low parts called H and L,
repsectively. The full multiplication can be implemented as:
((A * H) << 16) + (A * L)
On Intel platforms, special register accesses can be used to eliminate
the shift operation. This results in three instructions and a temporary
register for most values.
If H or L is 1, then one (or both) of the multiplications will later be
eliminated. On some platforms it may be possible to eliminate the
multiplication when H is 256.
If L is zero (note that H cannot be zero), one of the multiplications
will also be eliminated.
Instead of splitting the operand into high and low parts, it may
possible to factor the operand into two 16-bit factors X and Y. The
original multiplication can be replaced with (A * (X * Y)) = ((A * X) *
Y). This requires two instructions without a temporary register.
I may have gone a bit overboard with optimizing the factorization
routine. It was a fun brainteaser, and I couldn't put it down. :) On my
1.3GHz Ice Lake, a standalone test could chug through 1,000,000 randomly
selected values in about 5.7 seconds. This is about 9x the performance
of the obvious, straightforward implementation that I started with.
v2: Drop an unnecessary return. Rearrange logic slightly and rename
variables in factor_uint32 to better match the names used in the large
comment. Both suggested by Caio. Rearrange logic to avoid possibly
using `a` uninitialized. Noticed by Marcin.
v3: Use DIV_ROUND_UP instead of open coding it. Noticed by Caio.
Tiger Lake, Ice Lake, Haswell, and Ivy Bridge had similar results. (Ice Lake shown)
total instructions in shared programs: 19912558 -> 19912526 (<.01%)
instructions in affected programs: 3432 -> 3400 (-0.93%)
helped: 10 / HURT: 0
total cycles in shared programs: 856413218 -> 856412810 (<.01%)
cycles in affected programs: 122032 -> 121624 (-0.33%)
helped: 9 / HURT: 0
No shader-db changes on any other Intel platforms.
Tiger Lake and Ice Lake had similar results. (Ice Lake shown)
Instructions in all programs: 141997227 -> 141996923 (-0.0%)
Instructions helped: 71
Cycles in all programs: 9162524757 -> 9162523886 (-0.0%)
Cycles helped: 63
Cycles hurt: 5
No fossil-db changes on any other Intel platforms.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17718>
This is especially helpful for a*isign(a) generated by idiv_by_const
optimization. On many GPUs, isign(a) is lowered to imax(imin(a, 1),
-1).
There are no changes on fossil-db because ANV uses a different
optimization path for idiv with a constant denominator. A future MR
will change this.
NOTE: This commit used to help a few hundred shader-db shaders, but
now none are affected. I suspect this is due to some change in the
idiv_by_const optimization. This could possibly be dropped.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17718>
Only iabs and ineg are treated specially. Everything else just uses
nir_unsigned_upper_bound. The special treatment of source modifiers is
because they cause problems for nir_unsigned_upper_bound. Once those
are peeled off, nir_unsigned_upper_bound can generally produce a
tighter bound.
Future commits will add more opcodes. This mostly introduces the
basic framework.
v2: Add a bunch of comments to signed_integer_range_analysis. Re-arrange
the code a little to reduce duplication. Both suggested by
Caio. Rearrange some logic to simplify things. Suggested by Marcin.
Tiger Lake, Ice Lake, Haswell, and Ivy Bridge had similar results. (Ice Lake shown)
total instructions in shared programs: 19912894 -> 19912558 (<.01%)
instructions in affected programs: 109275 -> 108939 (-0.31%)
helped: 74 / HURT: 0
total cycles in shared programs: 856422769 -> 856413218 (<.01%)
cycles in affected programs: 15268102 -> 15258551 (-0.06%)
helped: 65 / HURT: 4
total fills in shared programs: 8218 -> 8217 (-0.01%)
fills in affected programs: 1171 -> 1170 (-0.09%)
helped: 1 / HURT: 0
Skylake and Broadwell had similar results. (Skylake shown)
total cycles in shared programs: 845145547 -> 845142263 (<.01%)
cycles in affected programs: 15261465 -> 15258181 (-0.02%)
helped: 65 / HURT: 0
Tiger Lake
Tiger Lake
Instructions in all programs: 157580768 -> 157579730 (-0.0%)
Instructions helped: 312
Instructions hurt: 28
Cycles in all programs: 7566977172 -> 7566967746 (-0.0%)
Cycles helped: 288
Cycles hurt: 53
Spills in all programs: 19701 -> 19700 (-0.0%)
Spills helped: 2
Spills hurt: 4
Fills in all programs: 33311 -> 33335 (+0.1%)
Fills helped: 5
Fills hurt: 4
Ice Lake
Instructions in all programs: 141998667 -> 141997227 (-0.0%)
Instructions helped: 420
Instructions hurt: 3
Cycles in all programs: 9162565297 -> 9162524757 (-0.0%)
Cycles helped: 389
Cycles hurt: 29
Spills in all programs: 19918 -> 19916 (-0.0%)
Spills helped: 2
Spills hurt: 3
Fills in all programs: 32795 -> 32814 (+0.1%)
Fills helped: 6
Fills hurt: 3
Skylake
Instructions in all programs: 132567691 -> 132567745 (+0.0%)
Instructions hurt: 24
Cycles in all programs: 8828897462 -> 8828889517 (-0.0%)
Cycles helped: 405
Cycles hurt: 6
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17718>
Gfx8 and Gfx9 platforms are helped for cycles because now many
instructions like
mul(8) g12<1>D g10<8,8,1>D 6D
become
mul(8) g12<1>D g10<8,8,1>D 6W
It is the same number of instructions, but the 32x16 multiply is a
little faster.
v2: Fix transposed hi and lo in "(hi >= INT16_MIN && lo <= INT16_MAX)".
Noticed by Caio. Use nir_src_is_const instead of open coding it.
Suggested by Caio.
Broadwell and Skylake had similar results. (Skylake shown)
total cycles in shared programs: 845748380 -> 845145547 (-0.07%)
cycles in affected programs: 446346348 -> 445743515 (-0.14%)
helped: 6017
HURT: 0
helped stats (abs) min: 2 max: 7380 x̄: 100.19 x̃: 8
helped stats (rel) min: <.01% max: 3.72% x̄: 0.41% x̃: 0.39%
95% mean confidence interval for cycles value: -113.37 -87.00
95% mean confidence interval for cycles %-change: -0.42% -0.41%
Cycles are helped.
Skylake
Cycles in all programs: 8844820715 -> 8828897462 (-0.2%)
Cycles helped: 47914
Cycles hurt: 1
No shader-db or fossil-db changes on any other Intel platform.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17718>
This enables copy propagation of
mov(8) g5<1>UD 0x00000180UD
mul(8) g10<1>D g2.3<0,1,0>D g5<16,8,2>W
into
mul(8) g10<1>D g2.3<0,1,0>D 180W
This is necessary for any optimization passes that generate imul_32x16
instructions.
No fossil-db or shader-db changes on any Intel platform.
v2: Fix type size check to (src size != 2) || (dest size != 4). It was
previously &&. :( This allowed copying constants into UB sources, and
that is invalid.
v3: Fix incorrect extraction of upper 16-bits of immediate value when
subnr=2. Noticed by Caio.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17718>
The previous bounds checking would cause
mul(8) g121<1>D g120<8,8,1>D 0xec4dD
to be lowered to
mul(8) g121<1>D g120<8,8,1>D 0xec4dUW
mul(8) g41<1>D g120<8,8,1>D 0x0000UW
add(8) g121.1<2>UW g121.1<16,8,2>UW g41<16,8,2>UW
Instead of picking the bounds (and the new type) based on the old type,
pick the new type based on the value only.
This helps a few fossil-db shaders in Witcher 3 and Geekbench5. No
changes on any other Intel platforms.
Tiger Lake
Instructions in all programs: 157581069 -> 157580768 (-0.0%)
Instructions helped: 24
Cycles in all programs: 7566979620 -> 7566977172 (-0.0%)
Cycles helped: 22
Cycles hurt: 4
Ice Lake
Instructions in all programs: 141998965 -> 141998667 (-0.0%)
Instructions helped: 26
Cycles in all programs: 9162568666 -> 9162565297 (-0.0%)
Cycles helped: 24
Cycles hurt: 2
Skylake
No changes.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17718>
Don't copy propagate the constant in situations like
mov(8) g8<1>D 0x7fffffffD
mul(8) g16<1>D g8<8,8,1>D g15<16,8,2>W
On platforms that only have a 32x16 multiplier, this will result in
lowering the multiply to
mul(8) g15<1>D g14<8,8,1>D 0xffffUW
mul(8) g16<1>D g14<8,8,1>D 0x7fffUW
add(8) g15.1<2>UW g15.1<16,8,2>UW g16<16,8,2>UW
On Gfx8 and Gfx9, which have the full 32x32 multiplier, it results in
mul(8) g16<1>D g15<16,8,2>W 0x7fffffffD
Volume 2a of the Skylake PRM says:
When multiplying a DW and any lower precision integer, the
DW operand must on src0.
See also https://gitlab.freedesktop.org/mesa/crucible/-/merge_requests/104.
Previous to INTEL_shader_integer_functions2 (in Vulkan or OpenGL), I
don't think it would be possible to create a situation where this could
occur. I discovered this via some optimizations that can determine that
the non-constant source must be able to fit in 16-bits. The case listed
above came from piglit's "ext_transform_feedback-order arrays points"
with those optimizations in place.
No shader-db or fossil-db changes on any Intel platform.
Fixes: de6c0f8487 ("intel/fs: Implement support for NIR opcodes for INTEL_shader_integer_functions2")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17718>
Currently in wglCreateContextAttribsARB(), we get and save the
pointers to OPENGL32.DLL's wglCreate/DeleteContext() functions.
But these function pointers might be invalid after opengl32.dll is
unloaded and reloaded again and possibly in a different address space.
This patch, provided by Jose Fonseca, uses GetModuleHandle and gets
the proc address of wglCreate/DeleteContext functions every time the
function is called.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19478>
This patch filters-out '-std=gnu++14' from the cflags obtained
from AOSP/KATI dummy target output to avoid the following building errors:
FAILED: src/gallium/drivers/r600/45f68e3@@r600@sta/sfn_sfn_assembler.cpp.o
...
clang++ ... -std=c++17 ... -std=gnu++14
...
In file included from ../src/gallium/drivers/r600/sfn/sfn_assembler.cpp:27:
In file included from ../src/gallium/drivers/r600/sfn/sfn_assembler.h:32:
In file included from ../src/gallium/drivers/r600/sfn/sfn_shader.h:31:
../src/gallium/drivers/r600/sfn/sfn_instr.h:369:56: error: no template named 'is_base_of_v' in namespace 'std'; did you mean 'is_base_of'?
template <typename T, typename = std::enable_if_t<std::is_base_of_v<Instr, T>>>
~~~~~^~~~~~~~~~~~
is_base_of
/home/utente/pie-x86_kernel/external/libcxx/include/type_traits:1412:29: note: 'is_base_of' declared here
struct _LIBCPP_TEMPLATE_VIS is_base_of
^
In file included from ../src/gallium/drivers/r600/sfn/sfn_assembler.cpp:27:
In file included from ../src/gallium/drivers/r600/sfn/sfn_assembler.h:32:
In file included from ../src/gallium/drivers/r600/sfn/sfn_shader.h:31:
../src/gallium/drivers/r600/sfn/sfn_instr.h:369:51: error: template argument for non-type template parameter must be an expression
template <typename T, typename = std::enable_if_t<std::is_base_of_v<Instr, T>>>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/utente/pie-x86_kernel/external/libcxx/include/type_traits:439:16: note: template parameter is declared here
template <bool _Bp, class _Tp = void> using enable_if_t = typename enable_if<_Bp, _Tp>::type;
^
2 errors generated.
Cc: "22.2" "22.3" mesa-stable
Reviewed-by: Roman Stratiienko <r.stratiienko@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19563>
XFB queries need to be enabled with NGG streamout and VS/TES.
Previously, the NGG lowering code relied on has_prim_query for XFB.
This fixes failures with RADV_PERFTEST=ngg_streamout on GFX10.3 with
the vkd3d-proton testsuite. Vulkan CTS is missing TES tests with XFB
queries apparently.
Cc: 22.3 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/19493>
While the GC880 is HALTI0, it still uses the old set of state registers
for PE pipe configuration. This is another specialty of the GC880, readd
the missing handling for this GPU otherwise e.g. Qt5 cube example suffers
from rendering corruption with both eglfs and wayland backends.
Fixes: 7c46a48836 ("etnaviv: use new PE pipe address states on >= HALTI0")
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Marek Vasut <marex@denx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19562>
The Vulkan spec says:
"When a command buffer is allocated, it is in the initial state.
Some commands are able to reset a command buffer (or a set of
command buffers) back to this state from any of the executable,
recording or invalid state. Command buffers in the initial state
can only be moved to the recording state, or freed."
Because the status wasn't initialized, it was implicitly set to
RADV_CMD_BUFFER_STATUS_INVALID and that triggered a reset for newly
allocated command buffers.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19506>
We're in 2022 now, and HTTPS is available in a lot more places in the
past. Let's upgrade some links, to protect the privacy of our readers.
The links that are left either don't support HTTPS, or are simply dead
and needs to be updated anyway. That's besides the scope of this
merge-request, so I'm leaving that for someone else.
Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19492>
This new section didn't use the correct RST syntax, and ended up
with a broken section in the rendered docs.
Fix the syntax, and clean things up a bit to avoid overly long lines.
Fixes: be235edfe2 ("zink: add profile documentation")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19481>
I got yet another new failure in VanGogh, and rather than playing the
game of wack a mole, let's be a little less picky and just use these
wildcards:
- dEQP-VK.query_pool.statistics_query.geometry_shader_primitives.*
- dEQP-VK.query_pool.statistics_query.host_query_reset.geometry_shader_primitives.*
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19541>
Currently float16 to int64 conversions don't work correctly, because
the "div" variable has an infinite value, since 2^32 isn't
representable as a 16-bit float, which causes the result of of rem(x,
div) to be NaN for all inputs, leading to an incorrect result. Since
no values of magnitude greater than 2^32 are representable as a
float16 we don't actually need to do the fdiv/frem operations, the
conversion is equivalent to f2u32 with the result padded to 64 bits.
Rework:
* Jordan: Handle f16 in if/else rather than conditional
Fixes: 936c58c8fc ("nir: Extend nir_lower_int64() to support i2f/f2i lowering")
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19391>
This is happened when multi-threading access to util_get_process_name
memory leak point:
Direct leak of 4097 byte(s) in 1 object(s) allocated from:
#0 0x7f42888c0e8f in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7f4288859d18 in __interceptor_realpath ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:3608
#2 0x55a9c272e03d in __getProgramName ../src/util/u_process.c:75
#3 0x55a9c272e03d in util_get_process_name ../src/util/u_process.c:197
#4 0x55a9c2746da7 in util_queue_init ../src/util/u_queue.c:416
#5 0x55a9c272c233 in queue_init ../src/util/perf/u_trace.c:403
#6 0x55a9c272c233 in u_trace_context_init ../src/util/perf/u_trace.c:453
#7 0x55a9c262eb54 in test_thread ../src/util/tests/perf/u_trace_test.cpp:14
#8 0x55a9c275228b in impl_thrd_routine ../src/c11/impl/threads_posix.c:67
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18764>
Even though initialized = true can make sure have no recursion, but that's may leading to
debug_get_option_should_print return false at the second thread, but the first thread
return true. These two threads should return the same value, even though this function is for
debug only, but it's better to getting it to be correct.
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18764>
GDS is used for NGG queries/streamout (GFX10+ only) and the BOs were
only added to the graphics queue because compute doesn't need them.
Though, the kernel emits a GDS switch when a queue submission doesn't
use GDS. That means that submitting jobs on the compute queue without
GDS can reset the state of the graphics queue and lead to GPU hangs.
The only viable solution for now is to make the GDS BOs resident to
avoid resetting the state between queues. This shouldn't introduce
more syncs between queues because GDS BOs are similar for both.
This fixes a GPU hang with Warhammer Chaosbane during loading time and
possibly some spurious random GPU hangs. Note that this GPU hang was
workarounded on the Steam side with RADV_DEBUG=nongg.
Cc: 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/19466>
This was only partially supported, with not way to cross D3D12
old compatibility boundary. With the RelaxedFormatCastingSupported
feature, we can cast any format to any other format with the same
block size, which maps pretty well to how Vulkan see things.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17339>
Some drivers need to know the full list of formats that can be used
when VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT or
VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT is set (dozen needs
that at least). While VkImageFormatListCreateInfo is a nice way to
get the actual of formats the user intends to use at view creation time,
this paramter is optional, and when it's missing, we need to know the
full list of compatible formats if we want things to work properly.
Provide a helper that hides all the complexity and return a format list
even when VkImageFormatListCreateInfo is missing.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17339>
A single backtick escaped string in Sphinx refers to the "default role"
which is vague, and in practice ends up producing the HTML cite-element.
That's almost certainly not what these uses wanted.
A bunch of these would probably be better served using appropriate roles
instead of inline-code markup, but this is almost certainly what was
meant here instead. Let's not let perfect be the enemy of good here, and
just do what was intended. Using the right roles everywhere is a big
task.
I usually don't do changes like these to the relnotes, but in this case
there were a *single* article that had these mistakes. I assume that was
an early bug in the script that generateg the relnotes. Let's patch it,
so we don't get misrendering if we change the default-role.
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19494>
This test as a whole does not seem to work anywhere, even lavapipe, but
one particular subtest was passing until a recent change
(!19438 - zink: polygon mode fixes?).
After consideration by @kusma, it appears that the subtest was passing
by accident due to zink generating the wrong values. Given that this is
not something that users would ever experience as a regression, we
simply document this new failure along with all the others for this
test.
Fixes: 53721827ea ("zink: correct depth-bias enable condition")
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19517>
In turnip we were using this a lot with the dynamic state enum, and
we're running out of space there because we're needing to add more and
more dynamic states that don't correspond to draw states. Make it
64-bit-safe so we don't need to rewrite everything in turnip. In the
case where the thing being operated on is 32-bit the compiler can
usually optimize it away, as can be seen with the release build size
before and after:
before:
text data bss dec hex filename
5404913 293592 22744 5721249 574ca1 /home/cwabbott/build/mesa-release/lib64/libvulkan_freedreno.so
text data bss dec hex filename
13981320 498550 205000 14684870 e012c6 /home/cwabbott/build/mesa-release/lib64/dri/msm_dri.so
after:
text data bss dec hex filename
5404969 293592 22744 5721305 574cd9 /home/cwabbott/build/mesa-release/lib64/libvulkan_freedreno.so
text data bss dec hex filename
13981320 498550 205000 14684870 e012c6 /home/cwabbott/build/mesa-release/lib64/dri/msm_dri.so
In the end the only changes is an additional ~50 bytes of text in
turnip.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18912>
This avoids a dependency on the sample count in the blend state, and
seems to work. Otherwise, we'd need to make blend dynamic if samples is
dynamic and record whether the sample mask was NULL, which is a lot more
complicated.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18912>
Most of the time we will only be updating either the number of samples
or whether it should be disabled, not both, and we don't need to compare
both. With pipelines we were comparing both, but with dynamic
rasterization samples we want to only update disable when binding the
pipeline and only update samples when calling
vkCmdSetRasterizationSamplesEXT(). Stop optimizing the uncommon case
where both are changed when binding a pipeline, and split it into 2
parts while sharing the common part that records and emits the state
packet.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18912>
From the spec language, it seems like this change wasn't strictly
required and is just an optimization for when minSampleShading would
be small enough to allow one sample per pixel. However
rasterizationSamples will soon possibly be dynamic, and I don't think we
should keep this around.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18912>
This is a little tricky because now we always have to store the
translated logicOp in the pipeline, regardless of whether it's enabled
or not, because the enable/disable may now be dynamic even if the
logicOp is not.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18912>
Emit GRAS_SU_CNTL, GRAS_CL_CNTL, the polygon mode, and the VRS registers
in one draw state. We're running out of draw states, and this saves a
draw state while preparing us for the rest of the rasterization state to
be dynamic.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18912>
At least in the current Vulkan spec there is no validation language
saying that it isn't valid to set this state if stippled lines aren't
supported, so it seems we have to just ignore it. Ignore it if the user
specifies a dynamic line stipple state and don't emit warnings if they
call CmdSetLineStippleEXT because zink will do this.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18912>
Vulkan allows the user to set extraneous dynamic state which then gets
ignored if a pipeline with static state is bound. We weren't
implementing this correctly for viewports because we weren't clearing
the dirty bit, but it was happening to work until changes for dynamic
depth negative-one-to-one broke
dEQP-VK.pipeline.*.depth.depth_clip_control.d32_sfloat_less_viewport_before_static.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18912>
Again sharing the same function across all Intel drivers.
There is still two additional DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM
calls, one in intel/dev and other in perf.
The first one can't call intel_gem_get_context_param() because of the
build order of libs and the second one because it sets the size
parameter.
Will revisit those calls in future but this is already an improvement.
v2:
- using intel_gem_get_context_param() for the recently added query for
I915_CONTEXT_PARAM_PROTECTED_CONTENT
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18974>
This function was returning a int but there was no meaninfull errno
code being returned, also context_id is a uint32_t what would be
problematic if i915 even returned 2147483648(-1).
So here changing the return type and add context_id pointer parameter.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18974>
Color and TS buffers are allocated separately for each etnaviv resource, so
getting the same base and TS buffer at import time is unexpected and a strong
hint at the application doing something wrong, like passing in the same GEM
handle for all planes on a GBM import. Print a warning to give the user some
feedback.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9780>
This adds support for sharing the TS buffer, which up until now has been
an internal implementation detail, with the outside world. This mainly
improves performance with a GPU compositor present, but on i.MX8M also
direct to display use-cases benefit.
The impact of this change depends on the GPU generation:
- old GPUs with a single pipe won't see any difference
- GC2000 can skip the TS resolve in the client and will benefit from a
more efficient blit into the sampler compatible format when the client
buffer contains cleared tiles
- GC3000 can directly sample with TS support, so saves both write and read
memory bandwidth when the client buffer contains cleared tiles
- GC7000 with compression support can keep the client buffer in compressed
format, thus saving both read and write bandwidth even for fully filled
client buffers
- GC7000 coupled to a display unit supporting the compression format (DCSS
on i.MX8M) does not even need to uncompress the render buffer for display
so will see significant bandwidth saving even when GPU compositing is
bypassed
There is a slight complication in that the tile clear color isn't part of
the TS buffer, but is programmed into state registers in the GPU. To handle
this externally shared TS buffers now contain a software metadata area,
where the clear color is stored by the driver, so the receiving end of the
TS buffer can retrieve the clear color from this area.
The compression format is handled in the same way by storing it in the SW
meta area. While we can derive the compression format from the color buffer
format in most cases, some users, like weston, expect that they can "upgrade"
ARGB to XRGB color formats. While this works with plain color formats, as
it's just masking a channel, the compression format differs when alpha is in
use. Receivers of the TS buffer should thus not try to infer the compression
format from the color buffer format, but instead fetch it from the SW meta.
The import/export handling of the TS buffer is modelled after the Intel iris
driver: we add a separate plane for the TS buffer and fold it into the base
resource after the import.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Tested-by: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9780>
Unknown modifiers are currently squashed down to linear when transforming
the modifier into our interal layout representation. However, the only real
modifier that we expect to see, which isn't Vivante specific or LINEAR, is
the INVALID modifier. Treat this modifier as linear and reject any other
unexpected modifiers.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9780>
Some display engines are able to resolve fast clear and/or compression
on the fly and need access to the TS buffer to do so. As they might
have restrictions on which memory they can access, allocate the TS
buffer memory from the KMS side when the resource should be SCANOUT
capable.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Tested-by: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9780>
The earlier understanding of how tile status tracks the color/depth
surface was wrong and the TS size calculations have long been fixed,
as we now know that color/depth tiles have a fixed size in bytes and
thus don't depend on the surface format. But nobody changed the comment
explaining how TS works, so it's still around as a trap for the reader.
Reword the comment to not confuse people that aren't intimately
familiar with the inner workings of tile status.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Tested-by: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9780>
When APIENTRY is not defined, GL/gl.h and GL/glext.h will automatically
include <windows.h>, so we save the macro APIENTRY by push_macro and then
define APIENTRY before include of GL/gl.h and GL/glext.h.
After that we use pop_macro to recover the previous macro again.
Because windows.h is not included by glheader.h, mesa/main/errors.c needs
to include <windows.h> directly to prevent the following error:
errors.c:98:10: error: implicit declaration of function 'OutputDebugStringA' [-Werror=implicit-function-declaration]
98 | OutputDebugStringA(buf);
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Brian Paul brianp@vmware.com
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19472>
Since we now implement events in the GPU we need to be more careful
and insert barriers to honor the dependencies provided by the API
as well as ensuring we are synchronizing these with the compute
queue, since that is how we implement GPU event functionality.
Fixes: ecb01d53fd ("v3dv: refactor events")
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19458>
These leaks on device creation failure have been there before, but
were only exposed as CTS failures after the recent event refactoring.
Partially fixes:
dEQP-VK.api.device_init.create_instance_device_intentional_alloc_fail.basic
dEQP-VK.api.object_management.alloc_callback_fail.device
dEQP-VK.api.object_management.alloc_callback_fail.device_group
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19458>
Copied wrong from radeonsi. The registers following the scratch
buffer address are the shader rsrc1/rsrc2. Not the user SGPR0
containing the ring resource word 1.
Fixes: 278e533ec9 ("radv: update scratch buffer registers on GFX11")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19488>
If nir->info.shared_size = 0 but grid->variable_shared_mem > 0, the shader uses
shared memory but the compiler may not realize that. We need to disable
workgroup merging even in this case. The alternate approach is to statically
check for shared intrinsics in the compiler, but this is a bit easier all things
considered.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18581>
This will be required if a frontend has to request additional shared mem
on top of the shader declared one, but wants to create the CSO before
knowing the total amount.
In OpenCL applications can bind additional shared mem through kernel
arguments and this happens quite late.
Note: Clover sets the req_local_mem incorrectly before so we can leave it
as broken.
v2: fix panfrost code (Alyssa)
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18581>
The entire point of resource shadowing is to avoid unnecessary flushing.
Flushing readers after shadowing is counterproductive. A refresher on
how resource shadowing is supposed to work:
First, we determine if it's beneficial to shadow resources. If so, we
create a new backing buffer object. We flush the current writer of the
resource, if there is one, so the current contents become known to the
CPU. If we are not discarding the original resource, we then copy the
existing contents of the buffer to the new shadow buffer on the CPU.
Finally, we swap the resource's backing buffer for our shadow. Any batch
that reads the resource will continue to read the old copy of the
resource, and any future draw calls will see the new copy with the
change implemented.
Where did we go wrong?
In 988d5aae74 ("panfrost: Flush resources when shadowing"), we started
flushing all readers. We didn't actually need to flush, we just needed
to avoid dangling references on the batches reading the old copy of the
resource. But that's easily enough avoided: just remove the references.
The batches still hold a reference to the underlying BO, which will be
freed at the right time regardless.
Originally motivated by glmark2 -bbuffer:update-method=subdata, which
has some pathological access paterns.
Firefox is a lot faster anecdotally (now scrolling at 60fps in firefox).
But what actually motivated this is an apitrace from Duckstation's GLES
renderer. With this patch, the in-game portion is improved 3fps to 21fps.
Closes: #4028
Fixes: 988d5aae74 ("panfrost: Flush resources when shadowing")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19361>
If a synchronized transfer_map is going to overwrite an entire resource,
there's no need to memcpy in the original contents ahead-of-time. This
memcpy is particularly bad for large buffers where it's copying WC->WC,
although that could be mitigated with threaded_context's cpu_storage in
the future if needed.
Prevents a performance regression in glmark2's buffer scenes from the
next patch, hence the Cc.
Cc: mesa-stable
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19361>
@@ -18,8 +18,8 @@ Linux mainline, that is why Mesa has its own kernel version which should be used
as the base for newer kernels.
So, one should base the kernel uprev from the last tag used in the Mesa CI,
please refer to `.gitlab-ci/container/gitlab-ci.yml``KERNEL_URL` variable.
Every tag has a standard naming: `vX.YZ-for-mesa-ci-<commit_short_SHA>`, which
please refer to ``.gitlab-ci/container/gitlab-ci.yml````KERNEL_URL`` variable.
Every tag has a standard naming: ``vX.YZ-for-mesa-ci-<commit_short_SHA>``, which
can be created via the command:
:code:`git tag vX.YZ-for-mesa-ci-$(git rev-parse --short HEAD)`
@@ -28,7 +28,7 @@ Building Kernel
---------------
When Mesa CI generates a new rootfs image, the Linux Kernel is built based on
the script located at `.gitlab-ci/container/build-kernel.sh`.
the script located at ``.gitlab-ci/container/build-kernel.sh``.
Updating Kconfigs
^^^^^^^^^^^^^^^^^
@@ -36,7 +36,7 @@ Updating Kconfigs
When a Kernel uprev happens, it is worth compiling and cross-compiling the
Kernel locally, in order to update the Kconfigs accordingly. Remember that the
resulting Kconfig is a merge between *Mesa CI Kconfig* and *Linux tree
defconfig* made via `merge_config.sh` script located at Linux Kernel tree.
defconfig* made via ``merge_config.sh`` script located at Linux Kernel tree.
Kconfigs location
"""""""""""""""""
@@ -70,9 +70,9 @@ Development routine
1. Compile the newer kernel locally for each platform.
2. Compile device trees for ARM platforms
3. Update Kconfigs. Are new Kconfigs necessary? Is CONFIG_XYZ_BLA deprecated? Does the `merge_config.sh` override an important config?
3. Update Kconfigs. Are new Kconfigs necessary? Is CONFIG_XYZ_BLA deprecated? Does the ``merge_config.sh`` override an important config?
4. Push a new development branch to `Kernel repository`_ based on the latest kernel tag used in GitLab CI
5. Hack `build-kernel.sh` script to clone kernel from your development branch
5. Hack ``build-kernel.sh`` script to clone kernel from your development branch
6. Update image tags. See `Updating image tags`_
7. Run the entire CI pipeline, all the automatic jobs should be green. If some job is red or taking too long, you will need to investigate it and probably ask for help.
- Install `Renderdoc <https://renderdoc.org/>`_ (only needed for some traces)
- Download and compile `Piglit <https://gitlab.freedesktop.org/mesa/piglit>`_ and install his `dependencies <https://gitlab.freedesktop.org/mesa/piglit#2-setup>`_
- Download traces you want to replay from `traces-db <https://gitlab.freedesktop.org/gfx-ci/tracie/traces-db/>`_
- Install `Renderdoc <https://renderdoc.org/>`__ (only needed for some traces)
- Download and compile `Piglit <https://gitlab.freedesktop.org/mesa/piglit>`__ and install his `dependencies <https://gitlab.freedesktop.org/mesa/piglit#2-setup>`__
- Download traces you want to replay from `traces-db <https://gitlab.freedesktop.org/gfx-ci/tracie/traces-db/>`__
Running single trace
--------------------
@@ -16,7 +16,7 @@ A simple run to see the output of the trace can be done with
apitrace replay -w name_of_trace.trace
For more information, look into the `Apitrace documentation <https://github.com/apitrace/apitrace/blob/master/docs/USAGE.markdown>`_.
For more information, look into the `Apitrace documentation <https://github.com/apitrace/apitrace/blob/master/docs/USAGE.markdown>`__.
For comparing checksums use:
@@ -32,7 +32,7 @@ Simulating CI trace job
Sometimes it's useful to be able to test traces on your local machine instead of the Mesa CI runner. To simulate the CI environment as closely as possible.
Download the YAML file from your driver's `ci/` directory and then change the path in the YAML file from local proxy or MinIO to the local directory (url-like format ``file://``)
Download the YAML file from your driver's ``ci/`` directory and then change the path in the YAML file from local proxy or MinIO to the local directory (url-like format ``file://``)
The problem with this simple implementation is the large amount of
@@ -94,10 +94,10 @@ where each can or cannot be used are listed.
Starting with the 2.4.20 Linux kernel, each thread is allocated an area
of per-thread, global storage. Variables can be put in this area using
some extensions to GCC that called `ELF TLS`. By storing the dispatch table
some extensions to GCC that called ``ELF TLS``. By storing the dispatch table
pointer in this area, the expensive call to ``pthread_getspecific`` and
the test of ``_glapi_Dispatch`` can be avoided. As we don't support for
Linux kernel earlier than 2.4.20, so we can always using `ELF TLS`.
Linux kernel earlier than 2.4.20, so we can always using ``ELF TLS``.
The dispatch table pointer is stored in a new variable called
``_glapi_tls_Dispatch``. A new variable name is used so that a single
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.
