As described in the comment, enabling the round_to_nearest_even results
in the upper 2^-9 of the texel i being sampled at i+1. This appears to
be allowed by the spec, but triggers a CTS bug[1]. Changing this behavior
is not necessary (we could fix the CTS), but is desirable regardless
because of the precision improvement.
[1]: https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/5547
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32985>
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>
Update the trace update script to use get_token_from_default_dir for
reading the GitLab token from the default location (~/.config/gitlab-token),
fixing the script and aligning it with our other tools.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33061>
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>
Update expectation files for the test
runs with kernel 6.13-rc4.
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Reviewed-by: David Heidelberg <None>
Reviewed-by: Sergi Blanch Torné <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32788>
Move to 6.13-rc4 for all mesa-ci jobs except anv-jsl.
Signed-off-by: Vignesh Raman <vignesh.raman@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>
shaderdb's report.py can only handle integer stats. So instead of
outputting early/late for the preamble stat, output 0/1 for the
early-preamble stat.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: 114a47544f ("ir3: Add preamble instr count metric")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33055>
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>
Input attachment reads are lowered to image reads and thus require
a flush of the read-only L1 caches.
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>
They're not supported yet so let's not pretend they are.
In particular use_local_buffers can cause VM_ALWAYS_VALID to be
used, which then prevents the creation of a dmabuf.
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>
- many non-inline functions are only used in 1 .c file: make them static
- some inline functions are only use in 1 .c file: move them there
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33046>
Not needed with ACO. It was used for big shaders on old APUs that took
forever to compile.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33046>
This should be faster than 32_ABGR.
Also, stencil exports are changed from UINT16_ABGR to 32_GR,
which should have no effect on performance.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33046>
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>
