This allows testing virgl over vtest by setting GALLIUM_DRIVER=virpipe
when the X server uses a proprietary driver.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Tested-by: John Bates <jbates@chromium.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8888>
Fix defect reported by Coverity Scan.
Invalid type in argument to printf format specifier (PRINTF_ARGS)
invalid_type: Argument *__errno_location() to format specifier %s was expected to have type char * but has type int.
Fixes: d37124b065 ("virgl: add support for VIRGL_CAP_V2_UNTYPED_RESOURCE")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8874>
This is really nasty, and shouldn't really be needed, but we have a
problem where both Zink and Lavapipe checks $GALLIUM_DRIVER, meaning that
Zink tries to use Lavapipe, and Lavapipe tries to use Zink.
This patch side-steps that by temporarily setting $GALLIUM_DRIVER to
"llvmpipe", giving Lavapipe a chance to succeed.
This is not great at all. The most obvious problem is that this is super
thread-unsafe, effectively modifying global state without any care. In
reality, we'd only want the pipe-loader in the *same thread* to ignore
Zink, but it's not so obvious how to do that without introducing lots of
ugly zink-specific cruft.
People shouldn't be using Zink if they don't have a GPU, it's going to
be much better to use LLVMpipe in that case. So let's not worry too much
about this case, and instead guard this dangerous logic with an
ZINK_USE_LAVAPIPE environment variable. This means this behavior only
happens if people opt in to it.
With this in place, we can start using Zink + Lavapipe on CI.
In the longer run, it might be better to use Adam Jackson's copper
loader instead, and drop exposing Zink as a software rasterizer
entirely. But that's something for the great future where we have flying
cars and all.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7881>
The new message buffer will save the dpb buffers from previous
allocation based on the max resolution.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Boyuan Zhang <boyuan.zhang@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8851>
Only batches involving the tiler block need to add the tiler heap to the
list of accessed BOs. While at it, clarify who's accessing this heap.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Tested-by: Icecream95 <ixn@disroot.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8822>
The polygon list is written by tiler jobs and read by fragment ones,
and nothing should re-use the heap until the fragment job is done.
4fec6c9448 ("panfrost: Add the tiler heap to fragment jobs") fixed
this for the !multi-context case by adding the heap BO to fragment job.
But the tiler heap is shared accross contexts, and vertex/tiler+fragment
job submission is done through 2 separate ioctls, meaning that
vertex/tiler and fragment jobs from 2 different context might be
interleaved.
Add a lock at the device level to ensure tiler/vertex+fragment jobs are
submitted sequentially, with no other jobs using the same tiler heap
in-between.
Cc: mesa-stable
Fixes: d8deb1eb6a ("panfrost: Share tiler_heap across batches/contexts")
Reported-by: Icecream95 <ixn@disroot.org>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Tested-by: Icecream95 <ixn@disroot.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8822>
Fix defect reported by Coverity.
Uninitialized pointer field (UNINIT_CTOR)
uninit_member: Non-static class member sub is not initialized in
this constructor nor in any functions that it calls.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7229>
It's exposed with ARB_tf2, which we claimed support for. All the KHR-GL33
TF tests pass for me locally except for no_errors, which I have some
outstanding fixes for with khronos. Our CI build seems to be having some
issue with exceptions inside of deqp.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8843>
The batch might not have stage == FD_STAGE_BLIT set because
fd_blitter_pipe_begin was sticking the stage on some random batch (or none
at all) rather than the one that would be used in the meta operation.
What we actually wanted to be looking at was set_active_query_state(),
which is already called by util_blitter and whose state we just needed to
track.
Fixes these piglit tests on a307:
occlusion_query_meta_fragments
occlusion_query_meta_save
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8789>
It's not the set of currently active providers, it's what's been used at
all in the current batch (this is used for doing the initialization of
query providers at initial HW setup in a submit).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8789>
If LIBGL_ALWAYS_SOFTWARE is set, then drisw is selected, and internally,
drisw should choose one of the actual software drivers. If it's not set,
but drisw is still selected (no hardware DRM driver, like in WSL), then
layered drivers are preferred over pure software.
Fixes: 4a3b42a7 ("drisw: Prefer hardware-layered sw-winsys drivers over pure sw")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4171
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8782>
Fix defects reported by Coverity Scan.
uninit_member: Non-static class member score is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member prevData is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member prevOp is not initialized in this constructor nor in any functions that it calls.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8604>
Fix defect reported by Coverity Scan.
Uninitialized pointer field (UNINIT_CTOR)
uninit_member: Non-static class member gpEmitAddress is not initialized
in this constructor nor in any functions that it calls.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8605>
This goes down the list and picks the first non-cpu device, when
we merge the CI patch we should add a forcing env var in here.
Fixes: 8d46e35d1 ("zink: introduce opengl over vulkan")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8845>
This increases the wasted memory to 140 MB for DeusExMD, still below
the original number. The advantage is that we now get 2 MB pages for more
buffers and fewer total buffers allocated by the kernel, enabling faster
GPU page translation and slightly lower kernel overhead.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8683>
Instead of aligning slab allocations to powers of two (e.g. 129K -> 256K),
implement slab allocations with 3/4 of power of two sizes to reduce
overallocation. (e.g. 129K -> 192K)
The limitation is that the alignment must be 1/3rd of the allocation size.
DeusExMD allocates 2.1 GB of VRAM. Without this, slabs waste 194 MB due
to alignment, i.e. 9.2%. This commit reduces the waste to 102 MB, i.e. 4.9%.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8683>
Slabs always allocate the next power of two size from their pools. This
wastes memory if the size is not a power of two.
bo->base.size is overwritten because the default is the allocated power of
two size, but we need the real size to compute the wasted size in
amdgpu_bo_slab_destroy. entry_size is added to the hole in pb_slab_entry
to hold the real entry size.
Like other memory stats, no atomics are used.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8683>
Left unchecked, an app that just did an endless series of draws could
result in VSC buffer sizes >4GB, which doesn't work out well.
This limit is semi-arbitrary (ie. it is lower than hw limit, but 32*8MB
seems a bit excessive and not a limit that you'd hit in the real world).
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8842>
This makes it possible to use a separate ralloc context, not gl context
itself which might not be allocated with ralloc.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8805>
We can just always specify the stride parameter regardless of whether
an alignment was forced or not. This fixes some issues where it is not
straightforward to detect the need to specify stride by checking the
buffer width (e.g. imported dmabuf to be used as texture).
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8549>
Enable r and rg targets to allow r and rg so that lima exposes
GL_EXT_texture_rg.
This is notably required by programs working with textures for
video playback.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8549>
lima is not able to use yuv textures directly.
Set them as external_only so that drivers don't attempt to send yuv
planes directly as dma bufs.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8549>
v2 (Ralph): don't allign address as the kernel handles that already
support migration from GPU to system RAM
v3 (Karol): use DIV_ROUND_UP for sizes not being page aligned
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6401>
Memory migration for SVM (share virtual memory). This allow to migrate
a range of virtual address of the process to device memory to speed up
device processing when that memory is in use by the device.
v2 (Karol): use tracked SVM allocation in order to support cases where
the size of the migration is not specified
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6401>
We need those to proper validate the SVM API.
v2: use std::map instead of std::unordered_map
v3: guard against segfaults on std::prev with empty containers
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6401>
v2 (Karol): Fix declaration of pointers argument
v3 (Karol): Move flags into function interface as bools
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Acked-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6401>
Using a ternary expression inside the argument list avoids some
repetition, showing that the rest of the call is the same. This increase
readability a tad.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8832>
