When I originally added vk_image_view, I was overly clever when it came
to the format field. I decided to make it only contain the bits of the
format contained in the selected aspects. However, this is confusing
(not generally a good thing) and it's also not always what you want.
The Vulkan 1.3.204 spec says:
"When using an image view of a depth/stencil image to populate a
descriptor set (e.g. for sampling in the shader, or for use as an
input attachment), the aspectMask must only include one bit, which
selects whether the image view is used for depth reads (i.e. using a
floating-point sampler or input attachment in the shader) or stencil
reads (i.e. using an unsigned integer sampler or input attachment in
the shader). When an image view of a depth/stencil image is used as
a depth/stencil framebuffer attachment, the aspectMask is ignored
and both depth and stencil image subresources are used."
So, while the restricted format makes sense for texturing, it doesn't
for when the image is being used as an attachment. What we probably
actually want is both versions of the format. We'll call the one given
by the VkImageViewCreateInfo vk_image_view::format and the restricted
one vk_image_view::view_format.
This is just the first commit which switches format to view_format so
the compiler will make sure we get them all. The next commit will
re-add vk_image_view::format but this time unmodified.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15007>
spec requires that the number of timeline waits/signals matches the
base number of waits/signals if there are any timeline semaphores
being processed by the submit, so asserting here is in line with what
validation will yield
failure to match these will also hang every driver I've tested, so asserting
here potentially saves some people their desktop session
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14741>
ANV currently smashes off the TIMELINE bit depending on whether or not
the i915 interface supports them, triggering assert(!type->get_value).
Instead of requiring ANV to smash off function pointers, let the extra
function pointers through and then assert on the feature bits before the
function pointers get used. This should give us roughly the same amount
of assert protection while side-stepping the feature disabling problem.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13839>
Instead of having a bunch of const vk_sync_type for each permutation of
vk_drm_syncobj capabilities, have a vk_drm_syncobj_get_type helper which
auto-detects features. If a driver can't support a feature for some
reason (i915 got timeline support very late, for instance), they can
always mask off feature bits they don't want.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13427>
This adds a new vk_queue_submit object which contains a list of command
buffers as well as wait and signal operations along with a driver hook
which takes a vk_queue and a vk_queue_submit and does the actual submit.
The common code then handles spawning a submit thread if needed, waiting
for timeline points to materialize, dealing with timeline semaphore
emulation via vk_timeline, etc. All the driver sees are vk_queue.submit
calls with fully materialized vk_sync objects which it can wait on
unconditionally.
This implementation takes a page from RADV's book and only ever spawns
the submit thread if it sees a timeline wait on a time point that has
not yet materialized. If this never happens, it calls vk_queue.submit
directly from vkQueueSubmit() and the thread is never spawned.
One other nicety of the new framework is that there is no longer a
distinction, from the driver's PoV, between fences and semaphores. The
fence, if any, is included as just one more signal operation on the
final vk_queue_submit in the batch.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13427>
This is built on the new vk_sync primitives. In the vk_physical_device,
the driver provides a null-terminated array of vk_sync_type pointers in
priority order. The semaphore implementation then selects the first
type that meets the necessary criterion. In particular, semaphores may
or may not be timelines depending on the VkSemaphoreType. It also
auto-selects the semaphore type based on the external handle types
provided and can down-grade as needed to support a particular external
handle.
The implementation itself is mostly copy+pasted from ANV. The primary
difference is the fact that anv_semaphore_impl has been replaced with
vk_sync. The permanent vk_sync is still embedded (like ANV) but the
temporary one is a pointer. This makes stealing the temporary state as
part of VkQueueSubmit a bit easier.
All of the interesting stuff around waits, signals, etc. is implemented
by the vk_sync interface. All this code does is wrap it all in the
annoyingly detailed VkFence rules so we can provide the correct Vulkan
entrypoint behavior.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13427>
This is built on the new vk_sync primitives. In the vk_physical_device,
the driver provides a null-terminated array of vk_sync_type pointers in
priority order. The fence implementation then selects the first type
that meets the necessary criterion. In particular, fences can't be
timelines and need to support reset and CPU wait. It also auto-selects
the fence type based on the external handle types provided and can
down-grade as needed to support a particular external handle.
The implementation itself is mostly copy+pasted from ANV. The primary
difference is the fact that anv_fence_impl has been replaced with
vk_sync. The permanent vk_sync is still embedded (like ANV) but the
temporary one is a pointer. This makes stealing the temporary state as
part of VkQueueSubmit a bit easier.
All of the interesting stuff around waits, resets, etc. is implemented
by the vk_sync interface. All this code does is wrap it all in the
annoyingly detailed VkFence rules so we can provide the correct Vulkan
entrypoint behavior.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13427>
This doesn't map directly to any particular Vulkan object but is,
instead, a base class for the internal implementations of both VkFence
and VkSemaphore. Its utility will become evident in later patches.
The design of vk_sync will look familiar to anyone with significant
experience in DRM. The base object itself is just a pointer to a vfunc
table with function pointers providing the implementation of the various
operations. Depending on how the vk_sync will be used some of of those
vfuncs are optional. If it's only going to be used for VkSemaphore, for
instance, there's no need for reset().
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13427>
It's a bit on the over-complicated side but the objective is to make the
debug log messages show up in the same thread as the first
VK_ERROR_DEVICE_LOST so we don't massively confuse the app. It's
unknown if this is actually ever a problem but, with submit happening
off on its own thread, logging errors from threads the client doesn't
know about doesn't seem like a massively great plan.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13427>
From VUID-VkAttachmentReference2-attachment-04755:
"If attachment is not VK_ATTACHMENT_UNUSED, and the format of the
referenced attachment is a depth/stencil format which includes both
depth and stencil aspects, and layout is
VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_OPTIMAL or
VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_OPTIMAL, the pNext chain must include
a VkAttachmentReferenceStencilLayout structure."
We did not check that there even could be a stencil layout
before fetching it.
Fixes a few tests from:
dEQP-VK.image.depth_stencil_descriptor.depth_read_only_optimal.*
Fixes: 979ea394e5 "vulkan/util: Move
helper functions for depth/stencil images to vk_iamge"
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13740>
