Re-use auto-generated vk_cmd_enqueue entrypoints instead of generating
our own version doing the same thing. In order to effectively do this,
we also add an allow-list of which entrypoints lavapipe actually handles
to avoid issues where the autogenerated one stomps a vkCmdFoo2 wrapper.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15311>
When llvmpipe is allowed execute fragment shaders overlapping
with other stuff, we have to start using the pipe fences.
With presentation, the acquire path needs to signal a semaphore
that can be waited on by the user, so add support for passing
signal/wait semaphores for non-timeline in, and just put a
fence pointer in the semaphore for that case.
This fixes rendering once we allow overlapping rasterization.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14923>
If the users ask for an infinte timeout, just pass it through
to gallium.
When llvmpipe ends up allowing async fragment shaders, it's important
to get this right for lots of CTS tests.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14923>
With the proper version checking in the common vulkan instance code
(commit 88b9b68) it is now possible to bring the reported interface
version up to v5.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14563>
This capability is enabled for drivers supporting formatless image
writing in shader.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13409>
vk_device_init already calls vk_error so this is redundant. Also, it
makes vk_error grumpy to see a VK_ERROR_FEATURE_NOT_PRESENT on an
instance rather than a physical device.
Fixes: 47adb11143 ("lavapipe: Switch to the new vk_error helpers")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13619>
This has a requirement on the display extensions.
VK-GL-CTS: dEQP-VK.info.instance_extensions
Fixes: 1d574d4860 ("lavapipe: remove display extension support")
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13616>
Support creating exportable memory. Use memfd file
descriptors and import/export them as opaque fd handles.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Tested-by: Heinrich Fink <hfink@snap.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12345>
Fences with VK_FENCE_CREATE_SIGNALED_BIT are created with
signalled=true and timeline=0, waiting on them without
submitting first returned VK_TIMEOUT instead of VK_SUCCESS.
Signed-off-by: Pavel Asyutchenko <sventeam@yandex.ru>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13128>
This is already handled by vk_device_init(); drivers no longer
need to do it themselves.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12867>
The remaining extensions are optional features, just turn on vk 1.2
with them reporting as off.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12953>
Again if you get passed an invoc but the exec mask has the
active lane somewhere other than at 0, then if we have an
invoc we should find the active lane and extract the value
from invoc rather than using the idx.
This fixes a bunch of VK 1.2 subgroup tests once 1.2 is enabled:
dEQP-VK.subgroups.ballot_broadcast.compute.subgroupbroadcast_nonconst*
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12953>
These pass all the CTS tests, though not sure how useful they are.
[airlied: these may need some work in the future depending on app expectations]
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12953>
Switch to using common structure.
Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13000>
We have no reason to report a subpixel precision of 4 for lines; in fact
LLVMpipe uses 8 subpixel bits for lines, similar to other primitives.
But let's use the pipe-cap for this instead of hard-coding it.
Fixes: 9fbf6b2abf ("lavapipe: implement VK_EXT_line_rasterization")
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12277>
Through some exhaustive searching, I've found that our log2 approximation
is precise to around 3.5 bits. And the squaring step should increase the
result with one bit, leaving us with 4.5 bits of precision.
Reporting the right mipmap precision fixes a few CTS-tests.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12238>
this uses a singly-linked list of timeline ids to compare against the device
queue's cmdbuf counter and determine which timeline id maps to which cmdbuf and
thus which fence can be waited on
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12071>
this simplifies the entire queue mechanism and makes it more consistent:
previously some cases (e.g., null cmdbuf submission) would immediately
be marked as finished, which meant that fences could theoretically become
desynchronized, breaking application assumptions
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12071>
The strictLines-feature requires lines to be rasterized as rectangles
by default instead of using the parallelograms you get from extending
bresenham lines along their minor axis.
Now that we can specify the line mode fully we can actually express
this, so let's do so.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11782>
I believe these Gallium caps imply these Vulkan features. If they don't,
then we got things wrong on the Zink side as well ;)
While we're at it, query shaderStorageImageWriteWithoutFormat based on
the PIPE_SHADER_CAP_MAX_SHADER_IMAGES cap. This matches what the gallium
OpenGL frontend does.
This brings Zink on Lavapipe up to OpenGL 4.5.
For some reason, a bunch of PBO tests starts failing on CI for Zink, but
that doesn't seem like a Lavapipe problem...
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10467>
These are duplicates from a few lines up
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11703>
really this only needs cso_cache api, but it's cumbersome to redo all
the hashing and state creation, so just use the whole context
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11071>
a fence applies to all the submitted cmdbufs, so it's necessary to do
the flush which creates the user fence after all the cmdbufs have been
processed in order to avoid creating a fence that only applies to the
first cmdbuf
Fixes: b38879f8c5 ("vallium: initial import of the vulkan frontend")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10795>
When emitting the state we add one to the UBO index, so we have to
subtract one from the number of UBOs that we support. This is still
fine, because Vulkan only requires 14 UBOs to be supported, and LLVMpipe
supports 16.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10731>
This isn't the perfect error-code, but we don't really have anything
better, it seems.
The ideal fix here would be to fix LLVMpipe to support larger textures,
but this is probably as far as I'm interested in chasing down this path
for now.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10689>
If you build --glx=gallium-xlib then lavapipe will fail to
link this should let it use the non-dri paths on Linux in that
case
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Tested-by: Brian Paul <brianp@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9400>
This is going to make it easier to implement the custom border-color
extension.
While we're moving the code, tweak the memset code a bit, so we don't do
any float-ism in the int-case. It doesn't change anything functionally,
just makes it slightly clearer what's going on here.
Reviewed-by: Joshua Ashton <joshua@froggi.es>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10320>
For these caps, we need to check all stages to be sure we've got things
right.
Again, this is probably benign, because LLVMpipe should support the same
value for all stages.
Fixes: b38879f8c5 ("vallium: initial import of the vulkan frontend")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10189>
We should really check for the minimum of all supported vertex-stages
here, not just the vertex-shader.
This shouldn't make any real-world difference, because we really only
support LLVMpipe here, and that driver has the same limits for all
stages. But it seems better to actually check all stages instead of just
assuming.
Fixes: b38879f8c5 ("vallium: initial import of the vulkan frontend")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10189>
This seems arbitrary, and makes us check for PIPE_SHADER_CAP_MAX_SAMPLER_VIEWS
instead of PIPE_SHADER_CAP_MAX_SHADER_IMAGES, which isn't what we want.
The end result is that we accidentally exposed 128 shader images,
instead of 16. This can lead to us writing outside of the array of
shader images in llvmpipe_set_shader_images, among other bad things.
Fixes: b38879f8c5 ("vallium: initial import of the vulkan frontend")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10189>
Mike Blumenkrantz
Jason Ekstrand
Boris Brezillon
Michel Zou
Dave Airlie
Charles Giessen
Konstantin Seurer
Thomas H.P. Andersen
Juan A. Suarez Romero
Marek Olšák
Jason Ekstrand
Thomas Wagner
Pavel Asyutchenko
Tapani Pälli
Yevhenii Kolesnikov
Roland Scheidegger
Erik Faye-Lund
Georg Lehmann