We're currently using uint arrays instead of uvec4 arrays for UBOs and
SSBOs, which requires scalarBlockLayout. Fixing this is a lot of work,
so let's just document it for now.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10127>
I misread the spec, and it turns out timeline ids can't be reused across
semaphores. This is obvious in retrospect, but what can be done?
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Tested-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10115>
unsetting zink from GALLIUM_DRIVER is required in order for lavapipe to
work, but setting it back is totally broken in the case where an app
creates a ton of screens simultaneously
instead, just leave it set to llvmpipe, and if a race condition occurs,
at least llvmpipe isn't going to fail a test that zink passes
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10120>
it turns out there's not actually a requirement that resources be unmapped,
which means that a ton of overhead can be saved both in the unmap codepath
(the cpu overhead here is pretty insane) and then also when mapping cached
resource memory, as the map can now be added to the cache for immediate reuse
as seen in radeonsi
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9980>
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>
when this is enabled, we need to push gl_FragData[1] to location 0 and
index 1 so that it gets blended like the application expects
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9095>
We should be exposing it in every driver, since it's required eventually
to reduce jank. Make drivers have to explicitly opt out instead of opt
in.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9088>
this writes the pipeline cache to disk on shutdown
ideally we'd rather write this incrementally any time we make a new pipeline,
but that ends up breaking the disk cache infrastructure since we're always writing
to the same file, so this is the best we can do for now
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9094>
The VkInstance is really display state not screen state, as is the
loader version. Factor this out a bit further so that
zink_create_instance fills in a zink_instance_info. The latter struct
still lives in the zink_screen for now but that'll move soon.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8968>
this needs to be unconditionally supported in some way, and it also
needs to use a more compatible fallback format if the base format is unavailable
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8959>
this fixes a bunch of issues with 3-component formats, which aren't supported
for various operations on certain drivers
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8697>
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>
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>
These limits are dependent on feature caps, so let's try to thread
a bit more carefully when the cap is unsupported.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8832>
gallium automatically sums up the per-stage buffers if this isn't set,
and some drivers (e.g., amdvlk) export UINT_MAX here which breaks the universe
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8742>
We don't actually support point-sprites by texcoord replacement, so let's
remove that cap. This allows gallium to automatically lower this to the
PNTC varying instead, which we do support.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6473>
we actually need more features here than just the one which was checked to
enabled this
Fixes: 2f6f4b613c3 ("zink: export shader image caps using features")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8656>
Without this, we'll expose GL_ARB_transform_feedback2 and
GL_ARB_transform_feedback3 even without VK_EXT_transform_feedback,
because these caps are directly wired up without checking the pervious
extensions.
Fixes: e8ad52f7b0 ("zink: enable xfb extension in screen creation")
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8640>
We enable the KHR_vulkan_memory_model extension whenever we use
tesselation, so right now this is a defacto requirement. So let's make
this requirement explicit.
Fixes: f815b87e18 ("zink: export tess shader pipe caps")
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8640>
This shouldn't change any behavior, it just seems a bit more to the
point to check for the extension that decides if these are NULL or not
than to check both of them.
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8640>
Even in the presence of VK_KHR_draw_indirect_count, we still technically
need to respect the feature-cap when using a Vk 1.0 core-function.
Fixes: cef876910a ("zink: enable PIPE_CAP_MULTI_DRAW_INDIRECT(_PARAMS) caps")
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8640>
Vulkan has a cap to enable this, we should check that one rather than
always claiming support.
Fixes: 0c70268ff7 ("zink: mark ARB_sample_shading as supported")
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8640>
Vulkan has a cap to enable this, we should check that one rather than
always claiming support.
Fixes: 8d46e35d16 ("zink: introduce opengl over vulkan")
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8640>
Vulkan has a cap to enable this, we should check that one rather than
always claiming support.
Fixes: 61720098fa ("zink: set PIPE_CAP_ROBUST_BUFFER_ACCESS_BEHAVIOR")
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8640>
This is not an optional feature in Vulkan, so we can rely on this being
supported. This has the nice benefit of enabling OpenGL ES 3.0 support
on ANV.
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8640>
this gives us new rasterizer states when multisample stuff changes instead
of new fs states, which is what we want since these correlate to pipeline
flags, not shader-specific things
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8631>
* struct shader_info provides a 32bit mask for textures_used
* samplers and samplerviews are a 1:1 mapping for shader descriptors
* also according to spec this is always 32 per stage
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8457>
some vulkan drivers (e.g., amdvlk) advertise absolutely huge values here,
resulting in bitmask overflows everywhere since gallium assumes a max of
32 for vertex inputs and nir uses 64bit types for others
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8318>
this makes tessellation work as expected in apps but has no impact on unit tests
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Witold Baryluk <witold.baryluk@gmail.com>
Tested-by: Witold Baryluk <witold.baryluk@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8274>
This moves the parts of zink_format.c that also operates on zink_screen
into zink_screen.c. This has the benefit that we can start testing the
enum-translation code separately from the state.
This will make the next commit a bit cleaner.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7982>
There's no harm in checking for the extension on non-macOS, just do it.
Nor can I see any point in checking for both the layer and the
extension, since you're never going to see the extension if the layer
isn't available, so just check for the extension instead of the reduced
boolean. Simplify some variable naming while we're at it.
Acked-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8019>
This result isn't actually used within zink_create_instance, so don't do
it there.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8019>
Mike Blumenkrantz
Marek Olšák
Erik Faye-Lund
Erik Faye-Lund
Adam Jackson
Antonio Caggiano
Eric Anholt
Dave Airlie
Michel Zou
Hoe Hao Cheng