this includes:
* async buffer mapping/replacement
* async queue submission
* async (threaded) gallium flush handling
the main churn here is from handling async gallium flushes, which involves
creating multiple gallium fences (zink_tc_fence) for each zink fence (zink_fence).
a tc fence may begin waiting for completion at any time, even before the zink_fence
has had its cmdbuf(s) submitted, so handling this type of desync ends up needing
almost a complete rewrite of the existing queue architecture
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9935>
This one is a bit of a tough nut to deal with gracefully. Zink has a set
of base-requirements that we always require. There's no Gallium caps to
report these missing features, so we're essentially left with two options:
1. Fail to create the screen.
2. Ignore the missing fetures.
Solution 1 will lead to difficulties bringing up a new Vulkan driver on
Zink, and solution 2 will lead to mis-rendering.
Since Zink is mostly an opt-in driver to use when there's no OpenGL driver
available, we should probably do 2 for now. It seems better to have some
mis-rendering than no rendering at all.
But let's at least check, and print a warning. That way people get to
know what's up.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9925>
this uses the same mechanics as surface caching, but it
also requires that surfaces keep refs of the framebuffers they're
attached to so that they can invalidate the fb object upon destruction,
as, similar to program objects, the fb objects are "owned" by their attachments
loosely based on patches by Antonio Caggiano
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9665>
lavapipe can only do up to 4bits, so this isn't just a binary check
Fixes: 0daa61553d ("zink: check if multisample support exists for shader image formats")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9713>
When we alloc with ralloc, we also need to free with it.
But let's take a step back here; we don't just need to use ralloc, we
also need to destroy all other screen-resources. So let's call the
destructor here instead.
Fixes: 2643f9ed28 ("zink: ralloc screen objects")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9647>
this is a global cache for all surface objects, enabling some memory
optimizations as well as improved reuse of cached descriptors
loosely based on patches from Antonio Caggiano
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9541>
this stores a number (currently 5) of backing allocations for resources
for later reuse when creating matching resources
because this is on the screen object it requires locking, but this is still
far faster than allocating new memory each time
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9540>
the maximum allowable runtime version of vk can be computed by MIN(instance_version, device_version)
despite this, instances and devices can be created using the maximum version available
for each respective type. the restriction is applied only at the point of
enabling/applying features and extensions, meaning that to correctly handle this,
zink must:
1. create an instance using the maximum allowable version
2. select a physical device using the instance
3. compute MIN(instance_version, device_version)
4. only now begin to enable/use features requiring vk 1.1+
ref #4392
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9479>
Available since Vulkan 1.0, and in fact already wired up, just not
advertised. It looks like we could make this dynamic state but this
works for now.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9371>
this ends up being a tradeoff where we waste a little startup time and
an extra ~4k memory for the overall screen object in exchange for never having
to fetch format properties again, which is a surprisingly expensive call
to be making as much as we have to make it
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9293>
the hardware supports it, the driver supports it, but the driver reports
a lower value due to subtracting some usage that we shouldn't exceed anyway
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9198>
non-intel platforms need border colors pre-swizzled
this is an internal khronos spec bug that will (someday) be resolved in
a more detectable manner
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9136>
PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE translate into
GL_MAX_*_UNIFORM_COMPONENTS, all of which are allowed to be as
low as 1024 by the GL 4.6 spec.
PIPE_CAP_MAX_SHADER_BUFFER_SIZE translate into
GL_MAX_SHADER_STORAGE_BLOCK_SIZE, which has different minimum values in
different versions of the GL spec. In the GL 4.6 spec for instance, it
is required to be 2^27, the same as what Vulkan requires.
But what these limits are in GL is irrelevant at this level of
abstraction. The OpenGL state-tracker cares, but the Gallium driver
shouldn't have to. So let's just delete those parts of the comments.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9216>
Enable pipe capability of exporting stencil from shader when Vulkan
extension is available.
Signed-off-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9244>
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9244>
The code was using the core versions, but for vulkan 1.0 at
least the extension versions are what is required to be asked for.
This fixes zink loading on lavapipe, and blows up the CI.
v2: Use LOCAL device extension variant (zmike)
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9185>
these caps correspond to descriptor binding limits provided by vulkan drivers
fixes KHR-GL46.shader_storage_buffer_object.basic-max
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9174>
Mike Blumenkrantz
Erik Faye-Lund
Adam Jackson
Erik Faye-Lund
Antonio Caggiano
Eric Anholt
Dave Airlie
Michel Zou