Otherwise we schedule this sort of thing wrong,
r0 = iadd3 r0 c[0x0][0x0] rZ
r0 = shf.l.w.i32 r0 rZ 0x2
r0 p0 = iadd3 r0 c[0x1][0x0] rZ
since raw latencies are more important than waw, but we go do a
waw for the first two instructions instead of a raw which is correct.
Fixes: 2d4e445099 ("nak/calc_instr_deps: Rewrite calc_delays() again")
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33573>
(cherry picked from commit 7a55a9afcc)
We currently just assume that textureCompressionETC2 and
textureCompressionASTC_LDR are always supported. And while that's true
for all the G52s, G610s abd G310s we've seen out in the wild, it's not
guaranteed to be true. An SoC vendor might disable support for one of
these formats.
So let's check properly, just for good measure.
Fixes: d970fe2e9d ("panfrost: Add a Vulkan driver for Midgard/Bifrost GPUs")
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34206>
(cherry picked from commit e4786cf971)
A pipeline barrier which contains an image layout transition like
COLOR_ATTACHMENT_OPTIMAL -> TRANSFER_DST_OPTIMAL on compute queue
would just hang. Such a barrier is useless in practice but it's legal.
Prevent GPU hangs by skipping FCE or FMASK_DECOMPRESS when it's not
on the graphics queue.
Fixes dEQP-VK.synchronization2.layout_transition.compute_transition*.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34231>
(cherry picked from commit 086f529bbe)
When we're using the PRIME path and using vkCmdCopyImageToBuffer to copy
to a linear image, the buffer memory is what's shared with the window
system. For legacy drivers that depend on memory signaling via
wsi_memory_signal_submit_info, we need to tell the driver to signal the
buffer memory, not the image memory or else the window system may wait
on a driver-internal buffer and not wait for the copy to complete.
Cc: mesa-stable
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34218>
(cherry picked from commit cf23ffcbae)
a1b05991 ("radv/rt: Flush L2 after writing internal node offset on GFX12")
did this for radv-internal CP writes - we also need to do this for PLOC
sync data initialization which is done in the common framework.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34178>
(cherry picked from commit c1e1d86bd1)
The mirror needs to be reversed because the rotation is applied
before the mirroring.
VAAPI docs:
Mirroring of an image can be performed either along the
horizontal or vertical axis. It is assumed that the rotation
operation is always performed before the mirroring operation.
Cc: mesa-stable
Acked-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34140>
(cherry picked from commit 962c33cbca)
We were never setting has_multiview. It's not actually necessary anyway,
since we can just do the optimization we were trying to do whenever
num_views is 1 instead.
This doesn't affect the actual fragment size, which was already correct,
only gl_FragSizeEXT.
Fixes: 6f2be52487 ("tu, ir3: Handle FDM shader builtins")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33991>
(cherry picked from commit 8864ee7b0f)
It's possible that the source is uniform but the destination is not. In
this case, we need to insert a copy or else we might accidentally
propagate a uniform into some place we don't expect it.
This fixes a bunch of fp64 KHR-Single-GL46.subgroups.arithmetic.* tests.
Fixes: d09d3f5246 ("nak/from_nir: Emit uniform instructions when !divergent")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34201>
(cherry picked from commit 1d1d79bbaa)
In 35df3925ca ("brw: ensure VUE header writes in HS/DS/GS stages") I
misread the PRMs and thought that the VF would initialize the header.
What actually happens is that the VF does not write valid values in
there and the PRMs explicitly say that the VS shader should overwrite
whatever is in there.
We could avoid writing the header in some cases when no HW is going to
read back the header. For example with rendering disables through
3DSTATE_STREAMOUT::RenderingDisable. But those cases are dynamic and
the compiler is not able to tell. So just always write the header.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 35df3925ca ("brw: ensure VUE header writes in HS/DS/GS stages")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12880
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34211>
(cherry picked from commit 4db4bd1d04)
The color format needs to be compatible with depth or stencil. Also
the depth/stencil format was incorrect when it's the source.
Fixes dEQP-VK.api.ds_color_copy.*
and VKD3D_TEST_FILTER=test_copy_texture.
Fixes: d4ff011b12 ("radv: advertise VK_KHR_maintenance8")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34142>
(cherry picked from commit 2c3b9312cc)
When updating delays, we'd update all dst regs based on reg_elems.
However, when wrmask has gaps, this would update delays for regs that
aren't actually written. Fix this by skipping regs for which the
corresponding wrmask bit is zero.
Note that this wasn't just a performance issue but could result in
illegal code because the delay is reset to zero for tex/sfu
instructions. For example, the following (post-legalization) code was
observed in the wild:
(rpt1)add.f r1.w, (r)r2.w, (r)c3.z
sam.base0 (f32)(w)r2.x, r3.y, s#0, t#1
rcp r2.x, r2.x
Here, the add would result in a required delay for r2.x which would then
be cleared by the sam (even though it doesn't write to it), resulting in
insufficient delay before the rcp.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: 61b2bd861f ("ir3: Rewrite nop insertion")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34107>
(cherry picked from commit 84dbd34332)
The call looks up a Program and creates it if it doesn't
already exist. However we weren't locking the hash between looking
up the name and adding it to the hash so it could be possible
another thread also generated the same name.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Fixes: 842c91300f ("mesa: enable GL name reuse by default for all drivers except virgl")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34091>
(cherry picked from commit 786b8b2d34)
The call looks up an ATIShader and creates it if it doesn't
already exist. However we weren't locking the hash between looking
up the name and adding it to the hash so it could be possible
another thread also generated the same name.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Fixes: 842c91300f ("mesa: enable GL name reuse by default for all drivers except virgl")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34091>
(cherry picked from commit 4c1e4d7b49)
The calls look up a renderbuffer and create it if it doesn't
already exist. However they weren't locking the hash between looking
up the name and adding it to the hash so it could be possible
another thread also generated the same name.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Fixes: 842c91300f ("mesa: enable GL name reuse by default for all drivers except virgl")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34091>
(cherry picked from commit 0e61d31e9d)
The calls look up a framebuffer and create it if it doesn't
already exist. However they weren't locking the hash between looking
up the name and adding it to the hash so it could be possible
another thread also generated the same name.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Fixes: 842c91300f ("mesa: enable GL name reuse by default for all drivers except virgl")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34091>
(cherry picked from commit c4ee84f3b6)
The calls look up a texture object and create it if it doesn't
already exist. However they weren't locking the hash between looking
up the name and adding it to the hash so it could be possible
another thread also generated the same name.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Fixes: 842c9130 ("mesa: enable GL name reuse by default for all drivers except virgl")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34091>
(cherry picked from commit 95e87f6a6a)
The spec allows to create aliased disjoint image for a specific plane of
a multi-planar image, and the format can be R8. When querying memory
requirement of such image, VkImagePlaneMemoryRequirementsInfo is not
required to be chained although it has the disjoint bit.
This change fixes to look for aspect info from plane memory info only
when that's chained. The implementation can be passive here as the spec
VU has sufficient guarantees for the validity around. See below VU for
details:
- VUID-VkImageMemoryRequirementsInfo2-image-01589
- VUID-VkImageMemoryRequirementsInfo2-image-01590
- VUID-VkImageMemoryRequirementsInfo2-image-02279
- VUID-VkImageMemoryRequirementsInfo2-image-02280
Meanwhile, the existing disjoint check for size info is kept as is for
the special handling of VK_FORMAT_D32_SFLOAT_S8_UINT.
Test: dEQP-VK.ycbcr.plane_view.memory_alias.* pass with venus-on-panvk
Fixes: 412c286331 ("panvk: Enable multiplane images and image views")
Reviewed-by: Rebecca Mckeever <rebecca.mckeever@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34134>
(cherry picked from commit 5dcb9f918d)
Per Vulkan spec 7.9. Host Write Ordering Guarantees, queue submission
commands automatically perform a domain operation from host to device
for all writes performed before the command executes. That is to say,
host updates to the mappings can occur after the end of the command
recording and must be flushed implicitly at submission boundary.
Before this change, necessary cache flushes could be missed once the
app starts reusing pre-recorded command buffers. e.g. a simple buffer
copy cmd while the app only updates the source buffer mapping in
different submissions. This changes backs out most of the current
version of cache flush reduction while still assigning LATEST_FLUSH_ID
to at least the final batch itself. This aligns with panfrost_batch
submit behavior on the gallium side.
Test: dEQP-VK.synchronization*.timeline_semaphore.* pass w/o flakiness
via venus-on-panvk
Fixes: 28e4d22497 ("panvk/csf: Pass a non-zero flush-id to benefit from cache flush reduction")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34093>
(cherry picked from commit 98a5acf352)
If the last owner thread has just unset the alive status and released
the watchdog, the new owner thread could have acquired to abort
unexpectedly if the ownership transfer occurs right before the next
owner's warn order. So we must set watchdog alive for new owner so that
it can properly check ring alive status in the next warn order.
Cc: mesa-stable
Acked-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34135>
(cherry picked from commit 8b2703fe08)
Register spilling can cause us to require thread local storage (tls).
However, we were not adjusting the tls stack size space to account for
the tls needed for the extra xfb shader when transform feedback is
needed. We noticed this when testing register allocation in the
OpenGL CTS (for testing we had forced spilling where none happened
before).
Cc: mesa-stable
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33935>
(cherry picked from commit 2ee3bef252)
If we pass zink=false to pipe_loader_drm_probe_fd, it could happen that
a Gallium driver that had been already discarded because of not
supporting the graphics CAP will be chosen.
To avoid that, explicitly ask pipe_loader_drm_probe_fd to choose the
zink Gallium driver.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30096>
(cherry picked from commit 854bc2ee05)
Exposing a rendernode from a supported driver is not a sufficient
matching criteria to qualify as the render part of a renderonly
device, as the rendernode might only expose compute or 2D accel
capabilities.
Look for a screen that actually supports gallium graphics operations
to qualify as a renderonly screen.
v2 (Tomeu): Have pipe-loader return a list of FDs for kmsro to choose
based on capabilities.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30096>
(cherry picked from commit 7e76c67632)
These changes happened with no mesa code change, only infrastructure
changes, which is really weird, but to be able to move on, let's simply
document the "new normal".
The current `s3cp` implementation does not work anymore after the
migration, and instead of fixing it and propagating the fix down to us,
it's simpler to directly use `curl`.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34120>
(cherry picked from commit 7178425ccf)
It seems the hardware requires a dummy PS state with a noop FS,
otherwise it might just hang. This used to work just fine on older
gens.
Note that RadeonSI refuses to draw if VS or PS is missing and AMDVLK
seems to also always emit this state. So, this might be a bug that AMD
didn't encounter at all.
This fixes a GPU hang during loading with Ghostwire: Tokyo.
Backport-to: 25.0
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34070>
(cherry picked from commit 1e4cfd9dfa)
This change began by fixing an old regression related to the dceil
functionality. This issue affected palm. Now, this change adjusts
the software fp64 support to make it fully operational.
This change was tested on palm and barts. This change fixes 561
"piglit run all" tests. The khr_gl tests are fixed as well (243 tests).
Here is a summary:
spec/arb_gpu_shader_fp64/execution/built-in-functions/*
spec/arb_gpu_shader_fp64/execution/fs-isnan-dvec: fail pass
spec/arb_gpu_shader_fp64/execution/gs-isnan-dvec: fail pass
spec/arb_gpu_shader_fp64/execution/vs-isnan-dvec: fail pass
spec/glsl-4.00/execution/built-in-functions/*
spec/glsl-4.10/execution/conversion/*
khr-gl4[3-5]/compute_shader/fp64-case1: fail pass
khr-gl4[0-5]/gpu_shader_fp64/builtin/*
Fixes: aed6a39c10 ("glsl: Retire dround lowering.")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33708>
(cherry picked from commit 186fb5e73a)
The problem occurs with a series of instructions build the subgroup
invocation value :
mov(8) g23<1>UW 0x76543210V
add(8) g23.8<1>UW g23<8,8,1>UW 0x0008UW
add(16) g23.16<1>UW g23<16,16,1>UW 0x0010UW
Our register spilling code operates on physical registers (64B on
Xe2+) and using the brw_inst::is_partial_write() helper only considers
32B registers. So the spiller doesn't see that the add(16) instruction
is doing a partial write and ends up discarding the previous value.
You can reproduce the issue by running a test like :
INTEL_DEBUG=spill_fs ./deqp-vk -n dEQP-VK.compute.pipeline.cooperative_matrix.khr_a.subgroupscope.constant.uint8_uint8.buffer.rowmajor.linear
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: aa494cbacf ("brw: align spilling offsets to physical register sizes")
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33642>
(cherry picked from commit c60180ba63)
std::slice::from_raw_parts requires that the slice pointer be non-null,
even when the slice contains zero elements. Failing this invariant is
undefined behavior.
v2: reordered commits to allow cherry-picking bugfixes
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33989>
(cherry picked from commit 5e365f1674)
When a slow/fast/slow clear sequence is executed on a surface, the second
slow clear will not regenerate the clear command if the clear value of the
fast clear is the same as the one used for the second slow clear, as the
current stored surface clear value is the same as the new clear value.
The command generated on the first slow clear however may have used a
different clear value, which is now submitted unchanged to the hardware on
the second slow clear.
Fix this by only generating the clear command if there is no valid one
already. If we already have a valid clear command simply update the fill
value in that command with the new clear value. This has some marginal
overhead, but has been chosen over the alternative of adding more state by
remembering the last slow clear value.
Cc: mesa-stable
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34029>
(cherry picked from commit fb0f9e6352)
Cayman has a non-deterministic behavior issue which is
visible with the test below (arb_shader_image_size).
The tests fail randomly at the "fragment" test category.
Anyway, if the "compute" category is removed, the same
tests are working flawlessly.
The "compute" part of the driver was interfering with the
graphic pipeline. The culprit is the packet PKT3_DEALLOC_STATE
which puts the gpu in an incorrect state to perform some
graphic operations.
This change fixes this problem by issuing a PKT3_CLEAR_STATE
packet just after the PKT3_SURFACE_SYNC packet. As explained
by d51dbe048a PKT3_DEALLOC_STATE is mandatory on cayman to
avoid a gpu hang at the PKT3_SURFACE_SYNC stage.
This correction makes tests like
"spec@glsl-4.30@execution@built-in-functions@cs-.*" to pass
in an utterly deterministic way without random failures.
This change removes around 500 random failures for a
"piglit run all".
For instance, this issue is triggered on cayman with
"piglit/bin/arb_shader_image_size-builtin -auto -fbo".
Fixes: d51dbe048a ("r600g/compute: Emit DEALLOC_STATE on cayman after dispatching a compute shader.")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33973>
(cherry picked from commit 085cfc98cc)
This optimization seems broken because eg. v_s_log_f32 uses SGPRs
for both the source and destination but applying OMOD seems to require
VGPRs.
This fixes a GPU hang when launching Enshrouded on GFX1201.
No fossils db changes on GFX1201.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34027>
(cherry picked from commit f46830912e)
Otherwise, the size of the EGLSurface and the drawable may get out of
sync if kopper needs to re-create the swapchain at a different size.
This can cause problems with things like eglSetDamageRegionKHR() where
the core EGL code clamps them to the size in the EGLSurface.
With Wayland, it's up to the client to choose a size and resize by
creating a new EGLSurface with a different size. Only on X11 can we
get a resize side-band like this.
Normally, without kopper, this goes the other direction where the X11
EGL code will detect a surface size change in dri2_x11_query_surface()
and it invalidates the drawable if they've changed, forcing
re-allocation. Kopper, however, works more like the DRI2 path where we
just get handed buffers at some size decided by X11 and have to deal
with them. In the DRI2 path, the size is unconditionally updated by
dri2_x11_get_buffers(). This is roughly equivalent, updating the size
right after every call to kopperSwapBuffers().
Fixes: 8ade5588e3 ("zink: add kopper api")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12797
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34015>
(cherry picked from commit ad90dbabe4)
A lot of people (including me) misinterpreted the conformanceVersion
field for so long. The Vulkan spec wasn't very clear either but it's
going to be clarified soon.
VkConformanceVersion is actually unrelated to the official CTS
conformance process in Khronos. It just reports the latest CTS version
that the driver can pass, not more.
For GFX8+, RADV should be passing CTS 1.4.0.0 on all GPUs because we
validated this CTS version recently for Vulkan 1.4.
For GFX6-7, which only suppports Vulkan 1.3, RADV should also be
passing CTS 1.4.0.0, because newer versions of the CTS can be used
to validate a driver against an older version of the spec, so
it's perfectly fine to report a higher CTS version than the Vulkan version.
Newer CTS versions likely can't pass 100% due to a DGC bug that I still
need to fix.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12799
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34018>
(cherry picked from commit e519e0b9e6)
With secondary command buffers, inherited rendering can be used but
it's basically impossible to know if the depth/stencil attachment
enabled HiZ/HiS. But it's required to disable WALK_ALIGN8 to avoid
GPU hangs.
This assumes that HiZ/HiS is enabled for inherited rendering as long
as a depth/stencil attachment is used. It's not the most optimal
approach but it's not supposed to hurt either.
This fixes a GPU hang with
dEQP-VK.dynamic_rendering.primary_cmd_buff.basic.contents_secondary_cmdbuffers
and friends.
GFX1200 isn't affected because it doesn't support HiZ/HiS.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33986>
(cherry picked from commit d1a2ba57f9)
We currently report a deviceName as e.g. "Mali-G610 (Panfrost)", but
panfrost has nothing to di with the physical device, and the suffix
doesn't belong there at all.
So let's remove that suffix from PanVK. This results in output like this
from vulkaninfo:
---8<---
VkPhysicalDeviceProperties:
---------------------------
apiVersion = 1.1.305 (4198705)
driverVersion = 25.0.99 (104857699)
vendorID = 0x13b5
deviceID = 0xa8670000
deviceType = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
deviceName = Mali-G610
pipelineCacheUUID = <snip>
---8<---
We already sort of namedrop Panfrost in the driver properties:
---8<---
VkPhysicalDeviceDriverPropertiesKHR:
------------------------------------
driverID = DRIVER_ID_MESA_PANVK
driverName = panvk
driverInfo = Mesa 25.1.0-devel (git-136dd9f985)
conformanceVersion:
major = 1
minor = 4
subminor = 1
patch = 2
---8<---
While this might techically speaking be a regression, PanVK has been
marked as experimental until Mesa 25.0. But to reduce the risk of people
starting to depend on this behavior, let's also backport this change to
the 25.0 release.
The patch looks a bit funny, because we add the " (Panfrost)"-suffix in
common code, and this moves it to the Gallium driver. But effectively,
this means PanVK is the only driver that sees a change of behavior.
Backport-to: 25.0
Reviewed-by: John Anthony <john.anthony@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33972>
(cherry picked from commit c34c7b1f3b)
Compositors sometime try to import BOs with lower alignments than 128B.
This seems particularly common in the case of cursor images but it can
also happen on other BOs allocated by the old nouveau GL driver. As
long as we avoid rendering to them (which NVK will do), the
texture/image hardware is fine as long as they're at least 32B-aligned.
Panicing in this case isn't very nice to compositors.
Backport-to: 25.0
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33990>
(cherry picked from commit 3c11da8aea)
When importing libdrm_radeon code [1][2] it was somehow missed
that what libdrm has in one r600_pci_ids.h, Mesa has split
into r600_pci_ids.h and radeonsi_pci_ids.h. So, devices
with ids from radeonsi_pci_ids.h were not considered valid for
radeon_surface_manager_new.
This commit changes that, thus fixing radeonsi for these
devices.
[1] commit 1299f5c50a
[2] commit 3aa7497cc0
Fixes: 1299f5c50a
Signed-off-by: Ivan A. Melnikov <iv@altlinux.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33940>
(cherry picked from commit 4ad5b8f5bb)
It is expected that inputs and prefetches are always in the first block.
However, ir3_create_empty_preamble would create blocks before the first
one, leaving inputs after the preamble. This causes issues with
(probably among others) spilling/RA where precolored inputs could
illegally reuse the spill base register.
Fixes RA validation failures on a7xx for
dEQP-VK.ray_query.multiple_ray_queries.vertex_shader
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: f3026b3d3e ("ir3: add some preamble helpers")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33977>
(cherry picked from commit c58ba21ba8)
For empty BVHs we shouldn't emit any leaf nodes, but there is one
invocation to encode the root node. Guard leaf node encoding so that
invocation doesn't try writing any leaves.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33985>
(cherry picked from commit cdadda2d51)
We get a kernel message "You are adding an unorder point to timeline!"
on many CTS runs. This stems from us SIGNALing the queue syncobj then
WAITing but not reseting it. It is assumed by the time we get to
panvk_queue_submit_init_signals() that the value is 0, however it is 1
due to the previous calls.
Signed-off-by: Ashley Smith <ashley.smith@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Fixes: 5544d39f ("panvk: Add a CSF backend for panvk_queue/cmd_buffer")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33943>
(cherry picked from commit 14101ff948)
At least, NAVI10, NAVI21 and NAVI24 are affected by this what looks
like a hardware bug when primitive restart is changed and no context
registers are written between draws. It seems the hardware doesn't
consider primitive restart at all in this situation.
Adding SQ_NON_EVENT(0) as suggested by Marek seems to fix it reliably
without introducing any overhead. It's basically a NOP packet that adds
a small delay.
Fixes new VKCTS coverage dEQP-VK.transform_feedback.primitive_restart.*.
Also fixes this old vkd3d-proton issue.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7258
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33929>
(cherry picked from commit 0bc9d59c2e)
We check for iamge layouts and feedback loops when we bind image
resources but not queue families. If the resource isn't on the graphics
queue, we need to add it to need_barriers so we can transition it back
to our queue.
Fixes: d4f8ad27f2 ("zink: handle implicit sync for dmabufs")
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33952>
(cherry picked from commit 18d206d67c)
Otherwise, we'll transition to QUEUE_FAMILY_FOREIGN and then forget that
we left it on the foreign queue and never transition back the next time
we use the resource. This was kind-of okay with Wayland compositors
because they always re-import the BO so it's always fresh and they pick
up on the queue transfer the first time. X11, on the other hand, does
not re-import BOs so they get stuck in this weird QUEUE_FAMILY_FOREIGN
limbo until something happens to randomly trigger a layout transition
check and then we find it and do the transition. We should mark them as
needing a barrier the moment we transition to QUEUE_FAMILY_FOREIGN.
Fixes: d4f8ad27f2 ("zink: handle implicit sync for dmabufs")
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33952>
(cherry picked from commit 396ece1ad8)
The free list must be re-initialized. Found the bug while running:
dEQP-VK.ray_tracing_pipeline.acceleration_structures.device_compability_khr.gpu_built.top
where it invokes VK_COMMAND_POOL_RESET_RELEASE_RESOURCES_BIT to purge
the cmd pool resources, and the next alloc still gets cache hit with the
"empty" list.
Fixes: e2c4bafccc ("venus: free query batches for VK_COMMAND_POOL_RESET_RELEASE_RESOURCES_BIT")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33908>
(cherry picked from commit 6868212774)
If PXP initialization is not completed and application requested a
protected context the GEM_CONTEXT_CREATE will wait up to 250ms for
PXP to finish initialization but if that do not happens it will
return a error and set errno to EIO.
This patch add the missing retry handling.
Cc: mesa-stable
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/30723>
(cherry picked from commit 008ac818ba)
This seems to fix some artifacts, but we're not sure why, so it might not
be a correct or optimal solution.
fossil-db (navi31):
Totals from 28424 (35.81% of 79377) affected shaders:
Instrs: 30112910 -> 30348977 (+0.78%); split: -0.00%, +0.78%
CodeSize: 159542980 -> 160485336 (+0.59%); split: -0.00%, +0.59%
Latency: 221438396 -> 221500856 (+0.03%); split: -0.00%, +0.03%
InvThroughput: 38154231 -> 38159984 (+0.02%); split: -0.00%, +0.02%
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Backport-to: 25.0
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33853>
(cherry picked from commit 0ec174afd5)
The old code got the accumulation a bit wrong. For one thing, it always
accumulates with whatever was there instead of resetting to empty each
time. For another, it sets with with y and height with x when it writes
back to the resource. This is also all too complicated because it
converts between pipe_box, u_rect, and VkRect2D on every iteration.
Instead, there are helpers in util/box.h which will do most of this work
for us and they're correct. Let's just use them to get rid of the bugs
and make everything simpler and more obvious at the same time.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12194
Fixes: 3d38c9597f ("zink: hook up KHR_partial_update")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33855>
(cherry picked from commit 11939a70df)
In case of constant lowering with halfswizzle sources, we were selecting
h01 causing an invalid instruction error to be yield later.
This can only be hit by conversion instructions and shouldn't be seen in
the wild (as this should be eliminated before entering the backend).
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Fixes: 7d07fb9a67 ("pan/va: Handle 8-bit lane when lowering constants")
Reviewed-by: Benjamin Lee <benjamin.lee@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33867>
(cherry picked from commit 2f1ce296d0)
Add a specific timeout for the U-Boot action in LAVA job definitions for
rockchip devices. This ensures sufficient time for U-Boot to download
the kernel and set up early network, preventing potential job failures
due to timeout constraints.
This behavior started to happen since LAVA 2025.02 version.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33839>
(cherry picked from commit 1dbebd2619)
Ideally this would be passed in pic params as the values are
in sequence header, but using the surface size also works.
Also add sanity checks for frame size.
Fixes decoding av1-1-b8-22-svc-L2T1 and av1-1-b8-22-svc-L2T2.
Cc: mesa-stable
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33737>
(cherry picked from commit d0414ef7fb)
This change fixes a regression introduced with 8b5d41cacb.
Indeed, lookup_resid was not updated.
This change was tested on palm and cayman. Here are the tests fixed:
khr-gl4[3-5]/shader_image_size/advanced-nonms-cs-float: fail pass
khr-gl4[3-5]/shader_image_size/advanced-nonms-cs-int: fail pass
khr-gl4[3-5]/shader_image_size/advanced-nonms-cs-uint: fail pass
khr-gl4[3-5]/shader_image_size/advanced-nonms-fs-float: fail pass
khr-gl4[3-5]/shader_image_size/advanced-nonms-fs-int: fail pass
khr-gl4[3-5]/shader_image_size/advanced-nonms-fs-uint: fail pass
khr-gl4[3-5]/shader_image_size/basic-nonms-cs-float: fail pass
khr-gl4[3-5]/shader_image_size/basic-nonms-cs-int: fail pass
khr-gl4[3-5]/shader_image_size/basic-nonms-cs-uint: fail pass
khr-gl4[3-5]/shader_image_size/basic-nonms-fs-float: fail pass
khr-gl4[3-5]/shader_image_size/basic-nonms-fs-int: fail pass
khr-gl4[3-5]/shader_image_size/basic-nonms-fs-uint: fail pass
Fixes: 8b5d41cacb ("r600/sfn: Use range_base for atomics and images")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33352>
(cherry picked from commit fd874bdd0c)
RUN_COMPUTE_INDIRECT has been found to cause intermittent hangs, so
this change replaces it with RUN_COMPUTE and a set TASK_AXIS_X.
While this task axis might be suboptimal, the performance cost is
somewhat offset by RUN_COMPUTE not being an emulated command.
Fixes: 2ffc05d8d2 ("panvk: Add support for CmdDispatchIndirect")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33841>
(cherry picked from commit fe31e7843d)
RUN_COMPUTE_INDIRECT has been found to cause intermittent hangs, so
this change replaces it with RUN_COMPUTE and a set TASK_AXIS_X.
While this task axis might be suboptimal, the performance cost is
somewhat offset by RUN_COMPUTE not being an emulated command.
Fixes: 447075eeee ("panfrost: Add support for the CSF job frontend")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33841>
(cherry picked from commit 6bf9ad2610)
This change fixes the indirect draw 8-bits path which does
a conversion to 16-bits. This change is implemented to process
the parameters the same way as the other indirect draw paths.
This change was tested on palm and cayman. Here are the tests fixed:
deqp-gles31/functional/draw_indirect/draw_elements_indirect/indices/index_byte: fail pass
deqp-gles31/functional/draw_indirect/random/35: fail pass
deqp-gles31/functional/draw_indirect/random/45: fail pass
khr-gl40/draw_indirect/basic-indicesdatatype-unsigned_byte: fail pass
khr-gl41/draw_indirect/basic-indicesdatatype-unsigned_byte: fail pass
khr-gl42/draw_indirect/basic-indicesdatatype-unsigned_byte: fail pass
khr-gl43/draw_indirect/basic-indicesdatatype-unsigned_byte: fail pass
khr-gl44/draw_indirect/basic-indicesdatatype-unsigned_byte: fail pass
khr-gl45/draw_indirect/basic-indicesdatatype-unsigned_byte: fail pass
Fixes: d80701df8a ("r600g: Implement GL_ARB_draw_indirect for EG/CM")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Acked-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32802>
(cherry picked from commit 9aea08e1db)
Calculation was wrongly walking uncompacted instructions, even if we had
some compacted in the middle, generating invalid size. Since we are
here just drop the instruction count, since in practice the caller will
have to walk the instruction stream anyway.
Fixes: 6267585778 ("intel/brw: Also return the size of the assembled shader")
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33532>
(cherry picked from commit dd1ca1588d)
After nir_lower_io we need to gather the info about 64 bit usage
to be up-to-date when deciding whether the remaining 64 bit IO ops
be lowered.
Before 89dad5618d ("gallium: add PIPE_CAP_CALL_FINALIZE_NIR_IN_LINKER")
the info was eventually updated to include the use of 64 bit values
also if only some IO was using this so that SFN was handling the code
correctly. As it seems with above patch this is not always the case
anymore, and we have to take care of it.
Fixes: 89dad5618d ("gallium: add PIPE_CAP_CALL_FINALIZE_NIR_IN_LINKER")
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32774>
(cherry picked from commit 6da19eafd5)
this is a nice idea, but there are apps/games that do not respect
hardware capabilities and yolo-bind fixed size buffers
fixes Ballionaire (2667120) launch on non-desktop drivers
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33819>
(cherry picked from commit b04eaa8589)
We would set the `src` flag on the interval of reloaded sources.
However, the interval might be merged with its parent when inserted and
the parent wouldn't have this flag set. This caused the parent interval
to potentially be reused to reload later sources. Fix this by setting
the `src` flag on the top-level interval after insertion.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: fa22b0901a ("ir3/ra: Add specialized shared register RA/spilling")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33810>
(cherry picked from commit 2d540b8074)
Fixes: 692b5fa9f2 ("anv: Add shader to copy acceleration structures")
This commit fixes the future test "sparse_binding_structures" for
"header_bottom_address" for ray tracing pipeline.
Even on 48-bit ray tracing (Xe1/2), the software-defined part
instance_leaf_part1.bvh_ptr has to be in canonical form for copy.comp
to deference a bvh, which means we have to preserve the upper 16bits.
This is especially relevant in cases where the acceleration structure buffer
is located high, such as sparse buffer.
Signed-off-by: Kevin Chuang <kaiwenjon23@gmail.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33745>
(cherry picked from commit 87ff7b061f)
Fixes: 2fe57947e3 ("anv: Implement encode shader to fit in ANV BVH")
This commit resolves the failures in the future tests
"sparse_binding_structures" for rayquery. Sparse buffers' heaps are
located high, and since it's in canonical form, the higher 16bits are
all set to 1. However, the existing encoder did not expect any non-zero
values at the higher 16bits. As a result, the instance flags got
corrupted, causing most triangle tests to fail.
Thanks for Paulo providing insights about sparse buffer properties.
Co-developed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Kevin Chuang <kaiwenjon23@gmail.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33745>
(cherry picked from commit b9a980ea73)
On vulkan, truncating to S/U16 before converting is not valid, because
out-of-range conversions are specified to be correctly rounded. IEEE 754
requires that out-of-range values round to ±inf with RTNE and ±F16_MAX
with RTZ.
On gl, truncating is valid for U16->F16, because out-of-range int->float
conversions are undefined behavior. For S16->F16, it is not valid
because S16_MAX < F16_MAX, so some in-range values will be truncated as
well.
Instead, just handle S/U16->F16 as S/U16->F32->F16.
Fixes dEQP-VK.spirv_assembly.instruction.compute.convertstof.int32_to_float16_*
when shaderFloat16 is enabled in panvk.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Fixes: be74b84e6f ("pan/bi: Fill in some more conversions")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Rebecca Mckeever <rebecca.mckeever@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33637>
(cherry picked from commit a33cd3def2)
If we insert
<code>
s_branch 1
s_branch Target
at the end of some block, and later hide an additional chained branch
after the existing one, then we have to update the 's_branch 1' to
also jump over the newly added branch.
Fixes: cab5639a09 ('aco/assembler: chain branches instead of emitting long jumps')
Closes: #12673
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33762>
(cherry picked from commit 6659db285a)
This is part of the hashing key :
==25753== Uninitialised byte(s) found during client check request
==25753== at 0x93D29AE: blob_write_bytes (blob.c:164)
==25753== by 0x93A62C6: vk_pipeline_precomp_shader_serialize (vk_pipeline.c:722)
==25753== by 0x93AC55E: vk_pipeline_cache_add_object (vk_pipeline_cache.c:433)
==25753== by 0x93A691B: vk_pipeline_precompile_shader (vk_pipeline.c:875)
==25753== by 0x93A8FB9: vk_create_graphics_pipeline (vk_pipeline.c:1715)
==25753== by 0x93A9799: vk_common_CreateGraphicsPipelines (vk_pipeline.c:1860)
==25753== Address 0xf1adf82 is 82 bytes inside a block of size 152 alloc'd
==25753== at 0x64FA858: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==25753== by 0x99AAC38: vk_default_alloc (vk_alloc.c:26)
==25753== by 0x93A403B: vk_alloc (vk_alloc.h:48)
==25753== by 0x93A406B: vk_zalloc (vk_alloc.h:56)
==25753== by 0x93A60A0: vk_pipeline_precomp_shader_create (vk_pipeline.c:680)
==25753== by 0x93A689D: vk_pipeline_precompile_shader (vk_pipeline.c:866)
==25753== by 0x93A8FB9: vk_create_graphics_pipeline (vk_pipeline.c:1715)
==25753== by 0x93A9799: vk_common_CreateGraphicsPipelines (vk_pipeline.c:1860)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 9308e8d90d ("vulkan: Add generic graphics and compute VkPipeline implementations")
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33792>
(cherry picked from commit 4dba1ad93f)
By actually setting the state packets according to the program data.
Also ensure that we correctly flag that the program may be dirty when
the geometry shader state changes
Fixes piglit tests: `spec@!opengl 3.2@gl-3.2-adj-prims * pv-first`
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Backport-to: 25.0
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33658>
(cherry picked from commit c33ebf09f5)
We never write the traversal shader address out to shader group handles,
so this is not necessary. On the flipside, it can cause conflicts if the
traversal shader is allocated in a range occupied by a replayed shader.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33711>
(cherry picked from commit 14b902c825)
Instead, only indicate that exec should be zero and do
so in the successive helper block. This allows to insert
the parallelcopies from logical phis directly before the
branch in break and continue blocks.
Totals from 56 (0.07% of 79377) affected shaders: (Navi31)
Latency: 2472367 -> 2472422 (+0.00%); split: -0.00%, +0.00%
InvThroughput: 253053 -> 253055 (+0.00%); split: -0.00%, +0.00%
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33527>
(cherry picked from commit 7f7c1d463a)
There is a spec issue about this to clarify this behavior, but the current
wording can be interpreted that the platform always lists all extensions
supported by all drivers.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33667>
(cherry picked from commit 0fd70ee9de)
Turns out we were missing the glapi bits, making it impossible to use get
the function pointers for this extension. Whoops?!
[daniels: Squashed in a618 SkQP fails, presumably caused by these not
being skipped anymore.]
Fixes: 9f5af68995 ("mesa/main: expose `EXT_multi_draw_indirect`")
Reviewed-by: Antonino Maniscalco <antomani103@gmail.com>
Tested-by: Chris Healy <healych@amazon.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33546>
(cherry picked from commit fde6aeb886)
These are persistant objects that you can use to signal and wait over.
We need to import without VK_SEMAPHORE_IMPORT_TEMPORARY_BIT and we can't
throw away the Vulkan semaphore after each submit.
Fixes: 32597e116d ("zink: implement GL semaphores")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33549>
(cherry picked from commit 651864151f)
When the size of the signals[] array was changed to 3, the
signal_values[] array was not updated accordingly. If we have a
signal_semaphore and are presenting at the same time, this can lead to
an array overflow and the driver will read some random stack value as
the signal value. This is causing chromium to lock up when running
WebGL.
Fixes: 7f56fd9655 ("zink: it's kopperin' time")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33549>
(cherry picked from commit 1ffa782227)
Implementing alpha-to-coverage dithering broke the non-dithering case.
(Discovered by accident, not really a big deal since it's almost always
enabled and can only be disabled by using a Nvidia GL extension, and
can't be disabled with Vulkan.)
Fixes: ad4635d6ef
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33586>
(cherry picked from commit 61911b6a4b)
Using memcpy with the max size generates a global-buffer-overflow, as
the performance counter strings are smaller than the max size.
Instead, use a string copy function to get a copy.
This was detected with address sanitizer enabled and running vulkaninfo.
Fixes: 3e8b2fe053 ("broadcom/simulator: Add DRM_IOCTL_V3D_GET_COUNTER to simulator")
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33627>
(cherry picked from commit 2d91798561)
We can't use the local variable key to insert in the hashtable, as the
key needs to be persistent for future searches.
This makes a copy of the key in the pipeline, which is kept persistent
in the hashtable.
This fixes a stack-buffer-overflow.
Backport-to: 25.0
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33630>
(cherry picked from commit eb8017ca68)
_mesa_make_current will use st_flush(ctx) to execute pending
commands before switching to the new context.
Since we can't have multiple threads using a pipe_context at
the same time, we must finish glthread to avoid having the
unmarshalling thread executing at the same time.
It's fixing random crashes where a thread would do:
st_destroy_context ->
_mesa_make_current ->
st_glFlush(save_ctx) ->
tc_execute_batch
While there's a glthread unmarshalling thread that's still
adding commands to TC.
Fixes: 08d97aadd1 ("st/mesa: fix texture deletion context mix-up issues (v2)")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33552>
(cherry picked from commit f062c83f3a)
Validation was checking that if an instruction was accessing FAU RAM,
only one 64-bit slot was accessed, and if it was accessing a FAU special
value, only one was accessed, however it was not checking if both RAM
and special were used, which is only allowed in messaging instructions
except ATEST and BLEND.
Fixes Piglit:
spec/ati_fragment_shader/ati_fragment_shader-render-ops/mov c0.r
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Fixes: fd1906afea ("pan/va: Add FAU validation")
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33608>
(cherry picked from commit e504825813)
Previously deqp tests with *.multisampled_image_sparse_residency.* would
crash with "Unknown image intrinsic" because
nir_intrinsic_bindless_image_sparse_load was not handled in the lowring
code.
This commits handles MSAA sparse residency lowering as with other cases.
Signed-off-by: Lorenzo Rossi <snowycoder@gmail.com>
Fixes: 7604697ec6 ("nvk: Implement shaderStorageImageMultisample")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33625>
(cherry picked from commit bce9e851c6)
Add support for GL_OVR_multiview's GL_MAX_VIEWS_OVR which can be
accessed with glGetIntegerv().
MaxViews is accessed via the hash table set up by get_hash_params.py as
a constant (MAX_VIEWS_OVR) using GL_MAX_VIEWS_OVR.
v2: Add this patch (thanks to Mike's guidance)
v3: Drop unnecessary enum size element in OVR_multiview.XML
v4: Switch to CONST(MAX_VIEWS_OVR) instead of gl_constants::MaxViews
(Marek's suggestion)
Fixes: 328c29d600 ("mesa,glsl,gallium: add GL_OVR_multiview")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Signed-off-by: James Hogan <james@albanarts.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32992>
(cherry picked from commit be106bd6c6)
Implement the OVR_multiview framebuffer attachment parameters in
get_framebuffer_attachment_parameter():
- GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_NUM_VIEWS_OVR: This reads the
attachment's NumViews.
- GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_BASE_VIEW_INDEX_OVR: This reads the
attachment's Zoffset, but only if NumViews is non-zero.
This allows apitrace (PR 937[1]) to show the correct layers for
multiview framebuffer attachment surfaces, as well as to show this
information in the framebuffer attachments state.
[1]: https://github.com/apitrace/apitrace/pull/937
Fixes: 328c29d600 ("mesa,glsl,gallium: add GL_OVR_multiview")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Signed-off-by: James Hogan <james@albanarts.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32992>
(cherry picked from commit a282a130fb)
The OVR_multiview spec specifies the INVALID_VALUE error to be generated
by FramebufferTextureMultiviewOVR if:
"- <texture> is a two-dimensional array texture and <baseViewIndex> +
<numViews> is larger than the value of MAX_ARRAY_TEXTURE_LAYERS."
Implement this in check_multiview_texture_target(), similar to the test
in check_layer().
Fixes: 328c29d600 ("mesa,glsl,gallium: add GL_OVR_multiview")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Signed-off-by: James Hogan <james@albanarts.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32992>
(cherry picked from commit 60509e187f)
The OVR_multiview spec adds the following condition for framebuffer
completeness:
"The number of views is the same for all populated attachments.
{ FRAMEBUFFER_INCOMPLETE_VIEW_TARGETS_OVR }"
So add a condition to _mesa_test_framebuffer_completeness to check that
all attachments have identical NumViews. This avoids an infinite
recursion between zink_clear() and zink_clear_depth_stencil() in the
event of an incomplete FBO.
Fixes: 328c29d600 ("mesa,glsl,gallium: add GL_OVR_multiview")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Signed-off-by: James Hogan <james@albanarts.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32992>
(cherry picked from commit 7819d322c4)
NumViews needs considering along with the other attachment data when
reusing a multiview framebuffer texture attachment (i.e. shared depth
and stencil texture).
The depth and stencil attachments should match in all respects including
NumViews before reusing the existing one, and NumViews should also be
copied when reusing.
This avoids an infinite recursion between zink_clear() and
zink_clear_depth_stencil() in the case of reuse of a multiview
depth/stencil attachment.
Fixes: 328c29d600 ("mesa,glsl,gallium: add GL_OVR_multiview")
Signed-off-by: James Hogan <james@albanarts.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32992>
(cherry picked from commit 65f18c4787)
In 2183bc73a6 ("nvk: Use suld for EDB uniform texel buffers"), we
started using suld instead of tld for EDB uniform texel buffers because
we needed it for correctness. However, it's slow as mud. Using
suld.constant seems to fix the performance regression. I don't know if
it's quite tld performance, but it's close.
Backport-to: 25.0
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33612>
(cherry picked from commit eb27cbf25a)
This is way faster than suld.sys, which is what we're using today. So
far I haven't seen it matter for anything but texel buffers but it
likely helps some app somewhere.
Backport-to: 25.0
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33612>
(cherry picked from commit ffdc0d8e98)
This should never happen as the client should always give us aligned
addresses. However, in the off chance that it does, aligning down is
probably safer than aligning up as it won't cause the top end of the
range increase and potentially fault.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33610>
(cherry picked from commit 5762586c6d)
The tricks we play for texel buffers with VK_EXT_descriptor_buffer don't
work with tld with very large buffers. suld, on the other hand, doesn't
seem to have these limitations.
Fixes: 3b94c5c22a ("nvk: Lower descriptors for VK_EXT_descriptor_buffer buffer views")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33610>
(cherry picked from commit 2183bc73a6)
We can theoretically hit this if CmdProcessGeneratedCommandsEXT is
called with a state command buffer that doesn't have compute shader set
if execute commands bind a shader. We do, however, need to still call
nvk_cmd_upload_qmd() because it also uploads push constants and we need
those regardless of whether or not there's a shader bound.
Fixes: 976f22a5da ("nvk: Implement CmdProcess/ExecuteGeneratedCommandsEXT")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33610>
(cherry picked from commit ca06a57702)
Since Xe2, the registers are bigger and even the instruction
structures got updated to have 6 bits.
The way I detected this issue was when I tried to use
src/intel/executor to add the following instruction:
add(8) g6.8<1>UD g4<8,8,1>UD 0x00000008UD { align1 WE_all 1Q I@1 };
Executor would read this and end up emitting an add with dst being
g6<1>UD instead of what we wanted. It turns out that inside
brw_gram.y, at dstoperand and dstoperandex we do:
$$.subnr = $$.subnr * brw_type_size_bytes($4);
which would overflow subnr back to 0.
The overflow doesn't seem to be a problem with code we emit directly
(unlike the code we parse, like above) due to the fact that we seem to
treat Xe2 registers as smaller all the way until we call phys_nr() and
phys_subnr() during code generation. The phys_subnr() function can
generate a value that would overflow reg.subnr, but this value is
never written back to reg.subnr, it's just returned as an unsigned
int.
Fixes: e9f63df2f2 ("intel/dev: Enable LNL PCI IDs without INTEL_FORCE_PROBE")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33539>
(cherry picked from commit 927d7b322b)
For decode this is also done in decode_video.
This breaks if app doesn't call vkCmdEncodeVideoKHR before end, eg:
vkCmdBeginVideoCodingKHR
vkCmdControlVideoCodingKHR
vkCmdEndVideoCodingKHR
Cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33582>
(cherry picked from commit ebd8893710)
Apparently fast path cannot handle mismatched mutability and we
should use CP_BLIT which has SP_PS_2D_SRC_INFO.MUTABLEEN to signal
src mutability. Previously it was partially handled by
tu_attachment_store_mismatched_swap.
Fixes: a104a7ca1a
("tu: Handle non-identity GMEM swaps when resolving")
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33514>
(cherry picked from commit 97f851e7c5)
This is part of VK_EXT_mutable_descriptor_type but we never did anything
with it. Since we use local memory for descriptor sets, copying from
them means reading VRAM through a WC map and it's pretty expensive.
Using malloc() for HOST_ONLY should be a nice perf boost for things
which give us the hint.
This massively improves the performance Dragon Age: The Veilguard,
taking it from 7 FPS to 25 FPS on an RTX 4060.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12622
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33571>
(cherry picked from commit 607686f6bf)
More are found missed from prior maint5 support. This change has
properly initialized the maint5 props as well as fixing its new
VkPipelineCreateFlags2CreateInfo integrations.
Verified with dEQP-VK.*maintenance5*
Fixes: be6fece6e1 ("venus: enable VK_KHR_maintenance5")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33566>
(cherry picked from commit 8741be3365)
This is not conformant and it can cause hard to debug issues or hide
existing bugs. Getting rid of this limit will allow lavapipe to use the
common bvh building framework since the ploc build shader has a loop
that waits to start the next phase.
cc: mesa-stable
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31426>
(cherry picked from commit ac0f643d4b)
iceil can return bogus (negative) values in case there's an overflow
(or a NaN). This would then take forever to run due to a couple billion
loop iterations.
Use unsigned minimum instead which will clamp iterations to max aniso
(not sure if that makes more sense than clamping negative values to 0,
probably doesn't really matter).
Fixes: 350a0fe632 ("llvmpipe: Use a simpler and faster AF implementation")
Reviewed-by: Brian Paul <brian.paul@broadcom.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33537>
(cherry picked from commit 24076eb3f9)
Previously DGC alignment requirements declared by
getGeneratedCommandsMemoryRequirementsExt were not also reported by
getDeviceBufferMemoryRequirements for preprocess buffers.
This fixes 1554 dEQP-VK failures related to device-generated commands
that previously failed with "DGC alignment requirement larger than
preprocess buffer alignment requirement".
Fixes: 976f22a5da ("nvk: Implement CmdProcess/ExecuteGeneratedCommandsEXT")
Reviewed-by: Faith Ekstrand <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33555>
(cherry picked from commit cc30e35306)
This will be needed in order to check off passing the VK CTS properly.
Please note, this does *not* mean that we are formally conformant, only
that we have passed the VK CTS at least once. Those are not the same
thing.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Backport-to: 25.0
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33254>
(cherry picked from commit 2653a3988f)
bi_opt_mod_prop_backward tries to propagate values backwards, but
stops checking for uses when it reaches the SSA definition. For
ordinary blocks that's fine, but for loops the definition can come
after a PHI that uses the value. This causes incorrect code to be
generated in shaderdb test `shaders/skia/2134.shader_test`. Fix this
by special casing PHI instructions, in a manner similar to done in
asahi/compiler/agx_optimizer.c.
This bug has been present a long time, so we want it back-ported to
stable.
Cc: mesa-stable
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33483>
(cherry picked from commit 18a14c4522)
It turns out that the change from CENTER_Y to CENTER_X for
422 YUV didn't actually happen until generation 14 of the
hardware, not generation 10 as some documents claimed. This
fixes the failing piglit tests ext_image_dma_buf_import-sample_yuv
associated with 422 formats (which apparently we aren't running on CI).
Fixes: 23aa784c
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33516>
(cherry picked from commit c7fed8b053)
init_queue() calls cleanup_queue() if anything fails in the middle, which
means finish_render_desc_ringbuf() will be automatically called if
init_render_desc_ringbuf() failed. Get rid of the the error path and
return directly instead. The one exception we have is the dev_addr
allocation, which needs to be explicitly freed if an error occurs between
util_vma_heap_alloc() and pan_kmod_vm_bind().
Reported-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Fixes: 5544d39f44 ("panvk: Add a CSF backend for panvk_queue/cmd_buffer")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33471>
(cherry picked from commit 5f3c6a0f27)
This code is old, copied from the old nouveau GL driver. As of Pascal,
we have have 32k images so we need 32k scissors as well. Use the
max_image_dimension() helper instead of hard-coding it.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33478>
(cherry picked from commit 6f64962f27)
Indeed, has_atomics is not yet initialized at the time of the
call of r600_init_shader_caps(). This change fixes this issue.
For instance, this issue is triggered with
"piglit/bin/clearbuffer-depth-cs-probe -auto -fbo":
clearbuffer-depth-cs-probe: ../src/gallium/drivers/r600/evergreen_state.c:5039: evergreen_emit_atomic_buffer_setup: Assertion `resource' failed.
Aborted
Fixes: 7cd606f01b ("r600: add r600_init_screen_caps")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33438>
(cherry picked from commit bb44052ee9)
Add current time when generating the stream handle initial value.
When running inside PID namespace there can be multiple processes
in the system that will share the same PID and with current code
this could result in the same stream handle being used at the same
time from different processes.
This can easily happen with Flatpak when running two instances of the
same application - both processes will have the same PID and we
will use the same stream handles.
For older UVDs kernel will reject the CS if we use duplicated handles.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12575
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33374>
(cherry picked from commit fdf747af3a)
The offset is measured in bytes. Some of the code here acted as though
it were measured in src.type units. Also modify the assertion to check
that all extracted bits come from data in the immediate value.
Fixes: 580e1c592d ("intel/brw: Introduce a new SSA-based copy propagation pass")
Fixes: da395e6985 ("intel/brw: Fix extract_imm for subregion reads of 64-bit immediates")
Yes, I missed this error *twice* in code review.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33049>
(cherry picked from commit ac4b93571c)
Command buffer private object destroy callbacks receive a 64-integer so their
signature should respect that to avoid alignment issues when passing pointers.
This is the same we were already doing for color pipelines, but now for D/S
pipelines too.
Fixes crash on 32-bit build with:
dEQP-VK.synchronization2.op.single_queue.fence.write_clear_attachments_read_copy_image_to_buffer.image_128x128_d16_unorm
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33463>
(cherry picked from commit daa48cbaef)
Since the binding value can be any 32-bit number, we cannot assume that
it is <= 27 bits. We need 64-bit keys to accommodate a 32-bit binding.
This will also provide more bits to store the subdesc id, which will be
needed for multiplane texture and sampler descriptors.
Fixes: 7bea6f86 ("panvk: Overhaul the Bifrost descriptor set implementation")
Signed-off-by: Rebecca Mckeever <rebecca.mckeever@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32563>
(cherry picked from commit 9c4b530c49)
On armhf integer divide by 0 can raise SIGFPE, whereas on aarch64
it just returns 0. This has become an issue because the recently
added panfrost_init_screen_caps always calls pan_gpu_time_to_ns to
calculate caps->timer_resolution, whereas before we only called it
when PIPE_CAP_TIMER_RESOLUTION was queried, and only OpenCL
does that (and not always).
Fixes: 205669e3a9 ("panfrost: add panfrost_init_screen_caps")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33435>
(cherry picked from commit e550a3cab0)
Prevent following warning if not running as a normal user:
Failed to create /home for shader cache (Permission denied)---disabling
disk_cache_delete_old_cache() is going to create first the cache directory
using disk_cache_generate_cache_dir(). From mkdir_if_needed(), the stat()
of "/home" is failing with "Permission denied" under some circumstances
when using Firefox.
Fixes: #12168
Fixes: c3bc6991d2 ("util/disk_cache: Delete the old multifile cache if using the default.")
Signed-off-by: Benjamin ROBIN <dev@benjarobin.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32886>
(cherry picked from commit 622f7407d7)
The release branch contains only what was on the staging branch first,
so testing it again is a waste of resources.
To do this, we split the rule into specifically "default branch" and
"staging branch", and "release branch" gets dropped by virtue of no
longer being caught by any rule.
Cc: mesa-stable
Reviewed-by: Martin Roukala <None>
Reviewed-by: Dylan Baker <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33411>
(cherry picked from commit 7152f343d6)
It's too late to run all the tests by then, the release has been made
based on the staging pipelines results
Cc: mesa-stable
Reviewed-by: Martin Roukala <None>
Reviewed-by: Dylan Baker <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33409>
(cherry picked from commit 31f0a9be3f)
It's unclear to me whether this is dead code that should be removed or
dead code that should be used, so I just marked it as unused to remove
a few thousand warnings when compiling.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33384>
(cherry picked from commit 93a720f81a)
The fix in e7ac1094f6 to emit preamble defs in the correct block would
move the cursor of the builder that is later used to insert descriptor
prefetches, emitting them at the wrong place. Fix this by resetting the
cursor before emitting the prefetches.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: e7ac1094f6 ("ir3: rematerialize preamble defs in block dominated by sources")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33399>
(cherry picked from commit 8404e7428b)
This switches to disk_cache instead of our own mechanism which only
stored meta shaders when the logical was destroyed.
Meta shaders are still stored separately from the application shaders
because they are common to all applications on a given GPU/Mesa version.
The default cache is 32MiB which should be large enough.
This fixes massive stuttering in FF7 Rebirth but all apps are
technically affected.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33405>
These have been switching between failing and passing recently. Not
really sure what's going on here, but we don't want the CI to flip
randomly between failing and passing, so let's mark them as flakes.
Backport-to: 25.0
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33381>
(cherry picked from commit 4d86a1c928)
Vulkan defines the line rasterization to *always* use perpendicular
rather than aligned line ends (unless otherwise specified by
VK_EXT_line_rasterization). So let's remove the code that conditionally
sets the bit, we always want the default value (0) here.
It might seem confusing because we kinda named this field wrong. It's
really about perpendicular vs aligned line ends. That's a cleanup we
might want to deal with later, but deleting the assignment is sufficient
to fix this issue. This is also what we do for v10.
This was probably just copied from the Gallium-driver, where this logic
is more or less correct.
Fixes: d970fe2e9d ("panfrost: Add a Vulkan driver for Midgard/Bifrost GPUs")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33373>
(cherry picked from commit 1d64095410)
The check in check_multiview_texture_target() whether numViews <= 0 (as
required by the OVR_multiview spec) is never triggered since it is only
called by frame_buffer_texture() when numviews > 1, as numviews of 0 is
passed in by non multiview FramebufferTexture functions. Such cases are
incorrectly treated as non-multiview attachments.
Tweak frame_buffer_texture() to take an extra bool argument "multiview"
to distinguish between a multiview call with numviews=0, and a
non-multiview call.
Fixes: 328c29d600 ("mesa,glsl,gallium: add GL_OVR_multiview")
Signed-off-by: James Hogan <james@albanarts.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33346>
(cherry picked from commit 7f493b45ae)
Fix the FBO attachment completeness test to ensure that multiview
attachments have all views referring to layers in range of the
underlying texture.
The OVR_multiview spec states:
Add the following to the list of conditions required for framebuffer
attachment completeness in section 9.4.1 (Framebuffer Attachment
Completeness):
"If <image> is a two-dimensional array and the attachment
is multiview, all the selected layers, [<baseViewIndex>,
<baseViewIndex> + <numViews>), are less than the layer count of the
texture."
Fixes: 328c29d600 ("mesa,glsl,gallium: add GL_OVR_multiview")
Signed-off-by: James Hogan <james@albanarts.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33346>
(cherry picked from commit 39491da1b6)
if there is no heap with device-local and host-visible, then
rebar cannot exist. the previous detection did not account for
the rebar heap using the device-local fallback, which of course
would have the same size as the device-local heap and pass the threshold
check
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33359>
(cherry picked from commit 3064bfc312)
We now use `parse_debug_string` to parse debug strings from files, which
may have newlines in them. This change ensures that newline characters
are ignored during parsing, a similar change was made to
`parse_enable_string` for consistency.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32906>
Currently the `nolrz` TU_DEBUG options are only checked during
device creation and image creation, respectively. This means that if
the options are enabled after the device/image is created, LRZ
will still be used. Similarly, if the options are disabled after the
device/image is created, LRZ will still be disabled.
This change moves the checks to the point where the LRZ is actually
used, allowing for runtime toggling of LRZ.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32906>
This adds a new environment variable, TU_DEBUG_FILE, which can be used to
enable/disable various debug options at runtime via writing to a file. This
is useful for switching between different debug options (such as toggling
between SYSMEM/GMEM) without needing to restart the application.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32906>
debian-testing is the critical path: the shortest possible job to build
exactly what we need to execute on hardware, and nothing else.
debian-build-testing exists to give us better coverage at the expense of
running longer.
Since the only jobs using r300 and Nine, and the only jobs using NVK,
are in post-merge stages which are manually triggered, move these builds
to debian-build-testing. This makes the critical path to those a little
longer, but we do get to make it shorter for everyone else just running
regular Marge jobs.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33287>
We don't need these Vulkan bits, so let's try not building them. This
might seem kind of petty, but given that we build dEQP four times for GL
(once for GL, once for GLES, once for EGL/X11, and once for
EGL/Wayland), it does actually make a measurable difference to the time
spent rebuilding dEQP.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33287>
This avoids a whole pile of nonsense that we don't need during the dEQP
build, which is helpful when you build it five times in a row. In
particular, not building the Vulkan validation layers means we don't
waste three minutes building a second copy of SPIRV-Tools which we never
use.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33287>
Create separate branches for output processing and exports.
Normally, emit attribute ring stores at the end of the shader,
but with the attribute ring wait bug, insert them between the
primitive and position export branches.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33218>
There is a possibility that some waves in an NGG workgroup
don't have any input vertices, only primitives. When these
waves store the primitive ID as a per-primitive attribute,
they will need to wait for those stores before the primitive
export, because the other waves can't wait for them.
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33218>
This case is unlikely but possible. We forgot to handle it here,
because it was originally handled by the backend compiler.
On GFX10 chips that have issues with 0 vertices and primitives
exported, this will always export at least 1 vertex and primitive.
This could theoretically fix some hangs on Navi 10, although we are not aware of a specific issue caused by this problem.
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33218>
These have been tested only with x86_64->i686 cross-compilation but I
don't see why they couldn't work with other architectures if/when Linux
distributions support them. For at least x86_64->i686 cross-compilation,
these commands save an enormous amount of time.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31945>
After optimization happen, if the sources are still in one or two
contigous spans for some reason (e.g. some data read from memory
now being written), it is beneficial to just use regular SEND
and avoid having to set the ARF scalar instruction.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Lionel Landwerlin <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32410>
Add an optimization pass to turn regular SENDs into SEND_GATHERs.
This allows the payload to be "broken" into smaller pieces that
can be further optimized, which _may_ result in
- less register pressure (no need to contiguous space), and
- less instructions (no need to MOV to such space).
For debugging, the INTEL_DEBUG=no-send-gather option skips this
optimization, and reporting how many opportunities were missed.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Lionel Landwerlin <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32410>
Starting in Xe3, there's a variant of SEND that take the
register numbers from the ARF scalar register, and don't
require them to be contiguous. The new opcode added here
represents that kind of SEND.
To make the original sources still reachable, we keep them
around during the IR, just ignoring them at generator time.
This allow software scoreboard to properly reason the
dependencies without trying to decode the contents of ARF
scalar register being used.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Lionel Landwerlin <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32410>
Isolate the BRW/ELK differences in a single place. The way is done now,
we are not reusing the isa_info between calls. For the tools here this
is probably fine, if its someday this gets in the way, we can add an
opaque pointer to store the right data.
This intentionally is not used in Iris, since there the driver need more
detailed view into BRW/ELK and we don't want to create an all
encompassing abstraction for that.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33054>
v2: Use MOV and wrap in conditional during BTD spawn header setup
(Lionel). Remove references to SIMD8 (Tapani).
v3: Update brw_bsr() to specify number of registers per thread, don't
initialize Registers Per Thread on BTD spawn header (Lionel).
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32664>
This is similar to what we used to do on pre-SNB platforms, the number
of GRF registers used by the shader will be used on Xe3+ to adjust the
trade-off between thread-level parallelism and size of the GRF file.
Plumb the value through prog_data so the driver can set up the
hardware state accordingly.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32664>
This is similar in principle to the previous commit "intel/brw/xe3+:
brw_compile_fs() implementation for Xe3+." but applied to compute-like
shader stages. It changes the implementation of brw_compile_cs/task/mesh()
to reduce compile time and take advantage of wider dispatch modes more
aggressively than the original logic, since as of Xe3 SIMD32 builds
succeed without spills in most cases thanks to VRT.
The new "optimistic" SIMD selection logic starts with the SIMD width
that is potentially highest performance and only compiles additional
narrower variants if that fails (typically due to spilling), while the
old "pessimistic" logic did the opposite: It started with the
narrowest SIMD width and compiled additional variants with increasing
register pressure until one of them failed to compile.
In typical non-spilling cases where we formerly compiled SIMD16 and
SIMD32 variants of the same compute shader, this change will halve the
number of backend compilations required to build it.
XXX - Possibly don't do this in cases with variable workgroup size
until effect on runtime performance can be measured directly.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
v2: Don't do this for now in cases with variable workgroup size, still
compile every possible variant in such cases.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32664>
This reworks the implementation of brw_compile_fs() to reduce compile
time and take advantage of wider dispatch modes more aggressively than
the original logic.
The new "optimistic" PS compilation logic starts with the SIMD width
that is potentially highest performance and only compiles additional
narrower variants if that fails (typically due to spilling or hardware
restrictions), while the old "pessimistic" logic did the opposite: It
started with the narrowest SIMD width and compiled additional variants
with increasing register pressure until one of them failed to compile.
The main disadvantage of this is that selectively throwing away some
of the compiled variants based on the static analysis of their
performance behavior will no longer be possible, however this is
expected to be less useful on Xe3+ since the GRF space allocated to a
thread can be scaled up or down, which leads to less dramatic
differences in scheduling between SIMD variants.
In typical non-spilling cases where we formerly compiled SIMD16 and
SIMD32 variants of the same fragment shader, this change will halve
the number of backend compilations required to build a shader. With
multi-polygon PS dispatch enabled (which is disabled by default right
now) this has an even more dramatic effect since the number of
compiler iterations can be reduced down to a fifth in the best case
scenario.
Even though in most cases we will only attempt to return a single
binary from the pixel shader compilation, the hardware allows a pair
of PS kernels to be specified, and we'll still take advantage of this
when the multi-polygon PS kernel has the potential to have worse
performance than the single-polygon shader because only the latter
register-allocates successfully at SIMD32 -- Only in such case
(SIMD2x8 multi-polygon, SIMD32 single-polygon) we'll continue
programming both so the hardware will chose one or the other at
runtime depending on the SIMD fullness and number of polygons it can
buffer at runtime.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32664>
This avoids running the optimizer uselessly if compilation of the
current kernel failed due to some hardware (e.g. SIMD-width)
restriction. This isn't only inefficient but it can break assumptions
throughout the compiler which would lead to crashes on Xe3 when this
arises during translation from NIR.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32664>
Xe3+ benefits from packing register allocations tightly in order to
make optimal use of the GRF space. The round-robin heuristic
previously in use often causes the whole GRF space to be used even if
register pressure is substantially lower, which would severely
decrease thread-level parallelism on Xe3+.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32664>
Xe3 supports 32 SBID tokens per thread regardless of the number of
register blocks allocated per thread. Take advantage of the increased
number of SBIDs in the scoreboard pass to reduce the frequency of
false dependencies on Xe3+.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32664>
These don't seem to be disallowed by recent hardware anymore. Stop
disabling SIMD32 due to hardware restrictions of multisample
rasterization, since it should have better performance, and on Xe3+
there may be no shader variant available other than SIMD32.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32664>
Request a fixed subgroup size for pixel shaders that require it due to
the hardware restrictions of fast clears and repeated data clears.
This requires plumbing the "is_fast_clear" boolean across several
callers since blorp_compile_fs_brw() currently has no information
regarding whether the kernel is intended for a fast clear operation.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32664>
On older hardware the "use_rep_send" compile parameter was being
implicitly used to request the compilation of the SIMD16 variant of
clear pixel shaders that require it due to hardware restrictions.
However starting on Gfx12+ this flag is never set since replicated
data clears are no longer supported, but BLORP still implicitly relies
on the SIMD16 variant being generated even though there's no way for
BLORP to explicitly request it. This doesn't cause much of a problem
right now since brw_compile_fs() typically generates a SIMD16 kernel
unless the SIMD8 kernel spills or SIMD debugging flags are enabled,
but it won't work reliably on Xe3+ since we'll start using SIMD32 more
aggressively.
In order to avoid these issues use the standard required subgroup_size
parameter from shader_info to signal that the SIMD16 variant of the
shader is needed by the caller.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32664>
The lavacli version 1.5.2 has been released in December 2022.
Use the most recent version 2.2.0, released in October 2023, instead.
Notable changes since 1.5.2:
- Authentication tokens are now stripped from exceptions when HTTP
requests fail. (1.6)
Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33266>
The panfrost-g52-piglit-gles2:arm64 job was taking 19 minutes on
average, and the pending durations of the meson-g12b-a311d-khadas-vim3
DUTs in LAVA were reaching 5-6 minutes, so we have to make this job
manual instead of pre-merge.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33082>
This fixes depth-only rendering with mesh shaders,
as well as array derefs in unlinked shaders in general.
Lowering array derefs of vectors is necessary for correctness.
Without this, nir_lower_io will incorrectly add the array index
to the IO intrinsic base instead of to the component offset.
This was previously only done during shader linking, which leaves
some problems with unlinked shaders and depth-only rendering.
Whether these calls can be safely removed from shader linking
will be investigated in a future commit.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12516
Cc: mesa-stable
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33264>
This is a preliminary implementation of detiling for
NV12_16L32 tiled format external images. When we
encounter such an image, decode it into a secondary
buffer which will then be used to actually texture from.
In some cases applications may wish to represent the individual
planes of an NV12 image separately, we support that by allowing
detiling of just an R8 (luma) or R8G8 (chroma) plane.
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31899>
After commit 44bda7c258 (dri: put shared-glapi into libgallium.*.so,
2024-12-26) the mesa Android build does not have a separate libglapi.so
object anymore in the install dir, so stop pushing it to the Android
device in cuttlefish-runner.sh
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33261>
Add a trailing dot to the remote directoyy in the `adb pull` command to
make sure to recursively pull only the **content** of the directory and
not the directory itself.
This prevents having `results/results/` in the artifacts.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33261>
This initial support should be good enough but it's missing two
features (cooperative matrix and video decode/encode) compared to
GFX11 (RDNA3) because lack of time.
DCC is still under active development but it might be possible to
finish it during the RC period.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33281>
There is no test for this, but it's been broken.
ARB_sample_shading doesn't set fs.uses_sample_shading in shader_info,
which causes us to enter this path to force per-sample interpolation,
but doing so breaks the shader if the PS prolog is used.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32910>
It just indicates that sample shading is enabled, which we were
checking already. The state is redundant.
Just check shader_info::fs::uses_sample_shading. ARB_sample_shading (GL3.3)
doesn't set fs.uses_sample_shading in shader_info (which is for GL4.0), and
that's why we have this codepath that forces per-sample interpolation.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32910>
All PS lowering that changes, adds, or removes system values based on
the shader key is done first, which is done in ac_nir_lower_ps_early and
other passes, so now we just need to gather them.
This should improve performance for ACO due to fewer VGPRs needed
for optimized shader variants of PS.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32910>
It will be done in a different place later, but for now, we need to get
it out of si_update_shader_binary_info because the function will be
removed and PS input gathering will be moved, which will be quite
complicated, but it's needed for having a linker in radeonsi.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32910>
This is a prerequisite for linking merged shaders.
At the beginning of get_nir_shader (renamed to get_nir_shaders), we get
both shaders that are going to be merged, and then we optimize them together
and pass them to LLVM or ACO-specific code as struct si_linked_shaders.
The code setting uses_instance_id is moved because the previous place
doesn't work with this new organization.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32910>
This splits shader variant compilation into the following stages:
* get_input_nir
* run_pre_link_optimization_passes
(not implemented yet: run linking optimizations here)
(not implemented yet: gather shader_info here)
* run_late_optimization_and_lowering_passes
This order is important when we start adding linking optimizations for
shader variants and start getting shader_info from shader variants instead
of input NIR.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32910>
We don't need to look at the framebuffer state and record how many color
buffers to write. Instead, we can deduce which color buffers are enabled
from spi_shader_col_format, which already does the right thing.
So PS epilogs only need a single bool flag that determines whether all
enabled color buffers should be written.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32910>
This adds an option into the prolog key to replace frag_coord.xy with
pixel_coord when sample shading is disabled, which is most of the time.
This reduces the number of input VGPRs.
It's already implement in ac_nir_lower_ps_early for monolithic shaders
and the PS prolog in ACO, so this just implements it for the PS prolog
in LLVM IR.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32910>
Using the used component count is not enough. We need to consider
the component mask because any component can be disabled. This might
fix tests.
This removes the component counting from ac_get_fs_input_vgpr_cnt
and determines the component mask where it's needed.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32910>
Liveness info can be huge, since with larger shaders it essentially
grows quadratically (linear increase in number of SSA defs *
linear increase in blocks).
Freeing liveness info early helps somewhat mitigate memory usage here.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29577>
LLVM 15 is pretty old, and notably not supported by either ANGLE nor
Skia anymore. So let's move up to LLVM 19 using packages provided by
LLVM themselves, apart from PPC and ARMv7 which don't have builds.
The Skia build now requires a bunch of new warning exclusions; hopefully
most of these are no longer needed when we can upgrade Skia shortly.
The ci-deb-repo revision has also been bumped to get us a new version of
xtensor which builds with LLVM 19, and a version of spirv-tools which
also works with LLVM 19.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Closes: mesa/mesa#11538
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33137>
We don't actually need this anymore. We were previously using it to find
ccache, but Meson will do this for us. Now that we pass
-Wl,--fatal-warnings, we don't need to pass -Werror to the link stage
either.
This removes two shell execs, one subshell, and one call to each of grep
and printf, per compile.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33137>
Enabling Werror on our code is good, but it's less good on external
projects. Some of the Rust subprojects are now failing due to warnings
exposed by the newer Rust toolchain in Fedora, which we don't care about.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33137>
When building for the dynamic loader used by e.g. Clover, pipe_i915 was
the only target failing to declare a driver descriptor. This becomes an
error with more aggressive linkers.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes: 87392385b5 ("gallium/drm: Define the DRM entrypoints in drm_helper.h")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33137>
We now have to do five builds of dEQP: one each for tools, GL, GLES,
Vulkan (release branch), and Vulkan (main).
dEQP is not a quick build, with even the tools build taking ten minutes,
at least three of which go to just pulling the SPIRV-Tools source.
Building all five takes a cumulative 60 minutes (10 tools, 11 GL, 9
GLES, 15 VK release, 13 VK main). That doesn't give us a load of time to
build everything else we need.
Two hours is obviously a completely unreasonable amount of time to spend
doing builds, especially for jobs which shouldn't really exist. But the
yak shave to allow the container jobs to be able to run on non-b2c
hardware has been a long one, and with no big-bang solution turning up
any time soon, we need to be able to actually do rootfs builds.
So, let's do the worst possible thing and go for a gigantic timeout.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33137>
Sitting here trying to get something else done tonight, I watched the
ASan and UBSan jobs, both on AArch64 and x86_64, regularly blow through
their timeouts.
They should be fixed to do less, but this makes them at least succeed in
the meantime.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33137>
Building and linking drivers, Rust code, and tools, takes an inordinate
amount of time with sanitisers. That could be justified if we used the
results to test, but we don't.
Reduce the coverage to get reasonable runtimes back.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33137>
Running the Meson tests doesn't take forever, but it does take a
noticeable amount of time.
For jobs in the critical path - like debian-testing and debian-arm64 -
we need them to complete as soon as possible to produce a build for the
hardware tests to consume. Running the tests here lengthens that time,
and introduces more hazard since the tests have previously been prone to
hitting timeouts, requiring the whole job to be retried before we can
proceed. These jobs also have build-only jobs which are not in the
critical path, and can run the tests just as well.
Running the tests under sanitisers is just too slow to deal with in
pre-merge pipelines.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33137>
NEW util/conversion.rs
Adds traits `TryFromWithErr` and `TryIntoWithErr` and their
implementation for types with `TryFrom` and `TryInto` traits
former
```
try_into().map_err(|_| CL_OUT_OF_HOST_MEMORY)
try_from(val).map_err(|_| CL_OUT_OF_HOST_MEMORY)
```
can now be written as
```
try_into_with_err(CL_OUT_OF_HOST_MEMORY)
try_from_with_err(val, CL_OUT_OF_HOST_MEMORY)
```
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33267>
cat3 instructions read their 3rd src later than their first two srcs.
This was implemented in two different places: once for scheduling and
once for legalization. Extract this logic in a new helper and also add
similar logic for gat/swz there (which the scheduling logic failed to
account for).
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33183>
Preamble defs were rematerialized at the end of the preamble. However,
when some of the sources were defined inside control flow, this would
lead to these sources not dominating their use. Fix this by finding the
block that is dominated by all sources and inserting the new instruction
there.
Also make sure we only de-duplicate instructions if the new instruction
is dominated by the existing one.
Fixes a NIR validation error in Devil may cry 5.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: fdfe86aa52 ("ir3: Expand preamble rematerialization")
Fixes: 6a744ddebc ("ir3: Initial support for pushing globals with ldg.k")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33270>
This was accidentally deleted when rewriting to use common Vulkan
dynamic state. This meant we wouldn't correctly fall back when someone
accidentally used FDM together with multiple viewports.
Fixes: 97da0a7734 ("tu: Rewrite to use common Vulkan dynamic state")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33241>
Scheduling an alias.rt right before an alias.tex causes a GPU hang.
Follow the blob and schedule all alias.rt at the end of the preamble to
prevent this from happening.
Fixes a hang in Borderlands 3 on medium or higher graphics settings.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: 0aa9678d4d ("ir3: add support for alias.rt")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33238>
Textures opcodes can't read from the contant registers, however we can
just handle this fine in the native swizzle pass. Others like saturate
for tex instructions) can't happen anyway since we swithed to nir_to_tgsi
long time ago. However, keep the asserts just to be safe.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33066>
The pass tried to convert shaders to a SSA-like form. However since
we no longer allocate registers in NIR, and we try hard to keep the
SSA-like form during the later passes, this is now superfluous.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33066>
Prevents shader-db regression, since NIR puts just everything to x and the
pair scheduling is not smart enough to fix it later, espetially after
presubtract happens.
Together with the previous patches that move the shadow lovering to NIR
this results in the following shader-db stats:
RV530:
total instructions in shared programs: 129598 -> 128697 (-0.70%)
instructions in affected programs: 19001 -> 18100 (-4.74%)
helped: 124
HURT: 9
total presub in shared programs: 8554 -> 8314 (-2.81%)
presub in affected programs: 1099 -> 859 (-21.84%)
helped: 17
HURT: 50
total temps in shared programs: 17514 -> 17000 (-2.93%)
temps in affected programs: 1368 -> 854 (-37.57%)
helped: 45
HURT: 18
total cycles in shared programs: 191286 -> 190593 (-0.36%)
cycles in affected programs: 32369 -> 31676 (-2.14%)
helped: 110
HURT: 29
RV410:
total instructions in shared programs: 112805 -> 112618 (-0.17%)
instructions in affected programs: 7089 -> 6902 (-2.64%)
helped: 65
HURT: 21
total presub in shared programs: 3244 -> 3314 (2.16%)
presub in affected programs: 228 -> 298 (30.70%)
helped: 7
HURT: 47
total temps in shared programs: 18163 -> 18138 (-0.14%)
temps in affected programs: 710 -> 685 (-3.52%)
helped: 36
HURT: 19
total cycles in shared programs: 169530 -> 169369 (-0.09%)
cycles in affected programs: 11304 -> 11143 (-1.42%)
helped: 63
HURT: 27
The stats are a bit less awesome for Rv410, since it can't run the heavy
Unigine Tropics shaders where this helps the most due to the TEX
indirection limits.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33066>
This means we now do fragment shader-variants at the NIR level and we
therefore need to run nir_to_rc translation later during the shader
variant creation.
This is a temporary instruction count as well as registers count
regression, due to NIR putting everything to x instead of w, this is
fixed in the next commit which also shows some nice shader-db stats
improvements in total.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33066>
We only care that the negates of the relevant components are the same.
Specifically the assert would incorectly trigger for code like this
ADD temp[3].x, 1.250000 (0x3a).-x___, -const[0].x___;
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33066>
The texture_map functions can fail, due to for instance address-space
exhaustion during mmap calls. Handling this by asserting turns this
into a fatal error when doing debug builds, which might not be what
users want.
Instead, let's allow this to fail. This is alredy what we do for
util_clear_color_texture and util_clear_render_target.
While we're at it, let's add some breadcrumbs to applications here, by
emitting an error at the same time. We should really consider returning
a proper pipe_error here instead, but that requires changing a lot of
function signatures, as this function are used as an implementation of
p_context::resource_copy_region()... So let's save that for later.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32431>
The DRIVER_NAME variable is used to locate the DRIVER_NAME-skips.txt
file. It was not used for panfrost, so remove the three places where
it was set, assign it to panvk, and add a panvk-skips.txt file.
Additionally, properly track changes to this file.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32817>
Due to the slow startup time of deqp-vk, the previous default of
500 tests per group caused the jobs to run up to twice as slowly
compared to using a higher number of tests per group.
Since the CTS uprev did not introduce any new leaks that caused
the entire caselist to get marked as fails, increasing the number
of tests per group is considered safe and improves efficiency.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32817>
This is simply following the redirects the same way the browser does.
The new pages were manually verified to still contain the corresponding
information.
For URLs where this was not the case, see the next commits.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33159>
The Vulkan spec says:
"If logicOpEnable is VK_TRUE, then a logical operation selected by
logicOp is applied between each color attachment and the
fragment’s corresponding output value, and blending of all
attachments is treated as if it were disabled. Any attachments
using color formats for which logical operations are not supported
simply pass through the color values unmodified."
When logic op and blending are both enabled, logic op takes precedence
and values should be passed through unmodified. Also RB+ shouldn't
have any effects when blending is disabled.
Fixes new VKCTS coverage dEQP-VK.pipeline.*.logic_op_na_formats.*.
Fixes: 03b037a0e3 ("radv: disable logic op for float/srgb formats")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33235>
From OpenGL 4.6 - 8.23.1 Depth Texture Comparison Mode
Let Dt be the depth texture value and St be the stencil index
component. If there is no stencil component, the value of St is
undefined. Let Dref be the reference value, provided by the shader’s
texture lookup function. If the texture’s internal format indicates
a fixed-point depth texture, then Dt and Dref are clamped to the
range [0, 1]; otherwise no clamping is performed.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33140>
..where N = # of functions in the shader. We were accidentally reprocessing the
whole shader for every function impl. Noticed when reading a vtn_bindgen2
profile.
We elect to port the relevant part of the pass to instrctions_pass which fixes
the perf problem while deleting a pile of code.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33245>
Only keep context mutex locked while waiting for fence.
This fixes issue with multi-threaded use of VAAPI where SyncSurface
and SyncBuffer would block all contexts, even those used in different
threads. The issue exists for all API calls, however in most cases this
is not a big deal as most calls will return fast, but sync is expected
to take up to tens of ms.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33165>
Changes required after commit 44bda7c2
Fixes the following building error:
FAILED: out/target/product/x86_64/obj/SHARED_LIBRARIES/libglapi_intermediates/libglapi.so
...
'out/target/product/x86_64/obj/MESON_MESA3D/install/usr/local/lib/libglapi.so': No such file or directory
Fixes: 44bda7c2 ("dri: put shared-glapi into libgallium.*.so, remove the remap table to reduce GL dispatch overhead")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33224>
VINTRP(gfx6-gfx10.3) is mostly just VALU, but we treated it like memory
instructions as an afterthought. This had issues as VINTRP was never reordered
with itself, or other memory instructions. Reordering VINTRP in clauses
increases ILP. We don't really need collect_clause_dependencies for VINTRP
either, because they ususally have the same dependencies already. That means
we can still form VINTRP clauses by selecting preferably VINTRP after a
previous one.
Foz-DB Navi21:
Totals from 34184 (43.16% of 79206) affected shaders:
Instrs: 18811270 -> 18812046 (+0.00%); split: -0.01%, +0.02%
CodeSize: 103627276 -> 103630056 (+0.00%); split: -0.01%, +0.01%
Latency: 188379364 -> 187936731 (-0.23%); split: -0.27%, +0.03%
InvThroughput: 42600163 -> 42590608 (-0.02%); split: -0.03%, +0.00%
VClause: 378960 -> 378912 (-0.01%); split: -0.02%, +0.00%
SClause: 727560 -> 720573 (-0.96%); split: -1.08%, +0.12%
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Reviewed-by: Daniel Schürmann <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33111>
After the fix in commit b016f218fb (ci/android: fix meson C++
cross-compiler argument detection, 2025-01-14) the cross-build meson
hacks should not be necessary anymore for the CI builds to pass.
Remove the hacks making sure that the removed arguments are all in the
regular list of arguments passed through cpp.get_supported_arguments()
Reviewed-by: Rob Clark <robclark@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33209>
For whatever reason NXP decided to call the GC3000 in the i.MX6QP a
GC2000+. This being a lie is marked in the IP core by the upper half
of the revision register being all ones. The kernel driver already
fixes the model and revision when it encounters this core, but this
breaks matching in the HWDB, which uses the bogus model/rev from the
core.
Revert the fixup done by the kernel for the lookup in the HWDB.
Fixes: 2192e620bb ("etnaviv: hwdb: Add etna_query_feature_db(..)")
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33223>
In unified uniform mode the constant memory is dynmically partitioned
between VS and FS, which allows to use far more FS constants than
currently supported with the fixed split when VS constant usage is low.
Limit computation taken from the Vivante kernel driver.
Fixes dEQP-GLES2.functional.uniform_api.random.79 on GPUs with
unified uniform support.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32983>
Unified uniform mode allows to dynamically partition the constant memory
by specifying the start of VS and FS constants within the memory area. Use
this to place the FS uniforms directly behind the VS uniforms, potentially
making more space available to FS uniforms.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32983>
This adds an option to replace frag_coord.xy with pixel_coord when sample
shading is disabled, which is most of the time. This reduces the number of
input VGPRs.
It's already implement in ac_nir_lower_ps_early for monolithic shaders.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33024>
- really update sample shading state when it's changed
- reduce log state bits in the shader key to 2 because we don't support
16x EQAA
- exit early from si_update_ps_iter_samples if ps_iter_sample has the same
value since the last call
- set missing wqm for the PS prolog (this might fix tests)
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33024>
In theory you can build a driver using OpenCL kernels with a
-Dmesa-clc=system. That shouldn't require any LLVM/Clang/etc...
But the checks to find the pre-compiled mesa_clc & vtn_bindgen
binaries are in meson files or conditions only triggered if you build
with LLVM (:
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Tested-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Dylan Baker <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33014>
This kernel was built using b2c's linux builder without any additional
patches... aside from the usual ones I apply for b2c, so we are almost
to the point where we can run a stable kernel on it!
The next uprev should be made from gfx-ci/linux rather than being
hosted on my server, but I would like to use a released kernel for
that.
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33162>
This Vulkan layer allows reporting a limited VRAM size to the
application. This layer can be useful for testing applications and
games which query for the memory budget adjusting their behavior
accordingly.
They layer does not set a hard limit on the amount of VRAM thus
applications can still make allocations even though the reported
budget might indicate no memory is left, if the set limit is lower
than of actually available VRAM.
Signed-off-by: Karmjit Mahil <karmjit.mahil@igalia.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30095>
Rename the variable ANDROID_NDK to ANDROID_NDK_VERSION and only use it
to specify the version itself.
This makes it consistent with ANDROID_SDK_VERSION and it is also in
preparation for using the same variable to build ANGLE in the future.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33188>
This change moves freedreno specific ForEachMacros from the top level
.clang-format to the freedreno specific .clang-format.
This is done to avoid triggering CI for all drivers when making changes
to this list.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32107>
Whenever we insert a (nopN) on the previous instruction to add nops, we
initially add them to the current cycle count. However, existing (nopN)
fields are not accounted for. This means the if a (nopN) gets inserted
and the block is processed again, the cycle count will be too low and we
might insert more nops than necessary.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33178>
Instead the complicated logic we currently have, do this :
We start with this shader :
int main() {
...
if (...) {
SetMeshOutputsEXT(0, 0);
return;
} else {
SetMeshOutputsEXT(...);
}
...
}
We turn it into this :
int main() {
uint __temp_prim_count = 0;
...
if (...) {
__temp_prim_count = 0;
return;
} else {
__temp_prim_count = ...;
}
...
if (is_first_group_lane()) {
SetMeshOutputsEXT(..., __temp_prim_count);
}
}
This works because the SPIRV spec says this :
"The arguments are taken from the first invocation in each
workgroup. Any invocation must execute this instruction no more
than once and under uniform control flow."
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12388
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33038>
This supports everything the blob does.
The registers exist on later a6xx gens, but they would be way more
inconvenient to use since they're mixed up with binning/not-binning and
compression state, and I'm not sure if it works.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33152>
These fields don't actually enable binning, but rather disables the FS.
This seems to happen automatically on a7xx when binning, because the
blob doesn't set them specially during the binning pass.
Move them to rasterization, because RB_RENDER_CNTL will start depending
on rasterization state in the next commit.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33152>
When WSI is working in prime/dma-buf mode, it has one additional
VkBuffer or VkImage where the main VkImage is copied to without any
compression or tiling different from linear
The batch buffer to do this copy is created in
wsi_finish_create_blit_context(). It performs a barrier transitioning
the VkImage to VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL, performs the
copy, and then transitions it back to VK_IMAGE_LAYOUT_PRESENT_SRC_KHR.
However, in this prime/dma-buf mode, no display modifiers are involved,
which causes compression to be disabled when switching to
VK_IMAGE_LAYOUT_PRESENT_SRC_KHR.
This change adds an exception to allow the Vkimage to remain compressed
because we can handle the compressed-to-uncompressed copy.
Doing so fixes an issue that was reported with BMG + integrated GPU
and should also improve performance by keeping the VkImage compressed.
Cc: mesa-stable
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12354
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33044>
When encountering pipeline barriers in secondary command buffers that do
not start their renderpasses, our barrier logic would not detect the
need to flush existing draws, leading to race conditions in case of
subpassLoad.
This change ensures we flush existing draws when required in secondary
command buffers.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33182>
if e.g., multiview framebuffer is enabled, shader objects cannot be used,
requiring the bound shaders to be compiled into a pipeline on-demand
this is not knowable in advance and will always result in a stall
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33005>
Setting zs_update_operation = FORCE_EARLY for color preloads triggers
hangs in the dEQP-VK.rasterization.rasterization_order_attachment_access
depth/stencil tests. I didn't determine why this is the case, but the
DDK uses WEAK_EARLY for color preload, and doing the same here fixes the
hang.
WEAK_EARLY requires ATEST, so I removed .is_blit=true from the compiler
inputs.
There aren't any known hangs outside of the one set of vulkan CTS tests,
and in particular no known hangs in the gallium driver. Because the
reason for the hangs is not understood, I also changed the gallium
driver to use WEAK_EARLY, under the assumption that the same conditions
that trigger the hang in vulkan might occur in GL.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Fixes: edd98aac3f ("panfrost: Add support for native wallpapering on Bifrost")
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32954>
On bifrost, zs_update_operation=STRONG_EARLY, is equivalent to
WEAK_EARLY except that it may test/update without waiting for pixel
dependencies if it can prove that the test will pass.
STRONG_EARLY no longer exists on valhall, and the value 2 is reserved.
Even on bifrost, all of our current uses of STRONG_EARLY are
incorrect. For color preload, the shader skips ATEST, so FORCE_EARLY is
required. In the no-FS case, ATEST is skipped by definition (because
there is no shader), so FORCE_EARLY is required.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Fixes: 519643bbe0 ("panfrost: Adjust the renderer state definition")
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32954>
a7xx introduced support for aliasing render target components using
alias.rt. This allows components to be bound to uniform (const or
immediate) values in the preamble:
alias.rt.f32.0 rt0.y, c0.x
alias.rt.f32.0 rt1.z, (1.000000)
This aliases the 2nd component of RT0 to c0.x and the 3rd component of
RT1 to the immediate 1.0. All components of all 8 render targets can be
aliased.
This is implemented by replacing const and immediate components of the
RT sources of end with alias.rt instructions in the preamble. If no
preamble exists, an empty one is created.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31222>
a7xx introduced support for aliasing render target components using
alias.rt. This allows components to be bound to uniform (const or
immediate) values in the preamble:
alias.rt.f32.0 rt0.y, c0.x
alias.rt.f32.0 rt1.z, (1.000000)
This aliases the 2nd component of RT0 to c0.x and the 3rd component of
RT1 to the immediate 1.0. All components of all 8 render targets can be
aliased.
In addition to using alias.rt, the hardware needs to be informed about
which render target components are being aliased using the
SP_PS_ALIASED_COMPONENTS{_CONTROL} registers. This commit implements
those registers.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31222>
a7xx introduced support for aliasing render target components using
alias.rt. This allows components to be bound to uniform (const or
immediate) values in the preamble:
alias.rt.f32.0 rt0.y, c0.x
alias.rt.f32.0 rt1.z, (1.000000)
This aliases the 2nd component of RT0 to c0.x and the 3rd component of
RT1 to the immediate 1.0. All components of all 8 render targets can be
aliased.
In addition to using alias.rt, the hardware needs to be informed about
which render target components are being aliased using the
SP_PS_ALIASED_COMPONENTS{_CONTROL} registers. This commit implements
those registers.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31222>
The clear FS shaders will statically use slot numbers from 0 up to the
number of supported render targets. However, the driver will remap those
slots to the actual render targets being cleared.
This means that ir3 should not make any assumptions about the static
slot number in those cases. This is especially important when
implementing alias.rt, which statically encodes the render target.
Add an new ir3_shader_option (fragdata_dynamic_remap) which allows the
driver to indicate to ir3 that it will perform such dynamic remapping.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31222>
When alias.rt is used to alias certain output components, we might end
up with a situation where some, but not all, of the components of
collects end up being unused. This is currently not supported which
means we end up with useless moves (coming from copy lowering) for
aliased output components.
Fix this by adding support for partial wrmasks for collects in DCE. The
wrmasks are initially zeroed out and then updated based on the wrmask of
their users. Sources of collects for which the corresponding dst ends up
being unused are treated as unused as well. This allows us to remove
the useless output moves by simply updating the wrmask of the end
sources.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31222>
Allocate alias registers for an alias group while trying to minimize the
number of needed aliases. That is, if the allocated GPRs for the group
are (partially) consecutive, only allocate aliases to fill-in the gaps.
For example:
sam ..., @{r1.x, r5.z, r1.z}, ...
only needs a single alias:
alias.tex.b32.0 r1.y, r5.z
sam ..., r1.x, ...
Also, try to reuse allocations of previous groups. For example, this is
relatively common:
sam ..., @{r2.z, 0}, @{0}
Reusing the allocation of the first group for the second one gives this:
alias.tex.b32.0 r2.w, 0
sam ..., r2.z, r2.w
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31222>
alias.tex allows us to construct an "alias table" that creates a mapping
between virtual alias registers and concrete GPRs, consts, or
immediates. The following texture instruction will lookup its sources in
this table and use the mapped value instead. This has a few advantages:
- We don't have to allocate consecutive registers (necessary for many
tex sources) as we can just map them to consecutive alias registers.
- We don't have to allocate GPRs at all for consts and immediates.
- There's no delay penalty when initializing alias registers with consts
or immediates.
For example, this code:
mov.u32u32 r1.x, r3.z
mov.u32u32 r1.y, c0.x
mov.u32u32 r1.z, 0
(rpt2)nop
sam ..., r1.x, ...
Can be implemented as follows:
alias.tex.b32.2 r40.x, r3.z
alias.tex.b32.0 r40.y, c0.x
alias.tex.b32.0 r40.z, 0
sam ..., r40.x, ...
Note that the alias registers (r40.xyz in this case) do not occupy GPR
space.
(More intelligent allocation strategies are possible; e.g., just mapping
r3.w and r4.x to c0.x and 0. This is implemented by the next commit.)
Support for alias.tex is implemented in two passes in ir3.
In a first pass, sources of tex instructions are replaced by alias
sources (IR3_REG_ALIAS) as follows:
- movs from const/imm: replace with the const/imm;
- collects: replace with the sources of the collect;
- GPR sources: simply mark as alias.
This way, RA won't be forced to allocate consecutive registers for
collects and useless collects/movs can be DCE'd. Note that simply
lowering collects to aliases doesn't work because RA would assume that
killed sources of aliases are dead, while they are in fact live until
the tex instruction that uses them.
The second pass inserts alias.tex instructions in front of the tex
instructions that need them and fixes up the tex instruction's sources.
This pass needs to run post-RA as discussed above. It also needs to run
post-legalization as all the sync flags need to be inserted based on the
registers instructions actually use, not on the alias registers they
have as sources.
This commit uses a very simple allocation strategy for alias registers:
simply allocate consecutive registers starting from r40.x. Note that
this works because the alias table is reset after a tex instruction is
executed so we don't have to worry about aliasing a live register.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31222>
Alias registers allow us to allocate non-consecutive registers and remap
them to consecutive ones using alias.tex. We implement this by adding
the sources of collects directly to the sources of their users. This
way, RA treats them as scalar registers and we can remap them to
consecutive registers afterwards. To keep track of the scalar sources
that should be remapped together, the IR3_REG_FIRST_ALIAS flag is
introduced. Every source of such an "alias group" will have the
IR3_REG_ALIAS set, while the first one will also have
IR3_REG_FIRST_ALIAS set.
This commit also adds a number of helpers to iterate over sources while
keeping track of the original src index (i.e., before they were expanded
to alias goups), and to iterate the sources within an alias group. It
also introduces a new notation (@{regs...}) to clearly show alias groups
when printing instructions.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31222>
Take the properties of alias.{rt,tex} and its registers into account:
- Don't count alias registers for GPR usage;
- Allow all immediates in alias regs;
- Fix properties like is_barrier and (ss) support;
- alias.rt dst is not a GPR, don't use it in legalize/postsched to track
dependencies;
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31222>
The UNK field encodes the table size for alias.tex: the first alias.tex
instruction uses it to indicate how many follow (i.e., it is the total
table size minus one).
Also switch from using a src to a cat7 field to store this value which
makes it a bit easier to handle.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31222>
The alias scope and type bits are intertwined in the encoding:
- bit 47: low scope
- bit 48: type
- bit 49: high scope
- bit 50: type size
Combining the low and high scope bits, the value is used as follows:
- 0: tex
- 1: rt
- 2: mem
- 3: mem
I don't know what the difference between 2 and 3 is. The blob currently
doesn't use mem at all.
The type bit seems to be used to make a distinction between floating
point (f) and integer (b) sources. There doesn't seem to be any
functional difference and it only affects how immediates are displayed.
Note that I haven't exactly mimicked the blob in these cases:
- alias.tex.f16/32: the blob uses b16/32 while printing immediates in
floating point notation. I think it make more sense to use f16/32.
- alias.rt.b16/32: the blob uses i16/32 here. I think it makes more
sense to stick to a single notation (b).
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31222>
There is a single swap field for each color attachment, regardless of
whether it's in GMEM or not, and this does appear to be used in
GMEM mode when MUTABLEEN is set on the attachment. This means that when
a color attachment has a non-identity swap because it's mutable on a750,
we have to use the same corresponding swap when it's a source in a
GMEM resolve. When using the fastpath, we have to make sure that the
swaps match because there aren't separate fields for GMEM and sysmem
swap.
This fixes dEQP-VK.image.mutable.2d.*_b8g8r8a8_unorm_draw_copy_resolve
with TU_DEBUG=gmem.
Fixes: 247d11d635 ("tu: Allow UBWC with images with swapped formats.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33115>
We don't currently support building acceleration structures on the CPU
or indirect building in the common framework, and drivers using it don't
either, but drivers have to return non-NULL entrypoints for CPU building
functions if they claim to support VK_KHR_acceleration_structure. Add
stub entrypoints here so that drivers don't have to have this
boilerplate.
Fixes dEQP-VK.api.version_check.entry_points on turnip.
Fixes: 671e3a65a6 ("tu: Support VK_KHR_acceleration_structure")
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33153>
The alignment was considered only for offset, but its users
(at least ir3_nir_opt_preamble) expect the size itself to also
be aligned.
Fixes tests:
dEQP-VK.spirv_assembly.instruction.graphics.16bit_storage.struct_mixed_types.uniform_buffer_block_geom
dEQP-VK.spirv_assembly.instruction.graphics.16bit_storage.struct_mixed_types.uniform_buffer_block_tessc
dEQP-VK.spirv_assembly.instruction.graphics.16bit_storage.struct_mixed_types.uniform_buffer_block_tesse
gmem-dEQP-VK.spirv_assembly.instruction.graphics.16bit_storage.struct_mixed_types.uniform_buffer_block_tesse
Fixes: 922ef8e720
("ir3: Make allocation of consts more generic and order independent")
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33161>
Previously, we just used the next block after a loop that
has a back-edge. This assumes that loop-exit blocks can
only be removed when falling through to the next block,
when in fact it can also be a jump to somewhere else,
in future even to some block before the actual loop.
12 (0.02% of 79395) affected shaders.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32477>
They might be needed as convergence point in order to
insert code (e.g. for loop alignment, wait states, etc.).
Totals from 1 (0.00% of 79395) affected shaders:
CodeSize: 12672 -> 12716 (+0.35%)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32477>
TS can be valid and flushed at the same time when no compression is
used. This state is beneficial if we needed to flush TS to the base
surface (filling cleared tiles) for any reason, but still use TS
state to accelerate read requests into PE or TX caches.
The current seqno based tracking of the TS flush state has a major
drawback with the following sequence of events:
1. fast clear surface (TS is now valid)
2. flush TS (base surface tiles filled, TS still valid,
flush seqno == surface seqno)
3. render to surface (surface seqno increased)
4. flush resource
Step 4 will now execute a full TS flush as the flush and surface seqnos
are different after rendering and TS is still valid, wasting memory
bandwidth to fill already filled tiled that are still marked as clear
in the TS state. If the TS has been flushed already, step 4 should be
a no-op.
Switch from the seqno based tracking to tracking the flush state itself,
marking the TS state un-/flushed as needed. With this boolean tracking
of the flush state step4 above will correctly see that the TS has already
been flushed since the last fast clear and skip the tile fill blit.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32956>
If we determine that the amount of varyings will fit within the 8-bit
offset of LD_VAR_BUF[_IMM], instruct the compiler to use it for varyings
and skip setting up Attribute Descriptors.
This should save a bit of memory and overhead in reading varyings.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32969>
Introduce a varying load count pass to get the maximum amount of varying
loads from a fragment shader (prior to optimization passes), in order to
only allocate as many Attribute Descriptors as required. This will
generally lead to smaller buffers in SRT0 for fragment shaders.
As the amount of ADs is now dynamic based on the shader, we need to
lower varying loads early for fragment shaders in v9+, as the amount of
ADs will determine the offset for dummy_sampler, required during
nir_lower_descriptors.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32969>
The current implementation uses LD_VAR_BUF[_IMM] to look up varyings,
which limits the number of varying components to 64 due to an 8-bit
offset value.
As this does not align to maxVertexOutputComponents (128), this change
replaces the use of LD_VAR_BUF[_IMM] with LD_VAR[_IMM] + Attribute
Descriptors, which do not have this limitation.
As allocating Attribute Descriptors is potentially expensive, this can
be further optimized by falling back to LD_VAR_BUF[_IMM] in cases where
we can ensure we do not use more than 64 varying components.
This change currently does not change behavior for gallium/panfrost,
though that should be done as well.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32969>
The fields "Attribute stride" and "Packet stride" are in the wrong
order, and "Packet stride" should not be shr() modified.
This has probably not shown up as an issue before due to the use of
LD_VAR_BUF[_IMM] for varyings, which does not require us to create
Attribute Descriptors with type vertex_packet.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32969>
If line smooth, stipple, quad_prims and a collection of other things are needed, zink produces a geometry shader to create them.
This code is disabling that from happening when there is no geometry shader support.
This removes a constant barrage of validation issues when trying to draw basic triangles.
Some of this missing functionality will be added back in later.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33059>
This returns the underlying device pointer but as an opaque
uintptr_t.
This will be required because libdrm_amdgpu will return the
same device when called multiple times from the same process.
radeonsi relies on the pointer value to identify if the device
are the same and adjust the synchronisation logic based on that.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33081>
This reported support for Profile2 on all VCNs that support Profile0
and reported no supported formats if Profile2 was not supported.
Instead, we should not advertise the Profile2 at all if not supported.
Fixes: e359b3c525 ("radeonsi/vcn: support 12bit YUV420 AV1 decoding")
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33092>
The progressive YUV shader used in vl_compositor_yuv_deint_full
does the same thing as util_compute_blit, but it also supports rotation.
Remove vlVaPostProcBlit and instead move the code to vlVaPostProcCompositor.
Reviewed-by: Thong Thai <thong.thai@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32919>
We're already limiting the maximum texture-size based on the available
system memory, so we shouldn't really need to limit this here. In
addition, the state-tracker also limits the max framebuffer size to
16384, so we don't have to worry about limiting this to the framebuffer
size either.
So I don't think we have a good reason to artificially limit the texture
size here. This allows us to support larger textures than 8192, which is
especially useful to support OpenCL images with RustiCL.
Unfortunately, while the HW supports up to 64k texture sizes, Gallium
currently caps us at 32k. So let's stick with that as the new limit for
now.
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32866>
We don't want huge textures to take up large amounts of system memory.
On a system with 1GB of RAM, this would limit us to 256 MB, which is the
same memory usage as a texture of 8192 x 8192 with 4 bytes per
component, which is what we currently limit max texture size to anyway.
The goal here is really to allow using larger textures on systems with
more memory, but that bit comes in a later patch in this series.
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32866>
We're doing a better job at selecting the tiler hierarchy mask in PanVK,
so let's move that to common code and reuse it for the Gallium driver as
well.
The logic to disable the first level for large tile-sizes has been left
at the call-sites, because this is specific to V10 GPUs and later, so it
doesn't apply to the JM code-paths.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32866>
We can handle invalidation of the FBO attachments at job
creation. It solves that we were skipping invalidations in jobs
that had been created by a clear call, as before this change
invalidations were only taken into account the first draw calls
of the job. In these cases where there is a clear after FB
invalidation the resource attachment was tracked as invalidated
for more time than expected. So the stores of the job with the
clear were not being loaded by the next job attaching it because
of the not correct application of the invalidation.
Fixes: 6c46890325 ("v3d: avoid load/store of tile buffer on invalidated framebuffer")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12456
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33148>
When a 2D_ARRAY view of a 3D image is created, the layer count of the 2D
view should be based on the depth of the 3D image. When
VK_REMAINING_ARRAY_LAYERS is used, we were incorrectly calculating them
from the layer count of the base image.
Fixes future tests: dEQP-VK.renderpass*.remaining_array_layers.*
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33075>
On AMD, this is a clear win. 2.0 is a free constant,
the multiplication can be fused into fma, or it can
be done as a free output modifier. Otherwise, fmul
and fadd have the same throughput/latency, with the only
possible downside being potentially power consumption.
For other hardware this might not be as clear,
but we should at least choose one option for NIR because
it allows more CSE.
Foz-DB Navi21:
Totals from 12231 (15.41% of 79395) affected shaders:
MaxWaves: 309068 -> 309032 (-0.01%)
Instrs: 11826395 -> 11790132 (-0.31%); split: -0.31%, +0.00%
CodeSize: 63531496 -> 63512868 (-0.03%); split: -0.03%, +0.00%
VGPRs: 551256 -> 551328 (+0.01%); split: -0.00%, +0.02%
SpillSGPRs: 984 -> 979 (-0.51%)
Latency: 88486492 -> 88394296 (-0.10%); split: -0.11%, +0.01%
InvThroughput: 22360595 -> 22300790 (-0.27%); split: -0.27%, +0.00%
VClause: 226267 -> 226273 (+0.00%); split: -0.01%, +0.01%
SClause: 293820 -> 293783 (-0.01%); split: -0.02%, +0.00%
Copies: 727187 -> 727106 (-0.01%); split: -0.03%, +0.02%
PreSGPRs: 539623 -> 539625 (+0.00%)
PreVGPRs: 440843 -> 440946 (+0.02%); split: -0.00%, +0.03%
VALU: 8324962 -> 8288809 (-0.43%); split: -0.43%, +0.00%
SALU: 1278550 -> 1278538 (-0.00%); split: -0.00%, +0.00%
VMEM: 440600 -> 440599 (-0.00%)
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32989>
The drm device file is closed and re-opened between perfetto traces. So
we either need to re-create the fd_device, or use fd_device_new_dup() so
we hold on to our own fd. The former is preferred so that the kernel
can realize when we are no longer reading the perfcntrs.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33073>
Requests with no reply will report errors by default to the event
loop, which then usually cause the not very useful log like this
to be printed:
X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 149 ()
Minor opcode of failed request: 2
Serial number of failed request: 33
Current serial number in output stream: 34
This commit introduce some helpers to handle the xcb errors in Mesa,
and be able to report errors properly.
For instance the same error will now log:
MESA: error: dri3_alloc_render_buffer:1634 xcb_dri3_pixmap_from_buffer[s] failed
MESA: error: X error: 11
It's not fixing the underlying issue, but at least now tests like
"glx-visuals-stencil -pixmap" and "glx-visuals-depth pixmap" fail
properly.
cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33036>
This allows us to drop the reboot condition on SaharaMode which means
that every time the reboot pattern is hit, it is due to a test
execution issue (GPU hang) and not something unrelated to the job.
Additionally, this allows us to try booting up to 5 times which should
help boot reliability.
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32572>
This will be helpful for DUTs that do not boot reliably due to firmware
issue as it will allow us to specify a boot retry count that only
counts towards booting linux and not other issues found during test
execution (like hitting a GPU hang).
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32572>
Indeed, has_streamout is not yet properly initialized at the time
of the call of r600_init_screen_caps(). This change fixes this
issue.
Here is the issue visible on palm at the glxinfo level; the right column is affected:
Preferred profile: core (0x1) | Preferred profile: compat (0x2)
Max core profile version: 4.5 | Max core profile version: 0.0
Max compat profile version: 4.5 | Max compat profile version: 2.1
Max GLES1 profile version: 1.1 Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1 | Max GLES[23] profile version: 2.0
Fixes: 7cd606f01b ("r600: add r600_init_screen_caps")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33106>
It's not rare when only last few draws in a big renderpass disable
LRZ, we shouldn't bail out in such case.
If LRZ is disabled in dir tracking bit during binning - LRZ would
be disabled for the whole IB in the tiling step, so we should avoid
disabling via dir tracking bit and track the state inside the driver.
This doesn't work with secondary command buffers (and renderpass
resume/suspend), in such cases we have to disable LRZ via dir tracking
bit, if LRZ is not valid.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32868>
If blend LRZ state was already calculated from static info,
re-calculating it with dynamic state would bring stale values
and therefor result in a wrong calculations.
This resulted in LRZ being disabled when it should have not in
native VK titles.
CC: mesa-stable
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32868>
Currently, when allocating the dst of shared collects, the registers of
its srcs would only be reused if they are killed. This results in a lot
of needless moves due to suboptimal register allocation.
This commit addresses this generically: allow unavailable registers to
be used for a new dst iff it shares a merge set with, and has the same
offset as, the currently live value.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32021>
Detecting non-trivial collects after the fact, i.e., once they are
created by a register assignment of their dst, does not work as this may
cause two different intervals to share a physreg. For example:
_meta:collect sssa_361:150(r50.x) (wrmask=0xf),
sssa_19:12(r50.x), sssa_103:13(r50.y),
sssa_355:102(r51.z), sssa_356:103(r51.w)
This is a non-trivial collect with a partial overlap with one of its
child intervals. After moving its dst to a new interval, it will have
the same physreg as the existing interval for sssa_19, causing all sorts
of trouble for RA.
Prevent this by detecting that a future collect may become non-trivial
at the moment one of its sources gets a register assignment that does
not correspond with it merge set's preferred reg and allocating a new
interval for this component.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: b36a7ce0f1 ("ir3/ra: prevent moving source intervals for shared collects")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32021>
The userq packets are added using _pkt_begin(), _pkt_add(), _pkt_end()
functions. As of now _pkt_being() and _pkt_add() is called once. It
is not advisible to update wptr value in mqd multiple times. Hence use
next_wptr as cache in the macros and update mqd mptr before job submission
only once.
Suggested-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32700>
The signal ioctl should only be called after guaranteeing that the hardware
started working on the submissions and that is only after doorbell is ringed.
Otherwise it can in theory happen that the application creates the fence and
is then interrupted before ringing the doorbell. That can result in a GPU
reset because the fence times out.
Suggested-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32700>
Determine whether the device has hardware raytracing support early, and
then use this result where needed, instead of checking for `gfx_level`
every time.
This is a prerequisite for CYAN_SKILLFISH chip enablement. This chip is
still GFX10, not GFX10_3, but has hardware support for accelerated
`image_bvh{,64}_intersect_ray` instructions. Just checking for `gfx_level`
is insufficient for it.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33109>
This should let us lower the RT query stack to registers instead of
scratch by getting rid of the rest of the members of the ray query
struct. This gives a 24% decrease in total time for 3DMark InVitro.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28447>
Remove the redundant error that will never be hit in practice (because
if fd_dev_name() succeeds then so will fd_dev_info()) and move it up so
that we can use the info when generating the name.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28447>
There is native support for D3D-style untyped UAVs, which are an unsized
array of "records."
This will be needed for acceleration structures, because normal SSBO
descriptors aren't large enough to cover all the 128-byte instance
descriptors for the maximum number of instances (2**24).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28447>
Make sure that struct vk_bvh_geometry_data is defined before
vk_fill_geometry_data(), to fix this error:
In file included from ../src/freedreno/vulkan/tu_acceleration_structure.cc:29:
../src/vulkan/runtime/vk_acceleration_structure.h:138:1: error: 'vk_fill_geometry_data' has C-linkage specified, but returns incomplete type 'struct vk_bvh_geometry_data' which could be incompatible with C [-Werror,-Wreturn-type-c-linkage]
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28447>
Currently, nir_lower_printf depends on a per-nir_shader table, writing out
indices into the printf buffer. This works for real OpenCL implementations
(rusticl, microsoft) which can associate the printf buffer with a particular
kernel, I guess. (Actually it's not clear to me that it works well there either
but that's not my problem.)
This mechanism is unsuitable for internal driver shaders, where printfs with
unique format strings can come from many different nir_shaders. There are two
current solutions in tree to this for driver CL:
* Honeykrisp: Only use one single nir_shader (libagx). This prevents us from
using printf in common CL and requires extra driver tracking. It won't work
with my upcoming vtn_bindgen rework, which is why I'm addressing this now.
* Anv: Offset format-string indices by a dynamic "base identifier" using relocs
or a push constant, then pool format strings into a table from nir_shader's
across the device. The problem here is that these indices now depend on the
order that nir_shaders are seen (which causes a mess for caching if relocs are
used, or requires extra push constants and extra bookkeping if relocs aren't
used). And the driver tracking required to do this pooling correctly is even
more complicated than what Honeykrisp does. I do not want every driver in-tree
needing to go down this path, and it wouldn't work with my upcoming
vtn_bindgen.
This MR introduces an alternate approach: rather than writing indices into the
table, we instead hash the format string itself and write the hash. That doesn't
depend on what nir_shader we came from, so we can freely mix & match and get
consistent hashes. That greatly alleviates driver tracking burden. To make that
possible, we need a global hash table mapping hashed format identifiers to the
format strings themselves.
That approach still requires a step to "register" format strings into the table.
That step would not be required if we wrote the actual strings themselves into
the table, but that was ruled out for performance/code size reasons. However, we
do not want drivers to need to explicitly register all the strings they use,
because once we have OpenCL in common code via vtn_bindgen2, drivers won't know
all the strings they use. Fortunately, there's a neat solution for that too.
By making this global table a singleton (with internal locking), vtn_bindgen2
can automatically register format strings via a static constructor. In
conjunction with the infrastructure added here, that eliminates all driver
bookkeeping required for format-strings.
The code itself is inspired by the glsl type singleton. Is it pretty? Not
really, but it gets the job done well.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33067>
We actually want to know if the backing memory is the same, it's also
easier to implement than checking on the parent memory object.
This will also allow for more flexibility if more memory types are
supported, e.g. proper SVM allocations.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32581>
This will handle the raw memory operations in the future, mostly focused
on guaranteeing consistency across devices.
It also handles sub allocation because it is the better place of tracking
this.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32581>
Various vkd3d-proton tests run via Turnip exposed an issue with the
a7xx-specific instantiation of the fd_lrzfc_layout struct used to allocate
memory for LRZ fast-clear operations.
The correct layout is quite bigger in size, and the duplicated FC buffers
are positioned at the beginning and the end of it. Smaller part of the area
in the middle is used for metadata, but it already seems to be used more
extensively than how we currently understand it.
Fixes in vkd3d-proton on tu/a750:
test_clear_depth_stencil_view
test_copy_texture
test_early_depth_stencil_tests
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33080>
This job is somehow failing to expand $RUNNER_TAG, and it seems to have
happened around the time that the last entry from the variables list was
removed.
Let's remove this, it's no longer needed anyway. And it seems to fix the
problem, so yay.
Fixes: 61d9c47944 ("ci/lava: Use CI_JOB_TIMEOUT instead of separate variable")
Reviewed-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33086>
Without this, WQM is only used for the lds_param_load like this:
s_wqm_b64 exec, exec
lds_param_load v5, attr0.x wait_vdst:15
s_mov_b64 exec, s[0:1]
v_mov_b32_dpp v5, v5 quad_perm:[0,0,0,0] row_mask:0xf bank_mask:0xf
With this change we get:
s_wqm_b64 exec, exec
lds_param_load v5, attr0.x wait_vdst:15
s_mov_b64 exec, s[0:1]
...
s_wqm_b64 exec, exec
v_mov_b32_dpp v5, v5 quad_perm:[0,0,0,0] row_mask:0xf bank_mask:0xf
s_mov_b64 exec, s[0:1]
This fixes KHR-GL46.shaders.uniform_block.random.nested_structs_instance_arrays.0
and other similar tests with LLVM.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32959>
The documentation says that if we don't use force_delta, the LOD will be
-infinity for non-active lanes before bias and clamp are applied. This
is not what we want, so let's instead assume all threads are active, and
let helper-invocations do their job to compute correct values.
While this is only needed for the second iteration, let's just leave it
on for both for simplicity.
Fixes: e317136536 ("pan/va: Add support for nir_texop_lod")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33069>
With the improved GPU recovery thanks to the new kernel, we can now
complete a full, non-fractioned run on the a660 in just over an hour.
To stay within this runtime, the fractions for the gmem-forced runs
have been increased.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Reviewed-by: David Heidelberg <None>
Reviewed-by: Sergi Blanch Torné <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32788>
Buffers with compression enabled (eg. DCC) have auxiliary planes that
needs to be all imported, but should not be used to create sampler views
and surfaces.
Only use main planes and ignore the remaining planes.
Also remove vl_video_buffer::num_planes as it's now unused.
Cc: mesa-stable
Acked-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32893>
MoltenVK fails to create a depth format target if `optimalDeviceAccess`, `info.have_EXT_host_image_copy` and `VK_IMAGE_USAGE_HOST_TRANSFER_BIT_EXT` are in used.
The specification seems to claim it is not needed if `hic.identicalMemoryLayout` is set, so for a MoltenVK build unset optimalDeviceAccess.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32651>
MoltenVK support for VK_DYNAMIC_STATE_VERTEX_INPUT_BINDING_STRIDE depends on the Metal API version in use. Which is directly related to the MacOS version.
Even if all the correct extensions or Vk versions are supported.
Detect if the feature is supported, assume it is not on MacOS unless told otherwise, and adjust the pipelines to honor this.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32651>
Applications tend to forget to describe subpass dependencies, especially
when it comes to write -> read dependencies on attachments. The
proprietary driver forces "others" invalidation as a workaround, and this
invalidation even became implicit (done as part of the RUN_FRAGMENT) on
v13+.
We will consider adding a dri-conf hook for this option in the future,
but for now, let's just keep it as an opt-in debug flag.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33056>
On the host side virglrenderer creates dmabuf on demand when:
* cpu mapping is requested
* setting up scan out
* sharing buffers between guest processes
On-demand dmabuf creation only works if the ctx that created the
BO still exists and knows about this BO. This assumption works ok for
the first 2 cases, but can break with the last one (and it does cause
issues on Android). eg:
* process A allocates BO and exports it as a guest dmabuf
* process A closes its handle to the BO (-> detach_resource)
* process B imports the guest dmabuf -> this triggers the attach_resource
function in virglrenderer. If the given resource isn't a
VIRGL_RESOURCE_FD_DMABUF it'll try to get one... But for this to work,
process A needs to be used -> this fails because this resource was
detached from it.
The reason we create dmabuf on demand is to avoid hitting the number of
open file descriptor limit. So to cover the 3rd case, we'll use the
VIRTGPU_BLOB_FLAG_USE_SHAREABLE flag, but try to limit to as few possible
buffers as possible.
Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658>
The virtio-gpu guest kmd reports timelines as supported, so querying
DRM_CAP_SYNCOBJ_TIMELINE as vk_drm_syncobj_get_type() does will return
true.
The native context code on the other hand doesn't support timelines,
and support is disabled in the "ac/virtio: disable timeline_syncobj support"
commit.
Fix the inconsistency by manually disabling timeline support when
info.has_timeline_syncobj is false.
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658>
No big code changes are needed to support virtio. The main caveat with
radv is about buffer allocations.
Allocating a cpu visible buffer requires the host process (eg qemu) to
create a dmabuf, mmap it, then map the host CPU address into the guest
application CPU address space.
The first issue is about the number of dmabuf created because we
might hit the number of open file limit. The host process limit can
be raised but we would hit the second issue - at least on qemu:
there's a limit on how many sections can be mapped and ultimately
we hit this assert:
assert(map->sections_nb < TARGET_PAGE_SIZE);
(the third issue is a performance one: these operations have a cost,
and this increases some Vulkan app loading times)
radeonsi is not really affected because it's using pb_slab to
suballocate small buffers from larger ones.
radv on the other hand doesn't, so if an app decides to allocate
lots of cpu visible small buffers, we're likely to fail.
Earlier versions of the amdgpu nctx code had a suballoctor, but it
was removed to simplified the code. It could be restored later; or
radv could be modified to use a suballocator (like anv does AFAICT).
Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658>
Native context support is implemented by diverting the libdrm_amdgpu functions
into new functions that use virtio-gpu.
VA allocations are done directly in the guest, using newly exposed libdrm_amdgpu
helpers (retrieved through dlopen/dlsym).
Guest <-> Host roundtrips can be expensive so we try to avoid them as much as
possible. When possible we also don't wait for the host reply in case where
it's not needed to get correct result.
Implicit sync works because virtio-gpu commands are submitted in order to the
host (there a single queue per device, shared by all the guest processes).
virtio-gpu also only supports one context per file description (but multiple
file descriptions per process) while amdgpu only allows one fd per process,
but multiple contexts per fd. This causes synchronization problems, because
virtio-gpu drops all sync primitive if they belong to the same fd/context/ring:
ie the amdgpu_ctx can't be expressed in virtio-gpu terms.
For now the solution is to only allocate a single amdgpu_ctx per application.
Contrary to radeonsi/radv, amdgpu_virtio can use libdrm_amdgpu directly: the
ones that don't rely on ioctl() are safe to use here.
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658>
This is required to implement virtio native-context.
In a virtualized environment, most of the functions provided
by libdrm_amdgpu will be implemented using virtio.
This allows to implement efficient virtualization, by
forwarding the kernel API to the host, instead of the GL/VK calls.
Similarly, the raw 'fd' or 'gem_handle' arguments are replaced
by opaque types. This allows to encapsulate all the needed
state in the handle, and use unmodified API between baremetal
and virtualized contexts.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658>
This unifies the behaviour between the LAVA, baremetal, and CI-Tron
farms by ensuring every job has access and runs the same scripts.
The init-* scripts are however still sourced from outside the build
artifact, hopefully not for too long.
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33026>
Just like other input loads, radeonsi needs to know the barycentric
coordinates for it. This adds the src and determines the optimal barycentric
coordinates in nir_lower_point_smooth, the only producer of the intrinsic.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33046>
When using Zink with VK_EXT_descriptor_buffer enabled on IMG proprietary
drivers, the rendering behavior is incorrect and uniforms are not
updated properly (the gears of es2gears_x11 become all red and
overlaps).
Use lazy descriptors for IMG proprietary driver unless explicitly
overriden for testing purpose.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32343>
The goal is to reduce symbol pollution, especially when building
with Perfetto support, which previously led to an excessive number
of exported symbols.
objdump -T build/src/egl/libEGL_mesa.so.0.0.0 | grep perfetto | wc -l
- before: 6963
- after: 0
The new egl.sym version script explicitly exports only relevant egl and
MesaGLInteropEGL symbols, while marking all others as local.
While this change effectively removes all Perfetto-related exported symbols,
some C++ standard library symbols remain as undefined. These are pulled in
by the linker due to dependencies.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33001>
Initial "compilable" version of mesa/gfxstream on Windows. For now it is
achieved through "#if !DETECT_OS_WINDOWS" directives hence it is NOT
functional. The compilation works with mingw only and the compilation is
tested in a windows host. This commit is intended to only pass the
compilation process without errors.
Also created stub code for a future windows implementation.
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32795>
After the SPIR-V generator is optimized to generate multiple constant
types, the shader compiler of Imagination proprietary drivers can no
longer correctly handle these shaders and will bail out.
Handle this as a driver quirk and revert to the old behavior with only
uint constants when IMG proprietary drivers are detected.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32342>
Right now, we have a problem when we flush draws inside a render pass
and we don't have enough information to re-emit the framebuffer/tiler
descriptors.
Turns out the only situations where this happens is when an occlusion
query end happens, but we shouldn't really flush the draws in that case.
What we should do instead is record the OQ in our command buffer, so we
can signal OQ availability when the fragment job is done.
In order to solve that, we add an OQ chain to the command buffer to
track OQs ending inside the render pass. We then walk this chain at
fragment job emission time to signal the syncobjs attached to each
query.
This also simplifies the whole occlusion query synchronization model:
instead of waiting for each syncobj individually, we now wait on
the iterators to make sure all OQs have landed. Thanks to this new
synchronization, we can batch OQ reset/copy operations and make the
command stream a lot shorter when big query ranges are copied/reset.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Benjamin Lee <benjamin.lee@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32973>
The SYSTEM scope triggers CPU interrupts we don't really need, so let's
use the CSG scope to avoid those. Note that the scope doesn't encode
the visibility aspect, meaning changes to the sync object with a CSG
scope will still be instantly visible to the CPU, it's just that the
CPU needs to poll the value to detect a change, which is basically what
we're doing for syncobjs attached to events/queries, so we're good.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Benjamin Lee <benjamin.lee@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32973>
Descriptor sets which have `size` of `0`, such as a descriptor set
with just dynamic descriptors, weren't being freed in
`vkDestroyDescriptorPool()` since that relies on keeping track of
descriptor sets in the `entries` list. Keep track of them in the
`entries` list.
Fixes a memory leak in:
dEQP-VK.binding_model.descriptor_copy.compute.uniform_buffer_dynamic_5
Signed-off-by: Karmjit Mahil <karmjit.mahil@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32968>
We can disable FDM in the renderpass based on
`tu_render_pass_disable_fdm()` however a pipeline could have
been bound before starting the renderpass which had
`...RENDERING_FRAGMENT_DENSITY_MAP_ATTACHMENT_BIT_EXT` set, in
which case the shader is compiled with FDM support. We still
need to apply the patchpoints. Previously `patchpoints_ctx` was
created only based on whether FDM was enabled in the renderpass,
which was leading to the patchpoints being allocated with no
context so they were never getting freed. Now setup `patchpoint_ctx`
regardless of FDM being disabled or not.
Fixes memory leaks in some tests from:
dEQP-VK.dynamic_rendering.*_cmd_buff.fragment_density_map.*
e.g.
dEQP-VK.dynamic_rendering.partial_secondary_cmd_buff
.fragment_density_map.2_views .render.divisible_density_size
.1_sample.static_subsampled_1_2
Fixes: 05f96dd00f ("tu: Add core FDM patchpoint infrastructure")
Signed-off-by: Karmjit Mahil <karmjit.mahil@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32968>
When no attachments are used in a renderpass we should ignore the
clear values. It seems to be valid applications to still pass clear
values in such a case.
Fixes memory leaks in some tests from:
dEQP-VK.image.texel_view_compatible.graphic.basic.*d_image.texture_read.*
dEQP-VK.image.texel_view_compatible.graphic.extended.*d_image.texture_read.*
Signed-off-by: Karmjit Mahil <karmjit.mahil@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32968>
On Bifrost/Midgard, when an attribute has a non-zero divisors, the
attribute offset is tweaked to take the base_instance into account,
which implies we have to re-emit the attributes if the base instance
value changed.
Let's not bother tracking the last base instance and re-emit
unconditionally in that case, which is still better than what we had
before 3db963a135 ("panfrost: Emit attribs in
panfrost_update_state_3d() on bifrost/midgard") and fixes the regression
introduced by this commit.
Fixes: 3db963a135 ("panfrost: Emit attribs in panfrost_update_state_3d() on bifrost/midgard")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Tested-By: Chris Healy <healych@amazon.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33010>
Although in some cases python 3.x will come without "3" as suffix,
"python3" should still be preferred because sometimes "python" is python
2.x instead.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33025>
Halti5 has no interpolation setting which will take into account the
rasterizer flatshade state. Force the interpolation qualifier to flatshade
for the color varyings when API level flatshade is enabled. Only set the
new bit in the shader key on halti5 GPUs to avoid generating unnecessary
shader variants on GPUs where the rasterizer flatshade state is properly
applied to the varyings.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32991>
During loading of snapshot, there will be a single-threaded
decoder that aquires the same mReconstructionMutex, repeatedly.
Since the mReconstructionMutex is intentionally changed to
be non-recursive, we should not aquire it at the beginning of
load call; otherwise, we will be deadlock the decoder thread.
Reviewed-by: Marcin Radomski <dextero@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33018>
Replace tryLock / unlock with regular scoped lock now that the
"extra handles" have been moved out of VkReconstruction and into
the VkSnapshotApiCallInfo.
Switch to regular std::mutex and std::lock_guard.
Annotate mReconstruction with GUARDED_BY to start to get more
thread safety analysis.
Reviewed-by: Marcin Radomski <dextero@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33018>
... so that `VkDecoderGlobalState` can append additional information
needed for snapshotting. Specifically, `VkDecoderGlobalState` may create
additional boxed handles that are not visible directly in the API surface.
For example, `vkCreateDevice()` creates boxed handles for the `VkQueue`-s
and `vkCreateDescriptorPool()` creates boxed handles for pre-allocated
`VkDescriptorSets`. These boxed handles are not recoverable from the API
for `vkCreateDevice()` nor `vkCreateDescriptorPool()` directly. This was
previously worked around by just sticking the extra boxed handles in
`VkReconstruction::mExtraHandlesForNextApi` but this is not thread safe.
Instead, let's give `VkDecoderGlobalState` and `VkDecoderSnapshot` exclusive
access to individual `VkSnapshotApiCallInfo` objects.
Reviewed-by: Marcin Radomski <dextero@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33018>
Removes the additional saving of opcode and packet len as this is
all available from within the packet itself.
Removes the "trace" position from `VulkanMemReadingStream` as these
seemed to only be used for getting the packet start and packet size
but these are already available.
Reviewed-by: Marcin Radomski <dextero@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33018>
Indirect draw calls upload VS params themselves, if indirect draw call
has zero instances GPU seem to still try to upload consts, however
with zer instances it doesn't apply draw state. Without the draw state
the the HLSQ_VS_CNTL values is stale, so less constants may be specified
than draw call expects. It is found that if CP_DRAW_INDIRECT_MULTI_1_DST_OFF
is less than 0x3f - GPU is happy even if the constlen is less than that.
As a workaround we allocate driver params first and ensure that VS
constlen always has the minimum size which is enough to upload driver
params.
Fixes one of the GPU hangs in "Disney Epic Mickey: Rebrushed" on a750.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32140>
With all consts going through generic allocations it's now possible
to call ir3_setup_const_state once, and have lowerings that dynamically
lower things to consts just to update the max consts being used.
The only exception for now are immediates, since they eat up the space
that was left and allocated much later.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32140>
The order of allocation was backed into ir3_setup_const_state and
some other parts of ir3, which is rather brittle.
And don't assume offsets for consts in other part of code, their order
and offset calculation is not guaranteed.
This also potentially fixes indirect UBO effect on constlen size.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32140>
In the current API, precomp implicitly assumes full barriers both before & after
every dispatch. That's not good for performance. However, dropping the barriers
and requiring user to explicitly call barrier functions before/after would have
bad ergonomics.
So, we add a new parameter to the standard MESA_DISPATCH_PRECOMP signature
representing the barriers required around the dispatch. As usual, the actual
type & semantic is left to drivers to define what makes sense for their
hardware. We just reserve the place for it. (I think most drivers will want
bitflags here, but I don't think the actual flags are worth. If a driver wanted
to use a struct here, that would work too.)
Since the asahi stack doesn't do anything clever with barriers yet, we
mechnically add an AGX_BARRIER_ALL barrier to all precomp users in-tree. We can
optimize that later, this just gets the flag-day change in with no functional
change.
For JM panfrost, this will provide a convenient place to stash both their "job
barrier" bit and their "suppress prefetch" bit (which is really a sort of
barrier / cache flush, if you think about it).
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32980>
When cross-building for Android meson fails to find supported compiler
arguments for the C++ cross-compiler, e.g.:
```
Compiler for C++ supports arguments -Wno-array-bounds: NO (cached)
Compiler for C++ supports arguments -Wno-overflow: NO
Compiler for C++ supports arguments -Wno-c++11-narrowing: NO (cached)
Compiler for C++ supports arguments -Wno-vla-cxx-extension: NO (cached)
```
This is due to an **unrelated** and more generic compilation failure
when testing for the supported arguments, e.g.:
```
Command line: `/tmp/android-ndk-r27c/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android34-clang++ -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -static-libstdc++ /home/ao2/Collabora/GOO0042/mesa/_build/meson-private/tmpv6_hke9l/testfile.cpp -o /home/ao2/Collabora/GOO0042/mesa/_build/meson-private/tmpv6_hke9l/output.obj -c -Wno-error=c99-designator -Wno-error=unused-variable -Wno-error=unused-but-set-variable -Wno-error=self-assign -D_FILE_OFFSET_BITS=64 -O0 -fpermissive -Werror=implicit-function-declaration -Werror=unknown-warning-option -Werror=unused-command-line-argument -Werror=ignored-optimization-argument -Wvla-cxx-extension -Wno-vla-cxx-extension` -> 1
stderr:
clang++: error: argument unused during compilation: '-static-libstdc++' [-Werror,-Wunused-command-line-argument]
-----------
Compiler for C++ supports arguments -Wno-vla-cxx-extension: NO
```
The issue is caused by how the cross compiler is set up by
.gitlab-ci/container/create-android-cross-file.sh
Allow the cross compiler to still start even when the
`-Werror,-Wunused-command-line-argument` error occurs in order to be
able to actually detect other arguments:
```
Command line: `/tmp/android-ndk-r27c/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android34-clang++ -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables --start-no-unused-arguments -static-libstdc++ --end-no-unused-arguments /home/ao2/Collabora/GOO0042/mesa/_build/meson-private/tmpm6eolxed/testfile.cpp -o /home/ao2/Collabora/GOO0042/mesa/_build/meson-private/tmpm6eolxed/output.obj -c -Wno-error=c99-designator -Wno-error=unused-variable -Wno-error=unused-but-set-variable -Wno-error=self-assign -D_FILE_OFFSET_BITS=64 -O0 -fpermissive -Werror=implicit-function-declaration -Werror=unknown-warning-option -Werror=unused-command-line-argument -Werror=ignored-optimization-argument -Wvla-cxx-extension -Wno-vla-cxx-extension` -> 0
Compiler for C++ supports arguments -Wno-vla-cxx-extension: YES
```
This makes argument detection work again, e.g:
```
Compiler for C++ supports arguments -Wno-array-bounds: YES (cached)
Compiler for C++ supports arguments -Wno-overflow: YES
Compiler for C++ supports arguments -Wno-c++11-narrowing: YES (cached)
Compiler for C++ supports arguments -Wno-vla-cxx-extension: YES (cached)
```
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12441
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Valentine Burley <valentine.burley@collabora.com>
Reviewed-by: Rob Clark <robclark@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33013>
The Xe uAPI is designed to use bind queues such that binds without input
dependencies (sync objects) do not block on binds with input
dependencies.
For example:
- Bind A (sparse) is submitted with a list of input dependencies.
- Bind B (immediate) is subsequently submitted without a list of input
dependencies.
If Bind A and Bind B share a single bind queue, Bind B will not be
scheduled until Bind A completes. Using individual bind queues decouples
Bind A and Bind B, allowing Bind B to make immediate progress.
This change creates a separate bind queue for each ANV queue, enabling
support for sparse bindings that may have input dependencies.
v2:
- Bail on bind queue creation failure (Linoel)
- Only create bind queue if VK_QUEUE_SPARSE_BINDING_BIT is set (Jose)
v3:
- Add comment around submit->queue usage (Jose)
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32873>
It's split into ac_nir_lower_ps_early ac_nir_lower_ps_late.
ac_nir_lower_ps_early doesn't generate any AMD specific intrinsics except
some system values and is mainly an optimization pass with some lowering.
The new change here is that it also eliminates output components not needed
by spi_shader_col_format.
ac_nir_lower_ps_late lowers output stores to exports and does the bc_optimize
thing.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32966>
Add support for getting time elapsed values via glBeginQuery/glEndQuery.
When recording query start & end time, we ensure that all pending jobs have
been completed by using v3d cpu_queue & the multisync extension.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32547>
Add support for getting timestamp values via
glGet(GL_TIMESTAMP) and glQueryCounter(GL_TIMESTAMP). For the case of
glQueryCounter, we make use of v3d cpu jobs via
DRM_IOCTL_V3D_SUBMIT_CPU and DRM_V3D_EXT_ID_CPU_TIMESTAMP_QUERY.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32547>
The spec says
vkCmdCopyQueryPoolResults is considered to be a transfer operation,
and its writes to buffer memory must be synchronized using
VK_PIPELINE_STAGE_TRANSFER_BIT and VK_ACCESS_TRANSFER_WRITE_BIT before
using the results.
While STORE_MULTIPLE is not exactly VK_PIPELINE_STAGE_TRANSFER_BIT /
VK_ACCESS_TRANSFER_WRITE_BIT, we can still rely on user barriers to do
the right thing (e.g., flush caches for host access).
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32697>
On gfx12+, the pre-amble and post-amble flushes contain the stalls
necessary to ensure the prior operation is complete. Remove the extra
uses of ANV_PIPE_END_OF_PIPE_SYNC_BIT in post-amble flushes. Also do
this for the pre-amble flushes, but this doesn't have any impact. The
flush application function will implicitly add the bit.
For A750, this improves the TWWH3 trace in the performance CI by 0.52%
(n=2).
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31600>
Each reg may store a list of conflict regs. This was handled by
util_dynarray, however each of those hold an extra pointer for
the ra_regs (which serves as mem_ctx for that). Since the usage
here is very simple, we just handle the array growth manually.
The initial size remains the same as before.
The mem_ctx of each ra_reg was being used to identify the case
in which the list wasn't used. Change to use a bool in the
ra_regs struct instead.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25744>
Each node stores a list of adjacent nodes. This was handled by
util_dynarray, however each of those hold an extra pointer for
the ra_graph (which serves as mem_ctx for that). Since the usage
here is very simple, we just handle the array growth manually.
For now keep using the same initial size as was being used by dynarray.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25744>
Fast-clears require expensive flushes beforehand and afterwards. The
cost of flushes are decreased in a series of back-to-back fast-clears as
no extra fast-clear flushes are required in between them. If the ratio
of a command buffer's recorded back-to-back fast clears over independent
fast-clears falls below 1/2, prevent that command buffer from recording
any further fast-clears.
Averaging two runs of our Factorio trace on an A750 shows a +14.37%
improvement in FPS.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32984>
RBBM_PRIMCTR registers are used for different pipeline statistics that can
be queried, but current usage was wrong in some cases. Comments in the
register file are updated, and the per-statistic register index mapping is
updated accordingly.
Fixes on a750:
test_query_pipeline_statistics in vkd3d-proton
arb_query_buffer_object failures in piglit (zink)
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32900>
The `sad` instruction (used for iadd3) doesn't support the scalar ALU.
This means we might fall back to non-earlypreamble whenever we use it in
the preamble. Prevent this by emitting it as two adds instead.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32943>
If a polygon offset is set via glPolygonOffset, but the functionality
isn't enabled via glEnable(GL_POLYGON_OFFSET_FILL) the offset must not
be taken into account when computing the sample depth. As the Vivante
hardware does not have a separate enable state, the offset units and
scale must both be set to 0 to keep the sample depth unchanged.
Fixes dEQP-GLES2.functional.polygon_offset.default_enable
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32982>
Through the spec it's required that cl_kernel doesn't hold references to
its bound kernel arguments.
There is a CL CTS test verifying this, but because the arguments were not
used in the test kernel, a reference was never taken. This will change
with SVM and BDA as we need to know all bound memory objects even if they
aren't directly used in kernels.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: @LingMan
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32961>
Turnip already had a pipeline stat to indicate whether we were using
early-preamble or not. But no way to tell if there was a preamble at
all. Adding a preamble instruction count tells us whether there is a
preamble, but also how big it is.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32977>
This limits the address register to simple cases inside a block.
Validation ensures that the address register is only written once and
read once.
Instruction scheduling makes sure that instructions using the address
register in the generator are not scheduled while there is an usage of
the register in the IR.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28199>
force_gl_names_reuse is changed to integer.
-1 means default (currently disabled), 0 means disabled, 1 means enabled
The names reuse initialization is moved to _mesa_alloc_shared_state ->
_mesa_InitHashTable instead of _mesa_HashEnableNameReuse.
It will be enabled by default.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32715>
Rather than emitting FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD to do block
loads that were cacheline aligned, loading entire cachelines at a time,
we now rely on NIR passes to group, CSE, and vectorize things into
appropriately sized blocks. This means that we'll usually still load
a cacheline, but we may load only 32B if we don't actually need anything
from the full 64B. Prior to Xe2, this saves us registers, and it ought
to save us some bandwidth as well as the response length can be lowered.
The cacheline-aligning hack was the main reason not to simply call
fs_nir_emit_memory_access(), so now we do that instead, porting yet
one more thing to the common memory opcode framework.
We unfortunately still emit the old FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD
opcode for non-block intrinsics. We'd have to clean up 16-bit handling
among other things in order to eliminate this, but we should in the
future.
fossil-db results on Alchemist for this and the previous patch together:
Instrs: 161481888 -> 161297588 (-0.11%); split: -0.12%, +0.01%
Subgroup size: 8102976 -> 8103000 (+0.00%)
Send messages: 7895489 -> 7846178 (-0.62%); split: -0.67%, +0.05%
Cycle count: 16583127302 -> 16703162264 (+0.72%); split: -0.57%, +1.29%
Spill count: 72316 -> 67212 (-7.06%); split: -7.25%, +0.19%
Fill count: 134457 -> 125970 (-6.31%); split: -6.83%, +0.52%
Scratch Memory Size: 4093952 -> 3787776 (-7.48%); split: -7.53%, +0.05%
Max live registers: 33037765 -> 32947425 (-0.27%); split: -0.28%, +0.00%
Max dispatch width: 5780288 -> 5778536 (-0.03%); split: +0.17%, -0.20%
Non SSA regs after NIR: 177862542 -> 178816944 (+0.54%); split: -0.06%, +0.60%
In particular, several titles see incredible reductions in spill/fills:
Shadow of the Tomb Raider: -65.96% / -65.44%
Batman: Arkham City GOTY: -53.49% / -28.57%
Witcher 3: -16.33% / -14.29%
Total War: Warhammer III: -9.60% / -10.14%
Assassins Creed Odyssey: -6.50% / -9.92%
Red Dead Redemption 2: -6.77% / -8.88%
Far Cry: New Dawn: -7.97% / -4.53%
Improves performance in many games on Arc A750:
Cyberpunk 2077: 5.8%
Witcher 3: 4%
Shadow of the Tomb Raider: 3.3%
Assassins Creed: Valhalla: 3%
Spiderman Remastered: 2.75%
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32888>
The hope here is to replace our backend handling for loading whole
cachelines at a time from UBOs into NIR-based handling, which plays
nicely with the NIR load/store vectorizer.
Rounding down offsets to multiples of 64B allows us to globally CSE
UBO loads across basic blocks. This is really useful. However, blindly
rounding down the offset to a multiple of 64B can trigger anti-patterns
where...a single unaligned memory load could have hit all the necessary
data, but rounding it down split it into two loads.
By moving this to NIR, we gain more control of the interplay between
nir_opt_load_store_vectorize and this rebasing and CSE'ing. The backend
can then simply load between nir_def_{first,last}_component_read() and
trust that our NIR has the loads blockified appropriately.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32888>
The NIR vectorizer may produce block loads with unread trailing
components. Upcoming passes may produce unread leading components
as well. With a bit of finesse, we can skip loading those, and only
bother with the ones we actually need. This can sometimes save us on
loads and MOVs.
v2: Skip this for SLM reads on pre-LSC platforms (caught by Lionel).
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32888>
If we pass an immediate, just trivially return that immediate.
This preserves the property that if x was an IMM, emit_uniformize(x)
will also be an IMM, without the need for optimizations to eliminate
unnecessary operations. That way, you can call emit_uniformize() on
a value and still check whether it's constant afterwards.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32888>
We return an immediate for 32-bit constant values, but fall back to
calling get_nir_src() for other values, as 64-bit, and even 8-bit
immediates have odd restrictions. We could probably support 16-bit
here without too many issues, but we leave it be for now.
This makes it usable for case where we'd like to get constants for
32-bit values but where it may be a different bit-size too.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32888>
We were already skipping unread trailing components, but now we skip
them on both ends.
About -3.5% spills on Shadow of the Tomb Raider on Alchemist (mostly a
wash elsewhere, but it will help additional shaders with later patches).
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32888>
HDC doesn't support block loads/stores with sub-DWord (<4B) aligned
offsets, and shared local memory has to use the Aligned OWord Block
messages which require OWord (16B) alignment.
Make the validator detect this case and say no. Also make the lowering
code assert that the alignment is valid as a second line of defense.
LSC has no such restrictions.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32888>
This patch exposes shader hashes (computes and draws) to Perfetto and
utrace. By including these hashes in traces, developers can correlate
compute and draw calls with their assoicated ASM dumps when analyzing
the traces.
To achieve this, intel_tracepoint.py has been reworked to preprocess
tracepoint arguments dynamically. Any argument containing "hash" in its
variable name is now forrmated as hexadecimal before being passed to the
tracepoint definition.
Signed-off-by: Michael <michael.cheng@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32708>
Was causing trouble in some build configurations, we don't really need
them. Unless there's a good reason, defaults to use ralloc for
consistency with the larger codebase.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Antonio Ospite <None>
Reviewed-by: Kenneth Graunke <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32916>
This message has been confusing users, especially now that
popular toolkits such as Gtk started using a Vulkan renderer.
Printing a message on non-conformant implementations is also
actually not required. So let's remove it.
We haven't fully finished the GFX12 implementation yet, but on
all other hardware, RADV should work just fine, and is definitely
not meant for "testing use only".
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12314
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32930>
DONTBLOCK is sort of almost good enough except that the api frontend
can also use this and it can't use the full power of Trust Me Buddy™
that qbo maps require
this causes unnecessary ioctl syncs, which annihilates perf in games
that constantly check query results
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31823>
this allows a return without checking syncobj, avoiding overhead,
but when a query still isn't completing after multiple checks then
try checking the pool directly
this circumvents the usual qbo mechanism in specific cases (e.g., Everspace)
where an app fires off a million timestamp queries and the overhead of
checking a timeline semaphore kills perf
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31823>
If there is a 4-byte hole between 2 loads, they are vectorized. Example:
load 4 + hole 4 + load 8 -> load 16
This helps GLSL uniform loads, which are often sparse. See the code for more
info.
RADV could get better code by vectorizing later.
radeonsi+ACO - TOTALS FROM AFFECTED SHADERS (45482/58355)
Spilled SGPRs: 841 -> 747 (-11.18 %)
Code Size: 67552396 -> 65291092 (-3.35 %) bytes
Max Waves: 714439 -> 714520 (0.01 %)
This should have no effect on LLVM because ac_build_buffer_load scalarizes
SMEM, but it's improved for some reason:
radeonsi+LLVM - TOTALS FROM AFFECTED SHADERS (4673/58355)
Spilled SGPRs: 1450 -> 1282 (-11.59 %)
Spilled VGPRs: 106 -> 107 (0.94 %)
Scratch size: 101 -> 102 (0.99 %) dwords per thread
Code Size: 14994624 -> 14956316 (-0.26 %) bytes
Max Waves: 66679 -> 66735 (0.08 %)
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29399>
There is nothing preventing ACO from generating loads with unused
components. This happens often with GLSL uniforms. Some of those loads
are partially re-vectorized after this.
radeonsi+ACO:
TOTALS FROM AFFECTED SHADERS (19564/58918)
VGPRs: 732900 -> 728448 (-0.61 %)
Spilled SGPRs: 429 -> 433 (0.93 %)
Code Size: 38446004 -> 38485612 (0.10 %) bytes
Max Waves: 305440 -> 305549 (0.04 %)
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29399>
Walk the whole vertex stride thanks to XFB info sorted by offset, gather
individual components from same or different outputs, and once we have
gathered 4, store them as vec4.
It also removes the memory_modes field from VMEM stores because I don't
think it's needed.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32686>
Walk the whole vertex stride thanks to XFB info sorted by offset, gather
individual components from same or different outputs, and once we have
gathered 4, store them as vec4.
It also removes the COHERENT flag from VMEM stores because NGG streamout
doesn't use it either and I don't think it's needed.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32686>
The mesa crate should just provide the means of creating those, but the
logic of what to create shouldn't be there.
The passed in arguments also heavily vary, and this way we can be explicit
about what variants needs what inputs.
Reviewed-by: @LingMan
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32903>
This allows us to use more contextual information of the image to create
the pipe_sampler_view properly instead of passing all the required
properties via function arguments.
Reviewed-by: @LingMan
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32903>
This simplifies sampler view tracking a bit for us. Also, drivers will
automatically free the pipe_sampler_view as well.
It was wrong to call into sampler_view_destroy directly anyway, because
pipe_sampler_view is a refcounted object and pipe_sampler_view_reference
should be used instead.
Reviewed-by: @LingMan
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32903>
I stumbled on this limit - it turns out that large local_sizes apply an
additonal limit on gprs per thread. If we violate this limit, then dmesg
just gives us a rather unhelpful message that the channel is killed:
nouveau 0000:01:00.0: gsp: rc engn:00000001 chid:64 type:13 scope:1 part:233
nouveau 0000:01:00.0: fifo:c00000:0008:0040:[hw_tests::test_[14761]] errored - disabling channel
Cc: mesa-stable
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32952>
Cast the value used in static assertion to be an unsigned integer,
instead of default signed integer.
This has been detected by Undefined Behaviour Sanitizer (UBSan).
```
../src/gallium/drivers/etnaviv/etnaviv_state.c:289:62: error: expression in static assertion is not constant
289 | static_assert((VIVS_PS_OUTPUT_REG2_SATURATE_RT4 << 24) == VIVS_PS_OUTPUT_REG2_SATURATE_RT7, "VIVS_PS_OUTPUT_REG2_SATURATE_RT7");
```
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30880>
This fixes VirglStagingMgr tests that tries to access a struct member of
a structure that is NULL.
This has been detected using Undefined Behaviour Sanitizer.
```
Running main() from ../src/gtest/src/gtest_main.cc
[==========] Running 9 tests from 2 test suites.
[----------] Global test environment set-up.
[----------] 7 tests from VirglStagingMgr
[ RUN ] VirglStagingMgr.non_fitting_allocation_reallocates_resource
stderr:
../src/gallium/drivers/virgl/tests/virgl_staging_mgr_test.cpp:72:22: runtime error: member access within null pointer of type 'struct virgl_hw_res'
```
Reviewed-by: Eric Engestrom <eric@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30880>
Detected when working on adding support for Undefined Behaviour
Sanitizer, this fixes:
```
../src/gallium/drivers/v3d/v3d_screen.c: In function 'v3d_get_compute_param.part.0':
../src/gallium/drivers/v3d/v3d_screen.c:480:17: error: null destination pointer [-Werror=format-overflow=]
480 | sprintf(ret, "v3d");
| ^~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
```
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30880>
Detected when working on adding support for Undefined Behaviour
Sanitizer, this fixes:
```
../src/gallium/drivers/radeonsi/radeon_vcn_dec.c: In function 'get_h264_msg':
../src/gallium/drivers/radeonsi/radeon_vcn_dec.c:239:50: error: 'k' may be used uninitialized [-Werror=maybe-uninitialized]
239 | && (k == ARRAY_SIZE(dec->h264_valid_poc_num))) {
| ~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/gallium/drivers/radeonsi/radeon_vcn_dec.c:77:19: note: 'k' was declared here
77 | unsigned i, j, k;
| ^
cc1: all warnings being treated as errors
```
Reviewed-by: David Rosca <david.rosca@amd.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30880>
Detected when working on adding support for Undefined Behaviour
Sanitizer, this fixes:
```
../src/gallium/drivers/freedreno/a2xx/ir2_nir.c: In function 'load_const':
../src/gallium/drivers/freedreno/a2xx/ir2_nir.c:154:24: error: 'swiz' may be used uninitialized [-Werror=maybe-uninitialized]
154 | unsigned imm_ncomp, swiz, idx, i, j;
| ^~~~
../src/gallium/drivers/freedreno/a2xx/ir2_nir.c:195:30: error: 'imm_ncomp' may be used uninitialized [-Werror=maybe-uninitialized]
195 | so->immediates[idx].ncomp = imm_ncomp;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
../src/gallium/drivers/freedreno/a2xx/ir2_nir.c:154:13: note: 'imm_ncomp' was declared here
154 | unsigned imm_ncomp, swiz, idx, i, j;
| ^~~~~~~~~
cc1: all warnings being treated as errors
```
Reviewed-by: Rob Clark <robclark@freedesktop.org>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30880>
It could run the companion batch buffer even if the main batch buffer
failed, that was possible to happen in i915 and Xe KMD.
In case the main context/queue is banned and companion is not it could
still return that submission was properly start what was not.
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/32850>
Fix defect reported by Coverity Scan.
Side effect in assertion (ASSERT_SIDE_EFFECT)
assert_side_effect: Argument ++eot_count of assert() has a side effect.
The containing function might work differently in a non-debug build.
Fixes: ebd6738260 ("intel/elk/chv: Implement WaClearArfDependenciesBeforeEot")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32884>
Mesa3D is commonly used, as evidenced by the use of the Mesa3D.org domain.
Additionally, it is unnecessary to advise against using "MesaGL"
since we do not use it ourselves.
Cc: mesa-stable
Signed-off-by: David Heidelberg <david@ixit.cz>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32447>
This feature actually worked, but accidentally triggered some
CTS failures due do an unrelated sample_mask bug. That bug
is fixed in the previous commits in this series, so re-enable
fragmentStoresAndAtomics.
There are two spurious CI failures created by this change; one is in
a ycbcr test (which we're still working on) and the other is a CTS
bug (it's using a feature we don't advertise).
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32879>
this was missed in the original v3d pass, and then the common code port
inherited the bug. (so strictly this fix "should" be backported even farther
back but it won't apply before the Fixes here, and I don't think we do LTS that
far back anyway).
in theory this should fix a corner case with robustness on the gl (but not
vulkan, at least for apple) drivers on broadcom & apple.
Fixes: f0fb8d05e3 ("nir: Add nir_lower_robust_access pass")
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32907>
rather than try to enumerate everything a driver might want with an unmanageable
collection of booleans, just do a filter callback + data. this ends up simpler
overall, and will allow Intel to use this pass for just 64-bit images without
needing to add even more booleans.
while we're churning the pass signature, also do a quick port to
nir_shader_intrinsics_pass
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> [NIR and V3D]
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32907>
The loop checking if exec is overwritten didn't check for NULL
instructions, and didn't fix up reg write indices after inserting
instructions.
Fixes: fcd94a8c ("aco: move try_optimize_branching_sequence() to postRA optimizations")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32746>
We need to add a variant of the texld instruction, which is used with a shadow
samper and passed the shadow reference value via src2.
Blob generates such texld's for deqp's GLES3.functional.texture.shadow.2d.* (GC3000).
Fixes spec@arb_depth_texture@texdepth.
Fixes: abe5bd35 ("etnaviv: Switch to isa_assemble_instruction(..)")
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32926>
Marek recently changed hole_size to be signed, rather than unsigned.
A negative hole_size means that the two loads overlap - and thus are
prime candidates to be combined.
My original hole_size handling was:
if hole_size > 4 * (8 - low->num_components) then don't vectorize
For non-overlapping loads, this worked: NIR's largest vector is vec16,
and if low was already a vec16, combining it with anything would exceed
that, so it'd never be considered. That meant low would always be a
vec8 or less, so (8 - low->num_components) was a positive number.
Now that we see overlapping loads, we can see a vec16 low, vec4 high,
and also a negative hole size, giving us fun comparisons like:
-16 > 4 * (8 - 16) => -16 > -32 => true, don't vectorize
Which is absolutely the wrong thing to do, because the high load's data
is entirely included within the former load's data.
The idea here was to make sure the second load would be able to pack at
least one component into the first's V8 result. But even this isn't the
best, because...even if it's simply adjacent, doing one V16 load is more
efficient than requesting two back to back V8 loads.
So, we just simplify down to a static check: if there's an entire V8 of
hole, don't vectorize. This already won't happen because the core pass
has max_hole set to 28 bytes (7 32-bit components), but that could
change based on the needs of other drivers, so let's be defensive.
fossil-db results on Alchemist:
Instrs: 161533978 -> 161295137 (-0.15%); split: -0.20%, +0.05%
Subgroup size: 8092544 -> 8092568 (+0.00%)
Send messages: 7915233 -> 7844503 (-0.89%); split: -0.94%, +0.05%
Cycle count: 16577700697 -> 16702609256 (+0.75%); split: -0.59%, +1.35%
Spill count: 72338 -> 67226 (-7.07%); split: -7.36%, +0.29%
Fill count: 134058 -> 125980 (-6.03%); split: -6.83%, +0.80%
Scratch Memory Size: 4092928 -> 3786752 (-7.48%); split: -7.53%, +0.05%
Max live registers: 33031460 -> 32945994 (-0.26%); split: -0.27%, +0.01%
Max dispatch width: 5778384 -> 5778536 (+0.00%); split: +0.26%, -0.26%
Non SSA regs after NIR: 179809505 -> 152735471 (-15.06%); split: -15.08%, +0.03%
Fixes: c21bc65ba7 ("nir/opt_load_store_vectorize: make hole_size signed to indicate overlapping loads")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32932>
When a SEND instruction is a EOT, the scoreboard lowering will not
allocate a new SBID for it, since nothing needs to wait for it. In
Gfx12 this allowed the SEND to get out-of-order $.dst or $.src
dependencies.
Starting on Xe2+ this is not supported anymore, in favor of supporting
more combined modes.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32712>
Currently we scale the polygon offset units with a fixed factor,
matching the MRD (minimal resolvable distance) for a 16bpp depth
buffer. This wastes a lot of precision when a 24bpp depth buffer
is used.
Apply the correct MRD scale, depending on the format of the
currently bound depth buffer.
Fixes piglit spec@!opengl 1.4@gl-1.4-polygon-offset.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32756>
This is similar to what link_intrastage_shaders is doing and it
fixes the following test:
KHR-Single-GL46.subgroups.builtin_var.compute.subgroupsize_compute
Which was failing with SPIRV but passing with GLSL, the diff being:
- SPIRV: "subgroup_size: 1"
- GLSL: "subgroup_size: 2"
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32698>
The blitter VS expects coords to fit in a signed int16. When this
is not the case, use util_blitter_draw_rectangle instead.
Since util_blitter_draw_rectangle sets vertex elements, we need
to make sure they're properly restored.
The alternative to this fallback would be to pass coordinates
unpacked (so 4 SGPRs instead of 2), but this doesn't fix the
fbo-blit-check-limits test because of uv interpolation precision
issue.
Using 2 triangles instead of a rectangle + disabling
window_space_position helps but then this breaks some GLES3 tests,
like dEQP-GLES3.functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_x
(which doesn't pass either if u_blitter is used for all cases).
Using a single triangle covering the whole rectangles fixes all
cases but it then requires to setup scissors to not write too
much pixels...
So, instead of adding so much complexity, let's use u_blitter
for the "large coordinates" fallback, and keep the rectangle blit
for the other cases.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32698>
This is actually a false positive detected by static analyzer, because
it assumes that `device->instance->meta_cache_enabled` can change
between two execution points.
In order to instruct static analyzer this is not the case, we assing it
to a local variable, and do the checks based on that.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32819>
Declaring a variable-length array (VLA) based on a variable that can be
0 is declared dangerous.
In this case, the variable can't take value 0, so adding an assertion
fixes the issue.
This was detected by static analyzer.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32819>
We're about to add more sysvals, and the more we add, the bigger the
sysvals region gets, which increases the amount of memory we have to
allocate when push_uniforms are dirty.
Instead of allocating FAUs for all sysvals/push_constants, track FAU
usage per-shader, and pack those. This implies emitting an FAU buffer
per stage instead of trying to share it, but that's an acceptable
trade-off.
While at it, automate the sysval dirty tracking a bit.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32415>
Now that panvk_cmd_buffer.h is accessible from
src/panfrost/vulkan/panvk_vX_xxx.c files, there's no reason to pass
a gazillon arguments to blend_emit_descs(). We can just pass a cmdbuf
and let the helper extract the other parameters from there. It also
allows for extra automation, like dirtying the push_uniform buffer
when the new blend config reads the blend constant.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32415>
load_vertex_id_zero_base() is supposed to return the zero-based
vertex ID, which is then offset by load_first_vertex() to get
an absolute vertex ID. At the same time, when we're in a Vulkan
environment, load_first_vertex() also encodes the vertexOffset
passed to the indexed draw.
Midgard/Bifrost have a sligtly different semantics, where
load_first_vertex() returns vertexOffset + minVertexIdInIndexRange,
and load_vertex_id_zero_base() returns an ID that needs to be offset
by this vertexOffset + minVertexIdInIndexRange to get the absolute
vertex ID. Everything works fine as long as all the load_first_vertex()
and load_vertex_id_zero_base() calls are coming from the
load_vertex_id() lowering. But as mentioned above, that's no longer
the case in Vulkan, where gl_BaseVertexARB will be turned into
load_first_vertex() and expect a value of vertexOffset in an
indexed draw context.
We thus need to fix the mismatch by introducing two new
panfrost-specific intrinsic so we can stop abusing load_first_vertex()
and load_vertex_id_zero_base().
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32415>
The csel-ladder we have in bi_lower_load_push_const_with_dyn_offset()
is not great, and is relying on base/range being valid. It turns out
nir_lower_mem_access_bit_sizes(), which we rely on to make push constant
accesses 32-bit aligned, doesn't preserve those when splitting accesses.
Let's simplify the thing by lowering push constant accesses with a
dynamic offset to global loads.
We also reset the base and offset values in the lowering pass, to make
sure the backend doesn't rely on them for other things.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32415>
This is required to optimize FP64 and Int64 shaders generated by
virglrenderer. It generates pack/unpack around every 64-bit op,
which NIR currently can't eliminate. This fixes that.
There is a new constraint ".y", which means that the use of an instruction
should have swizzle.y. This allows us to add patterns that have Y swizzle
on results of instructions.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32172>
Currently marge will ignore an error message if it is just the word
"error" without any further information. However, if she never finds a
more informative message, then she will just print that meaningless
error message.
Instead of an empty error message, just leave the message blank.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32773>
If marge doesn't find deqp-runner results or trace errors, she will parse
a failed job log for error messages. The parsing ignores certain phrases
in an attempt to find more relevant errors.
Add a test to check marge's error log parsing to make sure that we don't
create regressions when adding new phrases to ignore.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32773>
Currently, if the pipeline_message script runs in an an env missing the
aiohttp package, the pipeline_message script will throw a
ModuleNotFoundError and crash marge.
Make sure to catch and ignore these errors since the pipeline message
should never interfere with a merge request.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32773>
The calibrate domain and the device domain period are determined in
vk_device_init. With them known, and with the vk_time_max_deviation
helper, GetCalibratedTimestampsKHR is straightforward.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32689>
VK_TIME_DOMAIN_DEVICE_KHR is always supported. Host time domains are
checked by vk_device_get_timestamp.
This is not used when the driver does not advertise
VK_{KHR,EXT}_calibrated_timestamps.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32689>
This change prevents the reuse of the bo when the counter is already
zero. At zero, the bo is in a state where the deletion is pending,
and this implementation relying on an atomic counter can't be safely
stopped. In other words, the previous fix ccd3bb4548 lower the
probability of this race condition, but doesn't fix it.
This change prevents a race condition which has a high probability
on r600 with the test below. This change was tested with the thread
sanitizer.
For instance, this issue is triggered on r600 with
"piglit/bin/ext_image_dma_buf_import-refcount-multithread -auto":
==9876==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d000021a20 at pc 0x7f2c9f59f748 bp 0x7f2c8f3aa600 sp 0x7f2c8f3aa5f8
READ of size 4 at 0x60d000021a20 thread T6
#0 0x7f2c9f59f747 in pipe_is_referenced ../src/gallium/auxiliary/util/u_inlines.h:65
#1 0x7f2c9f59f747 in radeon_bo_destroy ../src/gallium/winsys/radeon/drm/radeon_drm_bo.c:342
#2 0x7f2c9f63b541 in radeon_bo_reference ../src/gallium/include/winsys/radeon_winsys.h:794
#3 0x7f2c9f63b541 in r600_texture_destroy ../src/gallium/drivers/r600/r600_texture.c:571
#4 0x7f2c9d65662d in pipe_resource_destroy ../src/gallium/auxiliary/util/u_inlines.h:146
#5 0x7f2c9d65662d in pipe_resource_reference ../src/gallium/auxiliary/util/u_inlines.h:163
#6 0x7f2c9d65662d in st_FreeTextureImageBuffer ../src/mesa/state_tracker/st_cb_texture.c:459
#7 0x7f2c9d5b6991 in _mesa_delete_texture_image ../src/mesa/main/teximage.c:226
#8 0x7f2c9d5f2593 in _mesa_delete_texture_object ../src/mesa/main/texobj.c:532
#9 0x7f2c9d5f2be7 in _mesa_reference_texobj_ ../src/mesa/main/texobj.c:639
#10 0x7f2c9d5f3773 in _mesa_reference_texobj ../src/mesa/main/texobj.h:92
#11 0x7f2c9d5f3773 in delete_textures ../src/mesa/main/texobj.c:1578
0x60d000021a20 is located 0 bytes inside of 144-byte region [0x60d000021a20,0x60d000021ab0)
freed by thread T5 here:
#0 0x7f2ca8b2b4f7 in free (/usr/lib64/libasan.so.6+0xb14f7)
#1 0x7f2c9f59efb3 in radeon_bo_destroy ../src/gallium/winsys/radeon/drm/radeon_drm_bo.c:401
#2 0x7f2c9f63b541 in radeon_bo_reference ../src/gallium/include/winsys/radeon_winsys.h:794
#3 0x7f2c9f63b541 in r600_texture_destroy ../src/gallium/drivers/r600/r600_texture.c:571
#4 0x7f2c9d65662d in pipe_resource_destroy ../src/gallium/auxiliary/util/u_inlines.h:146
#5 0x7f2c9d65662d in pipe_resource_reference ../src/gallium/auxiliary/util/u_inlines.h:163
#6 0x7f2c9d65662d in st_FreeTextureImageBuffer ../src/mesa/state_tracker/st_cb_texture.c:459
#7 0x7f2c9d5b6991 in _mesa_delete_texture_image ../src/mesa/main/teximage.c:226
#8 0x7f2c9d5f2593 in _mesa_delete_texture_object ../src/mesa/main/texobj.c:532
#9 0x7f2c9d5f2be7 in _mesa_reference_texobj_ ../src/mesa/main/texobj.c:639
#10 0x7f2c9d5f3773 in _mesa_reference_texobj ../src/mesa/main/texobj.h:92
#11 0x7f2c9d5f3773 in delete_textures ../src/mesa/main/texobj.c:1578
previously allocated by thread T6 here:
#0 0x7f2ca8b2b9a7 in calloc (/usr/lib64/libasan.so.6+0xb19a7)
#1 0x7f2c9f5a36d5 in radeon_winsys_bo_from_handle ../src/gallium/winsys/radeon/drm/radeon_drm_bo.c:1198
#2 0x7f2c9f641b2a in r600_texture_from_handle ../src/gallium/drivers/r600/r600_texture.c:1105
#3 0x7f2c9d47550a in dri_create_image_from_winsys ../src/gallium/frontends/dri/dri2.c:1007
#4 0x7f2c9d47eeb9 in dri2_from_dma_bufs ../src/gallium/frontends/dri/dri2.c:1629
#5 0x7f2ca8854360 in dri2_create_image_dma_buf ../src/egl/drivers/dri2/egl_dri2.c:2564
#6 0x7f2ca8854f45 in dri2_create_image_khr ../src/egl/drivers/dri2/egl_dri2.c:2817
#7 0x7f2ca8846f2c in dri2_create_image ../src/egl/drivers/dri2/egl_dri2.c:1864
#8 0x7f2ca87f9dd8 in _eglCreateImageCommon ../src/egl/main/eglapi.c:1850
Fixes: ccd3bb4548 ("winsys/radeon: fix a race between bo import and destroy")
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/32896>
Enables use of async compute for shader format conversions.
Deinterlace filter still need gfx.
On my system with RX570 this fixes performance issues when using
gpu-screen-recorder to record gameplay at full GPU load. It can
now record with full framerate, compared to half framerate before.
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32794>
There were a couple of issues this fixes:
- Using the env "RUSTICL_DEVICE_TYPE" variable made no device be default.
- If multiple GPUs were detected, multiple devices were default.
- If zink was used, no default device was advertized either.
The spec requires that there must be one and only one default device.
Cc: mesa-stable
Reviewed-by @LingMan
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32875>
It caused the Blender corruption, but the previous commit likely fixes it.
The workaround regressed performance for Furmark and Plot3D with 8xMSAA.
If you want to enable the workaround again in the future, just add this
line back: sscreen->info.gfx_level >= GFX11 ||
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32885>
This is based on the example given by the Vulkan specification: https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#textures-texel-anisotropic-filtering
The basic idea is to compute the axis in which the uv coordinates
change the fastest in screen space (rho_y and rho_y). If rho_x is larger
than rho_y, samples are summed up along the x-Axis and the y-Axis
viceversa. The x/y offsets are mapped back into texture (u/v) space
using a linear approximation of u(x,y) and v(x,y).
This approach does not use a nested loop and the number of samples is
basically limited to max_anisotropy (+/-). The sample count of the
previous approach could explode in some situations, leading to
frametimes >1s.
Reviewed-by: Aleksi Sapon <aleksi.sapon@autodesk.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31748>
Currently the list of buffer usage bits specified is hardcoded with
transform feedback bits, which leads to a validation layer error report
with ID VUID-VkBufferCreateInfo-None-09499 when EXT_transform_feedback
is not available.
Only set these bits when EXT_transform_feedback extension is really
available to suppress this error.
Cc: mesa-stable
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32386>
One new rv410 flake and one new rv530 fail which I can't reproduce
locally. Also remove the vs-varying-array-mat3* flakes, those were
failing because we run out of varyings, however this should no longer be
an issue since nir_opt_varyings was enabled for everyone.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32897>
The push_constant_loc[] array is always an identity mapping these days,
so it's kind of pointless. Just use the original uniform number and
skip the unnecessary "remap" step. With that gone, and shrinking UBO
ranges gone, assign_constant_locations() is now empty and can be removed
as well.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32841>
Back in the bad old days (vec4?) we had a bunch of smarts in the backend
to dead code eliminate unused vector components and re-pack regular
uniforms, so we really couldn't decide how much data we were pushing
until very late in the backend. Nowadays we have none of that - we do
all of our elimination and packing in NIR. anv shrinks ranges to deal
with Vulkan API push constants, and iris treats everything as a UBO and
as of the previous commit will also shrink appropriately.
So we don't need to do this anymore...which will let us simplify quite
a bit of code.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32841>
anv already does this limiting, since it needs to handle non-UBO push
constants as well. iris treats everything as a UBO, but doesn't have
a limiter and was relying on the backend to handle it.
Do this in the NIR pass so that we can eliminate the backend code.
It's not necessary for anv, but handling it here is simple and less
error prone for iris, which calls this in a number of places. We know
we need to limit things to this much; anv can limit more if needed.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32841>
The value of the PIPE_SHADER_CAP_MAX_CONST_BUFFERS parameter should be
less than PIPE_MAX_CONSTANT_BUFFERS, otherwise, it will lead to some
assert failures. For example:
void
cso_unbind_context(struct cso_context *cso)
{
...
int maxsam = scr->get_shader_param(scr, sh,
PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS);
int maxview = scr->get_shader_param(scr, sh,
PIPE_SHADER_CAP_MAX_SAMPLER_VIEWS);
int maxssbo = scr->get_shader_param(scr, sh,
PIPE_SHADER_CAP_MAX_SHADER_BUFFERS);
int maxcb = scr->get_shader_param(scr, sh,
PIPE_SHADER_CAP_MAX_CONST_BUFFERS);
int maximg = scr->get_shader_param(scr, sh,
PIPE_SHADER_CAP_MAX_SHADER_IMAGES);
assert(maxsam <= PIPE_MAX_SAMPLERS);
assert(maxview <= PIPE_MAX_SHADER_SAMPLER_VIEWS);
assert(maxssbo <= PIPE_MAX_SHADER_BUFFERS);
assert(maxcb <= PIPE_MAX_CONSTANT_BUFFERS); // Crash here
assert(maximg <= PIPE_MAX_SHADER_IMAGES);
...
}
Signed-off-by: Feng Jiang <jiangfeng@kylinos.cn>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32889>
Now that ACO has become the default on pre-RDNA GPUs, all pre-merge CI
coverage of radeonsi+LLVM has disapeared. Let's fix this by making
our post-merge glcts-vangogh-valve job run inpre-merge pipelines.
However, we are limited in vangogh capacity, so rather than running the
full glcts/piglit test suites we run a fraction of it to stay under 15
minutes of execution time on a single Steam Deck.
Suggested-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32865>
It's not entirely clear to me why this has moved from Crash/Fail to
Pass, the only thing I can see in the commit history between the last
nightly pass and failure is an optimization of unpacing 8-bit values
from a 64-bit value. It's a bit suspicious that an optimization makes
somethign pass...
But we need to have correct CI expectations, otherwise we won't notice
new failures. So let's update to the new reality, and debug this if the
problem reappears in the future.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32833>
Looks like this changed when IO-lowering was changed in the GLSL
linker, but because the traces job here runs post-merge, it wasn't
noticed at the time.
There's only a single pixel that has changed, from a very dark color to
another very dark color. Neigher the before nor after images looks
obviously more correct than the other.
Fixes: 73d675451b ("ci: update fail lists and trace checksums")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32833>
In OpenGL, non-multisample targets always have full coverage, and shader
writes to gl_SampleMask are ignored. On Vulkan, sample mask writes on
single-sample targets are treated the same way as writes with >1 sample.
Fixes dEQP-VK.pipeline.*.multisample_shader_builtin.write_sample_mask.1_samples
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32636>
Fix defect reported by Coverity Scan.
Arguments in wrong order (SWAPPED_ARGUMENTS)
swapped_arguments: The positions of arguments in the call to
hk_ia_update do not match the ordering of the parameters:stat_c_inv is
passed to c_prims.stat_c_prims is passed to c_inv.
Fixes: a3b796ba19 ("libagx,hk: handle pipeline stats queries without a GS")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32853>
The Vulkan spec says:
"The application can enable a logical operation between the
fragment’s color values and the existing value in the framebuffer
attachment. This logical operation is applied prior to updating
the framebuffer attachment. Logical operations are applied only
for signed and unsigned integer and normalized integer
framebuffers. Logical operations are not applied to floating-point
or sRGB format color attachments."
Missing VKCTS coverage has been reported.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12345
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32826>
When linking FS and VS with mismatched interpolation qualifiers, we need
to read the FS qualifiers and pass them to the VS. I put
nir_collect_noperspective_varyings in a separate function instead of
merging it into the existing walk_varyings loop because it will later be
used on uncompiled shaders that don't have a pan_shader_info yet.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32127>
Mali only supports perspective-correct varying interpolation in
hardware, so we have to emulate noperspective with lowering in both the
VS and FS.
Both vulkan and opengl allow mismatched interpolation qualifiers between
stages. Because we need all varyings that are noperspective in the FS to
be lowered in the VS, we cannot rely on the interpolation qualifiers in
the VS. Loading the set of noperspective varyings as a sysval allows the
implementation to pass them as a compile-time constant when known
statically, or a runtime push constant when not. Passing noperspective
varyings dynamically has a performance cost with unnecessary branches
and fmuls.
This sysval is not hooked up yet in either panfrost or panvk, so shader
compilation will fail.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32127>
Video decode target needs custom height alignment, but tex descriptor
still needs to be set to the original size the image was created with.
This makes the descriptor wrong for layer > 0, so we need to calculate
the layer offset and add it to bo address for this case.
Fixes: 5deb476095 ("radv: align video images internal width/height inside the driver.")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32069>
Coverity notices that `err` might be used uninitialized, which is true
as we don't assign the value we want to check! Fix that assignment so
the EXPECT_EQ macro does what we expect.
CID: 1635272
Fixes: 6b931a68c7 ("intel/common: Implement Xe KMD in mi_builder tests")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32849>
When we moved building the docs to Meson, we accidentally dropped the -W
flag that we used to have. This lead to us no longer detecting certain
problems in the docs, which is unfortunate.
Let's bring this back gated by the werror meson-option, and wire that up
on the CI end.
Fixes: fdd204538b ("ci: build docs using meson")
Reviewed-by: Dylan Baker <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32831>
We need an empty line after ".. code-block: [...]", otherwise the first
lines are interpreted as arguments, not content. This makes the entire
code-blocks not render at all.
Fixes: 5d6d67a4d1 ("docs/android: improve documentation about building llvmpipe for Android")
Reviewed-by: Dylan Baker <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32831>
Also add a note in .gitlab-ci/container/debian/x86_64_test-android.sh
that DEBIAN_TEST_ANDROID_TAG needs to be updated when that file changes
too.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
For future reference add some disabled rules to for running tests using
llvmpipe on Android, and for that to work also add
deqp-android-llvmpipe.toml
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
Cuttlefish performs some checks on the host system before launching,
setting VK_DRIVER_FILES to the path of the host artifacts makes sure
that a vulkan library can be found on the host side.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
Set XDG_CACHE_HOME when invoking deqp-runner so that mesa can create the
shader cache and avoid this error:
-----------------------------------------------------------------------
ERROR - dEQP error: Failed to create //.cache for shader cache (Read-only file system)---disabling.
-----------------------------------------------------------------------
And also pass --shader-cache-dir to deqp-runner for vulkan tests.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
Also copy mesa vulkan libraries to the Android guest, this makes it
possible to test venus with the latest upstream mesa build.
While at it also keep the *_angle libraries as they will be used by the
venus_guest_angle GPU_MODE.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
Prefer libraries from /cuttlefish when loading binaries, in particular
this solves some loading problem when launching
/cuttlefish/bin/virgl_render_server
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
The /etc/init.d/cuttlefish-host-resources wnants to perform some
operations that are not really desirable on a gitlab shared runner, like
loading specific kernel modules.
Since the script does not seem to be strictly necessary for basic
operation of cuttlefish, don't call it at all, avoiding the kernel
modules problem.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
Commit 4143199be7 (ci/android: Use common $RESULTS_DIR for cuttlefish,
2024-08-21) clarified the separation between the result dir used on the
host and shipped in the artifacts, and the result dir used in the
Android guest to collect test results, however the latter was not
correctly passed to deqp-runner.
Fix that so that deqp-runner can finally run.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
Fix warning when using chown:
-----------------------------------------------------------------------
+ chown root.kvm /dev/kvm
chown: warning: '.' should be ':': 'root.kvm'
-----------------------------------------------------------------------
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
Use a custom kernel when launching cuttlefish, this is needed for
-gpu_mode=venus.
And while at it also clean up the state from previous runs, this seems
to be required when passing a custom kernel.
In this change also pass -enable_bootanimation=false which makes
drm_virgl work, and pass -enable_minimal_mode=true to avoid using some
features which are not really needed.
Note that the file number limit has to be increased too in
.gitlab-ci/cuttlefish-runner.sh for cuttlefish to work properly.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
Clarify that artifacts from the Android guest are downloaded explicitly
and put them under /mesa-android directory so that they don't clash with
the Linux host artifacts downloaded by gitlab under
"${CI_PROJECT_DIR}/install".
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
Different Android images may contain different graphic libraries, for
example images from Google using an old mesa version may have
libGLES_mesa.so, while newer Android images built with mesa from
upstream have libGLESv1_CM_mesa.so, etc.
Use `rm -f` instead of just `rm` to avoid running into errors when
a file does not exist, resulting in a failing job.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
To test mesa on cuttlefish some special images tailored for upstream
mesa are needed, in particular these images may set properties or add
functionality that enable new use cases for upstream mesa on Android,
like for instance using venus via the vulkan.virtio mesa driver.
So instead of downloading the standard images from Google, get those
custom images from s3.freedesktop.org.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
The ./tools/buildutils/build_packages.sh script used by the
android-cuttlefish project built in debian/x86_64_test-android.sh uses
sudo, so install that as an EPHEMERAL dependency.
Also set SUDO_FORCE_REMOVE=yes when removing sudo to avoid some errors.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
Save some logs and stop cuttlefish more cleanly when
.gitlab-ci/cuttlefish-runner.sh exits prematurely because of some
errors.
This makes it possible to have the logs available as artifacts even if
the script didn't run to completion.
This approach also leaves the system in a cleaner state and makes it
possible to relaunch the script and have launch_cvd work even if it had
been run in the past both with or without errors.
This is especially useful for local experiments.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
After copying the newly built mesa libraries to the Android vendor
partition the services have to be restarted to make sure that the new
libraries are used, in particular by Surfaceflinger, so call 'stop'
and 'start' for that.
Also print the GLES implementation used by Surfaceflinger before and
after restarting, to be able to compare and check that the new libraries
are effectively picked up.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
For the current tests the DRI drivers do not seem to be needed on
Android, so remove the ANDROID_DRIVER variable and stop copying the DRI
libraries to the guest file system, only copy libgallium_dri.so which is
really needed.
While at it, also copy libGLESv1_CM.so and libGLESv2.so
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
In order to build the mesa llvmpipe driver for Android, llvm libraries
for Android are needed; force meson to use a fallback for llvm and
provide prebuilt libraries making them available to meson thanks to
a wrap file.
Enable other software drivers for the x86_64-linux-android build, but
also disable the amd and intel hardware drivers for now which don't
build correctly on Android.
Download the prebuilt LLVM libraries for Android in the container job
rather than in the build job, to avoid downloading some big artifacts
for every mesa version built for Android.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
In commit ad42be50c9 (ci/deqp: fully isolate deqp builds, 2024-03-17)
the deqp module version file was changed from something like
`/deqp/version-$deqp_api` to something like `/deqp-$deqp_api/version`
and this seems to cause some issues when building for Android:
-----------------------------------------------------------------------
[439/1301] Building CXX object external/amber/src/src/vulkan/CMakeFiles/libamberenginevulkan.dir/blas.cc.o
FAILED: external/amber/src/src/vulkan/CMakeFiles/libamberenginevulkan.dir/blas.cc.o
/tmp/android-ndk-r25b/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ --target=x86_64-none-linux-android28 --sysroot=/tmp/android-ndk-r25b/toolchains/llvm/prebuilt/linux-x86_64/sysroot -DAMBER_CTS_VULKAN_HEADER=1 -DAMBER_ENABLE_CLSPV=0 -DAMBER_ENABLE_DXC=0 -DAMBER_ENABLE_LODEPNG=1 -DAMBER_ENABLE_RTTI=1 -DAMBER_ENABLE_SHADERC=0 -DAMBER_ENABLE_SPIRV_TOOLS=0 -DAMBER_ENGINE_DAWN=0 -DAMBER_ENGINE_VULKAN=1 -DDE_ANDROID_API=28 -DDE_ASSERT_FAILURE_CALLBACK -DDE_COMPILER=DE_COMPILER_CLANG -DDE_CPU=DE_CPU_X86_64 -DDE_FENV_ACCESS_ON="_Pragma(\"STDC FENV_ACCESS ON\")" -DDE_MINGW=0 -DDE_OS=DE_OS_ANDROID -DDE_PTR_SIZE=8 -I/tmp/VK-GL-CTS/external/amber/../vulkancts/framework/vulkan/generated/vulkan -I/tmp/VK-GL-CTS/framework/delibs/debase -I/tmp/VK-GL-CTS/framework/delibs/decpp -I/tmp/VK-GL-CTS/framework/delibs/depool -I/tmp/VK-GL-CTS/framework/delibs/dethread -I/tmp/VK-GL-CTS/framework/delibs/deutil -I/tmp/VK-GL-CTS/framework/delibs/destream -I/tmp/VK-GL-CTS/execserver -I/tmp/VK-GL-CTS/external/spirv-headers/src/include -I/tmp/VK-GL-CTS/external/amber/src/include -I/tmp/VK-GL-CTS/external/amber/src -I/tmp/deqp-vk -I/tmp/deqp-vk/external/vulkancts/framework/vulkan/generated/vulkan -Wall -Wextra -Wno-long-long -Wshadow -Wundef -Wconversion -Wno-sign-conversion -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -frtti -fexceptions -fwrapv -fvisibility=hidden -fvisibility-inlines-hidden -O3 -DNDEBUG -std=gnu++17 -fPIC -w -fno-exceptions -fvisibility=hidden -Wall -Wextra -Wno-cast-function-type-strict -Wno-padded -Wno-switch-enum -Wno-unknown-pragmas -Wno-unsafe-buffer-usage -pedantic-errors -Werror -Wno-c++98-compat -Wno-c++98-compat-pedantic -Wno-format-pedantic -Wno-unknown-warning-option -Weverything -Wno-zero-as-null-pointer-constant -MD -MT external/amber/src/src/vulkan/CMakeFiles/libamberenginevulkan.dir/blas.cc.o -MF external/amber/src/src/vulkan/CMakeFiles/libamberenginevulkan.dir/blas.cc.o.d -o external/amber/src/src/vulkan/CMakeFiles/libamberenginevulkan.dir/blas.cc.o -c /tmp/VK-GL-CTS/external/amber/src/src/vulkan/blas.cc
In file included from /tmp/VK-GL-CTS/external/amber/src/src/vulkan/blas.cc:16:
In file included from /tmp/VK-GL-CTS/external/amber/src/src/vulkan/blas.h:19:
In file included from /tmp/android-ndk-r25b/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/vector:274:
In file included from /tmp/android-ndk-r25b/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/__bit_reference:14:
In file included from /tmp/android-ndk-r25b/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/bit:57:
In file included from /tmp/android-ndk-r25b/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/limits:105:
In file included from /tmp/android-ndk-r25b/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/type_traits:417:
In file included from /tmp/android-ndk-r25b/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/cstddef:37:
/tmp/deqp-vk/version:1:1: error: unknown type name 'dEQP'
dEQP base version vulkan-cts-1.3.10.0
^
-----------------------------------------------------------------------
This seems to be caused by `cstddef` from the Android NDK which includes
a file named `version`, i.e.:
-----------------------------------------------------------------------
#include <version>
-----------------------------------------------------------------------
To avoid the problem also add the deqp module name to the file name,
like: `/deqp-$deqp_api/deqp-$deqp_api-version`.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
Collect the mustpass lists also for the Android target, in particular
this makes vk-main.txt to be found again when running vulkan tests on
Android.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
The main branch of dEQP build fine for android but the GL and GLES
branches fail with errors like the following:
-----------------------------------------------------------------------
.../external/openglcts/modules/common/glcFramebufferBlitTests.cpp:715:26: error: no member named 'floor' in namespace 'std'
return (GLubyte)std::floor(f == 1.0f ? 255 : f * 255.0);
~~~~~^
.../external/openglcts/modules/common/glcFramebufferBlitTests.cpp:1491:14: error: no member named 'fabs' in namespace 'std'
if (std::fabs(actual - expected) > eps)
~~~~~^
2 errors generated.
-----------------------------------------------------------------------
Cherry-pick a couple of commit from main that fix the errors.
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
When adding patches wit git-am create the date format for
GIT_COMMITTER_DATE in a locale-agnostic format, this avoids potential
issues when running the scripts locally with a non-English locale, e.g.:
-----------------------------------------------------------------------
++ GIT_COMMITTER_DATE='gio 1 gen 1970, 01:00:00, CET'
++ git am
fatal: invalid date format: gio 1 gen 1970, 01:00:00, CET
-----------------------------------------------------------------------
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30895>
This message is printed on non-panfrost/panthor systems on every
physical device enumeration when panvk is present like in distribution
mesa builds.
This "breaks" gtk-4 tests in the default configuration since they fail
on warning log messages. gtk-4 still forwards the vulkan debug report as
warning messages after fixes for issue 11451 to stop handling it as
critical message.
Signed-off-by: Janne Grunau <j@jannau.net>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Fixes: d970fe2e9d ("panfrost: Add a Vulkan driver for Midgard/Bifrost GPUs")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11451
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32822>
If an instruction didn't already use SDWA convert_to_SDWA in apply_extract
will add ubyte0/uword0 selections for v1b/v2b operands. This loses information
that the instruction doesn't care about the high bits and makes the next
apply_extract_twice fail.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Fixes: 6cb9d39bc2 ("aco: combine extracts with sub-dword definitions")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32803>
Move the sym_config setting all together and ensure that we set either
a value or empty, since Meson complains about missing values.
Fixes the build warning
```
Configuring dri.sym using configuration
../src/gallium/targets/dri/meson.build:28: WARNING: The variable(s) 'va_driver_init',
'vdp_imp_device_create_x11' in the input file 'src/gallium/targets/dri/dri.sym.in' are
not present in the given configuration data.
```
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32808>
Due to the slow startup time of deqp-vk, the previous default of
500 tests per group caused the jobs to run up to twice as slowly
compared to using a higher number of tests per group.
Increase the number of tests per group in the deqp-runner suite
to bring job durations within a reasonable range.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32729>
Due to the slow startup time of deqp-vk, the previous default of
500 tests per group caused the jobs to run up to twice as slowly
compared to using a higher number of tests per group.
Increase the number of tests per group for both subsets of the
deqp-runner suite, which allows decreasing the fraction.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32729>
Due to the slow startup time of deqp-vk, the previous default of
500 tests per group caused the jobs to run up to twice as slowly
compared to using a higher number of tests per group.
Increase the number of tests per group in the deqp-runner suite,
which allows decreasing the fraction and lowering the timeout.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32725>
The goal of the commit is to fix a dead assignment detected by static
analyzer: value stored to `linear_ok` is never read.
But instead of just removing the dead assignment, we just remove the
full variable, and instead search for the linear modifier in the place
that is required.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32772>
The goal of the commit is to fix a dead assignment detected by static
analyzer: value stored to `linear_ok` is never read.
But instead of just removing the dead assignment, we just remove the
full variable, and instead search for the linear modifier in the place
that is required.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32772>
Static analyzer is complaining that value stored to `v3d` during its
initialization is never read.
But the variable is used just below in a loop, so it is not clear if
this is just a false positive.
In any case, having this intermediate variable provides nothing,
specially when it is used only in a single place. So rather remove it
and use the full variable.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32772>
In nested control flow this is nessecary to not demote/terminate invocations
that are part of the global but not part of the local mask.
At the top level, the masks are the same and no additional invocations
can be accidentally disabled.
Foz-DB Navi21:
Totals from 2095 (2.64% of 79395) affected shaders:
Instrs: 1058326 -> 1056839 (-0.14%)
CodeSize: 5632480 -> 5626616 (-0.10%)
Latency: 12082761 -> 12080520 (-0.02%); split: -0.02%, +0.00%
InvThroughput: 2246677 -> 2246636 (-0.00%); split: -0.00%, +0.00%
Copies: 114446 -> 114433 (-0.01%)
SALU: 230585 -> 229098 (-0.64%)
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32755>
This change caused the regression:
@@ -853,7 +853,7 @@ bool si_llvm_compile_shader(struct si_screen *sscreen, struct ac_llvm_compiler *
/* Reset the shader context. */
ctx.shader = shader;
- ctx.stage = sel->stage;
+ ctx.stage = nir->info.stage;
bool same_thread_count = shader->key.ge.opt.same_patch_vertices;
si_build_wrapper_function(&ctx, parts, same_thread_count);
because "nir" contains the previous shader (LS), not the current shader (HS).
Fix it by using prev_nir for the previous shader, so that we can keep using
"nir".
Fixes: 9b7ea720c9 - radeonsi: use nir->info instead of sel->info.base
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32780>
The lowering code does not generate efficient code. It is better to
just not emit the bad thing in the first place. The shaders that I
examined had blocks of NIR like:
con 32 %527 = extract_u8 %456.o, %5 (0x0)
con 32 %528 = extract_u8 %456.o, %35 (0x1)
con 32 %529 = extract_u8 %456.o, %14 (0x2)
con 32 %530 = extract_u8 %456.o, %11 (0x3)
con 32 %531 = u2f32 %527
con 32 %532 = u2f32 %528
con 32 %533 = u2f32 %529
con 32 %534 = u2f32 %530
In some cases the u2f results are multiplied with 1/255. There may be
a slightly more efficient way to do this by doing something like
mov(8) g40<1>UW g12.1<32,8,4>UB
mov(8) g41<1>UW g12.2<32,8,4>UB
mov(8) g42<1>UW g12.3<32,8,4>UB
mov(8) g60<1>F g12<32,8,4>UB
mov(8) g61<1>F g40<1,1,0>UW
mov(8) g62<1>F g41<1,1,0>UW
mov(8) g63<1>F g42<1,1,0>UW
In SIMD16 and SIMD32 that would save temporary register space. It could
save a register in SIMD8 by using g40.8 instead of g42. Making that
happen might be tricky. Maybe we should just add a special NIR opcode
that converts a packed uint32 to a vec4?
v2: Add a bunch of documentation explaining what's going on. Suggested
by Ken.
shader-db:
Lunar Lake, Meteor Lake, and DG2 had similar results. (Lunar Lake shown)
total instructions in shared programs: 18228689 -> 18228720 (<.01%)
instructions in affected programs: 43091 -> 43122 (0.07%)
helped: 0 / HURT: 30
total cycles in shared programs: 932542994 -> 932544290 (<.01%)
cycles in affected programs: 8150758 -> 8152054 (0.02%)
helped: 15 / HURT: 17
fossil-db:
Lunar Lake, Meteor Lake, and DG2 had similar results. (Lunar Lake shown)
Totals:
Instrs: 142890605 -> 142890392 (-0.00%); split: -0.00%, +0.00%
Cycle count: 21655049536 -> 21654693720 (-0.00%); split: -0.00%, +0.00%
Totals from 181 (0.03% of 553251) affected shaders:
Instrs: 188022 -> 187809 (-0.11%); split: -0.12%, +0.01%
Cycle count: 85291658 -> 84935842 (-0.42%); split: -0.47%, +0.05%
Tiger Lake, Ice Lake, and Skylake had similar results. (Tiger Lake shown)
Totals:
Instrs: 154438050 -> 154436980 (-0.00%)
Cycle count: 15334650326 -> 15334644375 (-0.00%); split: -0.00%, +0.00%
Spill count: 56754 -> 56706 (-0.08%)
Fill count: 95919 -> 95808 (-0.12%)
Scratch Memory Size: 2306048 -> 2304000 (-0.09%)
Max live registers: 32469924 -> 32469899 (-0.00%)
Totals from 112 (0.02% of 642922) affected shaders:
Instrs: 156186 -> 155116 (-0.69%)
Cycle count: 11111478 -> 11105527 (-0.05%); split: -0.62%, +0.56%
Spill count: 1766 -> 1718 (-2.72%)
Fill count: 2815 -> 2704 (-3.94%)
Scratch Memory Size: 78848 -> 76800 (-2.60%)
Max live registers: 11526 -> 11501 (-0.22%)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29884>
Between 5 and 10 shaders (depending on the platform) from Blender are
massively helped for spills and fills (e.g., from 45 spills to 0, and
180 fills to 0).
Previously this commit cause a lot of spill and fill damage to
Wolfenstein Youngblood and Red Dead Redemption 2. I believe due to
!32041 and !32097, this is no longer the case. RDR2 is helped, and
Wolfenstein Youngblood has no changes.
However, q2rtx/q2rtx-rt-pipeline is hurt:
Spill count: 126 -> 175 (+38.89%); split: -0.79%, +39.68%
Fill count: 156 -> 235 (+50.64%); split: -1.92%, +52.56%
By the end of this series this damage is fixed, and q2rtx is helped
overall by -0.79% spills and -1.92% fills.
v2: Fix for Xe2.
v3: Just keep using bld for the group(1, 0) call. Suggested by Ken.
v4: Major re-write. Pass bld and xbld to fs_emit_memory_access. The big
fix is changing the way srcs[MEMORY_LOGICAL_ADDRESS] is calculated
(around line 7180). In previous versions of the commit, the address
would be calculated using bld (which is now xbld) even if the address
source was not is_scalar. This could cause the emit_uniformize (later in
the function) to fetch garbage. This also drops the special case
handling of constant offset. Constant propagation and algebraic will
handle this.
v5: Fix a subtle bug that was ultimately caused by the removal of
offset_to_component. The MEMORY_LOGICAL_ADDRESS for
load_shared_uniform_block_intel was being calculated as SIMD16 on LNL,
but the later emit_uniformize would treat it as SIMD32. This caused GPU
hangs in Assassin's Creed Valhalla.
v6: Fix a bug in D16 to D16U32 expansion. Noticed by Ken. Add a comment
explaining bld vs xbld vs ubld in fs_nir_emit_memory_access. Suggested
by Ken.
v7: Revert some of the v6 changes related to D16 to D16U32
expansion. This code was mostly correct. xbld is correct because DATA0
needs to be generated in size of the eventual SEND instruction. Using
offset(nir_src, xbld, c) will cause offset() to correctly added
component(..., 0) if nir_src.is_scalar but xbld is not scalar_group().
v8: nir_intrinsic_load_shared_uniform_block_intel was removed. This
caused reproducible hangs in Assassin's Creed: Valhalla. There are some
other compiler issues related to this game, and we're not yet sure
exactly what the cause of any of it is.
shader-db:
Lunar Lake
total instructions in shared programs: 18058270 -> 18068886 (0.06%)
instructions in affected programs: 5196846 -> 5207462 (0.20%)
helped: 4442 / HURT: 11416
total cycles in shared programs: 921324492 -> 919819398 (-0.16%)
cycles in affected programs: 733274162 -> 731769068 (-0.21%)
helped: 11312 / HURT: 31788
total spills in shared programs: 3633 -> 3585 (-1.32%)
spills in affected programs: 48 -> 0
helped: 5 / HURT: 0
total fills in shared programs: 2277 -> 2198 (-3.47%)
fills in affected programs: 79 -> 0
helped: 5 / HURT: 0
LOST: 123
GAINED: 377
Meteor Lake, DG2, and Tiger Lake had similar results. (Meteor Lake shown)
total instructions in shared programs: 19703458 -> 19699173 (-0.02%)
instructions in affected programs: 5885251 -> 5880966 (-0.07%)
helped: 4545 / HURT: 14971
total cycles in shared programs: 903497253 -> 902054570 (-0.16%)
cycles in affected programs: 691762248 -> 690319565 (-0.21%)
helped: 16412 / HURT: 28080
total spills in shared programs: 4894 -> 4646 (-5.07%)
spills in affected programs: 248 -> 0
helped: 7 / HURT: 0
total fills in shared programs: 6638 -> 5581 (-15.92%)
fills in affected programs: 1057 -> 0
helped: 7 / HURT: 0
LOST: 427
GAINED: 978
Ice Lake and Skylake had similar results. (Ice Lake shonw)
total instructions in shared programs: 20384200 -> 20384889 (<.01%)
instructions in affected programs: 5295084 -> 5295773 (0.01%)
helped: 5309 / HURT: 12564
total cycles in shared programs: 873002832 -> 872515246 (-0.06%)
cycles in affected programs: 463413458 -> 462925872 (-0.11%)
helped: 16079 / HURT: 13339
total spills in shared programs: 4552 -> 4373 (-3.93%)
spills in affected programs: 546 -> 367 (-32.78%)
helped: 11 / HURT: 0
total fills in shared programs: 5298 -> 4657 (-12.10%)
fills in affected programs: 1798 -> 1157 (-35.65%)
helped: 10 / HURT: 0
LOST: 380
GAINED: 925
fossil-db:
All Intel platforms had similar results. (Lunar Lake shown)
Totals:
Instrs: 141528822 -> 141728392 (+0.14%); split: -0.21%, +0.35%
Subgroup size: 10968048 -> 10968144 (+0.00%)
Send messages: 6567930 -> 6567909 (-0.00%)
Cycle count: 22165780202 -> 21624534624 (-2.44%); split: -3.09%, +0.65%
Spill count: 69890 -> 66665 (-4.61%); split: -5.06%, +0.44%
Fill count: 128331 -> 120189 (-6.34%); split: -7.44%, +1.09%
Scratch Memory Size: 5829632 -> 5664768 (-2.83%); split: -2.86%, +0.04%
Max live registers: 47928290 -> 47611371 (-0.66%); split: -0.71%, +0.05%
Totals from 364369 (66.18% of 550563) affected shaders:
Instrs: 113448842 -> 113648412 (+0.18%); split: -0.26%, +0.44%
Subgroup size: 7694080 -> 7694176 (+0.00%)
Send messages: 5308287 -> 5308266 (-0.00%)
Cycle count: 21885237842 -> 21343992264 (-2.47%); split: -3.13%, +0.65%
Spill count: 65152 -> 61927 (-4.95%); split: -5.42%, +0.47%
Fill count: 122811 -> 114669 (-6.63%); split: -7.77%, +1.14%
Scratch Memory Size: 5438464 -> 5273600 (-3.03%); split: -3.07%, +0.04%
Max live registers: 34355310 -> 34038391 (-0.92%); split: -1.00%, +0.07%
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29884>
No shader-db changes on any Intel platform.
fossil-db:
Lunar Lake, Meteor Lake, and DG2 had similar results. (Lunar Lake shown)
Totals:
Instrs: 141808595 -> 141808815 (+0.00%); split: -0.00%, +0.00%
Cycle count: 22181300418 -> 22185066952 (+0.02%); split: -0.01%, +0.03%
Max live registers: 48052077 -> 48052083 (+0.00%)
Totals from 720 (0.13% of 551446) affected shaders:
Instrs: 116778 -> 116998 (+0.19%); split: -0.01%, +0.20%
Cycle count: 1197931082 -> 1201697616 (+0.31%); split: -0.21%, +0.53%
Max live registers: 56552 -> 56558 (+0.01%)
No fossil-db changes on any other Intel platform.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29884>
No shader-db changes on any Intel platform.
v2: Fix for Xe2.
v3: Rework the way that we determine that an intrinsic can actually be
convergent. This will now depend on whether or not the important
sources have previously be determined to be convergent. Fixes
intermitent failures in some test cases (including
dEQP-VK.spirv_assembly.instruction.graphics.16bit_storage.push_constant_float_16_to_32.scalar_frag).
v4: s/the it/it/ in a comment. Noticed by Ken.
fossil-db:
No fossil-db changes on Lunar Lake.
Meteor Lake and DG2 had similar results. (Meteor Lake shown)
Totals:
Instrs: 152743449 -> 152743161 (-0.00%)
Cycle count: 17399179660 -> 17399193488 (+0.00%)
Totals from 144 (0.02% of 633314) affected shaders:
Instrs: 5936 -> 5648 (-4.85%)
Cycle count: 51616 -> 65444 (+26.79%)
Tiger Lake, Ice Lake, and Skylake had similar results. (Tiger Lake shown)
Totals:
Instrs: 150646195 -> 150645907 (-0.00%)
Cycle count: 15618427818 -> 15618428942 (+0.00%)
Totals from 144 (0.02% of 632567) affected shaders:
Instrs: 6218 -> 5930 (-4.63%)
Cycle count: 39968 -> 41092 (+2.81%)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29884>
This commit used to be "brw/emit: Allow scalar sources to 64-bit
3-source instructions". These instructions were fixed up in
brw_eu_emit. There seems to be some conflict with the <0,1,0> stride an
post-RA scheduling. The only difference between the passing code
generated by this commit and the failing code generated by the older
commit is some post-RA scheduling.
v2: Change the stride of a MAD even if the instruction isn't
lowered. MAD instructions that are already SIMD8 have to follow the same
rules. 🤦
v3: Pull the lowering out to its own pass. Update the comment in
brw_fs_validate. Suggested by Ken.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29884>
Sources that are scalars (almost all source) and convergent generally
want <0,1,0> source stride. Sources that are vectors (e.g., texture
coordinates, SSBO write data, etc.) and convergent want no extra strides
applied. In nearly all cases LOAD_PAYLOAD lowering will do the right
thing.
v2: Use VEC in emit_pixel_interpolater_send. Suggested by Ken.
v3: With the elimination of offset_to_component(), offset() may not
convert an is_scalar source to have a zero stride. Explicitly do this
in get_nir_src and prepare_alu_destination_and_sources.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29884>
In SIMD16 and SIMD32, storing convergent values in full 16- or
32-channel registers is wasteful. It wastes register space, and in most
cases on SIMD32, it wastes instructions. Our register allocator is not
clever enough to handle scalar allocations. It's fundamental unit of
allocation is SIMD8. Start treating convergent values as SIMD8.
Add a tracking bit in brw_reg to specify that a register represents a
convergent, scalar value. This has two implications:
1. All channels of the SIMD8 register must contain the same value. In
general, this means that writes to the register must be
force_writemask_all and exec_size = 8;
2. Reads of this register can (and should) use <0,1,0> stride. SIMD8
instructions that have restrictions on source stride can us <8,8,1>.
Values that are vectors (e.g., results of load_uniform or texture
operations) will be stored as multiple SIMD8 hardware registers.
v2: brw_fs_opt_copy_propagation_defs fix from Ken. Fix for Xe2.
v3: Eliminte offset_to_scalar(). Remove mention of vec4 backend in
brw_reg.h. Both suggested by Caio. The offset_to_scalar() change
necessitates some trickery in the fs_builder offset() function, but I
think this is an improvement overall. There is also some rework in
find_value_for_offset to account for the possibility that is_scalar
sources in LOAD_PAYLOAD might be <8;8,1> or <0;1,0>.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29884>
We only set buf_filled_size for the first target, but draws from non-zero
streams use buf_filled_size from other targets, so share the same
buf_filled_size buffer among all streamout targets because it contains
all 4 offsets.
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32713>
alpha-to-coverage must be applied before alpha-to-one. The only way to do
that is to export alpha for alpha-to-coverage via mrtz, and export 1 via
mrt0.a.
ACO and monolithic shader support is already in place thanks to RADV,
so we only need to change the LLVM PS epilog and the shader key.
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32713>
This adds kill_z and kill_stencil flags to the shader PS epilog key, which
removes those outputs if depth or stencil are disabled.
It must be implemented in:
* ACO PS epilog
* LLVM PS epilog
* ac_nir_lower_ps for monolithic shaders
Some of the samplemask code wasn't completely correct, but probably harmless.
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32713>
This will take effect after nir_opt_varyings is enabled by another MR, and
will fix existing shader compiler crashes thanks to better optimizations.
For example, one GLSL program that failed to compile and had 226 VS
instructions and 356 FS instructions in NIR will be reduced to 2 or 3
instructions per shader.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31942>
Regression on test:
dEQP-GLES31.functional.geometry_shading.basic.output_256
voffset is missing if buffer store base >=4096, we need to
re-calculate offen after resolve_excess_vmem_const_offset().
Fixes: cdaf269924 ("aco: inline store_vmem_mubuf/emit_single_mubuf_store")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32767>
CI tests are carried out in debian/x86_64_pyutils container which is using
python version 3.11 so use this version also for local testing.
This makes local testing more accurate. For example repeated double
quotes in f-formatted strings will raise an error in python 3.11 but not
in python 3.12.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32602>
Since run-pytest.sh uses the debian/x86_64_pyutils container, it's not
necessary to add an additional layer of isolation by creating a virtual
environment for run-pytest.sh.
So stop creating a venv when run-pytest is run in a container, but keep
the option of using a venv to run-pytest.sh locally.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32602>
Currently the update_traces_checksum script prints a label verification
request with a line that is 167 characters long.
Split the long line to make it more readable. Update the flake8
configuration to enforce a maximum line length of 159 characters to ensure
consistency.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32602>
Currently the ci scripts and tests don't have any linting checks. Add
.flake8 linting to start adding some consistency to the scripts. Ignore
most of the existing errors until they can be addressed on an individual
basis.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32602>
Currently, run-pytest.sh won't run locally outside of a pipeline
because it can't find the `setup-test-env.sh` which provides necessary
functions.
Add a default value for the SCRIPTS_DIR so that run-pytest can find and
run the setup-test-env.sh and be run locally outside of a pipeline.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32602>
Without this the game crashes during the loading screen.
The game uses vkUpdateDescriptorSetWithTemplate and, in certain cases,
passes VkDescriptorBufferInfo structures where the offset + range
exceeds the size of the buffer. This triggers an assertion when
vk_buffer_range() is called, causing the game to crash.
When the nvidia vendor id is used the range is consistently set to 65536.
Without it the range varies and is much smaller - never exceeding 1000.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12349
Cc: stable
Reviewed-by: Faith Ekstrand <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32764>
This can happen in decode context when application send no slice
buffers or in processing context with no processing buffers.
We need to avoid calling driver end_frame as no begin_frame will be
called in this case.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32677>
It's not valid to call RenderPicture and EndPicture without calling
BeginPicture or when BeginPicture fails. FFmpeg will however call
EndPicture when BeginPicture fails, so we need to handle this.
Use target_id, which is assigned in BeginPicture, as an indication
whether we are inside the Begin - End picture sequence.
Cc: mesa-stable
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32677>
the previous logic was busted with the sequence Dolphin emits:
BeginRender
BindIndex
Draw
EndRender
BeginRender
Draw without restart
Draw with restart
EndRender
the second control stream would not have any restart index emitted, since the
dirty flag is set only on Begin and Bind, and cleared on draw.
this was probably also broken in the similar case
BeginRender
BindIndex
Draw without restart
Draw with restart
EndRender
fixes Zelda: Wind Waker, Xeno Blade, etc.
thank you to pokechu22 for debug help!
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32759>
We were inconsistent over the usage of PAN_BIND_DEPTH_STENCIL, putting
it on some stencil only formats but not others. Apply it to all
stencil formats. However, we also need to change is_format_supported
to ignore S8_UINT (at least for GLES), because the hardware is a little
weird with that format and the gallium driver gets confused by it.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32462>
This is not supported by VCN.
We indicate this limitation by not reporting YUV420_12 RT format
supported for VP9, and not reporting YUV422 and YUV444 for AV1.
Most applications however simply ignore this, and will pick some other
format that is supported, which obviously won't work.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32663>
Draws were validated against an XFB primitive type from the last
glBeginTransformFeedback call, ignoring glResumeTransformFeedback that
may have been after it that may have resumed for a different primitive
type.
The spec doesn't state this explicitly, but it's logical.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32685>
The HW can do it, however if the state tracker sees support for ATI2N,
it will assume we also don't need a fallback for ATI1N. So if something
actually tries to use ATI1N format later, we will crash.
This could be fixed at the st level, but I honestly don't think the added
complexity is worth it, especially as this is highly r300 specific and
only affects single generation. So just disable it.
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/32639>
The running container jobs scripts S3_JWT_FILE needs to be removed on
exit because the resulting image is committed and we don't want the auth
token to leak permanently in the fs.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31093>
In order to build the mesa llvmpipe driver for Android, LLVM libraries
for Android are needed, but building them each time a new upstream mesa
is built would be too much overhead.
So add a script to build LLVM libraries for Android and call it from the
debian/android_build job. The actual build will be performed only when
necessary and the resulting artifact will be uploaded to the S3 bucket
to be re-used when building mesa for Android.
The build process follows what has been documented in
docs/drivers/llvmpipe.rst
Reviewed-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31093>
Unset the compiler env vars in debian/android_build.sh used to
cross-build libelf for Android, to prevents those env vars to
inadvertently affect subsequent commands that might want to build for
the native host after the cross-builds.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31093>
Set up "${S3_JWT_FILE}" also for container jobs, this can be useful in
case some jobs want to save something to S3.
Note that for container jobs setting the file /s3_swt in the
`default:before_script` section would not work: this wold be "too early"
because, when using ci-templates, the cbuild invocation switches the
root filesystem before executing FDO_DISTRIBUTION_EXEC, resulting in the
file becoming unavailable after the switch.
So set up the file exactly in FDO_DISTRIBUTION_EXEC, before launching
the actual container script.
Do this using a new trampoline script
.gitlab-ci/container/container_job_trampoline.sh so that in the future
other tasks common to all container jobs can be added there.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31093>
When the gantt chart service was first implemented, the read_token()
function would attempt to read from the default token file if the token
argument was missing.
Now it's necessary to call a separate function to look in the default
token file, so if the token argument is not provided, expressly call
get_token_from_default_dir().
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32637>
The gantt charts have a vertical line indicating the time when marge-bot
stops waiting for CI to finish. Currently the ci-timeout is hard-coded at
60 minutes. But marge-bot's timeout is configurable, so allow this value
to be configured as well.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32637>
If a job is still running when the gantt chart is generated, the job's
phases won't be represented as a bar on the chart.
To show these jobs on the gantt chart, introduce a new phase "In-Progress"
to capture the current status of these jobs. Rename the "Running" phase
as "Time spent running" to emphasize that the running phase is complete.
This provides a more complete picture of the pipeline jobs when CI times
out.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32637>
The gantt chart script currently expect the pipeline url to be the last
line of marge-bot's comment on a failed pipeline. The pipeline summary
hook now adds additional information that was preventing the gantt chart
script from finding the pipeline url.
Change the regex for finding the pipeline url to account for pipeline
summary comments.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32637>
Add a pipeline-id to the gantt filename so that the filename is unique.
Reduce the additional info provided in the gantt comments since the tool
is now more familiar to developers.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32637>
Currently the gantt chart script will post a comment to any project that
uses the default marge bot user id. Although the gantt chart is flexible
enough to work for any project, restrict it to mesa/mesa by default. Add
the --project-id option to add a custom project or list of projects to
analyze.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32637>
The gantt chart currently hard-codes the marge user id, but since the
script can be used for any marge-bot user, add an option to specify the
marge-bot user id. If no option is specified, the default marge-bot user
id is still used.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32637>
The SIMD splitting pass does not handle wide force_writemask_all
instructions correctly at the moment. For example, a SIMD32 TXF
on pre-Xe2 would get split to a pair of SIMD16. But it will set
the groups to operate on channels 15:0 and 31:16. That's not what
we want for a NoMask instruction - both should be 15:0, i.e.
bld.group(inst->exec_size, 0).
We could (and perhaps should) fix the SIMD splitting pass to handle
this, but the pass already has subtle complexity in which builders
are used. Or we could alter fs_builder::group(), but that has broader
implications. As a stop-gap, just make opt_combine_covergent_txfs stop
relying on SIMD splitting. It's trivial to do and fixes the issue
without risking other breakage.
Fixes: 6341b3cd87 ("brw: Combine convergent texture buffer fetches into fewer loads")
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32714>
The Wayland protocol defines INVALID as a special marker indicating
that implicit modifiers are supported. If the driver doesn't support
explicit modifiers and the compositor advertises support for implicit
modifiers, fallback to these.
This effectively restores logic removed in 4c06515892, but only
for the specific case of Wayland instead of affecting all APIs.
(Wayland is one of the few APIs defining a special meaning for
INVALID.)
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: 4c06515892 ("dri: revert INVALID modifier special-casing")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32535>
If we supply modifiers to dri_create_image_with_modifiers() and
the driver doesn't support them, the function will fail. We pass
__DRI_IMAGE_USE_LINEAR anyways so stripping the modifier is fine.
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: 4c06515892 ("dri: revert INVALID modifier special-casing")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32535>
If we supply modifiers to dri_create_image_with_modifiers() and
the driver doesn't support them, the function will fail. The X11
server always supports implicit modifiers so we can always fall
back to that.
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: 4c06515892 ("dri: revert INVALID modifier special-casing")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32535>
When updating an AFBC-packed resource, the size of the resulting
texture data can change while the BO and modifier stay the same. We
still need to update the texture descriptor in that situation so
that the size is properly reported. Having a smaller size than the
real one might cause artifacts as the GPU doesn't want to read past
the reported size.
A future (more foolproof) fix might involve having a hash key to
track the size of all slices independently, but this patch still
improves the situation and make sure we don't hit a relatively
common issue when using `PAN_MESA_DEBUG=forcepack`.
Fixes: bc55d150a9 ("panfrost: Add support for AFBC packing")
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32598>
Unigine Heaven crash on GFX8/9 when use aco:
heaven_x64: ../../amd/mesa/src/gallium/drivers/radeonsi/si_nir_lower_abi.c:813: lower_tex: Assertion `samp_index >= 0 && comp_index >= 0' failed.
GFX8/9 will clamp texture comparison value in si_nir_lower_abi,
but it has to be done after si_nir_lower_resource.
Fixes: ae933169 ("radeonsi: lower NIR resource srcs to descriptors last")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32694>
While we're here, refactor the logic to split out the mutable and
pre-mutable cases since they are now very different.
The special case for NV12 is now necessary to avoid test failures, but
it was always necessary and we didn't notice it before because tests
didn't specify a format list.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32615>
Right now the image layout depends on the format for the R8G8 special
case, but this is clearly wrong if we set the mutable bit because it
could be reinterpreted. Refactor how it's set to make it part of the
layout struct, rather than specified in the view.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32615>
We can get into a situation where the layer size for a given mip isn't
large enough to hold the pitch times the aligned height, i.e. the height
isn't aligned. This can happen even if the size is 4K aligned. The
hardware seems not to align the height for us, so we have to use the
MINLAYERSZ hammer.
This was found with a Vulkan test when enabling tiling for mutable
textures on a750, but it's also reproducable via
"bin/texelFetch fs sampler3D 76x76" using piglit.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32615>
Due to the slow startup time of deqp-vk, the previous default of
500 tests per group caused the jobs to run up to twice as slowly
compared to using a higher number of tests per group.
Increase the number of tests per group in the deqp-runner suite,
which allows decreasing the fraction.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32704>
A next patch will emit more instructions in video and copy queues
for Gfx 200 and newer but the current code only creates anv_async_submit
if device has aux_map.
Instead we can always create anv_async_submit and only submit it to
hardware if any instruction was emited.
Fixes: 86813c60a4 ("mi-builder: add read/write memory fencing support on Gfx20+")
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/32680>
This effectively reverts a70b197741 ("turnip: Force linear mode for
non-ubwc R8G8 formats"), except that in the meantime we added HIC
support without supporting R8G8 so we still have to force linear tiling
in that case. The previous commit is a better fix.
Tiled uncompressed images will be used for sparse residency support,
it's not valid to arbitarily not support sparse texturing on R8G8,
the blob does use a tiled uncompressed image in that case, and we will
have to also.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32619>
Stop relying on the submit BO list, which won't exist with the new
"VM_BIND" uAPI. Instead, create a separate list in generic code, only
when dumping is enabled. As a bonus this means that it should work on
virtio and kgsl too, and more code is removed from the kernel backend.
We need to use the generic fence wait introduced in the previous commit.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32165>
Contrary to what the comment said, kgsl and drm actually have very
similar semantics for fences. Add a common function to wait on a fence,
and embed the queue + fence directly instead of a syncobj abstraction
that doesn't actually gain us much. This common fence wait function will
also be helpful for making more code generic.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32165>
Each driver implemented the Vulkan runtime submit callback itself, which
resulted in a lot of duplicated code to iterate through the command
buffers and gather the list of IBs to execute, deal with autotune and
command buffers with suspending/resuming dynamic renderpasses, etc. This
has been getting steadliy worse and was only going to get worse with
sparse, since to implement sparse bind submissions we have to similarly
traverse and flatten an array of bind structures.
Borrow an idea from nvk, and add an abstraction of a "submit" object
which holds a (dynamically growing) list of pending commands to submit.
We add kernel-specific functions to create a submit, add commands to it,
and finally submit it. For sparse, we will add additional an additional
function that adds a sparse bind and then we will parse the Vulkan
structures in common code. For now, we move various misc.
driver-independent parts of the submission path into a common
tu_queue_submit() that calls into the new abstractions.
In the future, if we need to add driver-internal syncobjs to the
user-provided ones, we could use the same approach with waits and
signals. For now we provide them as part of the submit function.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32165>
Because most pool-allocations happens during rendering, we have the same
issue as in the previous commit; we don't have a good way to report
the out-of-memory error here. So we do one of two things; we either
return a NULL-ish pointer, or we print an error and ignore the call.
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32428>
When allocations fail, we can end up with NULL-batches. This means we
can't really do much, so let's bail what we're trying to do here.
Unfortunately, we can't always report this up to the call-site easily,
because some pipe_context functions don't allows us to return a
pipe_error value. So in those cases, make let's just return log an error
and return as if nothing happened. It's not great, but there's nothing
super obvious to do here.
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32428>
There's more than one error-path out of cs_alloc_ins_block(), but only
one of them got the discar_instr_slot treatment. Instead of plugging
this in one more time, let's move this handling up to cs_alloc_ins(),
where we can easily whack two birds with one stone. This makes us
consistently return NULL on error here.
At the same time, we need to patch up cs_flush_block_instrs() here,
because we don't actually set the buffer invalid here. So let's
check for NULL here instead, which is the new contract.
Fixes: 0e6aaab00a ("pan/cs: add block to handle registers backup in exception handler")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Tested-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32428>
Cross-invocation TCS input access doesn't prevent same-invocation access.
This improves shaders that use both for the same inputs.
Also, if some components of a vec4 slot only use same-invocation access and
other components only use cross-invocation access (it's possible after
compaction), this takes the VGPR path for the components with
same-invocation access, which didn't happen previously because all masks
only describe whole vec4s.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31673>
Both can be used. Cross-invocation access can read it from LDS, while
same-invocation access can read it from VGPRs.
The entrypoints of the passes don't allow that flexibility yet,
but the logic inside the pass allows it.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31673>
We're parsing the descriptors here to read the size of the resource, but
what the HW wants and imageSize() wants is not the same. So let's fix up
the result for imageSize(), by dividing the result by 6.
If we change the descriptor instead, we end up failing shader-image
reads and writes instead.
I also looked for some unused bits in the descriptor that I could use
instead, but unfortunately there's only a few bits free here - not
enough for our needs.
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32612>
Previous code was assuming that load_sample_id loaded the hardware
sample ID register, which is 32 when sample shading is disabled. The
expectation was that we would read (0.5,0.5) from sample_positions[32].
Because the top 3 bits of the sample ID register are masked out in
bi_load_sample_id_to, we were instead reading the position of the first
sample.
This doesn't affect OpenGL, because opengl never uses
nir_load_sample_pos when sample shading is disabled.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Fixes: 60146cc57c ("panvk: implement sampleRateShading")
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32601>
The CI_JOB_TIMEOUT variable is the GitLab-defined job timeout in
seconds.
Use this variable in LAVA instead of the separate JOB_TIMEOUT,
which was intended to represent the test phase timeout (job timeout
minus 5 minutes), but was often overlooked.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32609>
At the moment, we're not initializing the base_{instance,vertex} sysvals
which we'll need to do if we want to support shader draw parameters. It
turns out even without shader draw parameters enabled, some shaders need
a valid base_instance value, so this alone should fix a few tests.
On CSF hardware, we have a way to pass a non-zero base instance that's
propagated to the instance ID, but this messes with instance divisors,
so instead of using the native base instance feature, we force it to
zero, pass the base instance through an FAU sysval, and let
panvk_lower_load_vs_input() do the lowering for vertex attribute loads.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32039>
load_attribute_pan is a panfrost-specific intrinsic for loading
vertex attributes. Takes explicit vertex and instance IDs which
we need in order to implement vertex attribute divisor with
non-zero base instance on v9+.
Passes which are used by panvk are modified to be aware of
load_attribute_pan.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32039>
Due to the slow startup time of deqp-vk, the previous default of
500 tests per group caused the jobs to run up to twice as slowly
compared to using a higher number of tests per group.
Increase the number of tests per group for all subsets of the
deqp-runner suites, which allows decreasing the fractions.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32681>
Due to the slow startup time of deqp-vk, the previous default of
500 tests per group caused the jobs to run up to twice as slowly
compared to using a higher number of tests per group.
Increase the number of tests per group for all subsets of the
deqp-runner suites, which allows decreasing the fractions.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32681>
Due to the slow startup time of deqp-vk, the previous default of
500 tests per group caused the jobs to run up to twice as slowly
compared to using a higher number of tests per group.
Increase the number of tests per group for all subsets of the
deqp-runner suites, which allows decreasing the fractions.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32681>
Flush and process trace events on queue submit when tracing is enabled
and timestamp_frequency is valid. Tracing can be enabled with, for
example, MESA_GPU_TRACES=print.
panvk_utrace_flush_data is allocated on queue submit and is freed after
all trace events associated with the queue submit are processed. It is
used for synchronize gpu timestamp writes and trace event processing.
It also specifies the subqueue the trace events belong to.
For the moment, cmdbufs without
VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT are silently ignored.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32360>
There is one u_trace per subqueue to record trace events. When tracing
is enabled, trace_begin_cmdbuf and trace_end_cmdbuf will emit trace
events to u_trace and emit timestamp writes to the command streams.
The trace events are buffered in u_trace and are not flushed for
processing yet.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32360>
Improve the documentation about building the llvmpipe driver for Android
by providing more ready-to-use scripts to build llvm and create the
needed meson wrap file.
Note: in the meson wrap file, remove 'libLLVMTableGenGlobalISel' from
the built dependencies, as apparently is not available anymore for
Android on recent LLVM versions.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32251>
The build of libgallium has been simplified for Android where the
versioned library is not used since it's not really needed.
Update the documentation and the proposed Android.bp files to only refer
to libgallium_dri.so
While at it also fix the proposed SELinux rules to use the correct path
for libglapi which is not under /vendor/lib(64)?/egl/
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32251>
Last VGT stages (VS, TES or GS) can always be used with a null FS when
nextStage is non-zero. Like if a VS is created with nextStage=TCS, it's
also allowed to draw without binding a CTS (ie. nextStage=None is always
a valid case).
Because we don't want to compile two variants for NONE and FRAGMENT,
let's compile only the FRAGMENT one when necessary.
Fixes new CTS coverage, see https://gerrit.khronos.org/c/vk-gl-cts/+/15976.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32665>
Modified the BVH dumping mechanism to synchronously wait for the command
buffer to complete before saving BVH data to files. This approach is
more robust compared to the previous method of dumping during
acceleration strucutre destruction.
Note: if DEBUG_BVH_ANY is enabled but intel-rt is disabled, we will wait
for nothing.
Signed-off-by: Kevin Chuang <kaiwenjon23@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32585>
Supporting Vulkan 1.1 was premature, as we don't support subgroup
operations, which are actually required (even if it's not listed in
section "46.1. Feature Requirements"):
Here's the relevant phrasing from the Vulkan 1.1 spec:
> subgroupSupportedOperations will have the VK_SUBGROUP_FEATURE_BASIC_BIT
> bit set if any of the physical device’s queues support
> VK_QUEUE_GRAPHICS_BIT or VK_QUEUE_COMPUTE_BIT.
So, it seems we have to support at least the basic feature set before we
can expose Vulkan 1.1. So let's back out of that for now.
Fixes: a6e03ce428 ("panvk: advertise version 1.1 support")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32654>
We are conditionally updating the push-sets, so we need to also
conditionally clear the dirty-flags here instead of clearing them
wholesale. Otherwise, we end up not updating the descriptors that are
used in subsequent draws, but not in the first one.
Fixes: 79e5146378 ("panvk: Sanitize the driver-internal dirty state tracking")
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32630>
\[WHY\]
The reason for making these changes is to address the defects identified
by the Coverity scan. By fixing these defects, we can ensure that any
future defects generated by our own code changes can be easily
identified and resolved.
\[HOW\]
To implement the changes/fixes, the following steps were taken:
1. CHECKED_RETURN: All cases were aligned to check the return value.
2. DC.WEAK_CRYPTO: The use of rand() to generate random numbers was
replaced with a more secure method using platofrm API.
3. DEADCODE: Useless code that always returned true was removed.
4. DIVIDE_BY_ZERO: A check was added to ensure that the divisor is not
zero before performing division.
5. HFA: An unused header was removed.
6. MISSING_BREAK: A break statement was added in switch cases where it
was missing.
7. PASS_BY_VALUE: Parameters that were being passed by value and were
too big were changed to pass by reference.
\[TESTING\]
What testings have been done (test IDs and json file):
Reviewed-by: Tomson Chang <Tomson.Chang@amd.com>
Signed-off-by: Min-Hsuan You <Min-Hsuan.You@amd.com>
Acked-by: Chenyu Chen <Chen-Yu.Chen@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32646>
\[WHY\]
System event logs are different than string logging. They are meant to
generate light weight events with ID and variable args and can be
coalesced with events generated by other IP components.
\[HOW\]
Add a callback function, which is implemented by the client (Like PAL)
VPELIB adds defines for a list of possible event IDs
The client is expected to handle the callback
And translate and emit the event through
native system infrastructure like ETW logging.
\[TESTING\]
Tested on system that triggers sys event, and viewed the event through
ETW viewer
Signed-off-by : Anthony Koo <anthony.koo@amd.com>
Reviewed-by: Roy Chan <Roy.Chan@amd.com>
Acked-by: Chenyu Chen <Chen-Yu.Chen@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32646>
ACO is still not perfect:
* It generates s_wait_loadcnt 0x0-0x3 when the only required wait instruction
is s_wait_loadcnt 0x5.
* It generates a lot of unnecessary jumps and blocks for uniform loop breaks.
Only scc1 jumps are necessary to break the loop. This is 10x better than
LLVM, but even ACO might consider using nir_intrinsic_ordered_add_loop_gfx12_amd
for the best performance.
How to print the streamout asm on any GPU:
PIGLIT_PLATFORM=gbm AMD_FORCE_FAMILY=gfx12_16pipe AMD_DEBUG=vs,mono,asm,useaco ../piglit/bin/shader-io-rate vs_out_xfb
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32570>
With the introduction of the slab allocator, most of our small
allocations now hit that rather than directly hitting the bucket
cache. Those now show up as 2MB slab allocations from the cache's
perspective. So, we don't need quite as many buckets. (Note that
only allocations in IRIS_MEMZONE_OTHER are suballocated today.)
Previously, we had 55 buckets, going from 4KB to 112MB, with sizes
N, N+1/4, N+1/2, N+3/4 for a series of power-of-two N's.
This patch prunes it down to 25 buckets:
- 4K-4MB => power-of-two sizes only
- 6MB => a one-off bucket to reduce waste between 4MB and 8MB
- 8MB+ => the usual N, N+1/4, N+1/2, N+3/4 system
- 64MB => the largest bucket size
In particular, this eliminates the 1.75MB, 2.5MB, 3MB, 3.5MB, and 7MB
buckets in favor of multiples of 2MB. Allocating multiples of 2MB is
preferable because it allows the kernel to allocate 64KB pages rather
than being stuck using inefficient 4K pages. And, the amount of waste
from bumping to the next multiple of 2MB isn't huge in that range of
sizes. We also eliminate buckets larger than 64MB because they're
rarely used, and also the amount of waste from rounding up to the
80/96/112MB buckets can get pretty large.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Fixes: 0b6693a3a1 ("iris: Align fresh BO allocations to 2MB in size")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10219
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32635>
Currently the python-test job runs pytest and then creates python
related artifacts for use by other jobs. But the python-test job isn't
triggered by changes to the python scripts and libraries. Instead, changes
to python scripts and libraries can currently be merged without running
pytest and, if they do generate errors, they will only appear in ci
later when trying to generate the python artifacts.
Add pytest to the existing linting jobs and expand the rules so that it
will be triggered by changes to python scripts and libraries. Remove
pytest from the job that creates artifacts. This will ensure that the
artifacts are still valid while catching script/library errors before they
are merged.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32340>
Currently the yaml-toml-shell-test extends the python-test job to make
use of the python packages available there. But the python-test also
generates artifacts which yaml-toml-shell-test does not need to do.
Instead of extending the python-test job, avoid extra work by just using
the pyutils container directly.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32340>
The current python-test job creates and compresses python related
artifacts for use by future jobs. The artifacts are currently named
`mesa-python-test` which is somewhat misleading because they are not
needed for testing python scripts or libraries.
Rename the artifacts generated by the python-test job to be more
descriptive of their purpose.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32340>
The debian/x86_64_pyutils job incorporates references to rules from the
python-test and .container jobs, but currently these jobs don't have any
express rules. The .container job does extend jobs that have rules, but
these same rules are already included in debian/x86_64 because it
extends the .debian-container job.
Remove these empty rule references to make debian/x86_64_pyutils more
readable.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32340>
This should not do any conversions and instead return error when image
and surface formats don't match.
There was also special case for I420 fourcc which would swap the order
of U/V planes and because of this the plane order of IYUV format was
incorrectly set to YVU in vl_video_buffer.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32605>
Due to the slow startup time of deqp-vk, the previous default of
500 tests per group caused the jobs to run up to twice as slowly
compared to using a higher number of tests per group.
Increase the number of tests per group for all subsets of the
deqp-runner suites, which allows decreasing the fractions.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32588>
Due to the slow startup time of deqp-vk, the previous default of
500 tests per group caused the jobs to run up to twice as slowly
compared to using a higher number of tests per group.
Increase the number of tests per group for all subsets of the
deqp-runner suites, which allows decreasing the fractions.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32588>
Due to the slow startup time of deqp-vk, the previous default of
500 tests per group caused the jobs to run up to twice as slowly
compared to using a higher number of tests per group.
Increase the number of tests per group for all subsets of the
deqp-runner suites, which allows decreasing the fractions.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32588>
When I last updated this, some of the jobs had too many tests that took
over 30 seconds to show them all in the output. So I only added the
longest ones. Here's the rest, and with this the skip-list seems correct
for now.
Note that there's a few tests that takes close to 30 seconds, so they
might end up getting pushed across the limit from time to time as well.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32603>
While these timeout when I run them locally,
MESA_VK_ABORT_ON_DEVICE_LOSS ends up turning them into crashes on the
CI. Correct this, so we don't accidentally fail the full job here.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32603>
According to HSD 14016252163 if compute shader uses the sample
operation, morton walk order and set the thread group batch size to 4 is
expected to increase sampler cache hit rates by increasing sample
address locality within a subslice.
Rework:
* Caio: "||" => "&&" for type checking in instr_uses_sampler()
* Jordan: Use nir's foreach macros rather than
nir_shader_lower_instructions()
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-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/32430>
SEND instructions of gather variant will use the upcoming ARF scalar
register. They use only Src0 and reuse the bits of Src1.Length (part of
ex_desc). Src1.Length is (implicitly) defined as 0.
Adapt the helper functions to take the new variant into account when
manipulating ex_desc.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32236>
It's allowed to place OpExecuteCallableKHR in a SPIR-V, even if the RT
pipeline doesn't contain any callable shaders. Unreal hits this case and
crashes. We can assume the intrinsic never gets executed, so we can
simply remove it.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32613>
There are a lot of restrictions for bfloat16. The one that prevents this
very useful optimization from being possible is, "Broadcast of bfloat16
scalar is not supported."
Part of the reason this MR exists is to build up to implementing BF
support, and there are a couple more commits that implement
this. However, it fails on both real hardware and simulation:
Instruction is: mad (8|M0) r6.0<1>:f 0xBF80:bf r2.0<8;1>:f r64.0<0>:f
In bfloat/float mixed mode, bfloat src must be packed.
Alas.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32436>
These can't mix with F values, but if the non-constant sources are
already HF, this is allowed in src0.
No shader-db changes on any Intel platform.
fossil-db:
Ice Lake
Totals:
Instrs: 236027458 -> 236027442 (-0.00%)
Cycle count: 24515944704 -> 24515945379 (+0.00%)
Totals from 8 (0.00% of 798454) affected shaders:
Instrs: 10226 -> 10210 (-0.16%)
Cycle count: 58567 -> 59242 (+1.15%)
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32436>
Nothing can generate this currently, but a future commit will.
The Bspec and experimentation support the following limitations:
- Gfx11: Either src0 or src2 can be W or UW.
- Gfx12: Either src0 or src2 can be W or UW.
- Gfx12.5: Both src0 and src2 can be W or UW.
- Gfx20: Both src0 and src2 can be W or UW.
v2: Add missing break statement.
v3: Leave the MAD handling in the case with the other 3 source
instructions. Suggested by Caio.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32436>
v2: Move the full constant folding part to
brw_constant_fold_instruction. Suggested by Caio. I did this by
extracting the core part of the folding to a helper function.
v3: Delete stale comment. Noticed by Caio.
shader-db:
All Intel platforms had similar results. (Lunar Lake shown)
total instructions in shared programs: 18090847 -> 18090843 (<.01%)
instructions in affected programs: 150 -> 146 (-2.67%)
helped: 1 / HURT: 0
total cycles in shared programs: 919664648 -> 919663210 (<.01%)
cycles in affected programs: 3426 -> 1988 (-41.97%)
helped: 1 / HURT: 0
LOST: 1
GAINED: 0
fossil-db:
All Intel platforms had similar results. (Lunar Lake shown)
Totals:
Instrs: 220496486 -> 220496403 (-0.00%)
Cycle count: 31610880908 -> 31610879044 (-0.00%); split: -0.00%, +0.00%
Totals from 70 (0.01% of 702439) affected shaders:
Instrs: 47018 -> 46935 (-0.18%)
Cycle count: 6335504 -> 6333640 (-0.03%); split: -0.11%, +0.09%
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32436>
This enables constant combining to do its job.
v2: Restore accidentally deleted line from a comment. Noticed by Caio.
shader-db:
All Intel platforms had similar results. (Lunar Lake shown)
total cycles in shared programs: 919668392 -> 919669310 (<.01%)
cycles in affected programs: 10125264 -> 10126182 (<.01%)
helped: 348 / HURT: 194
fossil-db:
All Intel platforms had similar results. (Lunar Lake shown)
Totals:
Cycle count: 31610720660 -> 31610692748 (-0.00%); split: -0.00%, +0.00%
Totals from 9066 (1.29% of 702433) affected shaders:
Cycle count: 810411934 -> 810384022 (-0.00%); split: -0.01%, +0.00%
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32436>
No shader-db changes on any Intel platform.
fossil-db:
Meteor Lake, DG2, Tiger Lake, and Ice Lake had similar results. (Meteor Lake shown)
Totals:
Cycle count: 25096109024 -> 25096108722 (-0.00%); split: -0.00%, +0.00%
Totals from 4106 (0.51% of 797610) affected shaders:
Cycle count: 63266176 -> 63265874 (-0.00%); split: -0.01%, +0.01%
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32436>
Always propagate into any source. Let commute_immedates and constant
combining sort out the mess. It's literally their job.
No shader-db changes on any Intel platform. The fossil-db changes just
appear to be subtle changes in register allocation if the immediate
source changes from src0 to src2.
v2: Update the comment in commute_immediates. Suggested by Caio.
fossil-db:
Lunar Lake, Meteor Lake, and DG2 had similar results. (Lunar Lake shown)
Totals:
Cycle count: 31610720510 -> 31610720660 (+0.00%); split: -0.00%, +0.00%
Totals from 8 (0.00% of 702433) affected shaders:
Cycle count: 5522382 -> 5522532 (+0.00%); split: -0.00%, +0.00%
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32436>
No shader-db or fossil-db changes on any Intel platform. This commit
just prevents issues with a later commit, "brw/copy: Don't try to be
clever about ADD3 constant propagation."
v2: Use 'can_promote = true; break;' instead of 'return
true;'. Suggested by Caio.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32436>
Fold the cases where one of the sources is zero or two of the sources
are constants. Both case will result in a regular ADD.
No shader-db or fossil-db changes on any Intel platform. This commit
just prevents issues with a later commit, "brw/copy: Don't try to be
clever about ADD3 constant propagation."
v2: Move the full constant folding part to
brw_constant_fold_instruction. Suggested by Caio.
v3: Eliminate the impossible src.file == BAD_FILE case in
brw_fs_opt_algebraic. Suggested by Caio.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32436>
The current assertion fails as soon as a MAD with src0 and src2 being
immediate is detected.
The assertion was supposted to catch, "If it's ADD3, only one of src0
and src2 can be immediate." The detect this, the opcode test should have
been !=.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Fixes: c1c09e3c4a ("brw/emit: Add correct 3-source instruction assertions for each platform")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32436>
Some callers of brw_constant_fold_instruction depend on the result being
a MOV of immediate when progress is made. Previously `MUL dst:D src0:D
1:D` would be converted to `MOV dst:D src0:D`. There was also no
handling for `MUL dst:D imm0:D imm1:D`.
This could cause problems if one of the immedate values was -1. The
existing code would convert this to a `MOV dst:D imm0:D` and set the
negate flag on src0. That is not correct.
v2: Fix the is_negative_one case handling of the non-negative-one
source. Add a comment explaining the assertion. Both suggested by Caio.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Fixes: 2cc1575a31 ("brw/algebraic: Refactor constant folding out of brw_fs_opt_algebraic")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32436>
Some callers of brw_constant_fold_instruction depend on the result being
a MOV of immediate when progress is made. Previously `ADD dst:D src0:D
0:D` would be converted to `MOV dst:D src0:D`. There was also no
handling for `ADD dst:D imm0:D imm1:D`.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Fixes: 2cc1575a31 ("brw/algebraic: Refactor constant folding out of brw_fs_opt_algebraic")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32436>
so we can use designated initializers and other fun features.
all affected shaders are in gfxbench:
total instructions in shared programs: 2750549 -> 2750497 (<.01%)
instructions in affected programs: 10832 -> 10780 (-0.48%)
helped: 4
HURT: 2
Inconclusive result (value mean confidence interval includes 0).
total alu in shared programs: 2278478 -> 2278760 (0.01%)
alu in affected programs: 7040 -> 7322 (4.01%)
helped: 2
HURT: 4
Alu are HURT.
total fscib in shared programs: 2276985 -> 2277267 (0.01%)
fscib in affected programs: 7040 -> 7322 (4.01%)
helped: 2
HURT: 4
Fscib are HURT.
total bytes in shared programs: 19922466 -> 19922734 (<.01%)
bytes in affected programs: 71412 -> 71680 (0.38%)
helped: 4
HURT: 2
Inconclusive result (value mean confidence interval includes 0).
total regs in shared programs: 865070 -> 865086 (<.01%)
regs in affected programs: 142 -> 158 (11.27%)
helped: 0
HURT: 2
total uniforms in shared programs: 2120930 -> 2121034 (<.01%)
uniforms in affected programs: 244 -> 348 (42.62%)
helped: 0
HURT: 2
total scratch in shared programs: 11576 -> 11600 (0.21%)
scratch in affected programs: 2744 -> 2768 (0.87%)
helped: 0
HURT: 2
total spills in shared programs: 958 -> 868 (-9.39%)
spills in affected programs: 958 -> 868 (-9.39%)
helped: 6
HURT: 0
total fills in shared programs: 732 -> 626 (-14.48%)
fills in affected programs: 732 -> 626 (-14.48%)
helped: 4
HURT: 2
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32529>
In this case, num_sources is bigger than this->sources, so if we loop
up to num_sources (instead of this->sources) we'll end up reading past
the end of old_src[]. Only copy up to what we originally had.
This was found by code inspection, I'm not aware of any applications
failing due to the lack of this patch.
Fixes: d9e737212d ("intel/brw: Add a src array for the common case in fs_inst")
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32600>
We already have and use vk_warn_non_conformant_implementation(), so
we're already being clear that PanVK is not yet conformant. Let's not
repeat that information here, and instead focus on it not being
well-tested.
This brings the wording more or less in-line with NVK.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32561>
This is beneficial to applications that rely on
the implicit primitive ID from VS.
- We don't have to disable provoking vertex reuse,
which results in more efficient vertex processing.
- There is no LDS access needed to export the primitive ID,
because it is already available to GS threads.
- As a consequence of not needing LDS, we can use this
together with NGG passthrough mode.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32270>
This configuration will be enabled in RADV in a subsequent commit.
On GFX10.3:
Do this together with the primitive export, to avoid adding extra
CF, and to ensure optimal access of the export space.
On GFX11:
It's not an export but a memory store instruction, so always do
it earlier and ensure the optimal attribute ring access pattern.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32270>
It doesn't do anything useful for other stages.
In VS, we use this when the implicit primitive ID is needed,
so that we can export that as a per-vertex attribute of the
provoking vertex.
In TES, the patch ID (which is used as the primitive ID) is
already a per-vertex input VGPR, so it doesn't make sense to
configure this.
In GS, the primitive ID is explicitly written by the shader,
so it makes no sense to disable provoking vertex reuse in the
input.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32270>
Borderlands 3 (both DX11 and DX12 renderers) have a common pattern
across many shaders:
con 32x4 %510 = (uint32)txf %2 (handle), %1191 (0x10) (coord), %1 (0x0) (lod), 0 (texture)
con 32x4 %512 = (uint32)txf %2 (handle), %1511 (0x11) (coord), %1 (0x0) (lod), 0 (texture)
...
con 32x4 %550 = (uint32)txf %2 (handle), %1549 (0x25) (coord), %1 (0x0) (lod), 0 (texture)
con 32x4 %552 = (uint32)txf %2 (handle), %1551 (0x26) (coord), %1 (0x0) (lod), 0 (texture)
A single basic block contains piles of texelFetches from a 1D buffer
texture, with constant coordinates. In most cases, only the .x channel
of the result is read. So we have something on the order of 28 sampler
messages, each asking for...a single uint32_t scalar value. Because our
sampler doesn't have any support for convergent block loads (like the
untyped LSC transpose messages for SSBOs)...this means we were emitting
SIMD8/16 (or SIMD16/32 on Xe2) sampler messages for every single scalar,
replicating what's effectively a SIMD1 value to the entire register.
This is hugely wasteful, both in terms of register pressure, and also in
back-and-forth sending and receiving memory messages.
The good news is we can take advantage of our explicit SIMD model to
handle this more efficiently. This patch adds a new optimization pass
that detects a series of SHADER_OPCODE_TXF_LOGICAL, in the same basic
block, with constant offsets, from the same texture. It constructs a
new divergent coordinate where each channel is one of the constants
(i.e <10, 11, 12, ..., 26> in the above example). It issues a new
NoMask divergent texel fetch which loads N useful channels in one go,
and replaces the rest with expansion MOVs that splat the SIMD1 result
back to the full SIMD width. (These get copy propagated away.)
We can pick the SIMD size of the load independently of the native shader
width as well. On Xe2, those 28 convergent loads become a single SIMD32
ld message. On earlier hardware, we use 2 SIMD16 messages. Or we can
use a smaller size when there aren't many to combine.
In fossil-db, this cuts 27% of send messages in affected shaders, 3-6%
of cycles, 2-3% of instructions, and 8-12% of live registers. On A770,
this improves performance of Borderlands 3 by roughly 2.5-3.5%.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32573>
On a single runner, this job currently times out due to taking over 5
hours. The estimate from dEQP runner itself suggests a full run might
take over 8 hours with the current configuration. We can't really work
with that long runs, even if they are manual.
We currently have 7 vim3 runners, so we can actually afford to
parallelize the run a bit, to make this a bit more manageable. If we
choose 4, we take up a bit more than half of the runners, but we leave
two runners (plus a spare) for the pre-merge CI.
With this, a each job takes about 2.5 hours. We leave the timeout at 3
hours for now, to have some headroom for new tests being enabled.
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32591>
We know we have a broken Vulkan driver, so it's debatable whether it's
a broken Vulkan 1.0 or broken 1.1. Advertising 1.1 lets us run more
tests, and this patch does this. We also bump the instance version id
to 1.4, which seems appropriate since the overall Vulkan infrastructure
within Mesa is at that level.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32464>
In preparation for supporting sad (which like mad may benefit from
swapping some of it srcs), extract the swapping from
try_swap_mad_two_srcs so that it can be reused for sad. This is
necessary since, unlike mad, sad might also benefit from swapping srcs
1->2 (instead of only 2->1) or 3->2.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32501>
We would mark mad srcs as swapped once we tried swapping them, even if
it would not succeed. However, it might happen (especially after running
ir3_shared_folding) that a new opportunity for swapping comes up later.
Therefore, we should only mark the srcs as swapped when it actually
succeeded.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32501>
Turns out that sad is just iadd3. I assume it's an acronym for "Sum of
Absolute Differences" which may make sense since its 2nd src supports
(neg) which would allow SAD to be implemented using this instruction.
NIR already supports algebraic patterns for selecting iadd3 so adding
codegen support in ir3 is trivial. However, sad seems to have the same
hardware limitation as mad and doesn't support the scalar ALU so we have
to make sure to disable it when emitting iadd3.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32501>
The override used for the immed encoding in #cat3-src-const-or-immed
used a pattern which isn't supported in overrides by isaspec. The
pattern in the base bitset (10) was too strict for immediates since it
didn't allow the most significant bit to be 1.
Fix this by making the base pattern 1 and adding an assert for the next
bit to be 0 in the non-immed case.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: 1c6c200c0d ("ir3: add newly found shlg.b16 instruction")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32549>
When a timestamped present is not used (MAILBOX or the very first present),
it's possible that the very last queued present ID won't complete in finite time.
Similar to frame callback based workaround, apply a timeout to present
waits when they target the very last submitted presentID.
Only apply the workaround when we're not guaranteed forward progress.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Cc: mesa-stable
Reviewed-by: Autumn Ashton <misyl@froggi.es>
Reviewed-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32556>
When commit-timing was not supported, but FIFO was we would end
up in a situation with throttling on FIFO barrier and legacy fence.
At that point, the entire point of FIFO falls flat.
There are some caveats with this approach, but it's not expected
that compositors will only support FIFO, and not commit-timing long
term.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Fixes: c26ab1aee1 ("vulkan/wsi/wayland: Pace frames with commit-timing-v1")
Reviewed-by: Autumn Ashton <misyl@froggi.es>
Reviewed-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32556>
On AMD hardware, it's possible to export a separate alpha channel for
applying alpha-to-one after alpha-to-coverage and not before.
On GFX11+, it's already mostly supported but alpha needs to be exported
to MRTZ.a and one to MRT0.a. The hw always uses alpha for
alpha-to-coverage from MRTZ.a.
On older generations, the driver needs the same separate alpha export
but it also needs to configure the hardware with COVERAGE_TO_MASK_ENABLE
which selects alpha from MRTZ.a.
This should fix alpha-to-coverage with alpha-to-one when either
depth, stencil or samplemask are exported but it still needs a slightly
different solution without MRTZ. I will fix that later.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32523>
It's just completely broken if alpha-to-coverage is also used. Given
this is a requirement for Zink and no known GL apps are affected, let's
disable for everything except Zink. This is going to be fixed but the
fixes aren't small enough for backporting.
This fixes a rendering issue with XPlane 12.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32576>
llvmpipe_resource_map() may fail, e.g. when the DMA-BUF cannot be
mmap'ed. Handle the error, either by returning NULL or by asserting.
Asserting is done in places where there is no good way to bubble up
the error (and is done in other places already, e.g. in
init_scene_texture).
Signed-off-by: Simon Ser <contact@emersion.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32537>
Seems like the multiview feature unlocked some tests that triggers a
previously unknown bug. This results in an assert triggering, but that
reveals a real, underlying issue.
A few of these doesn't trigger the assert, but still fails due to a GPU
hang.
Let's mark all of these as failures, to avoid holding back other MRs in
the mean time.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32574>
Rather than checking hwconfig items when using them, wait until after
devinfo has been fully initialized. This includes having workarounds
implemented.
We can then check if the hwconfig data and final Mesa initialization
agree. If the match fails, we need to investigate if Mesa or the
hwconfig data is wrong.
This code becomes a no-op when not on a release build.
Fixes: a4c5bfd34c ("intel/dev: Use hwconfig for urb min/max entry values")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12141
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32359>
We already have all the bits wired up to support both
VK_FORMAT_A4R4G4B4_UNORM_PACK16 and VK_FORMAT_A4B4G4R4_UNORM_PACK16_EXT
from VK_EXT_4444_formats, and were already setting the feature-flags for
them.
Let's also expose the extension, which should just work.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32083>
We were missing a couple of 4-bit formats, let's add them.
Vulkan 1.0 already requires VK_FORMAT_B4G4R4A4_UNORM_PACK16, which mapes
to PIPE_FORMAT_A4R4G4B4_UNORM, which we're currently missing support for.
But we can also support VK_FORMAT_R4G4B4A4_UNORM_PACK16, which maps to
PIPE_FORMAT_A4B4G4R4_UNORM. This format is optional, but there's no
reason we shouldn't expose support for it.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32083>
Without multiview, a shader that doesn't write to the any of the
extended FIFO attributes (pointsize and layer) can be used with either
FIFO format. This allows us to switch to the basic FIFO format when
using the no_psiz variant. In multiview vertex shaders, output offsets
depend on the FIFO format. Instead of trying to patch these in the
no_psiz variant, just don't do the optimization for now.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31704>
Two components to this: first we only issue fragment jobs for enabled
views. This prevents disabled layers from being cleared implicitly with
`LOAD_OP_CLEAR`, and also reduces overhead (these layers have no
primitives so the fragment job is wasted work). Second is hooking up the
view mask to vk_meta_clear.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31704>
In Valhall multiview, position/varying shaders are invoked once per
draw. Each invocation write separate outputs for all views. Fragment
processing is handled by the existing multilayer support. Note that
because the hardware only supports up to 8 views, we don't have to care
about the case where there are too many layers to fit in one tiler when
multiview is enabled.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31704>
In panvk we pass absolute view indices to the hardware, so we need to do
the conversion from compacted to absolute at some point. Emitting
absolute indices from nir_lower_multiview initially looks like the
simplest option, but nir_lower_io_to_temporaries will emit a write for
every element of array varyings. This results in unnecessary writes to
disabled views.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31704>
This is needed for implementing multiview in panvk, where the address
calculation for multiview outputs is not well-represented by lowering to
nir_intrinsic_store_output with a single offset.
The case where a variable is both per-view and per-{vertex,primitive} is
now unsupported. This would come up with drivers implementing
NV_mesh_shader or using nir_lower_multiview on geometry, tessellation,
or mesh shaders. No drivers currently do either of these. There was some
code that attempted to handle the nested per-view case by unwrapping
per-view/arrayed types twice, but it's unclear to what extent this
actually worked.
ANV and Turnip both rely on per-view outputs being assigned a unique
driver location for each view, so I've added on option to configure that
behavior rather than removing it.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31704>
Black Myth Wukong is generating more than 2Gb of shaders in
pre-compiling stage after VK_EXT_shader_image_atomic_int64 extension
enabled. Driver will crash in create shader stages due to dereference
null pointer of kernel map.
Signed-off-by: Mi, Yanfeng <yanfeng.mi@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32548>
The last argument seems to be used as brw_shader_reloc::delta (from
brw_add_reloc), and we're unconditionally setting it to 0 here, while
the other place where we handle nir_intrinsic_load_reloc_const_intel
seems to be setting the base appropriately.
I found this by inspection while debugging a bug related to this code,
so I'm not aware of any workloads that get improved by this patch.
Related patches:
- ecbec25e84 ("intel/nir: add reloc delta to load_reloc_const_intel intrinsic")
- 99047451c9 ("intel/fs: add plumbing for embedded samplers")
Fixes: ecbec25e84 ("intel/nir: add reloc delta to load_reloc_const_intel intrinsic")
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/32531>
The slips-file should use the plural form of skip, otherwise it doesn't
end up being used.
We also had some tests that were supposed to be skipped in the expected
failures. Let's remove them, and add a new failure that should have been
turned into a skip to the list as well.
Fixes: eff8a3517d ("panvk: Enable CI on G610")
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32460>
The texture/sampler reswizzle is implemented to allow AFBC for non
canonical component order formats, but it's enabled regardless of
whether the format supports AFBC.
Limit the reswizzling to only apply to formats that support AFBC.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32515>
The AFBC texture/sample reswizzle will not work for formats with
component orders that are not canonical or RB-swapped, as moving the
alpha channel breaks opaque black border-colors.
Disable AFBC for formats with other component orders than RGB and BGR on
v7.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32515>
There should be no limitation on component order support for AFRC, so
the reswizzling of texture/sampler should not be necessary in this case.
For PanVK, only the texture reswizzling was implemented (with the
equivalent sampler reswizzling missing), so removing it allows us to
pass various border-color tests.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32515>
The spec says:
"
When an image view of a depth/stencil image is used as a
depth/stencil framebuffer attachment, the aspectMask is
ignored and both depth and stencil image subresources are used.
"
Make sure we do that when initializing depth/stencil attachments.
Fixes the
dEQP-VK.renderpass.suballocation.subpass_dependencies.late_fragment_tests.*.subpass_count_*.d24_unorm_s8_uint
dEQP-VK.renderpass.suballocation.subpass_dependencies.late_fragment_tests.*.subpass_count_*.d32_sfloat_s8_uint
failures.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32379>
Unscissored glClearColor is using i915_fill_blit().
Clearing can be done with the 1 byte formats
GL_ALPHA, GL_LUMINANCE or GL_INTENSITY.
Routine i915_fill_blit() is called with a rgba-mask containing
1 byte, but it is handling this as a 2-byte color.
This fix adds the needed 1 byte setup to both
i915_fill_blit() and i915_copy_blit().
It solves 1 piglit-test concerning arb_clear_texture-base-formats
and 15 tests concerning fbo-clear-formats.
No regression is shown at other piglit-tests.
Cc: mesa-stable
Signed-off-by: GKraats <vd.kraats@hccnet.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32178>
"constant" is a special keyword in OpenCL C, and we'd like to #define it
suitably in host C23 to facilitate compatiblity between host/device headers.
That means we can't have any identifiers named "global" or "constant".
Fortunately, this is the only 'constant' in any file I'm hitting.
To avoid the clash, don't abbreviate "constant factor", use "constant_factor"
instead. For consistency, "slope factor" then becomes "slope_factor".
The new names are longer but match the Vulkan API exactly.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> [Intel]
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com> [NVK and panvk]
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> [V3DV]
Reviewed-by: Simon Perretta <simon.perretta@imgtec.com> [IMG]
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32505>
Source 2 games segfault if certain buffers are not able to use the same
memory types as images. CS2 specifically expects this to be the case for
vertex and index buffers (VK_BUFFER_USAGE_2_INDEX_BUFFER_BIT,
VK_BUFFER_USAGE_2_VERTEX_BUFFER_BIT). I have not tested other Source 2
games to see how much the requirement differs for the usage (if at all).
Up until now, we've disabled CCS for the Source 2 engine with the
anv_disable_xe2_ccs driconf option. However, this option is not great
for performance. So, replace this with a new option to allow the same
memory types we use for images on buffers - anv_enable_buffer_comp.
Compression of buffers is generally not good for performance. I
collected the result of unconditionally enabling the feature in the
performance CI on BMG. I used the default configuration to average the
result of two runs of each trace.
The CI reports that 4 game traces would regress between 0.44-1.01% FPS
with buffer compression. However, the CI actually shows it to be
beneficial in three of our game traces:
* Cyberpunk-trace-dx12-1080p-high 106.51%
* Hitman3-trace-dx12-1080p-med 101.59%
* Blackops3-trace-dx11-1080p-high 100.44%
So, enable the option for the two games we already have driconf entries
for, Cyberpunk and Hitman3.
Of course, also enable the option for Source 2 games. Casey Bowman
reports that on BMG, some frame times drop from ~15ms to ~7ms in CS2.
This is in large part due to the removal of HiZ resolves, which is a
consequence of the game now using of HIZ_CCS_WT instead of plain HIZ.
Ref: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11520
Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32519>
* drop FDO_CI_CONCURRENT to 1; eliminate intermittent piglit concurrecy issues
* bump PIGLIT_FRACTION to 2; lowering concurrency increases exec time, so
for now compensate with job fraction set to 50%
* triage piglit failures
Signed-off-by: Martin Krastev <martin.krastev@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32526>
As regular branch instructions cannot jump further than
32768 dwords, previously we used long jumps as fallback
solution. The disadvantage of that is that an extra SGPR
pair must be provided in order to temporarily store the PC.
This patch changes that to chained branch instructions by
inserting an artificial extra block into the code to be
targeted by the original branch. This block contains a
single branch instruction jumping to the original target.
Before the block, if necessary, we insert a <branch 1>
instruction for the existing code in order to jump over
the newly inserted block.
Only a few RT shaders are affected.
Totals from 29 (0.04% of 79395) affected shaders: (Navi31)
CodeSize: 17281176 -> 17276332 (-0.03%)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32037>
We are about to add new blocks during assembly which makes
pointers into a vector unreliable.
Also, only set it if the loop has no back-edge.
Totals from 126 (0.16% of 79206) affected shaders: (Navi31)
CodeSize: 1486152 -> 1488152 (+0.13%)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32037>
In IR3 `sel.b32` works based on the 0 so add `icsel_eqz` to fuse the
cmp and sel that we'd otherwise need.
total Instruction Count in shared programs: 1112814 -> 1110473 (-0.21%)
Instruction Count in affected programs: 162701 -> 160360 (-1.44%)
helped: 81
HURT: 29
Instruction count are helped.
total MOV Count in shared programs: 86777 -> 88671 (2.18%)
MOV Count in affected programs: 28119 -> 30013 (6.74%)
helped: 1
HURT: 292
Mov count are HURT.
total COV Count in shared programs: 15070 -> 14962 (-0.72%)
COV Count in affected programs: 5770 -> 5662 (-1.87%)
helped: 76
HURT: 2
Cov count are helped.
total Last helper instruction in shared programs: 592729 -> 590638 (-0.35%)
Last helper instruction in affected programs: 91331 -> 89240 (-2.29%)
helped: 30
HURT: 1
Last helper instruction are helped.
total Instructions with SS sync bit in shared programs: 29336 -> 29546 (0.72%)
Instructions with SS sync bit in affected programs: 4702 -> 4912 (4.47%)
helped: 8
HURT: 43
Instructions with ss sync bit are HURT.
total Estimated cycles stalled on SS in shared programs: 111590 -> 112401 (0.73%)
Estimated cycles stalled on SS in affected programs: 27708 -> 28519 (2.93%)
helped: 21
HURT: 61
Estimated cycles stalled on ss are HURT.
total cat1 instructions in shared programs: 101933 -> 103695 (1.73%)
cat1 instructions in affected programs: 35804 -> 37566 (4.92%)
helped: 18
HURT: 290
Cat1 instructions are HURT.
total cat2 instructions in shared programs: 380299 -> 377499 (-0.74%)
cat2 instructions in affected programs: 128609 -> 125809 (-2.18%)
helped: 322
HURT: 0
Cat2 instructions are helped.
Signed-off-by: Karmjit Mahil <karmjit.mahil@igalia.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32189>
The pass that lowers PS outputs has been rewritten since 45d8cd037a
("ac/nir: rewrite ac_nir_lower_ps epilog to fix dual src blending
with mono PS") to handle invalid uses of dual-source blending.
This drirc used to workaround game bugs on GFX11 only should no longer
be necessary.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32514>
DRM_XE_TOPO_EU_PER_DSS and DRM_XE_TOPO_SIMD16_EU_PER_DSS can be any
number of bytes long but it was assuming it was always 4 bytes long.
That was not a issue because Xe KMD return 4 bytes even if only needs
1 or 2 bytes but that is a problem with our HW simulator that was
returning 2 bytes.
Fixes: a24d93aa89 ("intel/dev: Query and compute hardware topology for Xe")
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/32307>
If the state tracker chooses to implement one format with a more
general one (e.g. GL_ALPHA implemented with GL_RGBA) we end up
in a situation where some components should be ignored. Readpix
handles this correctly, but blit does not, which means that if
we blit between different formats we can end up writing garbage
into some components. Work around this by adding an explicit
swizzle to the pipe_blit_info struct, which can re-arrange elements
and/or put 0 or 1 into appropriate channels, and use this to
set the appropriate values into unused channels via the sampler
view.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31378>
We create NIR shaders here, and we need to free them when we're done with
them as well.
These shaders are created using nir_builder_init_simple_shader(), which
allocates using a NULL ralloc-parent, so ralloc_free should be the right
function to free them with.
Fixes: 514c10344e ("vulkan/meta: Add a concept of rect pipelines")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32486>
In panfrost_query_compression_modifiers we need to ignore AFBC
modifiers if the device does not support AFBC. In order to avoid
duplicating code, we do this by calling panfrost_walk_dmabuf_modifiers
with a flag that indicates we do not want AFRC modifiers.
Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32406>
We need to start treating flakes as fails and they are likely different
between chips.
I removed the gfx9 flakes file and renamed the original flakes file
to gfx6-tahiti-flakes.csv, but it would be better to add a new flakes
file for each generation we test.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32288>
The culling code always computes the determinant for culling zero-area
triangles, so passing the state via user SGPRs doesn't really add much
shader code to justify having shader variants for front/back face
culling that uses the same determinant.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32288>
for AGX, we preserve amul all the way until fusing address modes in order to be
able to fuse effectively. so the load/store vectorizer wouldn't vectorize before
fusing.
however, after fusing we get fused intrinsics which are tricky to teach the
vectorizer about as their semantics are pretty subtle. so we can't vectorize
after, either.
the easiest solution is to teach the vectorize about amul, which can always be
replaced by imul for our pattern matches.
this fixes certain cases of vectorization in OpenCL kernels on asahi.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32398>
This is the selector, and it must always be a uniform UD, so there's no
reason to not propagate into it.
No shader-db change on any Intel platform.
fossil-db:
All Intel platforms had similar results. (Lunar Lake shown)
Totals:
Instrs: 220507131 -> 220507127 (-0.00%)
Cycle count: 31607052398 -> 31607053364 (+0.00%); split: -0.00%, +0.00%
Totals from 5 (0.00% of 702410) affected shaders:
Instrs: 995 -> 991 (-0.40%)
Cycle count: 86392 -> 87358 (+1.12%); split: -0.07%, +1.19%
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32097>
The next two commits modify the destination regioning in a way that,
which still correct, trigger assertion failures if we try to fix the
regioning here.
Broadcast gets lowered in brw_eu_emit. For the purposes of region
restrictions, let's assume that the final code emission will do the
right thing. Doing a bunch of shuffling here is only going to make a
mess of things.
No shader-db or fossil-db changes on any Intel platform.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32097>
The spec mandates that if the program object isn't created from IL, it
should not touch the buffer. Passing an empty slice would achieve that,
but it's better to be explicit here.
Reviewed-by: @LingMan
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32268>
The old way was quite annoying as it required to create a Vec to even get
the size of the result causing needless computations.
This also meant that copying into the result buffer always required to go
through a byte Vec even though we could just do the copy directly.
The main idea here is that instead of returning the result, we simply call
into a write function giving us more flexibility here.
Potentially this will also allow us to add overloads for Iterators or to
even use closures in case the size calculation is cheaper than creating
the value just to get the size.
Reviewed-by: @LingMan
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32268>
If input_value, index, index1 or index2 is an input, here are examples of
code that this commit moves from consumers to producers:
* input_value * uniform_array[index]
* uniform_array[index]
* ubo[0].array[index]
* ubo[index].var
* ubo[index1].array[index2]
If the array index is computed from an input, it must be flat or convergent
within a primitive to be moved. If the array index is not an input, it must
be a uniform expression.
dEQP-GLES31.functional.shaders.opaque_type_indexing.ubo.dynamically_uniform_fragment
has UBO indexing that is moved to the producer by this.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32424>
They are a maintainenance burden since they would need changes to
support more instruction types that nir_opt_varyings will be able to
move between shaders, and they are almost identical to
default_varying_estimate_instr_cost, so just use that.
The cost threshold is adjusted for AMD because
default_varying_estimate_instr_cost is slightly different.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32424>
Without this, compaction can put inputs into vec4 slots already occupied
by indirectly-accessed inputs while ignoring their interpolation qualifier,
which is incorrect.
All input components sharing the same vec4 slot must use interpolation
qualifiers that are compatible with each other.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32424>
Even the most flexible interpolation that we have in NIR options
(nir_io_has_flexible_input_interpolation_except_flat) doesn't allow
mixing flat and non-flat in the same vec4. This (legacy) optimization
can't promote interpolated inputs to flat if it doesn't consider
the interpolation mode of the whole vec4 slot.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32424>
The fast implementation can be off by a lot for small values.
Fixes:
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.compute.lod_op.query.linear.16_1_1.mip_0
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.compute.lod_op.query.linear.16_1_1.mip_1
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.compute.lod_op.query.linear.4_4_1.mip_0
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.compute.lod_op.query.linear.4_4_1.mip_1
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.mesh.lod_op.query.linear.16_1_1.mip_0
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.mesh.lod_op.query.linear.16_1_1.mip_1
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.mesh.lod_op.query.linear.4_4_1.mip_0
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.mesh.lod_op.query.linear.4_4_1.mip_1
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.task.lod_op.query.linear.16_1_1.mip_0
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.task.lod_op.query.linear.16_1_1.mip_1
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.task.lod_op.query.linear.4_4_1.mip_0
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.task.lod_op.query.linear.4_4_1.mip_1
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31056>
This commit allows you to dump different regions of memory related to
bvh building. An additional script to decode the memory dump is also
added, and you're able to view the built bvh in 3D view in html. See the
included README.md for usage.
Rework:
- you can now view the actual child_coord in internalNode in html
- change exponent to be int8_t in the interpreter
- fix the actual coordinates using an updated formula
- now you can have 3D view of the bvh
- blockIncr could be 2 and vk_aabb should be first
- Now, if any bvh dump is enabled, we will zero out tlas, to prevent gpu
hang caused by incorrect tlas traversal
- rootNodeOffset is back to the beginning
- Add INTEL_DEBUG=bvh_no_build.
- Fix type of dump_size
- add assertion for a 4B alignment
- when clearing out bvh, only clear out everything after
(header+bvh_offset)
- TODO: instead of dumping on destory, track in the command buffer
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31588>
Rework: (Kevin)
- Properly setup bvh_layout
Our bvh resides in contiguous memory and can be divided into two sections:
1. anv_accel_struct_header, tightly followed by
2. actual bvh, which starts with root node, followed by interleaving
leaves or internal nodes.
- Update comments for some fields for BVH and nodes.
- Properly populate the UUIDs in serialization header
- separate header func into completely two paths based on compaction bit
- Encode rt_uuid at second VK_UUID_SIZE.
- Write query result at correct slot
- add assertion for a 4B alignment
- move bvh_layout to anv_bvh
- Use meson option to decide which files to compile
- The alignment of serialization size is not needed
- Change static_assert to STATIC_ASSERT and move them inside functions
Rework (Sagar)
- Use anv_cmd_buffer_update_buffer instead of MI to copy data
Rework (Lionel)
- Remove flush after builds, and add flush in copy before dispatch
- Handle the flushes in CmdWriteAccelerationStructuresPropertiesKHR properly
Co-authored-by: Kevin Chuang <kaiwenjon23@gmail.com>
Co-authored-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31588>
This shader gets called and will construct ANV BVH from IR BVH. More
specifically, each invocation will take care of one internal node. The
internal nodes get processed starting from root node all the way to the
bottom leaves.
During processing, we keep track of the destination of
where the internal node should be encoded (tracked in
vk_ir_box.bvh_offset), and where its leaves should be encoded (tracked
in vk_ir_header.dst_node_offset).
The processed bvh is in contiguous memory, which starts with header,
followed by interleaving internal nodes and leaves. The nodes
information are also populated.
Rework: (Sagar)
- Return out of bounds threads early
- Mimic GRL internal node encoding
- Handle node mask
- Fix block_incr_and_start_prim
- Fix shader_index_and_geom_mask for instance node
- Fix instance flag
- Fix block_incr and instance_contribution_and_geom_flags initialized to be zero
- Fix lower_x and upper_x to be properly flipped for invalid child
- For invalid node, clear blockIncr and set startPrim to INVALID
- Calculated things upfront and assign, cutting down more than ~200
instructions
Co-authored-by: Kevin Chuang <kaiwenjon23@gmail.com>
Co-authored-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31588>
This commit adds build interface and helper header for ANV BVH.
Rework: (Kevin)
- Use block_size macro to represent bvh node/leaf size
- Rename BVH-related node/leaf size macros for clarity
- Updated comments for some fields for bvh and nodes.
- move bvh_layout to anv_bvh.h
- Draw anv_bvh layout
- rename child_offset to child_block_offset
Co-authored-by: Kevin Chuang <kaiwenjon23@gmail.com>
Co-authored-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31588>
We were wanting to check if the destination region spanned multiple
registers. But we were checking against REG_SIZE, when the register
size is actually REG_SIZE * reg_unit(devinfo) now.
This meant that SIMD32 LOAD_PAYLOAD was always getting SIMD-split
on Xe2 platforms, generating a lot of unnecessary mess for compute
shaders.
fossil-db results on Lunar Lake:
Totals:
Instrs: 146178614 -> 143291988 (-1.97%); split: -1.98%, +0.00%
Subgroup size: 11089632 -> 11089376 (-0.00%); split: +0.00%, -0.00%
Cycle count: 22528892444 -> 22507551650 (-0.09%); split: -0.12%, +0.03%
Max live registers: 48834202 -> 48886685 (+0.11%); split: -0.09%, +0.20%
Totals from 134306 (24.10% of 557327) affected shaders:
Instrs: 28806335 -> 25919709 (-10.02%); split: -10.02%, +0.00%
Subgroup size: 4297680 -> 4297424 (-0.01%); split: +0.00%, -0.01%
Cycle count: 956867650 -> 935526856 (-2.23%); split: -2.84%, +0.61%
Max live registers: 13085711 -> 13138194 (+0.40%); split: -0.33%, +0.73%
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32471>
* In the ACM PRMs, the programming notes under
RENDER_SURFACE_STATE::MemoryCompressionEnable state that the
DecompressInL3 bit must be set for media compression.
* Unlike TGL, ACM seems to handle format reinterpretation just fine
without using the bit.
Update the assignment accordingly.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32192>
The bitstreamStartOffset from the VK_QUERY_TYPE_VIDEO_ENCODE_FEEDBACK_KHR query in RADV is currently relative to the dstBuffer, and not dstBuffer + dstBufferOffset like the spec states.
To fix this, let's append the offset to the VA directly and not tell the encoder about the offset relative to the VA at all.
The Vulkan spec states:
"VK_VIDEO_ENCODE_FEEDBACK_BITSTREAM_BUFFER_OFFSET_BIT_KHR specifies that queries managed by the pool will capture the byte offset of the bitstream data written by the video encode operation to the bitstream buffer specified in VkVideoEncodeInfoKHR::dstBuffer relative to the offset specified in VkVideoEncodeInfoKHR::dstBufferOffset."
The relevant part being that is is relative to dstBufferOffset and not the start of the VkBuffer.
Signed-off-by: Autumn Ashton <misyl@froggi.es>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32452>
We also need to report minmax as part of the format-features.
This fixes the following CTS tests for me:
- dEQP-VK.api.info.format_properties.r8_unorm
- dEQP-VK.api.info.format_properties.r8_snorm
- dEQP-VK.api.info.format_properties.r16_sfloat
- dEQP-VK.api.info.format_properties.r32_sfloat
- dEQP-VK.api.info.format_properties.d16_unorm
Fixes: 1fc454673a ("panvk: Implement VK_EXT_sampler_filter_minmax for v10")
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32445>
This is a prerequisite for enabling nir_opt_varyings for all gallium
drivers.
nir_lower_io_passes (called by the GLSL linker) only uses NIR options
to lower indirect IO access before lowering IO and calling
nir_opt_varyings.
Most drivers report full support for indirect IO and lower it themselves,
which prevents compaction of lowered indirectly accessed varyings because
nir_opt_varyings doesn't touch indirect varyings.
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> (Rb for asahi)
Reviewed-by: Pavel Ondračka <pavel.ondracka@gmail.com> (for r300)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32423>
In case of userqueue, kernel bo kms_handle will not hold fences for non
shared bo. Non shared bo fences are taken care within mesa. Hence need
to copy the data to another shared buffer for export.
Keeping has_local_buffers true for userq will make non shared bo to
be copied to shared bo for export in si_texture_get_handle().
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29010>
This patch adds the job submission code for userq. An indirect buffer, in
short ib, can be considered a job. The job is submitted directly to the
userq ring buffer and the doorbell is rung to notify the firmware to
execute the job.
The packets that are submitted to execute the job is below,
1) fence wait multi packet for any dependency fence
2) hdp flush packs to flush host data path
3) indirect buffer packet
4) protected signal packet
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29010>
In case of userq when destroying bo, fences are gathered and passed to kernel.
Fences are gathered using bo_fence_lock, In do_winsys_deinit() currently
bo_cache is destroyed after destroying bo_fence_lock. This leads to crash.
Fix this by moving destroying bo_fence_lock late in do_winsys_deinit().
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29010>
In case of kernel queues method of job submission, buffer list for the job
is passed to amdgpu_cs ioctl. Kernel can ensure that VM mapping is
completed before submitting the job.
With user queues amdgpu_cs ioctl is not called, so the kernel can't determine
automatically when BO should be prepared for submissions. To achieve this, a
timeline syncobj is attach to the gem_va ioctls, which can then be used as a
dependency for future jobs.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29010>
RS and BLT operations can exhibit issues in some cases. To help in debugging
such issues stall after RS and BLT operations when ETNA_MESA_DEBUG=draw_stall
is enabled. In that case the FE will point right at the faulty RS/BLT
operation, instead of the next stall which may be many state loads later.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32444>
This moves the tlb job load/store logic to the new helper
v3d_update_job_tlb_load_store. Then an early return is included
so if the rasterizer discard is enabled, no load/stores are
emitted because of the draw call.
This helps in situations where transform feedback is used
and there is only interest in the geometry results. We identified
that some jobs were not rendering at all, but they were having the
performance cost of doing several loads and stores.
This generates a huge performance improvement on manhattan benchmarks.
fps_avg helped: gl_gfxbench_manhattan.trace: 8.37 -> 11.54 (37.85%)
fps_avg helped: gl_gfxbench_manhattan31.trace: 6.02 -> 7.51 (24.62%)
total fps_avg in affected (through threshold) runs: 14.39 -> 19.04 (32.32%)
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32351>
Move the tool to summarize a failed pipeline to a generic .marge/hooks
directory. This will allow the fdo-bots repo to handle all marge hooks in
a consistent way across repositories that use this service.
Add a symlink to the bin/ci directory so that the pipeline summary tool
can still be run locally as well.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32413>
Notably, our convergent block loads were already overfetching - we
rounded up to block sizes of 8, 16, 32, or 64(LSC-only). But we did
so in the backend, rather than NIR.
With recent changes, nir_opt_load_store_vectorizer allows holes of up
to 28 bytes (7 components at 4 bytes each). This allows us to detect
cases where we did a convergent block load for 1 component (but loaded
a whole vec8), then another load for the next vec8, and combine them
into a single V16 load. Single component loads aren't the most common,
but convergent loads of a vec2 in one group and a vec3 in another are
quite common, and it makes no sense to do V8+V8 loads instead of V16.
For non-block loads, we allow a max hole of 4 bytes. This allows the
common case of XYZ_ + XYZ_ loads (where the last component is unread)
to combine into a single larger load.
fossil-db results on Lunarlake:
Totals:
Instrs: 146692608 -> 146246432 (-0.30%); split: -0.33%, +0.02%
Subgroup size: 11100528 -> 11100512 (-0.00%)
Send messages: 7003425 -> 6862529 (-2.01%); split: -2.01%, +0.00%
Cycle count: 22396273274 -> 22523048654 (+0.57%); split: -1.08%, +1.64%
Spill count: 67671 -> 67594 (-0.11%); split: -1.59%, +1.48%
Fill count: 128999 -> 130223 (+0.95%); split: -1.73%, +2.68%
Scratch Memory Size: 5986304 -> 6042624 (+0.94%); split: -1.40%, +2.34%
Max live registers: 48898858 -> 48881655 (-0.04%); split: -0.05%, +0.01%
Non SSA regs after NIR: 172397792 -> 167577380 (-2.80%); split: -2.80%, +0.00%
Totals from 451003 (80.87% of 557667) affected shaders:
Instrs: 134111754 -> 133665578 (-0.33%); split: -0.36%, +0.03%
Subgroup size: 9039104 -> 9039088 (-0.00%)
Send messages: 6127775 -> 5986879 (-2.30%); split: -2.30%, +0.00%
Cycle count: 20306336726 -> 20433112106 (+0.62%); split: -1.19%, +1.81%
Spill count: 56230 -> 56153 (-0.14%); split: -1.92%, +1.78%
Fill count: 112920 -> 114144 (+1.08%); split: -1.97%, +3.06%
Scratch Memory Size: 3769344 -> 3825664 (+1.49%); split: -2.23%, +3.72%
Max live registers: 43750259 -> 43733056 (-0.04%); split: -0.05%, +0.01%
Non SSA regs after NIR: 158449343 -> 153628931 (-3.04%); split: -3.04%, +0.00%
In particular, sends get cut by 20.85% for Borderlands 3 DX12, 13.82%
on Cyberpunk 2077, 10.75% on Strange Brigade, and 10.20% on Red Dead
Redemption 2. Yet, spill/fills remain about the same.
fossil-db results on Alchemist are similar though not quite as good.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32315>
nir_opt_load_store_vectorize checks for potential address wrapping
when vectorizing two loads ("low" and "high"). It looks for cases where
"low" might have a large address, and "high" has a positive offset
which, when added together, could trigger integer wraparound. The issue
here is that if the large address of "low" was considered out-of-bounds,
adding offset could wrap around to a small address, which might actually
be in-bounds. Thus, when loaded separately, "low" will fail and trigger
robustness out-of-bound-read behavior, but "high" would read correctly.
When vectorized, the entire load would fail. This is explicitly tested
for with 32-bit SSBO addresses in the Vulkan CTS.
However, anv's 64-bit global addresses and VMA handling effectively
prevent this case. Addresses 0-4095 are a reserved page so that if
people try to use 0 as a NULL pointer, it never maps to a valid BO.
That alone guarantees that the above case where "high" gets a small
address would never be in-bounds, so we don't need to check for it.
In fact, we allocate most user allocations out of high addresses,
and have specialized allocation heaps for certain types of GPU data
structures in the lower GB of memory. For a load to wrap around and
successfully land in the right heap, it would have to load gigabytes.
Disabling this allows load vectorization and overfetching in more cases.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32315>
The load_*_uniform_block_intel intrinsics always load either 8x or 16x
32-bit components worth of data (so 32 byte increments). This leads to
cases where we load a few components from one vec8, followed by a few
components of an adjacent vec8. We want to combine those into a vec16
load, as that loads a whole cacheline at a time, and requires less hoops
to calculate addresses and request memory loads.
So, we allow 7 * 4 = 28 bytes of holes, which handles vec8+vec8 where
only the .x component is read.
Most drivers and intrinsics will not want such large holes. I thought
about adding a per-intrinsic max_hole to the core code, but decided that
since we already have driver callbacks, we can just rely on them to
reject what makes sense to them.
No driver callbacks currently allow holes, so this should not currently
affect any drivers. But any work in progress branches may need to be
updated to reject larger holes.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32315>
This will matter more with overfetching, where we may suggest loading
additional data that we don't actually need for vectorization purposes.
We want to make sure that push ranges have the data we actually need;
any extra padding is irrelevant.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32315>
i965 used to upload its own regular GL uniforms and push those in
addition to UBO ranges. st/mesa instead uploads regular uniforms
and presents those to use as UBO 0. So this really isn't a thing
anymore.
nir_intrinsic_load_uniform is still used today but it represents
Vulkan push constants. anv_nir_compute_push_layout already takes
care of ensuring too many ranges aren't present, so it doesn't need
the pass to do so. iris doesn't use this intrinsic at all.
We can also drop the compute shader check, because neither iris nor
anv use UBO push analysis for compute shaders - except for anv's
internal kernels, which already have well specified push layouts.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32315>
DXIL requires that each I/O variable has a unique semantic name, but when
dealing with semantics that take up multiple slots, that variable implicitly
takes up multiple names. So when assigning driver_location, we need to do
the same.
That means also updating outputs and patch constants to have a mapping from
driver_location to a compacted index, since the metadata arrays *can't* have
holes.
This would be simpler if we could hang it off the nir_variable but there's
not really any free fields to be able to do that. We only need this compacted
mapping inside the DXIL backend anyway so we can just store the array in the
module.
Tested-by: Benjamin Otte <otte@gnome.org>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12128
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32047>
Vulkan 1.4 can only be exposed on a7xx devices due to a number of bumps
in the required limits, including bumping maxDescriptorSets to 7. a7xx
bumped the number of bindless bases from 5 to 8, with one reserved for
the driver.
I've followed what we've already done and exposed a conformanceVersion
of 1.4.0.0 for all a7xx devices, even though I've only submitted
conformance for X1-85. I'm not sure if we want to change this, but at
least for now a618 on Chromebooks and X1-85 on laptops are the only
cases where turnip is being "shipped" to users in some official
capacity, so it shouldn't be a huge deal.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32437>
Vulkan runtime doesn't layer vkGetImageMemoryRequirements2
on top of vkGetDeviceImageMemoryRequirements, as that would
require initializing a full image, which is expensive on
certain drivers such as NVK, so it's up to us to implement
both functions.
In our implementation of vkGetDeviceImageMemoryRequirements,
we initialize a slimmed down image and then forward everything
to vkGetImageMemoryRequirements2.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32361>
pan_resource_modifier_convert can use a blit to convert images
from AFBC. If we call this from panfrost_set_shader_images then
we end up crashing due to using an inconsistent set of images.
Fix this by doing the AFBC/AFRC conversion before the image
bindings.
This fixes a crash in piglit oes_egl_image_external_essl3 tests.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30243>
agx_gpu_time_to_ns() was broken since it was overflowing the u64
timestamp after just ~10 minutes. Fix that by automatically computing a
reduced conversion fraction, and add support for DRM_ASAHI_GET_TIME
where supported (replacing the CPU timer hack).
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32434>
Commit 361f362258 ("dri: Unify createImage and createImageWithModifiers")
has introduced new behavior for drivers which don't support explicit
format modifiers. Before this commit, INVALID was not special-cased
and any call to dri_create_image() with one or more modifiers returned
NULL. After this commit, INVALID gained a special meaning: it indicates
that the implicit modifier is accepted by the caller. This is surprising
and is an API break.
This causes further API breaks: for instance, before this commit a BO
created via gbm_bo_create_with_modifiers() was guaranteed to always
return a non-INVALID modifier in gbm_bo_get_modifier().
This is inconsistent with gbm_dri_surface_create(): that function
treats INVALID as a bad entry in the modifier list, and fails if
it's the only acceptable modifier.
Additionally, drivers don't special-case INVALID and just ignore it
if they see it in a modifier list. This causes more inconsistencies.
For instance, let's say that a library user passes the modifier list
{ INVALID, FOO } to GBM. If a driver supports explicit modifiers and
doesn't support FOO for scanout, it'll return NULL. If a driver
doesn't support explicit modifiers, the current logic would return
a non-NULL BO with an INVALID modifier. This discrepency makes it
harder to reason about the system: half of the API ignores INVALID,
while the other half assumes INVALID indicates an implicit modifier.
To fix these issues, revert to the behavior before the commit, and
require use of the dedicated API without supplying any modifier for
implicit modifiers.
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: 361f362258 ("dri: Unify createImage and createImageWithModifiers")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32396>
We never split live ranges, so we don't need to store the location of
each live value when recording live outs, but the physreg assigned to a
register will still be clobbered when we reload it so we have to record
the original physreg and then make sure to use it when reloading the
live out.
We probably never encountered a case where we needed to reload live outs
in a loop before, but after enabling clustered subgroup reductions
dEQP-VK.subgroups.clustered.compute.subgroupclusteredmin_{i,u}64vec4_requiredsubgroupsize
hits this case and fails in RA validation without this fix.
Fixes: fa22b0901a ("ir3/ra: Add specialized shared register RA/spilling")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32435>
If the caller passed in the same DRM file description, use it for sws->fd
as well. This is simpler than the previously reverted commit and also
fixes https://gitlab.freedesktop.org/mesa/mesa/-/issues/12208.
v2:
* Move fallback sws->fd assignment to proper scope, fixes CI failures.
* Remove close(sws->fd) from amdgpu_winsys_create failure path, it can
never be a valid file descriptor != aws->fd there.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32377>
If the condition of the loop terminator is based on an unsigned value we
can in some cases find the max number of possible loop trips. With the
max loop trips know a complex unroll can unroll the loop.
For example:
uniform uint x;
uint i = x;
while (true) {
if (i >= 4)
break;
i += 6;
}
The above loop can be unrolled even though we don't know the initial
value of the induction variable because it can have at most 1 iteration.
There were no changes with my shader-db collection. Change was inspired
by MR #31312 where builtin shader code failed to unroll.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31701>
This is mostly adapted from radv's BVH building. This defines a common
"IR" for BVH trees, two algorithms for constructing it, and a callback
that the driver implements for encoding. The framework takes care of
parallelizing the different passes, so the driver just has to split the
encoding process into "stages" and implement just one part for each
stage.
The runtime changes are:
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
The radv changes are;
Reviewed-by: Friedrich Vock <friedrich.vock@gmx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31433>
This is mostly adapted from radv's BVH building. This defines a common
"IR" for BVH trees, two algorithms for constructing it, and a callback
that the driver implements for encoding. The framework takes care of
parallelizing the different passes, so the driver just has to split the
encoding process into "stages" and implement just one part for each
stage.
The runtime changes are:
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
The radv changes are;
Reviewed-by: Friedrich Vock <friedrich.vock@gmx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31433>
All of these are functions that could reasonably be incorporated into a
Vulkan extension, but are currently missing. While we could in theory do
BVH building without them, using them simplifies the code significantly
and both radv and turnip can reasonably implement them.
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31433>
All functions that used to take an ir3_block as argument to append
instructions to now take an ir3_builder as argument.
Add an ir3_builder field to ir3_context and replace all uses of
ir3_context::block for creating instructions with ir3_context::build.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32088>
During instruction selection, instructions are sometimes emitted to
blocks other than the current one. For example, to predecessor blocks
for phi sources or to the first block for inputs. For those cases, a new
builder is created to emit at the end of the target block. However, if
the target block happens to be the same as the current block, the main
builder would not be updated to point past the new instructions.
Therefore, don't update the cursor when it points to the end of a block
to ensure that new instructions will always be added at the end.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32088>
Use box with largest ray interval for shadow rays (terminate on first
hit) as it maximizes the probability of finding some object in that box;
for reflection (closest hit) rays, use midpoint instead, which defers
processing of larger boxes the ray origin is in in favor of smaller
boxes closer to origin.
Since the sorting mode must be uniform, when terminate_on_first_hit flag
is divergent, we leave it as closest.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32416>
This allows `gbm_bo_get_offset()` to return the correct offset for e.g.
the second plane of a resource with the NV12 format. Crucially this
fixes direct scanout / hardware plane usage in Mutter and possibly other
clients.
While on it also add support for stride, modifier and n_planes queries.
The later two should not change in behavior and just safe a few CPU
cycles. The stride query support in theory fixes queries for multi-plane
formats, however in practice most/all currently used formats such as NV12,
P010 and YUV420 use the same stride for all planes.
Cc: mesa-stable
Acked-by: Rob Clark <robclark@freedesktop.org>
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32282>
This is implemented differently depending on the cluster size:
- At most 8: in this case, executing brcst.active will leave the
reduction in the last invocation of each cluster. Simply iterate the
clusters and broadcast the last invocation to the rest.
- Otherwise, also iterate the clusters but execute the usual
reduce_clusters_ir3 loop for each of them.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31731>
Now that we use shfl for lowering shuffle operations, the generic
lowering of scan/reduce to shuffles results in faster code than our
custom loop for 64b operations.
Note that this was measured using a micro benchmark on full subgroups.
The generic lowering might be slower when not all invocations are active
but this should be a rare case.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31731>
Basic vertex/fragment shader I/O and sysval allocation rewritten to use
the new compiler/driver interface, with allocation moved entirely into
the driver.
RHW coeffs now only emitted when required.
Boilerplate support for converting formats for vs inputs/fs outputs.
Signed-off-by: Simon Perretta <simon.perretta@imgtec.com>
Acked-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32258>
Fix addition where one summand was already used as input to an earlier
operation, for example in the last operation of MobileNet V2 residual
blocks.
Fixes an assertion when trying to run MobileNet V2:
.../src/gallium/drivers/etnaviv/etnaviv_ml.c:58: etna_ml_create_tensor: Assertion `size == pipe_buffer_size(res)' failed.
Reviewed-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31987>
The hardware only supports unsigned 8-bit tensors, but with the
configurable zero point we can map signed 8-bit integers to unsigned
8-bit integers by adding a constant offset of 128 to all values and to
the zero point setting.
This requires adding 128 to all input tensors and subtracting 128
from all output tensors during inference.
Reviewed-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31979>
Prior to VCN4, the encode queue is separate from the decode queue. For
encode, the WRITE_MEMORY command can be executed with similar framing as
for VCN4, but notably there is no signature support, so it must be
skipped.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32400>
Use the new event-based tracing system to capture IDVS/COMPUTE/FRAGMENT
jobs and their context.
When tracing is enabled, the descriptor ring buffer is replaced by
a bigger linear buffer such that descriptors are not recycled before
we get a change to decode the trace.
If the decode buffer is too small and a OOB is detected, the driver will
suggest the user to allocate a bigger buffer with the
PANVK_{DESC,CS}_TRACEBUF_SIZE env vars.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32284>
Interpreting the command buffer only really works if everything is
static, but panvk started to make extensive use of loops, and
conditionals which depends on memory values that get updated by the
command stream itself. This makes it impossible to walk back to the
original state in order to replay the CS actions.
Move away from this approach in favor of an event-based tracing
mechanism recording particular CS commands and their context at
execution time. Of course, that means the auxiliary descriptors
shouldn't be recycled until the traces are decoded, but that's more
tractable. We just need to turn the descriptor ring buffers into
linear buffers with a guard page, and crash on OOB, with a message
suggesting the user to tweak the maximum trace buffer sizes.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32284>
The previous code not only left them undefined, but also
didn't increment the array index, so subsequent PS inputs
would be broken after the undefined one.
Note that this doesn't affect any valid Vulkan apps, but it makes
the code a bit simpler and it makes undefined inputs a little more
forgiving, at no expense for valid PS.
This code actually uncovers a bug in Zink, so I'm also documenting
the failing Zink test case.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32220>
There are some FS built-ins that can be per-vertex or
per-primitive depending on whether a mesh shader is used:
primitive ID (implicit in VS), layer and viewport.
However, the HW requires per-primitive FS inputs to be ordered last.
This causes bugs when the same unlinked FS is used together
with VS/TES/GS and MS (with unlinked ESO or fast-linked GPL).
To solve this problem, we reorder the FS inputs so that these
potentially per-primitive inputs go after per-vertex inputs but
before per-primitive inputs.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32220>
switch libagx to the precompilation pipeline. see the big comment in the
previous commit for why we're doing this.
while doing so, we move some dispatch stuff. there was so much churn from
precompile that this avoids doing the churn twice. that new header will be used
for DGC down the road.
there's also a small vtn/bindgen patch in here to skip bindgen'ing entrypoints,
as that conflicts with the new dispatch macros. this is the sane behaviour, we
just need to do the full precomp switch across the tree at once.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32339>
This seems to be a little faster.
insert_NOPs (navi31):
Difference at 95.0% confidence
-11.484 +/- 6.13377
-1.62767% +/- 0.860593%
(Student's t, pooled s = 5.71913)
insert_NOPs (gfx1200):
Difference at 95.0% confidence
-35.6745 +/- 4.97972
-8.1236% +/- 1.10453%
(Student's t, pooled s = 4.6431)
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32374>
After the breaking commit, gbm_bo_create_with_modifiers({LINEAR}) returns
a BO with gbm_bo_get_modifier() = INVALID. This restores the functionality
and fixes most notably, hardware cursors for cards without modifiers.
Fixes#12039.
Fixes: 361f362258 ("dri: Unify createImage and createImageWithModifiers")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31725>
This is currently needed to fix d3d12 for st_unlower_io_to_vars.
The idea is to track the current value of ClipVertex in a temporary
variable, and for every emit_vertex, we load the ClipVertex value from
the temporary (which matches the stored value) and insert new CLIP_DIST
stores before emit_vertex.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32363>
The code for IO variables was interleaved with code for IO intrinsics,
which was difficult to follow.
lower_clip_outputs is split and replaced by more accurate names:
lower_clip_vertex_var and lower_clip_vertex_intrin
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32363>
Predication instructions sometimes need extra nops to workaround what
seems to be a hardware bug: prede needs 6 nops and the second
predt/predf of a predt/predf pair needs 4 nops.
The prede workaround is enabled starting from a6xx gen3 and the
predf/predt workaround from a6xx gen4, following the blob.
Fixes rendering corruption in God of War (2018).
Signed-off-by: Job Noorman <job@noorman.info>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32366>
ir3 has a number of bitwise triops (e.g., shrm == (src0 >> src1) & src2)
that don't have NIR-equivalents. Doing instruction selection for them is
a lot more convenient using algebraic patterns than to have to manually
match for them. This patch add NIR opcodes for these instructions.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Reviewed-by: Rob Clark <robclark@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32181>
This reverts commit c49a71c03c.
It broke radeonsi.
GBM can't set __DRI_IMAGE_USE_BACKBUFFER if gbm itself doesn't use it as
a back buffer by rendering to it and calling SwapBuffers. If another
library uses it as a back buffer, that library should set
__DRI_IMAGE_USE_BACKBUFFER, not GBM. A different flag could be added
to indicate the behavior that the original commit expected.
Fixes: c49a71c03c - gbm: mark surface buffers as explicit flushed
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11996
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32345>
In commit a34982063 (Support standalone executable builds on Android,
2024-09-12) upstream VK-GL-CTS added support for building deqp as an
executable command for Android, this change is included in the vulkan
branch used by build-deqp.sh so the custom patches can be dropped for
the Vulkan CTS build.
After that and by passing -DDEQP_ANDROID_EXE=ON deqp can now be built
with DEQP_API=tools.
[Eric]
Note that the upstream solution seems to be broken on EGL, so GL & GLES
continue to use the local android patches; for more details, see:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28168#note_2676128
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28168>
GFX10.3 and earlier were configured to count the number of dwords written,
and VGT_STRMOUT_DRAW_OPAQUE_VERTEX_STRIDE was also configured in dw units.
GFX11+ on the other hand used nir code that would use bytes.
This commit aligns radeonsi's logic on the radv's one, and use STRMOUT_DATA_TYPE
to configure older chips to use bytes as well.
This fixes GTF-GL46.gtf40.GL3Tests.transform_feedback2.transform_feedback2_two_buffers.
It also seems to have an effect on:
- dEQP-GLES3.functional.transform_feedback.random.separate.*
- dEQP-GLES3.functional.transform_feedback.random_full_array_capture.separate.*
but the results seem flaky so need further investigation.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32281>
The specification doesn't say which error should be reported, but
piglit expects BadMatch:
/* The GLX_ARB_create_context_robustness spec does not say what error
* code should be generated. However, similar cases (e.g., valid GL
* versions) specify BadMatch. This is also the behavior of NVIDIA's
* closed-source driver.
*/
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32281>
Front rendering and (display) DCC are causing artifacts on screen.
si_texture_get_handle deals with this problem by disabling dcc, but
we can make it simpler by not allocating DCC at all when this flag
is set.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32281>
a7xx hardware has 8x MSAA capabilities we can expose. The 8-bit sample
count flag is included in the supported sample counts when computing image
format properties for MSAA-capable image creation conditions, with the
exception of 128-bit formats that don't support 8x MSAA.
UBWC blocksize logic is updated to cover cases of 16-bit and 32-bit formats
that support 8x MSAA. The per-cpp blocksize array is adjusted to also cover
128-byte values for which UBWC has to be disabled anyway.
VK_EXT_sample_locations implementation is adjusted to support sampling in
up to 8 locations, achieved by writing into additional sample location
registers.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32180>
When debugging a game that compiles a ton of shaders at beginning, it
can be very very slow because shaders cache was disabled by default
with RADV_DEBUG=hang.
To make debugging such a game faster, let's cache shaders with
RADV_DEBUG=hang. Note that only the backend IR (ACO or LLVM) and the
disassembly are stored in the cache. To get SPIR-V and NIR, you might
need RADV_DEBUG=hang,nocache.
This also handles the trap handler.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32246>
With Linux kernel 6.12-rc2, crosvm crashes in drm-ci
with the following error,
[ERROR crosvm::sys::linux::panic_hook] thread 'crosvm_vcpu0' panicked at devices/src/virtio/gpu/mod.rs:1761:14:
[ERROR crosvm::sys::linux::panic_hook] failed to send activation resources to worker thread: SendError { .. }
Uprev crosvm to fix this issue.
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31900>
ANB implementation aims to rely as much as possible on 'ANB common' code in vulkan/runtime
and vk_common_* entry points automatically handled by mesa at build time.
(v1) Initial Vulkan HAL skeleton with vk_android_{init,destroy}_ugralloc() in nvk_open_hal()
Changelog:
nvk_android.{c,h}: skeleton nvk_open_hal()/nvk_close_hal() and meson.build changes
nvk_instance.h: nvk_*() functions declaration required by nvk_android.c
nvk_device.c: add ANB support
nvk_image.c: add ANB code paths
nvk_physical_device.c: enable ANB extension support
NOTE: Avoid including any AHB code/headers <vndk/hardware_buffer.h>
use only <vulkan/vk_android_native_buffer.h>
Achievements:
Vulkan HAL is detected by Android build, but no Vulkan application is rendering
Android libvulkan.so loader performs dlopen() of /vendor/lib64/hw/vulkan.nouveau.so
Sascha Willems vulkanCapsViewer App detects the Vulkan HAL in Android builds on RTX2060
Android CTS 11 dEQP-VK can be run and completed, but com.drawelements.deqp app shows black surface
dEQP Test Results:
Module Passed Failed Total
dEQP-VK 568738 161 568899
(v2) Further replication of other using 'ANB common' implementation
Changelog:
Move vk_android_{init,destroy}_ugralloc() from nvk_open_hal() to nvk_CreateInstance()
Remove nvk_GetPhysicalDeviceProperties2() and rely on vk_common_GetPhysicalDeviceProperties2()
Achievements:
Improvements in dEQP-VK test results, but many dEQP.wsi.android.* tests are still failing
dEQP Test Results:
Module Passed Failed Total
dEQP-VK 568783 115 568899
(v3) Get inspiration from lavapipe recent llvmpipe ANB implementation and cleanups
nvk_physical_device.c: brace nvk_init_wsi,nvk_finish_wsi with #ifdef NVK_USE_WSI_PLATFORM/#endif
nvk_image.c: if (!mem) return VK_SUCCESS in DETECT_OS_ANDROID path
nvk_android.h: remove nvk_ahb_format_for_vk_format() and add vk_format_from_android()
Achievements:
Improvement in dEQP.wsi.android.* test results, only dEQP.wsi.android.swapchain.simulae_oom.* are failing.
Most of Vulkan Apps generate these errors in logcat:
... E BufferQueueConsumer: [tech.incr.vulkanandroid/tech.incr.vulkanandroid.MinimalNativeActivity#0](id:85900000010,api:1,p:5060,c:2137) acquireBuffer: max acquired buffer count reached: 2 (max 1)
... E BufferLayerConsumer: [tech.incr.vulkanandroid/tech.incr.vulkanandroid.MinimalNativeActivity#0] updateTexImage: acquire failed: Function not implemented (-38)
while some other apps (vkCube and GearsVK) generate these errors:
... E RenderEngine: failed to wait on fence fd
... E Layer : [Surface(name=Task=136)/@0x832783c - animation-leash#0] No local sync point found
... E Layer : [Surface(name=Task=1)/@0xd82067 - animation-leash#0] No local sync point found
dEQP Test Results:
Module Passed Failed Total
dEQP-VK 568820 79 568899
(v4) Vulkan HAL implement nvk specific ANB gralloc and synchronization, inspired by llvmpipe ANB
Changelog:
nvk_android.c: nvk_GetSwapchainGrallocUsageANDROID, nvk_AcquireImageANDROID, nvk_QueueSignalReleaseImageANDROID
implemented as porting of llvmpipe commit 0dce939e with 's/lvp_/nvk_/g' for functions rename
NOTE: at this stage nvk_GetSwapchainGrallocUsageANDROID is only setting gralloc SW usage flags
nvk_image.h: NVK_MAX_PLANE_COUNT 1 - NOTE: I don' know how many max planes are supported by NVK
Achievements:
GearsVK working
dEQP-VK tests produce colored output on screen
3DMARK API Overhead, Slingshot Extreme: running but meshes are not rendered
Other Vulkan API enabled Android Apps (Sascha Willems vulkanTriangle) are showing black surface,
which is due to basic gralloc SW usage flags implemented in nvk_GetSwapchainGrallocUsageANDROID()
dEQP Test Results:
Module Passed Failed Total
dEQP-VK 568820 79 568899
The failed tests are in the following modules/test:
dEQP-VK.api.driver_properties#driver_id_match 1
dEQP-VK.pipeline.multisample.min_sample_shading_enabled.* 9
dEQP-VK.pipeline.multisample.min_sample_shading.* 56
dEQP-VK.sparse_resources.image_sparse_binding.cube_array.rgba32i#256_256_6 1
dEQP-VK.sparse_resources.image_sparse_binding.cube_array.rgba32ui#256_256_6 1
dEQP-VK.ssbo.layout.random.all_shared_buffer#5 1
dEQP-VK.wsi.android.swapchain.simulate_oom 10
(v5) use ANB common code for GetSwapchainGrallocUsage*ANDROID
Changelog:
Replace the "SW usage only" nvk_GetSwapchainGrallocUsage{,2}ANDROID
and rely on vk_common_GetSwapchainGrallocUsage{,2}ANDROID
Achievements:
Vulkan Apps are rendering on screen
Tested on Android 11 with Vulkan 1.1 API
Android apps working:
Khronos Vulkan-Samples
Sacha Willems Vulkan Examples
Vulkan Android Test
vkCube
GearsVK
PPSSPP
3DMARK API Overhead, Slingshot Extreme - Still with meshes issue
dEQP Test Results:
Module Passed Failed Total
dEQP-VK 568820 79 568899
The failed tests are in the following modules/test (same as per previous iteration):
dEQP-VK.api.driver_properties#driver_id_match 1
dEQP-VK.pipeline.multisample.min_sample_shading_enabled.* 9
dEQP-VK.pipeline.multisample.min_sample_shading.* 56
dEQP-VK.sparse_resources.image_sparse_binding.cube_array.rgba32i#256_256_6 1
dEQP-VK.sparse_resources.image_sparse_binding.cube_array.rgba32ui#256_256_6 1
dEQP-VK.ssbo.layout.random.all_shared_buffer#5 1
dEQP-VK.wsi.android.swapchain.simulate_oom# 10
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30833>
Required to compile nvk for android
Fixes the following building error:
FAILED: src/nouveau/compiler/nak_bindings.rs
...
/usr/include/xf86drm.h:40:10: fatal error: 'drm.h' file not found
panicked at 'Unable to generate bindings: ClangDiagnostic("/usr/include/xf86drm.h:40:10:
fatal error: 'drm.h' file not found\n")', main.rs:52:36
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30833>
On A7XX reading fragment shading rate correctly requires declare
SAMPLEMASK input. It doesn't need to be used anywhere, just declared.
This workaround was seen in the prop driver v512.762.12
Fixes a lot of tests in:
dEQP-VK.fragment_shading_rate.*
Fixes: 2ab8eff511
("tu/a7xx: Implement VK_KHR_fragment_shading_rate")
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32335>
FSR with VK_EXT_post_depth_coverage enabled has wrong values of
gl_SampleMaskIn[0]. Prop driver has fragmentShadingRateWithShaderSampleMask
enabled, but it doesn't support VK_EXT_post_depth_coverage.
Sample mask is supplied by HW and there is no flag in sight to fix it.
The failing tests were:
dEQP-VK.pipeline.fast_linked_library.multisample_with_fragment_shading_rate.sample_mask_with_depth_test.samples_2_post_depth_coverage
dEQP-VK.pipeline.fast_linked_library.multisample_with_fragment_shading_rate.sample_mask_with_depth_test.samples_4_post_depth_coverage
dEQP-VK.pipeline.monolithic.multisample_with_fragment_shading_rate.sample_mask_with_depth_test.samples_2_post_depth_coverage
dEQP-VK.pipeline.monolithic.multisample_with_fragment_shading_rate.sample_mask_with_depth_test.samples_4_post_depth_coverage
dEQP-VK.pipeline.pipeline_library.multisample_with_fragment_shading_rate.sample_mask_with_depth_test.samples_2_post_depth_coverage
dEQP-VK.pipeline.pipeline_library.multisample_with_fragment_shading_rate.sample_mask_with_depth_test.samples_4_post_depth_coverage
Fixes: 2ab8eff511
("tu/a7xx: Implement VK_KHR_fragment_shading_rate")
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32335>
The Mesa log infrastructure is really useful as it allows us to get
debug and error information in Android systems. Apart from that, it also
allows us to forward diagnostics into the right logs and files.
Therefore, instead of using stderr for all messages, use Mesa log and
separate the messages into debugging and error messages.
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32304>
This commit adds support for incremental rendering on V10+ in PanVK by
setting a tiler out-of-memory exception handler in the fragment subqueue
when waiting for the tiler work to complete.
In case the tiler is unable to finish its work due to lack of memory,
the handler is invoked which will render out the fragment work available
so far, recycle the tiler heap memory and trigger a preload for the
remaining fragment work.
Once the fragment subqueue is made aware that the tiler work has
completed, it will disable the exception handler until the state for the
next renderpass has been set up correctly, as we could otherwise get the
handler invoked based on state from a previous renderpass.
The implementation based on the similar implementation in Panfrost [1],
but works slightly differently due to PanVK utilizing multiple subqueues
and supporting layered rendering.
[1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31174
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31941>
Start explicitly passing the pan_fb_info-pointer to use for building
preloads rather than implicitly fetching it from the passed
command_buffer.
This allows building preloads for different fb_infos, which is required
for incremental rendering.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31941>
The pass converts:
...
%.. = load_deref(input)
to:
temp = copy_deref(input) // beginning of the shader
...
%.. = load_deref(temp)
If interp_deref_at_* occurs between copy_deref and load_deref,
the interp_deref_at_* lowering overwrites temp, so all future
load_deref(temp) return the result of interp_deref_at_* instead of
copy_deref, which is incorrect.
The issue manifests when the same input is used by both load_deref
and interp_deref_at_* in the same shader and when interp_deref_at_*
happens to be before load_deref.
This fixes it by using a completely new temporary for each instance
of interp_deref_at_*.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32344>
This imports 35 libdrm_amdgpu functions into Mesa.
The following 15 functions are still in use:
amdgpu_bo_alloc
amdgpu_bo_cpu_map
amdgpu_bo_cpu_unmap
amdgpu_bo_export
amdgpu_bo_free
amdgpu_bo_import
amdgpu_create_bo_from_user_mem
amdgpu_device_deinitialize
amdgpu_device_get_fd
amdgpu_device_initialize
amdgpu_get_marketing_name
amdgpu_query_sw_info
amdgpu_va_get_start_addr
amdgpu_va_range_alloc
amdgpu_va_range_free
We can't import them because they make sure that we only use 1 VMID
per process shared by all APIs. (except the marketing name)
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32067>
Builtin functions do no make use of gl_shader at all other than to store
a symbol table. So lets just create and use the symbol table directly
instead. This will allow us to drop the symbol table member from
gl_shader in the following patch.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32293>
The DETECT_OS_LINUX constant defined in util/detect_os.h allows
replacing the ocurrences of defined(__linux__) and __linux__. They
are equivalent in functionality but the util's one is easier to read and
write. Also it does not require the define() syntax.
The change involve replacing every ocurrence of defined(__linux__) with
DETECT_OS_LINUX. Then replacing every ocurrence of #ifdef __linux__
with #if DETECT_OS_LINUX.
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32286>
The DETECT_OS_FUCHSIA constant defined in util/detect_os.h allows
replacing the ocurrences of defined(__Fushsia__) and __Fuschsia__. They
are equivalent in functionality but the util's one is easier to read and
write. Also it does not require the define() syntax.
The change involve replacing every ocurrence of defined(__Fuchsia__) with
DETECT_OS_FUCHSIA. Then replacing every ocurrence of #ifdef __Fuchsia__
with #if DETECT_OS_FUCHSIA.
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32286>
The DETECT_OS_ANDROID constant defined in util/detect_os.h allows
replacing the ocurrences of defined(__ANDROID__) and __ANDROID__. They are
equivalent in functionality but the util's one is easier to read and
write. Also it does not require the define() syntax.
The change involve replacing every ocurrence of defined(__ANDROID__) with
DETECT_OS_ANDROID. Then replacing every ocurrence of #ifdef __ANDROID__
with #if DETECT_OS_ANDROID.
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32286>
We've supported GL_ARB_transform_feedback3 since 2019,
GL_ARB_draw_indirect and GL_ARB_texture_cube_map_array since 2021.
...you get the picture. There's more, and they've all been around for a
good while. But it seems we forgot to tell features.txt about them.
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32300>
Both of GL_OES_sample_shading and GL_OES_shader_multisample_interpolation
are enabled on panfrost when GL_OES_gpu_shader5 is enabled. And that's
the case on Bifrost and later, but not Midgard.
Let's fix up features.txt to match reality here.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32300>
We always support the extension. Wether we support any formats or not
depends on one of two conditions:
1. If Mesa is built with shader-cache support or not, which is not a
driver decision.
2. If GL_ARB_gl_spirv is supported or not, which is covered elsewhere.
So there's no reason to list individual drivers here, as that doesn't
really change anything.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32300>
When simul_use=true, the tiler descriptors are allocated from
the descriptor ringbuf. We set state.gfx.render.tiler to a
non-NULL value to satisfy the is_tiler_desc_allocated() tests,
but we want it to point to a faulty address so we can easily
detect if it's used in the command stream/framebuffer
descriptors.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32213>
Fix cross command buffer render pass suspend/resume by
emitting a render context (tiler+framebuffer descriptors)
on suspend that we can re-use on resume.
This involves splitting the issue_fragment_jobs() logic to
decouple the framebuffer descriptor initialization and the
run_fragment emission. This also requires patching a few
places where we were testing the tiler/fbd values to
determine if we are in a render pass, which no longer works
when a render pass is resumed.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32213>
We don't need to check anymore if this was already applied and it turned
out the check was not working properly in the first place.
The check for vs is kept in place, because that one still detects that
few wine shaders already have the sin/cos input in correct range.
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/32160>
finalize_nir requires that calling it multiple times on the same shader
doesn't break it.
RV530 shader-db:
total instructions in shared programs: 132915 -> 132851 (-0.05%)
instructions in affected programs: 2016 -> 1952 (-3.17%)
helped: 16
HURT: 0
total temps in shared programs: 18238 -> 18232 (-0.03%)
temps in affected programs: 42 -> 36 (-14.29%)
helped: 6
HURT: 0
total cycles in shared programs: 197510 -> 197446 (-0.03%)
cycles in affected programs: 2102 -> 2038 (-3.04%)
helped: 16
HURT: 0
Reviewed-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/32160>
When dealing with AFBC render targets using wide blocks, the GPU needs to
keep rendering tiles that are a multiple of 16x16. This is described
as AFBC render block size, and adds extra constraints:
- render target buffers need to be aligned on 16 pixels in the vertical
direction, even if the AFBC super block size is 4 or 8 pixels.
- if the effective tile size is smaller than the render block size, we
should force a clean write and discard+ignore the CRC
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31948>
This allows using the tile size to make decisions not related to the
framebuffer descriptor. Mainly, for the near future, to decide
whether some tiling hierarchy levels should be disabled.
The color buffer allocation size is also calculated at the same time
as it's using common data underneath.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31948>
In certain cases, the hardware fails to properly process a mipmap level
of these special stencil and depth formats. This happens at width=16.
This change adds a software workaround.
Modifying the corresponding mipmap nblk_x, and the other related
values, could make the tests below to work. Anyway, this method
generates regressions.
This change was tested on palm and cayman and fixes the following tests:
spec/arb_framebuffer_object/framebuffer-blit-levels read stencil: fail pass
spec/arb_depth_buffer_float/fbo-clear-formats stencil/gl_depth32f_stencil8: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31957>
This situation is happening, for instance, when the hardware is
using the type FMT_8_8_8_8 (4 bytes) while the software was
requesting a 3 bytes type. The width should be adjusted to the
expected hardware size; otherwise, the last vertex is lost.
Note: The rv770 didn't behave like this. This is definitely
a hardware change between these gpus.
This change was tested on palm and cayman. Here are the tests fixed:
spec/!opengl 2.0/gl-2.0-vertexattribpointer-size-3: fail pass
deqp-gles2/functional/draw/random/62: fail pass
deqp-gles2/functional/vertex_arrays/single_attribute/strides/buffer_0_32_byte3_vec4_dynamic_draw_quads_1: fail pass
deqp-gles2/functional/vertex_arrays/single_attribute/strides/buffer_0_32_short3_vec4_dynamic_draw_quads_1: fail pass
deqp-gles2/functional/vertex_arrays/single_attribute/strides/buffer_0_32_short3_vec4_dynamic_draw_quads_256: fail pass
deqp-gles3/functional/draw/random/117: fail pass
deqp-gles3/functional/vertex_arrays/single_attribute/strides/byte/buffer_stride32_components3_quads1: fail pass
deqp-gles3/functional/vertex_arrays/single_attribute/strides/short/buffer_stride32_components3_quads1: fail pass
deqp-gles3/functional/vertex_arrays/single_attribute/strides/short/buffer_stride32_components3_quads256: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32184>
This change fixes the evergreen nonconformity issue on non-mipmap
textures when the minification and the magnification are not in
the same state.
This modification disables 5278436d67 when the minification and
the magnification are different. This fixes the nonconformity
without new regressions. Anyway, I was unable to reproduce
the issue described by 5278436d67 on palm and cayman.
This change was tested on cayman and palm. It fixes 84 deqp-gles2
tests and 128 deqp-gles3 tests:
deqp-gles2/functional/texture/filtering/2d/linear_nearest_*
deqp-gles2/functional/texture/filtering/2d/nearest_linear_*
deqp-gles2/functional/texture/filtering/cube/linear_nearest_*
deqp-gles2/functional/texture/filtering/cube/nearest_linear_*
deqp-gles2/functional/texture/vertex/2d/filtering/linear_nearest_*
deqp-gles2/functional/texture/vertex/2d/filtering/nearest_linear_*
deqp-gles2/functional/texture/vertex/cube/filtering/linear_nearest_*
deqp-gles2/functional/texture/vertex/cube/filtering/nearest_linear_*
deqp-gles3/functional/texture/filtering/2d/combinations/linear_nearest_*
deqp-gles3/functional/texture/filtering/2d/combinations/nearest_linear_*
deqp-gles3/functional/texture/filtering/2d_array/combinations/linear_nearest_*
deqp-gles3/functional/texture/filtering/2d_array/combinations/nearest_linear_*
deqp-gles3/functional/texture/filtering/3d/combinations/linear_nearest_*
deqp-gles3/functional/texture/filtering/3d/combinations/nearest_linear_*
deqp-gles3/functional/texture/filtering/cube/combinations/linear_nearest_*
deqp-gles3/functional/texture/filtering/cube/combinations/nearest_linear_*
deqp-gles3/functional/texture/vertex/2d/filtering/linear_nearest_*
deqp-gles3/functional/texture/vertex/2d/filtering/nearest_linear_*
deqp-gles3/functional/texture/vertex/2d_array/filtering/linear_nearest_*
deqp-gles3/functional/texture/vertex/2d_array/filtering/nearest_linear_*
deqp-gles3/functional/texture/vertex/3d/filtering/linear_nearest_*
deqp-gles3/functional/texture/vertex/3d/filtering/nearest_linear_*
deqp-gles3/functional/texture/vertex/cube/filtering/linear_nearest_*
deqp-gles3/functional/texture/vertex/cube/filtering/nearest_linear_*
Fixes: 5278436d67 ("r600: force LOD range to be only one value when mip.min filter is NONE")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32185>
On evergreen depth-stencil textures are allocated as two objects, and
when using the eg_surface_init_1d_miptrees code path the size evaluation
uses the generalized surf_minify function. Here when allocating the
depth texture the alignment takes the depth bpe value into account, and
uses bpe=1 for the stencil texture. As a result the texture pair may
consist of textures with two different nblk_x sizes and this seems to
be a problem with some textures, namely npot and small (width < 32), but
not for mipmapped textures. In the problematic cases, if the so allocated
depth texture is larger than the stencil texture, then the kernel may reject
sent data with an error message like:
evergreen_cs_track_validate_stencil:622 stencil read bo too
small (layer size 131072, offset 524288, max layer 1, bo size 606208)
- because apparently the expected layer size is evaluated from the depth
texture size, but the actual bo size is evaluated based on the true texture
size values. If, on the other hand, the stencil texture is larger than the
depth texture, then the data is send with a wrong alignment, and certain
dEQP-GLES31 tests fail.
In order to obtain equal texture sizes in the problematic cases magnify
the depth texture alignment requirement by its bpe, so that the relative
alignment is the same for depth and stencil texture.
Fixes:
dEQP-GLES31.functional.stencil_texturing.format
.depth32f_stencil8_2d
.depth32f_stencil8_2d_array
.depth24_stencil8_2d
.depth24_stencil8_2d_array
.stencil_index8_2d
.stencil_index8_2d_array
.depth32f_stencil8_draw
.depth24_stencil8_draw
dEQP-GLES31.functional.texture.border_clamp.formats
.stencil_index8.nearest_size_npot
.depth24_stencil8_sample_stencil.nearest_size_npot
.depth32f_stencil8_sample_stencil.nearest_size_npot
dEQP-GLES31.functional.texture.border_clamp.per_axis_wrap_mode.texture_2d
.uint_stencil.nearest.s_clamp_to_edge_t_clamp_to_border_npot
.uint_stencil.nearest.s_repeat_t_clamp_to_border_npot
.uint_stencil.nearest.s_mirrored_repeat_t_clamp_to_border_npot
piglits:
arb_framebuffer_object-depth-stencil-blit *stencil*
framebuffer-blit-levels draw stencil
arb_texture_stencil8/
texwrap formats offset/gl_stencil_index8, npot
texwrap formats/gl_stencil_index8, npot
ext_framebuffer_multisample
accuracy all_samples stencil_resolve small depthstencil
unaligned-blit * stencil downsample
ext_texture_array/fbo-depth-array *stencil
egl_khr_gl_renderbuffer_image-clear-shared-image gl_depth_component24
v2: use util_is_power_of_two_or_zero (Marek)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32169>
I don't know of any case of Apple's driver using this, but it seems to work. The
stream link bit is identical to VDM so that was easy, the tricky part was the
return but I bruteforced the encoding space and this is the (only) thing that
worked. So add the XML.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32320>
can help a lot for scratchy shaders. affected shader is a compute shader in
graphics bench.
total instructions in shared programs: 2751334 -> 2750950 (-0.01%)
instructions in affected programs: 4308 -> 3924 (-8.91%)
helped: 2
HURT: 0
total bytes in shared programs: 21482512 -> 21480592 (<.01%)
bytes in affected programs: 27448 -> 25528 (-7.00%)
helped: 2
HURT: 0
total fills in shared programs: 732 -> 540 (-26.23%)
fills in affected programs: 396 -> 204 (-48.48%)
helped: 2
HURT: 0
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32320>
This is a small command line utility to generate NIR bindings for a SPIR-V
library, using vtn's infrastructure for this. This is split out from asahi_clc
in an effort to make clc more modular. Notably, this tool does not depend on:
* LLVM, SPIRV-LLVM, CLC, etc (important for Android, and gets us closer to the
clang spir-v future)
* Driver details other than addressing modes (which are already largely
hardcoded, setting them to anything else doesn't make a ton of sense for CL C)
* The driver itself, or its backend compiler. That means that the backend
compiler can depend on the generated bindings header, even if the compiler is
also used for internal shader precompiling. This breaks the dep loop.
So in short term, this solves the dependency problem for asahi, and in the long
term helps more drivers use clc infrastructure without re-rolling things
themselves.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32226>
These fields are only valid in certain formats, so set them accordingly.
Note the check if !is_send is used because FORMAT_BASIC is reused for
SEND/SENDS in some platforms. If we start to see more cases like that,
we can create a new FORMAT for it.
The cond_modifier is trickier because on top of that, it is not valid
for 64-bit immediates in some platforms. Found when EU validation
complained about moving 64-bit immediates with higher bits.
Fixes: e4440df2d8 ("intel/brw: Add pred/cmod/sat to brw_hw_decoded_inst")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32287>
When we create a new swapchain to replace the one currently presenting on
a surface, we need to reset all these timing variables. Otherwise we can
lose track of corrections that were made for the old swapchain when we
delete undelivered presentation feedback results.
Also, we use these variables when queuing a presentation, but we also use
them in the dispatch code that can be called by WaitForPresent from another
thread. We need to protect these variables against concurrent usage.
This is all much easier to do when they're stored as part of the swapchain
instead of the surface, so just move them there and adjust the locking.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Fixes: c26ab1aee1 ("vulkan/wsi/wayland: Pace frames with commit-timing-v1")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32121>
When we start using timestamps, the current code will generate an event
stream like:
feedback
set barrier
wait barrier
commit
feedback
set timestamp
set barrier
commit
wait barrier
commit
The second content update can cause the feedback request from the first to
send a discarded event if the timestamp is in the past.
Be less clever and just put waits in both our content updates.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Fixes: c26ab1aee1 ("vulkan/wsi/wayland: Pace frames with commit-timing-v1")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32121>
When occluded, the current math always rounds down to 0 cycles and leads
to improperly throttled frame delivery.
Improve the comment, and use a formula that leads to generating future
times even when occluded.
Also remove some dead code, as we can never get here with a period of 0.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Fixes: c26ab1aee1 ("vulkan/wsi/wayland: Pace frames with commit-timing-v1")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32121>
Update just enough of the fail list to have a green CI. I'm sure a
no-fraction run would uncover other improvements/failures/flakes, but
the goal here is to detect improvements/regressions introduced by new
MRs, not to make the list accurate. This will be tackled in a follow-up
MR.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32302>
We assume everywhere that RGB is not planar, so sampling
and color space conversions will not work correctly with RGBP.
Drivers can still support RGBP, but processing entrypoint with
shaders doesn't support it.
Fixes: bdb7f36aa8 ("frontends/va: add support for RGBP rt_format")
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32252>
This matches the supported formats we query for in config attributes.
Also prefer YUY2 over YUYV (identical formats), as YUY2 has a VA_FOURCC_YUY2
definition and some applications will only try to use this fourcc code.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32252>
I did half the job in that commit: I split the two apis into two
invocations, but I didn't fix the binary used for the gles one...
Fixes: 14279087fb ("ci/deqp-runner: split gl & gles groups to use the correct binary")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32250>
Currently if you try to probe the virtio ICD on a non-virtio system
it will fail in CreateInstance which causes the loader to spit on the
screen.
However instance creation shouldn't fail, the driver should just
not enumerate any devices in this case. It's a bit tricky to ensure
this, but return instance and then handle instance destruction
and fail device enumeration.
Cc: mesa-stable
Reviewed-by: Ryan Neph
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32266>
Create a CS which contains just a cache flush,
that can be used as a postamble in command submissions.
According to RadeonSI code, the kernel flushes L2
before shaders are finished on GFX6.
Previously, RADV always added a flush at the end of
each command buffer. The flush postamble should be
a less wasteful alternative to that.
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/31695>
- A650+ - should be able to support pipelineFragmentShadingRate
but in some other way than A7XX. Not implemented here.
- A7XX - support pipelineFragmentShadingRate and attachmentFragmentShadingRate
- A740+ - support primitiveFragmentShadingRate
layeredShadingRateAttachments is unsupported at the moment due to tests
failure, but prop driver supports it.
Passes:
dEQP-VK.fragment_shading_rate.*
On A750/A740
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30905>
Raspberry Pi 5 has different drivers for different types of connectors.
For example, HDMI connections are handled through vc4, but DSI
connections are handled through drm-rp1-dsi.
Currently, we only allow vc4 as display driver, which means that, when
we use VK_KHR_display with a DSI display, we won't get any available
displays.
In order to make sure we have available displays when using DSI/DPI/VEC
displays, enumerate all DRM primary nodes and use the first fd that has
a connected output. For example, in the case we have only a DSI display
connected to the RPi 5, it will pick the drm-rp1-dsi as the device. In
the case we have both DSI and HDMI displays connected, it will pick the
first fd that it checks.
Ideally, we would like to see all displays available in the return of
`vkGetPhysicalDeviceDisplayProperties2KHR`, but `wsi->fd` is a variable,
not an array. Therefore, it only supports one fd.
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/32123>
Protocol version 3 used host side resource IDs that may be reused.
Because with older host versions index-buffer binding may go wrong
in this case, we have to check whether the host vrend version is
actually ready for protocol version 3, and if not we re-negotiate
the protocol version only allowing up to version 2.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31624>
There's no reason to calculate this more closely; the Vulkan spec
explicitly allows for it to be conservative. And there's no other Vulkan
driver in Mesa that currently does anything else.
But, we have another reason to limit to this specific value (which also
happens to be the minimum value allowed by the spec); we'll overflow the
32-bits of slice_stride for resources where the product of width, height
and texel-size is over UINT32_MAX. But with this limit in place, we
avoid this.
This limit will go away in v11, beacuse there's an additional five bits
of slice_stride there. But let's leave that for later.
Anyway, let's document why this is the correct limit, insted of having
the FINISHME-comment.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: John Anthony <john.anthony@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32265>
Panvk currently enables VK_EXT_vertex_attribute_divisor, but Mali HW
does not support a non-zero firstInstance when a divisor is used.
supportsNonZeroFirstInstance is correctly set to false to advertise
this, however this property was only added when the extension was
promoted. Thus we need to remove support for
VK_EXT_vertex_attribute_divisor and enable
VK_KHR_vertex_attribute_divisor instead.
Also fixes an issue with non-zero divisor for v10.
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32137>
Sets the default exit code to 1 to ensure the GitLab job fails when the
LAVA job fails or is interrupted. Adds tests to verify the exit code is
correctly set based on the logs or the lack of them (unexpected
finishing: timeouts and canceling).
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32163>
This reverts commit 46bf687882.
We wont be removing this lowering file and having this workaround in
glsl_to_nir() creates a dependency on the const values that we could
otherwise avoid, so lets just move this back. Dropping the consts
will be useful in a follow up series that aims to drop all the glsl
ir function inlining code by converting builtin functions to nir.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32239>
Instead of using unreliable polling to wait for foz db updater to parse
and load from the dynamic list, also use inotify to wait for foz db
updater close the list file after its done updating.
Fixes: 4dfd306454 ("disk_cache: Disable the "List" test for RO disk cache.")
Signed-off-by: Juston Li <justonli@google.com>
Reviewed-by: David Heidelberg <david@ixit.cz>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32237>
It doesn't enable back face culling and small line culling. Those can only
be enabled for monolithic shaders. It only enables view culling and small
triangle culling.
Doing this has these minor advantages:
1. We can enable at least some culling immediately instead of when the first
monolithic shader finishes compilation.
2. If back face culling and clip planes are disabled, we no longer compile
monolithic TES and GS shader variants to get only view culling and small
triangle culling.
3. shader-db will show culling code changes for TES and GS.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32257>
For a TU_PIPELINE_GRAPHICS_LIB we were taking a ref to the descriptor
set layout but never releasing on VK_PIPELINE_COMPILE_REQUIRED.
Since VK_PIPELINE_COMPILE_REQUIRED is technically an error, the user
doesn't call vkDestroyPipeline() for it so the descriptor sets
referenced were never getting freed.
Addresses:
```
Direct leak of 304 byte(s) in 1 object(s) allocated from:
#0 0x7fa5a93ee0 in __interceptor_malloc
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7fa44bac84 in vk_default_alloc ../src/vulkan/util/vk_alloc.c:26
#2 0x7fa32ea5d8 in vk_alloc ../src/vulkan/util/vk_alloc.h:48
#3 0x7fa32ea60c in vk_zalloc ../src/vulkan/util/vk_alloc.h:56
#4 0x7fa32ea750 in vk_descriptor_set_layout_zalloc
../src/vulkan/runtime/vk_descriptor_set_layout.c:49
#5 0x7fa306fc98 in tu_CreateDescriptorSetLayout(VkDevice_T*,
VkDescriptorSetLayoutCreateInfo const*, VkAllocationCallbacks
const*, VkDescriptorSetLayout_T**)
../src/freedreno/vulkan/tu_descriptor_set.cc:161
```
and
```
Direct leak of 48 byte(s) in 1 object(s) allocated from:
#0 0x7f9b4b3ee0 in __interceptor_malloc
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7f9925e900 in ralloc_size ../src/util/ralloc.c:118
#2 0x7f9925e8d4 in ralloc_context ../src/util/ralloc.c:105
#3 0x7f98b4b214 in tu_pipeline_builder_build<(chip)7>
../src/freedreno/vulkan/tu_pipeline.cc:3898
#4 0x7f98b46bd8 in tu_graphics_pipeline_create<(chip)7>
../src/freedreno/vulkan/tu_pipeline.cc:4203
#5 0x7f98b22588 in VkResult
tu_CreateGraphicsPipelines<(chip)7>(VkDevice_T*,
VkPipelineCache_T*, unsigned int, VkGraphicsPipelineCreateInfo const*,
VkAllocationCallbacks const*, VkPipeline_T**)
../src/freedreno/vulkan/tu_pipeline.cc:4234
```
seen in:
dEQP-VK.pipeline.pipeline_library.shader_module_identifier.pipeline_from_id.graphics.4_variants.no_spec_constants.no_pipeline_cache.all_zeros_id.no_exec_properties.vert_tesc_tese_frag
Cc: mesa-stable
Signed-off-by: Karmjit Mahil <karmjit.mahil@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32188>
Combination of concurrent resolve groups and generic clear support on a750
exposed a problem around color and depth/stencil clears. With all resolves
now non-blocking in nature, we need a guarantee that clears issued through
commands will complete before any future resolves.
To achieve that, in case of generic clears being used, a cache flush is
done in order to generate the CCU_RESOLVE_CLEAN event that will ensure any
future resolve will block until the just-emitted clears are completed.
Fixes following flaky CTS tests on a750:
dEQP-VK.pipeline.monolithic.framebuffer_attachment.2d_array_32x32_48x48_4_ms
dEQP-VK.pipeline.pipeline_library.framebuffer_attachment.2d_array_32x32_48x48_4_ms
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Fixes: 25b73dff5a ("tu/a7xx: use concurrent resolve groups")
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32242>
rip the pan_tristate enum from panfrost and move it to common.
I've often wanted some sort of "yes/no/maybe" or "true/false/unknown" or
"always/never/sometimes" data structure. This adds a common one that is
hopefully neutral enough to cover all of the above.
Asahi will use this.
The Intel drivers could be ported to this (brw_sometimes/elk_sometimes), it
should be straightforward but I don't want to do that without being able to
easily test those changes.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32224>
It doesn't feel great that we need to compile multiple identical shaders
just because we're going to toggle a bit in the command-stream, but this
seems to be the current state-of-art in mesa, so hmpf...
It makes state-validation trivial, so there's that.
This is loosely based on what NVK does.
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32004>
Use TfLiteDepthwiseConvParams for kTfLiteBuiltinDepthwiseConv2d.
The layout of stride_width, stride_height, and padding struct members
happens to be the same, but we shouldn't depend on that.
This prepares for using the activation, dilation_width_factor, and
dilation_height_factor members, which are at different offsets.
Reviewed-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31981>
The BO list member isn't the head/entrypoint for a list, but is only
to be used to link the BO in various lists, so it should not be
initialized as a list head.
Now that the member is properly NULL initialized, we can use the
proper list_is_linked() function to check if the BO is on any
cache bucket or the zombie list.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32233>
Also ensure that 'needs_scratch_reg' is always true if SCC might be overwritten.
Few changes, because some p_split_vector get SCC as scratch reg assigned,
and thus, can inhibit some postRA optimizations.
Totals from 3 (0.00% of 79395) affected shaders: (Navi31)
Instrs: 10501 -> 10500 (-0.01%); split: -0.02%, +0.01%
CodeSize: 51580 -> 51520 (-0.12%); split: -0.12%, +0.01%
Latency: 84166 -> 84174 (+0.01%)
InvThroughput: 13109 -> 13111 (+0.02%)
SALU: 859 -> 860 (+0.12%)
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32217>
This was just broken because individual shaders were still stored
on-disk in many situations:
- for shader object, all compute/graphics shaders were stored
- for fast-GPL, graphics shaders were stored
- for pipeline binaries, when the create flag was used
- for rt capture/replay and ray history
This should stop storing unused binaries on-disk and save space.
Found this by inspection.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32227>
We updated maxImageDimension2D etc to report the actual max size, but we
forgot to update GetPhysicalDeviceImageFormatProperties in the same way.
Let's do that to make things consistent.
This fixes the following CTS test-case:
dEQP-VK.wsi.wayland.swapchain.create.image_extent
Fixes: d5ed77800e ("panvk: Fix GetPhysicalDeviceProperties2() to report accurate info")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32221>
On modern Mali GPUs, we can have 16 bits for the X and Y sizes, already
overflowing 32-bit barrier even with a single layer of byte-sized
formats.
So let's make sure we have enough bits to avoid overflows here.
Fixes: d5ed77800e ("panvk: Fix GetPhysicalDeviceProperties2() to report accurate info")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32221>
There is no good reason to use interlaced surfaces when progressive
is supported and it only creates issues when exporting the surface
or trying to do transcoding.
This allows to remove all workarounds that handled reallocating
from interlaced to progressive because a given operation would not
work for interlaced.
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32095>
No functional change, just move i915 specific data to a struct
and check for kmd_type where appropriate. This will make the
next patch (which adds Xe KMD support here) cleaner.
This patch had to make intel_kmd.h header C++ friendly so it
can use its symbols.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32194>
deqp-runner version is 0.20.2 already. But we would like to keep
MESA_VK_ABORT_ON_DEVICE_LOSS globally because, without it, after the
first VK_ERROR_DEVICE_LOST in a test group, the error is sticky and the
remaining tests will be considered failed as well.
deqp-vk gained --deqp-terminate-on-device-lost since 1.3.8.0 and enabled
it by default since 1.3.10.0. But let's prefer our own mechanism.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32228>
The meaning is negated.
This NIR option is deprecated and shouldn't be used. It means any IO
optimizations can be disabled and it's a currently a workaround for zink,
which is the only driver that asks for it by default. The original option
is replaced by an environment variable for the GLSL linker.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32173>
If we have NIR such as:
32x4 %48 = @load_vulkan_descriptor (%47) (desc_type=SSBO)
32x4 %76 = deref_cast (tint_symbol_11 *)%48 (ssbo tint_symbol_11) (ptr_stride=0, align_mul=4, align_offset=0)
32x4 %77 = deref_struct &%76->tint_symbol_10 (ssbo int) // &((tint_symbol_11 *)%48)->tint_symbol_10
A single nir_rematerialize_deref_in_use_blocks() will rematerialize the
deref_struct and then it's deref_cast. However,
nir_foreach_instr_reverse_safe is not safe if the next iteration's
instruction is removed. This can result in the instruction loop exiting
and the load_vulkan_descriptor never having an LCSSA phi.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Fixes: 439e8c42cc ("nir/lcssa: Fix rematerializing derefs")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11770
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32225>
This was needed because of the issue with using NV12 regardless
of RT format that was fixed in previous commit.
There was a special case for AV1, because AV1 Profile 0 supports
both 8 and 10 bit, but this is also not needed anymore.
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32089>
If applications doesn't send any attributes to describe the format,
we would always use driver preferred format (NV12). This is wrong
for any RT format other than the driver preferred (YUV420).
Driver doesn't have a choice here, we must use the matching format.
Cc: mesa-stable
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32089>
The code wants the number of components used by the variable in the
current attribute slot, not the total number of components.
For e.g. a 4x3 matrix, glsl_get_components() returns 12, leading to the
following error reported by AddressSanitizer:
```
Test case 'dEQP-VK.tessellation.shader_input_output.cross_invocation_per_patch_mat4x3'..
../src/compiler/nir/nir_lower_io_to_vector.c:265:16: runtime error: index 4 out of bounds for type 'nir_variable *[4]'
```
Fixes: 5ef2b8f1f2 ("nir: Add a pass for lowering IO back to vector when possible")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32193>
assert(!shader->key.ps.part.prolog.force_persp_center_interp ||
(!G_0286CC_PERSP_SAMPLE_ENA(input_ena) && !G_0286CC_PERSP_CENTROID_ENA(input_ena)));
failed when all FS inputs have been eliminated by optimizations, which
causes LLVM to set PERSP_SAMPLE_ENA because at least 1 of those must be
enabled, which this code didn't expect.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32186>
The semantics of this newly introduced system value match
Vulkan's InstanceIndex exactly, and are equivalent to
instance_id + base_instance.
Some hardware, such as Mali Valhall or later, only provides
instance id offset by base_instance. Introducing a new system
value to represent this, rather than handling the mismatch
when lowering to BIR lets us use NIR to eliminate redundant
arithmetic that would follow from mismatched semantics, e.g.
instance_id could be lowered to instance_index - base_instance,
so expressions such as instance_id + base_instance would be
optimized to a simple instance_index.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32158>
The game aliases two images. It binds a memory object to two different
images, the first one being an image with 4 mips and the second with
only one mip but the bind offset is incorrect. It's like it queried
the first image size with different usage flags, so that DCC was
disabled.
Force disabling DCC for mips fixes the incorrect rendering and doesn't
hurt performance.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10200
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32190>
There are new combinations of ordered and unordered dependencies
available for the instructions to use, which among others include:
- combining FLOAT and INT pipe deps in SENDs;
- combining SRC mode deps in regular instructions for the inferred type.
This patch enables a couple of tests checking for the first case.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31375>
A recent algebraic opt made a function that used to inline
with llvmpipe CL not inline anymore. However that function
has a barrier in it.
Handling barriers from inside a callstack is hard for llvmpipe
coroutines, so just force functions with barriers to be inlined.
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32204>
The spec says that the user-specified srcStageMask/srcAccessMask should
be ignored for the acquire operation and the user-specified
dstStageMask/dstAccessMask should be ignored for the release operation.
Since we don't need any special handling for VK_QUEUE_FAMILY_EXTERNAL,
override them to NONE.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32164>
In two functions implementing resource discard rebind_resource is called
on resource before its track record is reset. This prevents update of
dirty_resource or dirty_shader_resource because of conditions in
needs_dirty_resource. With rsc->track reset and dirty_resource bits
missing further calls to transfer_map will not try to reallocate
resource storage when needed.
A way to reproduce the issue in both functions is by executing at least
3 draws modifying bound texture or VBO each time. This patch fixes those
cases and some related piglit tests on a5xx and should fix it on other
GPUs. Also it fixes rendering in Firefox and vsraytrace (except vertical
line at right edge).
Fixes: 0a62a874fc ("freedreno: Re-work dirty-resource tracking")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10374
Reviewed-by: Rob Clark <robclark@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32167>
Many debug flags influence shader codegen but are currently not included
in the hash key. This causes surprising effects as cache lookups may
return shaders compiled with different debug flags than currently in
effect. This patch fixes this by including all debug flags in the
shader hash key.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: c323848b0b ("ir3, tu: Plumb through support for per-shader robustness")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32052>
This is mostly a developer preference issue. Some Android
devs like to commit auto-generated files for ${reasons},
though the style of Mesa is not to do so.
I personally like the Mesa style, since otherwise a 25 million
LoC project would be 40 million, but whatever.
An easy solution to just to check them in AOSP Mesa, but not
in upstream. There are various mechanisms, particularly
auto-rollers, that enable this. For example, there is no plan to
check in Blueprint files upstream, but they will be checked-in
and committed by the auto-roller.
For the scheme to work, we'll need slightly different meson
rules when the build target is Android versus otherwise.
Reviewed-by: Marcin Radomski <dextero@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32148>
Removed a function that creates anonymous file descriptors when called.
Additionally replaced a call of said function with the one from the "util"
directory. The intention is to avoid repeated functionality
util: Allow code to be compatible in c++ compilers
Added an extern "C" statement and preprocessor directives to make the
“os_create_anonymous_file” function compatible with c++ compilers
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32096>
Prevents the next patch from failing CTS tests such as:
dEQP-VK.api.image_clearing.core.clear_color_image.*.b4g4r4a4*
Brings back the feature that was introduced in commit 46187bb54f
("anv: Swizzle fast-clear values"), but went unused in commit
721d0c3e77 ("anv,hasvk: Always use BLORP_BATCH_NO_UPDATE_CLEAR_COLOR").
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32187>
We're going to drop a generic restriction on clear color conversions in
anv_can_fast_clear_color(). Without preparing for it, the following
tests would fail:
* piglit.spec.arb_framebuffer_srgb.blit texture srgb msaa disabled clear.gen9_zinkm64
* piglit.spec.arb_framebuffer_srgb.blit renderbuffer srgb msaa disabled clear.gen9_zinkm64
* piglit.spec.arb_framebuffer_srgb.blit texture srgb downsample enabled clear.gen9_zinkm64
* piglit.spec.arb_framebuffer_srgb.blit renderbuffer srgb downsample enabled clear.gen9_zinkm64
* piglit.spec.arb_framebuffer_srgb.blit renderbuffer srgb msaa enabled clear.gen9_zinkm64
* piglit.spec.arb_framebuffer_srgb.blit texture srgb msaa enabled clear.gen9_zinkm64
So, add support for sRGB sampling via BLORP transfer operations and drop
the gfx9-specific restriction on sRGB fast-clears.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32187>
We have to honor drivers when they say that different interpolation
qualifiers can't be mixed in the same vec4, indicated by
nir_io_has_flexible_input_interpolation_except_flat not being set.
This is a prerequisite for enabling nir_opt_varyings for all drivers.
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32174>
The main difference between load_global and load_global_constant is that
the latter can be reordered arbitrarily. If the access being lowered is
already tagged as being reorderable, then we can preserve that by using
the load_global_constant intrinsics instead of load_global. This gives
us more flexibility.
On Intel, this lets us use the load_global_constant_uniform_block_intel
intrinsic for doing convergent block loads in more cases. This nets us
significant reductions in spill/fills: Borderlands 3 on Lunarlake sees
spills/fills reduced by 53%. Alchemist sees a 13% reduction.
Improves performance of Borderlands 3 DX12 on Intel Battlemage by
around 44%. Improves Hogwarts Legacy by around 14%.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31995>
We were accidentally doing a signed integer comparison here for ult32,
or a sign-extending shift for ushr.
One notable bit of fallout was that load_global_uniform_block_intel
address calculations broke on platforms that don't have native 64-bit
integer support, as the iadd64 lowering for "do I need to carry?" was
using ult32...and performing the wrong comparison. We spotted this in
Borderlands 3 on Alchemist once we turned on other optimizations.
Thanks to Lionel Landwerlin for helping spot the problem!
Fixes: c7b312ad45 ("brw: factor out source extraction for rematerialization")
Fixes: 339630ab05 ("brw: enable A64 loads source rematerialization")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31995>
This was triggering an assertion in the fs_builder::MOV helper that
the destination stride can't be 0 when dispatch_width > 1. What we
want to do is copy the single 64-bit channel of data from the UNIFORM
file to a VGRF. We can use a SIMD1 builder for that.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31995>
Previously, double-buffer mode would apply to all jobs except msaa,
but this is not smart, since not all jobs can benefit from this. In
particular, if jobs load the tile buffer and don't store tiles
double buffer mode won't be effective and we would instead pay the
cost of the smaller tile size so we only want to enable in jobs
that meet these requirements.
In order to achieve this we need to postpone the decision about
double buffering until we know the loads and stores of the job,
which means we need to do this late after we have recorded draws.
This means that by default, we assume no double-buffer mode is
used and if we find we want to enable after emitting the draws
we need to re-compute tile sizes and rewrite the
TILE_BINNING_MODE_CFG packet accordingly.
Making the decison about double-buffer late will also enable us to
add heuristics to decide about double-buffer based on the draw calls
emitted in the job, but we will do this in a separate patch.
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32111>
We want to make the decision about double-buffer enablement much later
when we have enough information to make it. That means we might need
to rewrite this packet, so we need to save a pointer to its location
in the CL.
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32111>
By restricting these limitations up to GFX 12, CCS support
can be present on these cases that we think Xe2+ platform
should support compression.
Noticeably, CCS is allowed on depth resources without HiZ,
multi-sampled resources without CCS, and multi-sampled
stencil resources.
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31496>
Two aux functions are updated to fix piglit test once CCS is enabled on
multi-sampled stencil resources in a following change. As reviewers
suggested, we don't see much value of the assertion.
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31496#note_2601233
Piglit test:
fbo-depthstencil blit default_fb -samples=16 -auto
iris_resolve.c:972: iris_resource_get_aux_state: Assertion
`res->surf.samples == 1 || res->surf.msaa_layout == ISL_MSAA_LAYOUT_ARRAY' failed.
iris_resolve.c:996: iris_resource_set_aux_state: Assertion
`res->surf.samples == 1 || res->surf.msaa_layout == ISL_MSAA_LAYOUT_ARRAY' failed.
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31496>
Using intel_needs_workaround() within a block of GFX version
checker requires extra carefulness on the road because both
of them specify a range of applicable platforms. The WA block
can be unexpectedly skipped once the GFX version checker gets
updated later.
Moving the WA implementation out of the GFX block to decouple
them for more clarity and less chance of messing up next time.
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31496>
If nir_tcs_info::all_invocations_define_tess_levels is true, the pass
doesn't have to insert a barrier and use output loads to get tess level
output values. It can just use the SSA defs that are being stored (or phis
thereof) to get the tess level output values.
The remaining tcs_info fields will be used by the HS shader message.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32171>
Separate KIL counts to the indirection limit, so try to schedule it
within the TEX block on R300/R400, except for small shaders, where we
already know we are fine.
42 gained shaders on R400 (40 Trine and 2 This war of mine) at the
expense of some increase in register pressure.
shader-db:
total temps in shared programs: 18107 -> 18129 (0.12%)
temps in affected programs: 262 -> 284 (8.40%)
helped: 0
HURT: 22
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/32023>
It is an easy way to check that the installation works and is in a
useful state.
The Python script is based on a example in the TensorFlow repository at:
tensorflow/lite/examples/python/label_image.py
The labels file is distributed by Google along the MobileNetV1 model
that we already have. These files are released under the Apache
license.
Reported-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Tested-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Acked-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31860>
Operations other than tensor addition will also need to be able to
handle multiple inputs, and a variable number of them.
And for testing individual operations, we also need to support models
with multiple inputs.
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32105>
When IDVS+malloc is used, there's no linking involved (getting the
VS and FS shaders to agree on the varyings attributes), so we can
purely and simply skip this phase.
If we ever have to support the non-malloc or non-IDVS case, we'll need
to revisit the linking logic anyway, so let's kill the linking on v10
for now.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31911>
We're about to bitset-based driver-internal dirty state tracking, and
we'll need to define new xx_is_dirty() macros, so let's rename the
existing one dyn_gfx_state_dirty() to avoid the confusion, and move it
to panvk_cmd_draw.h, since it's the same for JM and CSF.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31911>
We're going to put the panvk_cmd_graphics_state definition to
panvk_cmd_draw.h, which involves including panvk_cmd_draw.h from
panvk_cmd_buffer.h, which in turn means we can't include
panvk_cmd_buffer.h from panvk_cmd_draw.h.
Kill the circular inclusion by changing the prototype of
panvk_select_tiler_hierarchy_mask() to take a panvk_physical_device
and a panvk_cmd_graphics_state instead of a panvk_cmd_buffer oject.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31911>
The BROADCOM_SAND128 modifier is usually used with an extra parameter
to pass in the stride via a side channel. Quoting from drm_fourcc.h:
> The pitch between the start of each column is set to optimally
> switch between SDRAM banks. This is passed as the number of lines
> of column width in the modifier (we can't use the stride value due
> to various core checks that look at it , so you should set the
> stride to width*cpp).
So apparently this is just a workaround for limitations in some kernel
APIs. DRM modifiers, however, are arguably a bad fit for extra
parameters that aren't known in advance. In the Wayland/KMS ecosystem
many components depend on being able to treat modifiers as opaque, e.g.
for negotiations etc. In practice the current approach requires various
software components to manually use the
`DRM_FORMAT_MOD_BROADCOM_SAND128_COL_HEIGHT()` macro - using the
`DRM_FORMAT_MOD_BROADCOM_SAND128` modifier directly with formats like
`NV12` results in a rejection in the KMS driver and corrupted output
in Mesa (because we'd bail out early in `v3d_sand8_blit()`).
Fortunately the stride check limitations mentioned above don't seem to
apply to Mesa though. Thus we can just add support for the base modifier
and stride (coming from V4L2), allowing various toolkits, Wayland
compositors and V4L2 decoder implementations to support e.g.
`NV12` + `DRM_FORMAT_MOD_BROADCOM_SAND128` (`NC12` in V4L2) in a generic
way.
Notes:
1. Wayland compositors trying to offload composition to KMS will still
fail when doing a test commit.
2. There is another limitation - in the V4L2 MPLANE API - that
requires userspace to know the correct offset of the second plane. That's
a known API limitation though and only affects V4L2 decoder implementations.
Cc: mesa-stable
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32033>
This fixes a corner case of the LNL sub-dword integer restrictions
that wasn't being detected by has_subdword_integer_region_restriction(),
specifically:
> if(Src.Type==Byte && Dst.Type==Byte && Dst.Stride==1 && W!=2) {
> // ...
> if(Src.Stride == 2) && (Src.UniformStride) && (Dst.SubReg%32 == Src.SubReg/2 ) { Allowed }
> // ...
> }
All the other restrictions that require agreement between the SubReg
number of source and destination only affect sources with a stride
greater than a dword, which is why
has_subdword_integer_region_restriction() was returning false except
when "byte_stride(srcs[i]) >= 4" evaluated to true, but as implied by
the pseudocode above, in the particular case of a packed byte
destination, the restriction applies for source strides as narrow as
2B.
The form of the equation that relates the subreg numbers is consistent
with the existing calculations in brw_fs_lower_regioning (see
required_src_byte_offset()), we just need to enable lowering for this
corner case, and change lower_dst_region() to call lower_instruction()
recursively, since some of the cases where we break this restriction
are copy instructions introduced by brw_fs_lower_regioning() itself
trying to lower other instructions with byte destinations.
This fixes some Vulkan CTS test-cases that were hitting these
restrictions with byte data types.
Fixes: 217d412360 ("intel/fs/gfx20+: Implement sub-dword integer regioning restrictions.")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30630>
Since the shader parameters are passed as inline data, push constants
are no longer used and so, not actually set on dispatch. But the
nr_params = 4 was still making the shader emit the code to load them,
causing page faults on simulation, and would also on HW if we didn't
always have a scratch page set.
The uses_inline_data parameter will be set from brw_compile_cs(), called
shortly after this point, so we don't need it here.
The subgroup_size is misleading, as we don't actually require that size
and the code that checks for it isn't even running for this shader.
Fixes: 97b17aa0b1 ("brw/nir: rework inline_data_intel to work with compute")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12152
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32150>
From the perspective of the gpu, host read or host write has the same
implication (gpu cache flush) in the dst access flags. We should
include host write in the dst access flags.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32102>
Fragments are processed in rasterization order within a fragment job.
The fragment subqueue self-wait is nop in most cases. The only
exception is when there is a feedback loop.
When there is a feedback loop, because we lower subpassLoad to
texelFetch, we have to split the render pass.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32074>
src_stages and dst_stages together define an execution dependency. Both
of them should be considered at the same time.
Add a low-level helper, add_execution_dependency, to translate pipeline
stages to subqueue wait masks. The subqueue wait masks only specify
which subqueues should wait for which. The callers will decide how the
waits are performed exactly.
Update collect_cs_deps to call add_execution_dependency and use the
subqueue wait masks to initialize panvk_cs_deps.
The main difference is that barriers such as
.srcStageMask = VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
.dstStageMask = VK_PIPELINE_STAGE_2_NONE,
are ignored.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32074>
src_access defines the availability op and the host-to-device domain op.
dst_access defines the visibility op and the device-to-host domain op.
They should be treated separately.
Add a low-level helper, add_memory_dependency, to translate access flags
to panvk_cache_flush_info.
Update collect_cache_flush_info to use add_memory_dependency. Also
replace the custom subqueue access flag mappings by
vk_filter_{src,dst}_access_flags2.
The main difference is that barriers such as
.srcAccessMask = VK_ACCESS_2_MEMORY_WRITE_BIT,
.dstAccessMask = VK_ACCESS_2_NONE,
or
.srcAccessMask = VK_ACCESS_2_NONE,
.dstAccessMask = VK_ACCESS_2_MEMORY_READ_BIT,
are no longer ignored.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32074>
Adds an optional region selection, based off percentages of the
starting/ending of an image's X & Y values.
This is intended as a performance enhancement tradeoff for smaller
images to be created.
With a smaller image size, the screenshotting layer will change the
region boundaries on the GPU side, which will decrease the amount of
time it takes to copy the image over to CPU-accessible memory.
Using vkcube as an example, the original image size is 500x500:
mesa-screenshot: DEBUG: Screenshot Authorized!
mesa-screenshot: DEBUG: Needs 2 steps
mesa-screenshot: DEBUG: Time to copy: 123530 nanoseconds
Then, by cropping the area to a 100x100 image, we get the following:
mesa-screenshot: DEBUG: Screenshot Authorized!
mesa-screenshot: DEBUG: Using region: startX = 40% (200), startY = 40% (200), endX = 60% (300), endY = 60% (300)
mesa-screenshot: DEBUG: Needs 2 steps
mesa-screenshot: DEBUG: Time to copy: 12679 nanoseconds
For this example, this is a ~90% time reduction improvement!
Overall, this option reduces the copy time to a point where it can
become negligible, relative to the frame time of the application.
Signed-off-by: Casey Bowman <casey.g.bowman@intel.com>
Reviewed-by: Felix DeGrood felix.j.degrood@intel.com
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32016>
Lots of tests are hitting the assert, one in particular :
dEQP-VK.binding_model.mutable_descriptor.single.switches.sampler_combined_image_sampler.update_copy.nonmutable_source.normal_source.pool_same_types.pre_update.no_array.comp
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: b6d11ba5b4 ("anv: Protect memcpy/memset/qsort calls against NULL arguments")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32133>
Avoids sanitizer errors like:
```
../src/intel/vulkan/anv_pipeline_cache.c:409:4: runtime error: null pointer passed as argument 1, which is declared to never be null
../src/intel/vulkan/anv_descriptor_set.c:696:4: runtime error: null pointer passed as argument 1, which is declared to never be null
../src/intel/vulkan/anv_descriptor_set.c:2709:10: runtime error: null pointer passed as argument 1, which is declared to never be null
../src/intel/vulkan/anv_descriptor_set.c:2709:10: runtime error: null pointer passed as argument 2, which is declared to never be null
```
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32098>
Avoids sanitizer errors like:
```
../src/intel/vulkan/anv_pipeline_cache.c:406:4: runtime error: null pointer passed as argument 1, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:406:4: runtime error: null pointer passed as argument 2, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:417:4: runtime error: null pointer passed as argument 2, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:435:4: runtime error: null pointer passed as argument 1, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:435:4: runtime error: null pointer passed as argument 2, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:439:4: runtime error: null pointer passed as argument 1, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:439:4: runtime error: null pointer passed as argument 2, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:443:4: runtime error: null pointer passed as argument 1, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:443:4: runtime error: null pointer passed as argument 2, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:447:4: runtime error: null pointer passed as argument 1, which is declared to never be null
../src/intel/vulkan/anv_pipeline_cache.c:447:4: runtime error: null pointer passed as argument 2, which is declared to never be null
```
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32098>
As per the code comment added in this commit the nir produced from
glsl to nir doesn't always keep function declarations before the
code that calls them e.g. calls from within other function
implementations. The change in this commit works around this problem by
first cloning all function declarations in a first pass, then cloning
the implementations in a second pass once we have filled the remap
table.
Fixes: cbfc225e2b ("glsl: switch to a full nir based linker")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12115
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32100>
This means the fork jobs now have clear priority over nightly jobs,
although it might not matter much as nightly jobs are mostly
long-running jobs and pre-merge & forks will have to wait regardless of
priority.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32093>
KernelCI jobs have priority 44 and are very long-running jobs (and
there might be an issue with the KernelCI that makes it create hundreds
of jobs, @sergi is looking into that).
While bumping to 45+ would be enough to allow Mesa release staging
pipelines to run despite the KernelCI, during the CI meeting with @sergi
and @mupuf it was determined that the Mesa releases are an important
enough operation to warrant being a higher priority than user forks
pipelines, so priority 70 was picked (still under the 75 of Marge
pipelines).
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32093>
Have had to tweak the code to stay safe on the i.MX8MP.
Also, we are for now being very conservative with tiling to prevent
underruns.
In the future, we may want to consider testing different possibilities
during compilation and choosing the optimal one. Also maybe detecting
underruns by checking whether the NPU hung with a given combination.
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31842>
Because dyn_start and dyn_end are indices into
nvk_root_descriptor_table->dynamic_buffers, we would need to offset
cbuf->dynamic_idx by
nvk_root_descriptor_table->set_dynamic_buffer_start[cbuf->desc_set]
in order to do those comparisons correctly.
We could do that, but it's simpler and no less precise to sinply
re-use the same comparison that we do in the other cases here.
This fixes a rendering artifact in Baldur's Gate 3 (Vulkan), which
regressed with the commit listed below.
Fixes: 091a945b57 ("nvk: Be much more conservative about rebinding cbufs")
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32086>
- Modifications to directory paths.
- saveStringArray moved to Stream.h/Stream.cpp to avoid
importing StreamSerializing
- C++ include guards
- Namespace changes
find ./ -type f -exec sed -i -e 's/namespace android/namespace gfxstream/g' {} \;
Reviewed-by: Aaron Ruby <aruby@blackberry.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32062>
This imports certain files from libaemu into gfxstream
guest.
Some are quite specific to gfxstream (Stream, ring_buffer) and others
we expect to Mesa-ify with time (AlignedBuf, Allocator) [probably
while keeping some C++ interface].
The main benefit of importing is easier refactoring and packaging.
Reviewed-by: Aaron Ruby <aruby@blackberry.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32062>
According to PAL, L2 should be invalidated only for images with
DCC/HTILE even on GPUs with non-coherent RBs. In practice, most of
the images have either DCC/HTILE but this can reduce the number of L2
flushes for images without any compression.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31921>
The Early-Z optimization is disabled when there is a discard
instruction in the shader used in the draw call.
But if discard is the only reason to disable Early-Z, and at
draw call time the updates in the draw call are disabled we
can enable Early-Z using a shader variant.
If there are occlussion queries active we also need to disable
Early-z optimization.
So this patch enables Early-Z in this scenario.
The performance improvement is significant when running gfxbench
benchmark showing an average improvement of 11.15%
fps_avg helped: gl_gfxbench_aztec_high.trace: 3.13 -> 3.73 (19.13%)
fps_avg helped: gl_gfxbench_aztec.trace: 4.82 -> 5.68 (17.88%)
fps_avg helped: gl_gfxbench_manhattan31.trace: 5.10 -> 6.00 (17.59%)
fps_avg helped: gl_gfxbench_manhattan.trace: 7.24 -> 8.36 (15.52%)
fps_avg helped: gl_gfxbench_trex.trace: 19.25 -> 20.17 ( 4.81%)
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32028>
We can end up calling vk_multialloc_alloc with 0 size when
`attachment_count` is 0 and `clearValueCount` is 0.
Addressed:
```
Direct leak of 1 byte(s) in 1 object(s) allocated from:
#0 0x7faf033ee0 in __interceptor_malloc
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7fada5cc10 in vk_default_alloc ../src/vulkan/util/vk_alloc.c:26
#2 0x7fac50b270 in vk_alloc ../src/vulkan/util/vk_alloc.h:48
#3 0x7fac555040 in vk_multialloc_alloc
../src/vulkan/util/vk_alloc.h:234
#4 0x7fac555040 in void
tu_CmdBeginRenderPass2<(chip)7>(VkCommandBuffer_T*,
VkRenderPassBeginInfo const*, VkSubpassBeginInfo const*)
../src/freedreno/vulkan/tu_cmd_buffer.cc:4634
#5 0x7fac900760 in vk_common_CmdBeginRenderPass
../src/vulkan/runtime/vk_render_pass.c:261
```
seen in:
dEQP-VK.robustness.robustness2.bind.notemplate.r32i.dontunroll.nonvolatile.uniform_texel_buffer.no_fmt_qual.len_252.samples_1.1d.frag
Fixes: 4cfd021e3f ("turnip: Save the renderpass's clear values in the cmdbuf state.")
Signed-off-by: Karmjit Mahil <karmjit.mahil@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32057>
Establish groups of resolve and unresolve operations that the a7xx
hardware can then use to improve efficiency. Creating such groups enables
continuation of command stream processing while these (un)resolves are in
progress, as long as those latter operations don't depend on the grouped
(un)resolves.
To enable concurrent resolves and unresolves, corresponding fields on the
RB_CCU_CNTL register have to be set appropriately.
Resolve groups are tracked through a scoped struct that logs any pending
resolve operation. Once the group is complete, the emit helper function
will write out the CCU_END_RESOLVE_GROUP event to the command stream.
The buffer ID field on the RB_BLIT_INFO register can be used to disperse
different resolve operations across all available slots in the resolve
engine. The 0x8 and 0x9 IDs are reserved for depth and stencil buffers,
while the 0x0-0x7 range is used for color buffers. A simple incremented
counter is used to assign IDs for all color buffers inside any resolve
group. While it can occur for two color or depth/stencil buffers inside
the same resolve group to have identical IDs, hardware doesn't seem to
have a problem with handling that.
Two TU_DEBUG options are provided, 'noconcurrentresolves' and
'noconcurrentunresolves` disable respective operations by adjusting the
mode set through RB_CCU_CNTL.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31190>
Non-trivial collects (i.e., ones that will introduce moves because the
sources don't line-up with the destination) may cause source intervals
to get implicitly moved when they are inserted as children of the
destination interval. Since we don't support moving intervals in shared
RA, this may cause illegal register allocations. Prevent this by
creating a new top-level interval for the destination so that the source
intervals will be left alone.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: fa22b0901a ("ir3/ra: Add specialized shared register RA/spilling")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31978>
Otherwise anv_descriptor_set is accessed through an unaligned pointer,
which is undefined behavior in C.
```
anv_descriptor_set.c:1620:17: runtime error: member access within misaligned address 0x61900002c2b5
for type 'struct anv_descriptor_set', which requires 8 byte alignment 0x61900002c2b5
```
Fixes: 2570a58bcd ("anv: Implement descriptor pools")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32070>
We have to reject DRM_FORMAT_MOD_APPLE_TWIDDLED_COMPRESSED for surfaces
which are too small. Since the modifier is for all planes, that means
that for multiplane images we need to test all planes for compression
support.
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32081>
Provide various derived counters that can be reported by the freedreno
perfetto producer on a7xx devices.
Specific to a7xx is the split of counters for some countables between the
rendering and visibility bins. Such counters have to be configured
separately inside the appropriate perfcounter group, which then enables
the derived counter to use the separate counter values in its measured
metrics.
Not all possible derived counters are enabled because the perfcounter
groups cannot handle as many counters as would be necessary. There's also
disabled derived counters that would require counters from the VBIF group
which isn't exposed for now due to its more complex way of enabling the
relevant counters.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Acked-by: Rob Clark <robclark@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29677>
For each countable that's being set up, the specific counter group is now
also required. This way on a7xx it will be possible to differentiate
between countables that have the same name but can be used through counter
groups for rendering bin or for visibility bin (e.g. CP and BV_CP).
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Acked-by: Rob Clark <robclark@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29677>
Since $RESULTS_DIR is now centrally defined in setup-test-env.sh it's no
longer necessary to manually add a hard-coded results directory for the
b2b-test job results.
This keeps the results directory consistent between b2c-test jobs and lava.
Fixes: 9b6d14aed1 ("ci: Always create results dir from init")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32051>
The RESULTS_DIR variable is defined by reference to the present
working directory, but if the pwd is the root directory then the
$RESULTS_DIR begins with two slashes instead of one like this: //results.
This is harmless but not necessary, so remove it.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32051>
Currently a630-vk-asan has separate files for its expected failures and
skips, but by using the deqp-runner prefix option, the job can use the
common a630 expectation files. This simplifies `a630-vk-asan` without any
substantive changes to the ci job.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31970>
AGX load/stores supports a single family of addressing modes:
64-bit base + sign/zero-extend(32-bit) << (format shift + optional shift)
This is a base-index addressing mode, where the index is minimally in elements
(never bytes, unless we're doing 8-bit load/stores). Both base and the resulting
address must be aligned to the format size; the mandatory shift means that
alignment of base is equivalent to alignment of the final address, which is
taken care of by lower_mem_access_bit_size anyhow.
The other key thing to note is that this is a 64-bit shift, after the sign- or
zero-extension of the 32-bit index. That means that AGX does NOT implement
64-bit base + sign/zero-extend(32-bit << shift)
This has sweeping implications.
For addressing math from C-based languages (including OpenCL C), the AGX mode is
more helpful, since we tend to get 64-bit shifts instead of 32-bit shifts.
However, for addressing math coming from GLSL, the AGX mode is rather annoying
since we know UBOs/SSBOs are at most 4GB so nir_lower_io & friends are all
32-bit byte indexing. It's tricky to teach them to do otherwise, and would not
be optimal either since 64-bit adds&shifts are *usually* much more expensive
than 32-bit on AGX *except* for when fused into the load/store.
So we don't want 32-bit NIR, since then we can't use the hardware addressing
mode at all. We also don't want 64-bit NIR, since then we have excessive 64-bit
math resulting from deep deref chains from complex struct/array cases. Instead,
we want a middle ground: 32-bit operations that are guaranteed not to overflow
32-bit and can therefore be losslessly promoted to 64-bit.
We can make that no-overflow guarantee as a consequence of the maximum UBO/SSBO
size, and indeed Mesa relies on this already all over the place. So, in this
series, we use relaxed amul opcodes for addressing
math. Then, we rewrite our address mode pattern matching to fuse AGX address
modes.
The actual pattern matching is rewritten. The old code was brittle handwritten
nir_scalar chasing, based on a faulty model of the hardware (with the 32-bit
shift). We delete it all, it's broken. In the new approach, we add some NIR
pseudo-opcodes for address math (ulea_agx/ilea_agx) which we pattern match with
NIR algebraic rules. Then the chasing required to fuse LEA's into load/stores is
trivial because we never go deeper than 1 level. After fusing, we then lower the
leftover lea/amul opcodes and let regular nir_opt_algebraic take it from
here.
We do need to be very careful around pass order to make sure things like
load/store vectorization still happen. Some passes are shuffled in this commit
to make this work. We also need to cleanup amul before fusing since we
specifically do not have nir_opt_algebraic do so - the entire point of the
pseudo-opcodes is to make nir_opt_algebraic ignore the opcodes until we've had a
chance to fuse. If we simply used the .nuw bit on iadd/imul, nir_opt_algebraic
would "optimize" things and lose the bit and then we would fail to fuse
addressing modes, which is a much more expensive failure case than anything
nir_opt_algebraic can do for us. I don't know what the "optimal" pass order for
AGX would look like at this point, but what we have here is good enough for now
and is a net positive for shader-db.
That all ends up being much less code and much simpler code, while fixing the
soundness holes in the old code, and also optimizing a significantly richer set
of addressing calculations. Now we don't juts optimize GL/VK modes, but also CL.
This is crucial even for GL/VK performance, since we rely on CL via libagx even
in graphics shaders.
Terraintessellation is up 10% to ~310fps, which is quite nice.
The following stats are for the end of the series together, including this
change + libagx change + the NIR changes building up to this... but not
including the SSBO vectorizer stats or the IC modelling fix. In other words,
these are the stats for "rewriting address mode handling". This is on OpenGL,
and since the old code was targeted at GL, anything that's not a loss is good
enough - we need this for the soundness fix regardless.
total instructions in shared programs: 2751356 -> 2750518 (-0.03%)
instructions in affected programs: 372143 -> 371305 (-0.23%)
helped: 715
HURT: 75
Instructions are helped.
total alu in shared programs: 2279559 -> 2278721 (-0.04%)
alu in affected programs: 304170 -> 303332 (-0.28%)
helped: 715
HURT: 75
Alu are helped.
total fscib in shared programs: 2277843 -> 2277008 (-0.04%)
fscib in affected programs: 304167 -> 303332 (-0.27%)
helped: 715
HURT: 75
Fscib are helped.
total ic in shared programs: 632686 -> 621886 (-1.71%)
ic in affected programs: 113078 -> 102278 (-9.55%)
helped: 1159
HURT: 82
Ic are helped.
total bytes in shared programs: 21489034 -> 21477530 (-0.05%)
bytes in affected programs: 3018456 -> 3006952 (-0.38%)
helped: 751
HURT: 107
Bytes are helped.
total regs in shared programs: 865148 -> 865114 (<.01%)
regs in affected programs: 1603 -> 1569 (-2.12%)
helped: 10
HURT: 9
Inconclusive result (value mean confidence interval includes 0).
total uniforms in shared programs: 2120735 -> 2120792 (<.01%)
uniforms in affected programs: 22752 -> 22809 (0.25%)
helped: 76
HURT: 49
Inconclusive result (value mean confidence interval includes 0).
total threads in shared programs: 27613312 -> 27613504 (<.01%)
threads in affected programs: 1536 -> 1728 (12.50%)
helped: 3
HURT: 0
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31964>
Some drivers generally need int64 lowered, but prefer to do this lowering
themselves late, to have a chance to optimize targeted int64 patterns before
lowering the rest. This isn't currently possible since nir_lower_int64 takes no
options except what's const* in the shader, and frontends call nir_lower_int64
before passing the shader off to the driver. Add an option to defer int64
lowering. This is a bit ugly but the alternative is replumbing nir_lower_int64's
option handling cross-tree and no-thank-you-not-right-now.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31964>
It could be confusing that a newer platform named with a smaller
number than a half-generation of an older platform like 'gfx20' and
'gfx75' in xml files.
Down the road, it can be a little worse once we pass something like
'gfx40' when there is already a gfx45.xml for the oldest platform.
Unify naming xml files with verx10 numbers to resolve the issue.
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
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/31943>
While the documentation says to use NUM_SIMD_LANES_PER_DSS for the stack
address calculation, what the HW actually uses is
NUM_SYNC_STACKID_PER_DSS. The former may vary depending on the platform,
while the latter is fixed to 2048 for all current platforms.
Fixes: 6c84cbd8c9 ("intel/dev/xe: Set max_eus_per_subslice using topology query")
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32049>
There are two fragment shaders from RDR2 that is hurt for spills and
fills on Lunar Lake.
Totals from 2 (0.00% of 551413) affected shaders:
Spill count: 1252 -> 1317 (+5.19%)
Fill count: 2518 -> 2642 (+4.92%)
Those shaders... have a lot of room for improvement. There are some
patterns in those shaders that we handle very, very poorly. Improving
those patterns would likely improve the spills and fills in these
shaders quite dramatically.
Given how much other platforms are helped, I don't this should block
this commit.
No shader-db or fossil-db changes on any pre-Gfx12.5 Intel platforms.
v2: Add some comments and an additional assertion. Suggested by Ken.
shader-db:
Lunar Lake
total instructions in shared programs: 18094517 -> 18094511 (<.01%)
instructions in affected programs: 809 -> 803 (-0.74%)
helped: 6 / HURT: 0
total cycles in shared programs: 921532158 -> 921532168 (<.01%)
cycles in affected programs: 2266 -> 2276 (0.44%)
helped: 0 / HURT: 3
Meteor Lake and DG2 had similar results. (Meteor Lake shown)
total instructions in shared programs: 19820845 -> 19820839 (<.01%)
instructions in affected programs: 803 -> 797 (-0.75%)
helped: 6 / HURT: 0
total cycles in shared programs: 906372999 -> 906372949 (<.01%)
cycles in affected programs: 3216 -> 3166 (-1.55%)
helped: 6 / HURT: 0
fossil-db:
Lunar Lake
Totals:
Instrs: 141887377 -> 141884465 (-0.00%); split: -0.00%, +0.00%
Cycle count: 21990301498 -> 21990267232 (-0.00%); split: -0.00%, +0.00%
Spill count: 69732 -> 69797 (+0.09%)
Fill count: 128521 -> 128645 (+0.10%)
Totals from 349 (0.06% of 551413) affected shaders:
Instrs: 506117 -> 503205 (-0.58%); split: -0.79%, +0.21%
Cycle count: 32362996 -> 32328730 (-0.11%); split: -0.52%, +0.41%
Spill count: 1951 -> 2016 (+3.33%)
Fill count: 4899 -> 5023 (+2.53%)
Meteor Lake and DG2 had similar results. (Meteor Lake shown)
Totals:
Instrs: 152773732 -> 152761383 (-0.01%); split: -0.01%, +0.00%
Cycle count: 17187529968 -> 17187450663 (-0.00%); split: -0.00%, +0.00%
Spill count: 79279 -> 79003 (-0.35%)
Fill count: 148803 -> 147942 (-0.58%)
Scratch Memory Size: 3949568 -> 3946496 (-0.08%)
Max live registers: 31879325 -> 31879230 (-0.00%)
Totals from 366 (0.06% of 633185) affected shaders:
Instrs: 557377 -> 545028 (-2.22%); split: -2.22%, +0.01%
Cycle count: 26171205 -> 26091900 (-0.30%); split: -0.54%, +0.24%
Spill count: 3238 -> 2962 (-8.52%)
Fill count: 10018 -> 9157 (-8.59%)
Scratch Memory Size: 257024 -> 253952 (-1.20%)
Max live registers: 28187 -> 28092 (-0.34%)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32041>
Previously an instruction like
cmp.l.f0.0(16) null:F, v359:F, 0f
would get lowered to
undef(16) v13703:UD
cmp.l.f0.0(16) v13703:F, v359:F, 0f
mov(16) null:UD, v13703:UD
After copy propagation and dead-code elimination are run again, the
original CMP gets turned back into its original form!
Some cases can also emit MOVs from the original NULL register.
It should be possible to not do any lowering here, but there are some
interactions with source lowering passes for things like
cmp.l.f0.0(16) null:HF, g89.1<16,16,1>:HF, 0hf
What inspired this was... diff'ing step-by-step dumps from
INTEL_DEBUG=optimizer had a lot of useless changes due to these MOVs
and undefs. It was very annoying. This low-effort change gets the
majority of the possible benefit.
No shader-db or fossil-db changes on any Intel platform.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32041>
Copy propagation would incorrectly occur in this code
mov(16) v4+2.0:UW, u0<0>:UW NoMask
...
mov(8) v6+2.0:UD, v4+2.0:UD NoMask group0
to create
mov(16) v4+2.0:UW, u0<0>:UW NoMask
...
mov(8) v6+2.0:UD, u0<0>:UD NoMask group0
This has different behavior. I think I just made a mistake when I
changed this condition in e3f502e007.
It seems like this condition could be relaxed to cover cases like (note
the change of destination stride)
mov(16) v4+2.0<2>:UW, u0<0>:UW NoMask
...
mov(8) v6+2.0:UD, v4+2.0:UD NoMask group0
I'm not sure it's worth it.
No shader-db or fossil-db changes on any Intel platform. Even the code
for the test case mentioned in the original commit did not change.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Fixes: e3f502e007 ("intel/fs: Allow copy propagation between MOVs of mixed sizes")
Closes: #12116
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32041>
Specifically, allow two immediate sources for BFE on Gfx12+. I stumbled
on this while trying some stuff with !31852.
v2: Don't be lazy. Add proper assertions for all the things on all the
platforms. Based on a suggestion by Ken.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Fixes: 7bed11fbde ("intel/brw: Allow immediates in the BFE instruction on Gfx12+")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31858>
This is required, otherwise we regress latency in cases where
applications are using FIFO without explicit KHR_present_wait.
This is an unacceptable regression.
The fix is to normalize the behavior to X11 WSI.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Fixes: d052b0201e ("vulkan/wsi/wayland: Use fifo protocol for FIFO")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32029>
If the gfx version is overriden by the exporter process, the surface
layout might not be compatible with the importer process (which uses
the real gfx version).
So fail early, except if the layout is LINEAR (because it should work
on all gen) or a modifier is used (which should be rejected elsewhere
if not supported).
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31841>
Instead of increasing the version number to describe which fields
are set, use the lower 16 bits for the metadata format version,
and the other bits as flags.
This way the version number defines the layout, and the flags
tell which values are set.
The format version is bumped to 3 (= can have flags), and 2 flags
are defined:
* AC_SURF_METADATA_FLAG_EXTRA_MD_BIT: replaces what was version
number = 2. This means the metadata contains extra information
for tools.
* AC_SURF_METADATA_FLAG_FAMILY_OVERRIDEN_BIT: if set, it means the
surface was allocated from a context that used an overriden gfx
family. This allows the importer process to fail the import early,
as the surface is likely to be invalid.
It also adds an extra dw at the end, to store the fake family.
This is a breaking change for existing code that interpreted
"version > 1" as 2, but only in one case:
AC_SURF_METADATA_FLAG_FAMILY_OVERRIDEN_BIT being set, but not
AC_SURF_METADATA_FLAG_EXTRA_MD_BIT, which produces a version number
of 0x20001 but there's not extra data.
I think this is ok, since both gfx family overriding and extra_md
are debugging tools.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31841>
mount -t tmpfs -o nosuid,nodev,size=2G,mode=1755 tmpfs ${SHADER_CACHE_DIR}
}
if[ -z "$DEQP_SUITE"];then
if[ -z "$DEQP_VER"];then
echo'DEQP_SUITE must be set to the name of your deqp-gpu_version.toml, or DEQP_VER must be set to something like "gles2", "gles31-khr" or "vk" for the test run'
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.
