2019-11-25 15:29:12 +00:00
|
|
|
/*
|
2022-02-17 11:38:42 +00:00
|
|
|
* Copyright © 2019 Raspberry Pi Ltd
|
2019-11-25 15:29:12 +00:00
|
|
|
*
|
|
|
|
* based in part on anv driver which is:
|
|
|
|
* Copyright © 2015 Intel Corporation
|
|
|
|
*
|
|
|
|
* based in part on radv driver which is:
|
|
|
|
* Copyright © 2016 Red Hat.
|
|
|
|
* Copyright © 2016 Bas Nieuwenhuizen
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
* copy of this software and associated documentation files (the "Software"),
|
|
|
|
* to deal in the Software without restriction, including without limitation
|
|
|
|
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
|
|
|
|
* and/or sell copies of the Software, and to permit persons to whom the
|
|
|
|
* Software is furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice (including the next
|
|
|
|
* paragraph) shall be included in all copies or substantial portions of the
|
|
|
|
* Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
|
|
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
|
|
|
|
* IN THE SOFTWARE.
|
|
|
|
*/
|
|
|
|
#ifndef V3DV_PRIVATE_H
|
|
|
|
#define V3DV_PRIVATE_H
|
|
|
|
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <string.h>
|
|
|
|
#include <vulkan/vulkan.h>
|
|
|
|
#include <vulkan/vk_icd.h>
|
2020-01-15 07:48:07 +00:00
|
|
|
#include <vk_enum_to_str.h>
|
2019-11-25 15:29:12 +00:00
|
|
|
|
2022-09-15 23:50:04 +01:00
|
|
|
#include "vk_descriptor_update_template.h"
|
2021-01-24 15:06:09 +00:00
|
|
|
#include "vk_device.h"
|
2021-11-18 11:16:43 +00:00
|
|
|
#include "vk_format.h"
|
2021-01-27 12:46:58 +00:00
|
|
|
#include "vk_instance.h"
|
2021-07-26 11:06:17 +01:00
|
|
|
#include "vk_image.h"
|
2021-09-24 21:31:03 +01:00
|
|
|
#include "vk_log.h"
|
2021-01-27 12:46:58 +00:00
|
|
|
#include "vk_physical_device.h"
|
2021-03-10 22:50:00 +00:00
|
|
|
#include "vk_shader_module.h"
|
2022-03-29 23:52:32 +01:00
|
|
|
#include "vk_sync.h"
|
2022-04-05 00:37:26 +01:00
|
|
|
#include "vk_sync_timeline.h"
|
2021-03-09 14:30:09 +00:00
|
|
|
#include "vk_util.h"
|
v3dv: add support for multi-planar formats, enable YCbCr
Original patches wrote by Ella Stanforth.
Alejandro Piñeiro main changes (skipping the small fixes/typos):
* Reduced the list of supported formats to
VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and
VK_FORMAT_G8_B8R8_2PLANE_420_UNORM, that are the two only
mandatory by the spec.
* Fix format features exposed with YCbCr:
* Disallow some features not supported with YCbCr (like blitting)
* Disallow storage image support. Not clear if really useful. Even
if there are CTS tests, there is an ongoing discussion about the
possibility to remove them.
* Expose VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT, that is
mandatory for the formats supported.
* Not expose VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Some
CTS tests are failing right now, and it is not mandatory. Likely
to be revisit later.
* We are keeping VK_FORMAT_FEATURE_2_DISJOINT_BIT and
VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Even if they
are optional, it is working with the two formats that we are
exposing. Likely that will need to be refined if we start to
expose more formats.
* create_image_view: don't use hardcoded 0x70, but instead doing an
explicit bit or of VK_IMAGE_ASPECT_PLANE_0/1/2_BIT
* image_format_plane_features: keep how supported aspects and
separate stencil check is done. Even if the change introduced was
correct (not sure about that though), that change is unrelated to
this work
* write_image_descriptor: add additional checks for descriptor type,
to compute properly the offset.
* Cosmetic changes (don't use // for comments, capital letters, etc)
* Main changes coming from the review:
* Not use image aliases. All the info is already on the image
planes, and some points of the code were confusing as it was
using always a hardcoded plane 0.
* Squashed the two original main patches. YCbCr conversion was
leaking on the multi-planar support, as some support needed
info coming from the ycbcr structs.
* Not expose the extension on Android, and explicitly assert that
we expect plane_count to be 1 always.
* For a full list of review changes see MR#19950
Signed-off-by: Ella Stanforth <estanforth@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19950>
2022-07-28 09:15:43 +01:00
|
|
|
#include "vk_ycbcr_conversion.h"
|
2020-11-12 15:30:41 +00:00
|
|
|
|
2021-04-06 13:13:14 +01:00
|
|
|
#include "vk_command_buffer.h"
|
2022-02-07 20:29:26 +00:00
|
|
|
#include "vk_command_pool.h"
|
2021-04-06 13:30:32 +01:00
|
|
|
#include "vk_queue.h"
|
2022-09-27 12:02:45 +01:00
|
|
|
#include "vk_pipeline.h"
|
2021-04-06 13:13:14 +01:00
|
|
|
|
2019-11-29 12:55:38 +00:00
|
|
|
#include <xf86drm.h>
|
|
|
|
|
2019-11-27 10:49:12 +00:00
|
|
|
#ifdef HAVE_VALGRIND
|
2020-11-30 20:40:34 +00:00
|
|
|
#include <valgrind.h>
|
|
|
|
#include <memcheck.h>
|
2019-11-27 10:49:12 +00:00
|
|
|
#define VG(x) x
|
|
|
|
#else
|
|
|
|
#define VG(x) ((void)0)
|
|
|
|
#endif
|
|
|
|
|
2020-07-30 13:32:26 +01:00
|
|
|
#include "v3dv_limits.h"
|
|
|
|
|
2019-11-25 15:29:12 +00:00
|
|
|
#include "common/v3d_device_info.h"
|
2019-12-03 11:54:30 +00:00
|
|
|
#include "common/v3d_limits.h"
|
2021-06-01 13:33:06 +01:00
|
|
|
#include "common/v3d_tiling.h"
|
2021-04-29 08:23:28 +01:00
|
|
|
#include "common/v3d_util.h"
|
2019-11-25 15:29:12 +00:00
|
|
|
|
2019-12-02 12:59:04 +00:00
|
|
|
#include "compiler/shader_enums.h"
|
|
|
|
#include "compiler/spirv/nir_spirv.h"
|
|
|
|
|
|
|
|
#include "compiler/v3d_compiler.h"
|
|
|
|
|
2019-11-25 15:29:12 +00:00
|
|
|
#include "vk_debug_report.h"
|
2019-12-13 09:48:12 +00:00
|
|
|
#include "util/set.h"
|
|
|
|
#include "util/hash_table.h"
|
2022-01-04 11:56:42 +00:00
|
|
|
#include "util/sparse_array.h"
|
2019-11-25 15:29:12 +00:00
|
|
|
#include "util/xmlconfig.h"
|
2022-11-05 11:55:32 +00:00
|
|
|
#include "util/u_atomic.h"
|
2019-11-25 15:29:12 +00:00
|
|
|
|
|
|
|
#include "v3dv_entrypoints.h"
|
2019-12-10 11:00:49 +00:00
|
|
|
#include "v3dv_bo.h"
|
2019-11-25 15:29:12 +00:00
|
|
|
|
2020-04-20 12:24:09 +01:00
|
|
|
#include "drm-uapi/v3d_drm.h"
|
|
|
|
|
2019-11-27 10:49:49 +00:00
|
|
|
#include "vk_alloc.h"
|
2019-11-29 12:55:38 +00:00
|
|
|
#include "simulator/v3d_simulator.h"
|
2019-11-27 10:49:49 +00:00
|
|
|
|
2021-05-28 12:46:57 +01:00
|
|
|
#include "v3dv_cl.h"
|
2019-12-03 11:54:30 +00:00
|
|
|
|
2021-05-28 12:46:57 +01:00
|
|
|
#include "wsi_common.h"
|
2020-01-05 00:51:04 +00:00
|
|
|
|
2019-12-03 11:54:30 +00:00
|
|
|
/* A non-fatal assert. Useful for debugging. */
|
|
|
|
#ifdef DEBUG
|
|
|
|
#define v3dv_assert(x) ({ \
|
|
|
|
if (unlikely(!(x))) \
|
|
|
|
fprintf(stderr, "%s:%d ASSERT: %s", __FILE__, __LINE__, #x); \
|
|
|
|
})
|
|
|
|
#else
|
|
|
|
#define v3dv_assert(x)
|
|
|
|
#endif
|
|
|
|
|
2020-03-18 09:41:19 +00:00
|
|
|
#define perf_debug(...) do { \
|
2022-08-15 22:37:30 +01:00
|
|
|
if (V3D_DBG(PERF)) \
|
2020-03-18 09:41:19 +00:00
|
|
|
fprintf(stderr, __VA_ARGS__); \
|
|
|
|
} while (0)
|
|
|
|
|
2019-11-25 15:29:12 +00:00
|
|
|
struct v3dv_instance;
|
|
|
|
|
2019-11-29 12:55:38 +00:00
|
|
|
#ifdef USE_V3D_SIMULATOR
|
|
|
|
#define using_v3d_simulator true
|
|
|
|
#else
|
|
|
|
#define using_v3d_simulator false
|
|
|
|
#endif
|
|
|
|
|
|
|
|
struct v3d_simulator_file;
|
|
|
|
|
2021-05-25 09:49:06 +01:00
|
|
|
/* Minimum required by the Vulkan 1.1 spec */
|
|
|
|
#define MAX_MEMORY_ALLOCATION_SIZE (1ull << 30)
|
|
|
|
|
2019-11-25 15:29:12 +00:00
|
|
|
struct v3dv_physical_device {
|
2021-01-27 12:46:58 +00:00
|
|
|
struct vk_physical_device vk;
|
2019-11-25 15:29:12 +00:00
|
|
|
|
2019-11-29 08:01:56 +00:00
|
|
|
char *name;
|
2020-01-23 10:59:28 +00:00
|
|
|
int32_t render_fd;
|
2020-01-20 09:45:06 +00:00
|
|
|
int32_t display_fd;
|
v3dv: move authenticated display fd acquisition to swapchain creation time
So far, we have only been supporting X11, so we assumed that we were running
inside X11 and would always try to get an authenticated fd from Xorg during
device initialization. While this works for desktop Raspbian, it is not
really correct and it is not what we want to do when we start considering
other WSIs.
Initially, one could think we can still do this by guarding the WSI code
under the proper instance extension check. This, however, doesn't work
reliably, as the Vulkan loader can call vkEnumerateDevices without enabling
surface extensions on the instance, which then can lead to us not
initializing any display_fd and failing with VK_ERROR_INITIALIZATION_FAILED,
which is not correct, so while we can try to acquire the display_fd here,
it might not always work, and we should definitely not fail initialization
of the physical device for that.
Instead, with this change we move acquisition of display_fd to swapchain
creation time where required extensions need to be enabled in the instance.
This was also suggested by Daniel Stone during review of a work-in-progress
implementation for the Wayland WSI.
There is a special case to consider though: applications like Zink that
don't use Vulkan's swapchains at all but still allocate images that they
intend to use for WSI. We need to handle these by checking that we have
indeed acquired a display_fd before doing any memory allocation for WSI,
and acquiring one at that time if that's not the case.
This change also removes the render_fd and display_fd fields from the
logical device (which we were copying from the physical device), because
now there is no guarantee that we have acquired a display_fd at the
time we create a logical device. Instead, we now put a reference to the
physical device on the logical device from which we can access these.
Finally, this also fixes a regression introduced with VK_KHR_display, where
if that extension is enabled but we are running inside a compositor, we would
acquire a display_fd that is not authenticated and try to use that instead
of acquiring an authenticated display_fd from the display server.
Fixes: b1188c9451 (v3dv: VK_KHR_display extension support)
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7546>
2020-11-11 08:45:33 +00:00
|
|
|
int32_t master_fd;
|
2020-10-05 09:44:59 +01:00
|
|
|
|
2021-02-28 18:52:36 +00:00
|
|
|
/* We need these because it is not clear how to detect
|
|
|
|
* valid devids in a portable way
|
|
|
|
*/
|
|
|
|
bool has_primary;
|
|
|
|
bool has_render;
|
|
|
|
|
|
|
|
dev_t primary_devid;
|
|
|
|
dev_t render_devid;
|
|
|
|
|
2022-04-27 10:30:06 +01:00
|
|
|
#if using_v3d_simulator
|
|
|
|
uint32_t device_id;
|
|
|
|
#endif
|
|
|
|
|
2021-03-18 21:56:50 +00:00
|
|
|
uint8_t driver_build_sha1[20];
|
2019-11-28 08:48:29 +00:00
|
|
|
uint8_t pipeline_cache_uuid[VK_UUID_SIZE];
|
2020-10-05 09:44:59 +01:00
|
|
|
uint8_t device_uuid[VK_UUID_SIZE];
|
|
|
|
uint8_t driver_uuid[VK_UUID_SIZE];
|
2019-11-28 08:48:29 +00:00
|
|
|
|
2022-03-29 23:52:32 +01:00
|
|
|
struct vk_sync_type drm_syncobj_type;
|
2022-04-05 00:37:26 +01:00
|
|
|
struct vk_sync_timeline_type sync_timeline_type;
|
|
|
|
const struct vk_sync_type *sync_types[3];
|
2022-03-29 23:52:32 +01:00
|
|
|
|
2021-03-18 21:56:50 +00:00
|
|
|
struct disk_cache *disk_cache;
|
|
|
|
|
v3dv: move authenticated display fd acquisition to swapchain creation time
So far, we have only been supporting X11, so we assumed that we were running
inside X11 and would always try to get an authenticated fd from Xorg during
device initialization. While this works for desktop Raspbian, it is not
really correct and it is not what we want to do when we start considering
other WSIs.
Initially, one could think we can still do this by guarding the WSI code
under the proper instance extension check. This, however, doesn't work
reliably, as the Vulkan loader can call vkEnumerateDevices without enabling
surface extensions on the instance, which then can lead to us not
initializing any display_fd and failing with VK_ERROR_INITIALIZATION_FAILED,
which is not correct, so while we can try to acquire the display_fd here,
it might not always work, and we should definitely not fail initialization
of the physical device for that.
Instead, with this change we move acquisition of display_fd to swapchain
creation time where required extensions need to be enabled in the instance.
This was also suggested by Daniel Stone during review of a work-in-progress
implementation for the Wayland WSI.
There is a special case to consider though: applications like Zink that
don't use Vulkan's swapchains at all but still allocate images that they
intend to use for WSI. We need to handle these by checking that we have
indeed acquired a display_fd before doing any memory allocation for WSI,
and acquiring one at that time if that's not the case.
This change also removes the render_fd and display_fd fields from the
logical device (which we were copying from the physical device), because
now there is no guarantee that we have acquired a display_fd at the
time we create a logical device. Instead, we now put a reference to the
physical device on the logical device from which we can access these.
Finally, this also fixes a regression introduced with VK_KHR_display, where
if that extension is enabled but we are running inside a compositor, we would
acquire a display_fd that is not authenticated and try to use that instead
of acquiring an authenticated display_fd from the display server.
Fixes: b1188c9451 (v3dv: VK_KHR_display extension support)
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7546>
2020-11-11 08:45:33 +00:00
|
|
|
mtx_t mutex;
|
|
|
|
|
2020-01-16 10:14:17 +00:00
|
|
|
struct wsi_device wsi_device;
|
|
|
|
|
2019-12-04 09:25:21 +00:00
|
|
|
VkPhysicalDeviceMemoryProperties memory;
|
|
|
|
|
2019-11-29 12:55:38 +00:00
|
|
|
struct v3d_device_info devinfo;
|
|
|
|
|
|
|
|
struct v3d_simulator_file *sim_file;
|
2019-12-02 12:59:04 +00:00
|
|
|
|
|
|
|
const struct v3d_compiler *compiler;
|
|
|
|
uint32_t next_program_id;
|
2020-01-10 10:31:51 +00:00
|
|
|
|
2022-09-08 12:04:46 +01:00
|
|
|
uint64_t heap_used;
|
|
|
|
|
2022-01-04 11:56:42 +00:00
|
|
|
/* This array holds all our 'struct v3dv_bo' allocations. We use this
|
|
|
|
* so we can add a refcount to our BOs and check if a particular BO
|
|
|
|
* was already allocated in this device using its GEM handle. This is
|
|
|
|
* necessary to properly manage BO imports, because the kernel doesn't
|
|
|
|
* refcount the underlying BO memory.
|
|
|
|
*
|
|
|
|
* Specifically, when self-importing (i.e. importing a BO into the same
|
|
|
|
* device that created it), the kernel will give us the same BO handle
|
|
|
|
* for both BOs and we must only free it once when both references are
|
2022-11-04 21:04:49 +00:00
|
|
|
* freed. Otherwise, if we are not self-importing, we get two different BO
|
2022-01-04 11:56:42 +00:00
|
|
|
* handles, and we want to free each one individually.
|
|
|
|
*
|
2022-11-04 21:04:49 +00:00
|
|
|
* The BOs in this map all have a refcnt with the reference counter and
|
2022-01-04 11:56:42 +00:00
|
|
|
* only self-imported BOs will ever have a refcnt > 1.
|
|
|
|
*/
|
|
|
|
struct util_sparse_array bo_map;
|
|
|
|
|
2020-01-10 10:31:51 +00:00
|
|
|
struct {
|
|
|
|
bool merge_jobs;
|
|
|
|
} options;
|
2021-10-04 12:53:17 +01:00
|
|
|
|
|
|
|
struct {
|
|
|
|
bool multisync;
|
2021-11-23 22:29:48 +00:00
|
|
|
bool perfmon;
|
2021-10-04 12:53:17 +01:00
|
|
|
} caps;
|
2019-11-25 15:29:12 +00:00
|
|
|
};
|
|
|
|
|
2023-04-04 09:12:02 +01:00
|
|
|
VkResult v3dv_physical_device_acquire_display(struct v3dv_physical_device *pdevice,
|
2020-11-16 08:50:22 +00:00
|
|
|
VkIcdSurfaceBase *surface);
|
v3dv: move authenticated display fd acquisition to swapchain creation time
So far, we have only been supporting X11, so we assumed that we were running
inside X11 and would always try to get an authenticated fd from Xorg during
device initialization. While this works for desktop Raspbian, it is not
really correct and it is not what we want to do when we start considering
other WSIs.
Initially, one could think we can still do this by guarding the WSI code
under the proper instance extension check. This, however, doesn't work
reliably, as the Vulkan loader can call vkEnumerateDevices without enabling
surface extensions on the instance, which then can lead to us not
initializing any display_fd and failing with VK_ERROR_INITIALIZATION_FAILED,
which is not correct, so while we can try to acquire the display_fd here,
it might not always work, and we should definitely not fail initialization
of the physical device for that.
Instead, with this change we move acquisition of display_fd to swapchain
creation time where required extensions need to be enabled in the instance.
This was also suggested by Daniel Stone during review of a work-in-progress
implementation for the Wayland WSI.
There is a special case to consider though: applications like Zink that
don't use Vulkan's swapchains at all but still allocate images that they
intend to use for WSI. We need to handle these by checking that we have
indeed acquired a display_fd before doing any memory allocation for WSI,
and acquiring one at that time if that's not the case.
This change also removes the render_fd and display_fd fields from the
logical device (which we were copying from the physical device), because
now there is no guarantee that we have acquired a display_fd at the
time we create a logical device. Instead, we now put a reference to the
physical device on the logical device from which we can access these.
Finally, this also fixes a regression introduced with VK_KHR_display, where
if that extension is enabled but we are running inside a compositor, we would
acquire a display_fd that is not authenticated and try to use that instead
of acquiring an authenticated display_fd from the display server.
Fixes: b1188c9451 (v3dv: VK_KHR_display extension support)
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7546>
2020-11-11 08:45:33 +00:00
|
|
|
|
2022-01-04 11:56:42 +00:00
|
|
|
static inline struct v3dv_bo *
|
|
|
|
v3dv_device_lookup_bo(struct v3dv_physical_device *device, uint32_t handle)
|
|
|
|
{
|
|
|
|
return (struct v3dv_bo *) util_sparse_array_get(&device->bo_map, handle);
|
|
|
|
}
|
|
|
|
|
2020-01-16 10:14:17 +00:00
|
|
|
VkResult v3dv_wsi_init(struct v3dv_physical_device *physical_device);
|
|
|
|
void v3dv_wsi_finish(struct v3dv_physical_device *physical_device);
|
2021-05-27 09:17:08 +01:00
|
|
|
struct v3dv_image *v3dv_wsi_get_image_from_swapchain(VkSwapchainKHR swapchain,
|
|
|
|
uint32_t index);
|
2020-01-16 10:14:17 +00:00
|
|
|
|
2020-08-26 07:38:41 +01:00
|
|
|
void v3dv_meta_clear_init(struct v3dv_device *device);
|
|
|
|
void v3dv_meta_clear_finish(struct v3dv_device *device);
|
|
|
|
|
|
|
|
void v3dv_meta_blit_init(struct v3dv_device *device);
|
|
|
|
void v3dv_meta_blit_finish(struct v3dv_device *device);
|
|
|
|
|
2020-11-12 09:43:54 +00:00
|
|
|
void v3dv_meta_texel_buffer_copy_init(struct v3dv_device *device);
|
|
|
|
void v3dv_meta_texel_buffer_copy_finish(struct v3dv_device *device);
|
|
|
|
|
2021-07-15 07:51:55 +01:00
|
|
|
bool v3dv_meta_can_use_tlb(struct v3dv_image *image,
|
v3dv: add support for multi-planar formats, enable YCbCr
Original patches wrote by Ella Stanforth.
Alejandro Piñeiro main changes (skipping the small fixes/typos):
* Reduced the list of supported formats to
VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and
VK_FORMAT_G8_B8R8_2PLANE_420_UNORM, that are the two only
mandatory by the spec.
* Fix format features exposed with YCbCr:
* Disallow some features not supported with YCbCr (like blitting)
* Disallow storage image support. Not clear if really useful. Even
if there are CTS tests, there is an ongoing discussion about the
possibility to remove them.
* Expose VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT, that is
mandatory for the formats supported.
* Not expose VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Some
CTS tests are failing right now, and it is not mandatory. Likely
to be revisit later.
* We are keeping VK_FORMAT_FEATURE_2_DISJOINT_BIT and
VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Even if they
are optional, it is working with the two formats that we are
exposing. Likely that will need to be refined if we start to
expose more formats.
* create_image_view: don't use hardcoded 0x70, but instead doing an
explicit bit or of VK_IMAGE_ASPECT_PLANE_0/1/2_BIT
* image_format_plane_features: keep how supported aspects and
separate stencil check is done. Even if the change introduced was
correct (not sure about that though), that change is unrelated to
this work
* write_image_descriptor: add additional checks for descriptor type,
to compute properly the offset.
* Cosmetic changes (don't use // for comments, capital letters, etc)
* Main changes coming from the review:
* Not use image aliases. All the info is already on the image
planes, and some points of the code were confusing as it was
using always a hardcoded plane 0.
* Squashed the two original main patches. YCbCr conversion was
leaking on the multi-planar support, as some support needed
info coming from the ycbcr structs.
* Not expose the extension on Android, and explicitly assert that
we expect plane_count to be 1 always.
* For a full list of review changes see MR#19950
Signed-off-by: Ella Stanforth <estanforth@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19950>
2022-07-28 09:15:43 +01:00
|
|
|
uint8_t plane,
|
2021-07-15 07:51:55 +01:00
|
|
|
const VkOffset3D *offset,
|
|
|
|
VkFormat *compat_format);
|
|
|
|
|
2019-11-25 15:29:12 +00:00
|
|
|
struct v3dv_instance {
|
2021-01-27 12:46:58 +00:00
|
|
|
struct vk_instance vk;
|
2019-11-25 15:29:12 +00:00
|
|
|
|
2020-07-07 14:56:44 +01:00
|
|
|
bool pipeline_cache_enabled;
|
2020-09-20 21:54:33 +01:00
|
|
|
bool default_pipeline_cache_enabled;
|
2019-11-25 15:29:12 +00:00
|
|
|
};
|
|
|
|
|
2022-03-29 23:52:32 +01:00
|
|
|
/* FIXME: In addition to tracking the last job submitted by GPU queue (cl, csd,
|
|
|
|
* tfu), we still need a syncobj to track the last overall job submitted
|
|
|
|
* (V3DV_QUEUE_ANY) for the case we don't support multisync. Someday we can
|
|
|
|
* start expecting multisync to be present and drop the legacy implementation
|
|
|
|
* together with this V3DV_QUEUE_ANY tracker.
|
|
|
|
*/
|
|
|
|
enum v3dv_queue_type {
|
|
|
|
V3DV_QUEUE_CL = 0,
|
|
|
|
V3DV_QUEUE_CSD,
|
|
|
|
V3DV_QUEUE_TFU,
|
|
|
|
V3DV_QUEUE_ANY,
|
|
|
|
V3DV_QUEUE_COUNT,
|
|
|
|
};
|
2020-05-18 09:41:11 +01:00
|
|
|
|
2022-03-29 23:52:32 +01:00
|
|
|
/* For each GPU queue, we use a syncobj to track the last job submitted. We
|
|
|
|
* set the flag `first` to determine when we are starting a new cmd buffer
|
|
|
|
* batch and therefore a job submitted to a given queue will be the first in a
|
|
|
|
* cmd buf batch.
|
|
|
|
*/
|
|
|
|
struct v3dv_last_job_sync {
|
2022-07-18 10:12:11 +01:00
|
|
|
/* If the job is the first submitted to a GPU queue in a cmd buffer batch.
|
|
|
|
*
|
|
|
|
* We use V3DV_QUEUE_{CL,CSD,TFU} both with and without multisync.
|
|
|
|
*/
|
2022-03-29 23:52:32 +01:00
|
|
|
bool first[V3DV_QUEUE_COUNT];
|
2022-07-18 10:12:11 +01:00
|
|
|
/* Array of syncobj to track the last job submitted to a GPU queue.
|
|
|
|
*
|
|
|
|
* With multisync we use V3DV_QUEUE_{CL,CSD,TFU} to track syncobjs for each
|
|
|
|
* queue, but without multisync we only track the last job submitted to any
|
|
|
|
* queue in V3DV_QUEUE_ANY.
|
|
|
|
*/
|
2022-03-29 23:52:32 +01:00
|
|
|
uint32_t syncs[V3DV_QUEUE_COUNT];
|
2020-05-18 09:41:11 +01:00
|
|
|
};
|
|
|
|
|
2019-11-25 15:29:12 +00:00
|
|
|
struct v3dv_queue {
|
2021-04-06 13:30:32 +01:00
|
|
|
struct vk_queue vk;
|
2019-11-25 15:29:12 +00:00
|
|
|
|
|
|
|
struct v3dv_device *device;
|
2020-05-18 09:41:11 +01:00
|
|
|
|
2022-03-29 23:52:32 +01:00
|
|
|
struct v3dv_last_job_sync last_job_syncs;
|
2022-03-18 07:04:22 +00:00
|
|
|
|
2020-09-18 17:02:05 +01:00
|
|
|
struct v3dv_job *noop_job;
|
2021-11-23 22:29:48 +00:00
|
|
|
|
|
|
|
/* The last active perfmon ID to prevent mixing of counter results when a
|
|
|
|
* job is submitted with a different perfmon id.
|
|
|
|
*/
|
|
|
|
uint32_t last_perfmon_id;
|
2019-11-25 15:29:12 +00:00
|
|
|
};
|
|
|
|
|
2022-03-29 23:52:32 +01:00
|
|
|
VkResult v3dv_queue_driver_submit(struct vk_queue *vk_queue,
|
|
|
|
struct vk_queue_submit *submit);
|
|
|
|
|
2020-11-12 09:43:54 +00:00
|
|
|
#define V3DV_META_BLIT_CACHE_KEY_SIZE (4 * sizeof(uint32_t))
|
2021-07-12 12:16:06 +01:00
|
|
|
#define V3DV_META_TEXEL_BUFFER_COPY_CACHE_KEY_SIZE (3 * sizeof(uint32_t) + \
|
2021-02-04 07:17:43 +00:00
|
|
|
sizeof(VkComponentMapping))
|
2020-08-07 14:16:19 +01:00
|
|
|
|
2020-03-31 12:06:55 +01:00
|
|
|
struct v3dv_meta_color_clear_pipeline {
|
|
|
|
VkPipeline pipeline;
|
|
|
|
VkRenderPass pass;
|
2020-08-25 13:25:45 +01:00
|
|
|
bool cached;
|
2020-08-07 14:16:19 +01:00
|
|
|
uint64_t key;
|
2020-07-16 11:34:30 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
struct v3dv_meta_depth_clear_pipeline {
|
|
|
|
VkPipeline pipeline;
|
2020-08-07 14:16:19 +01:00
|
|
|
uint64_t key;
|
2020-03-31 12:06:55 +01:00
|
|
|
};
|
|
|
|
|
2020-04-21 13:09:23 +01:00
|
|
|
struct v3dv_meta_blit_pipeline {
|
|
|
|
VkPipeline pipeline;
|
|
|
|
VkRenderPass pass;
|
2020-10-08 12:24:13 +01:00
|
|
|
VkRenderPass pass_no_load;
|
2020-08-07 14:16:19 +01:00
|
|
|
uint8_t key[V3DV_META_BLIT_CACHE_KEY_SIZE];
|
2020-04-21 13:09:23 +01:00
|
|
|
};
|
|
|
|
|
2020-11-12 09:43:54 +00:00
|
|
|
struct v3dv_meta_texel_buffer_copy_pipeline {
|
|
|
|
VkPipeline pipeline;
|
|
|
|
VkRenderPass pass;
|
|
|
|
VkRenderPass pass_no_load;
|
|
|
|
uint8_t key[V3DV_META_TEXEL_BUFFER_COPY_CACHE_KEY_SIZE];
|
|
|
|
};
|
|
|
|
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 00:05:54 +00:00
|
|
|
struct v3dv_pipeline_key {
|
|
|
|
uint8_t topology;
|
|
|
|
uint8_t logicop_func;
|
|
|
|
bool msaa;
|
|
|
|
bool sample_alpha_to_coverage;
|
|
|
|
bool sample_alpha_to_one;
|
|
|
|
uint8_t cbufs;
|
|
|
|
struct {
|
|
|
|
enum pipe_format format;
|
2021-11-10 10:26:06 +00:00
|
|
|
uint8_t swizzle[4];
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 00:05:54 +00:00
|
|
|
} color_fmt[V3D_MAX_DRAW_BUFFERS];
|
|
|
|
uint8_t f32_color_rb;
|
|
|
|
uint32_t va_swap_rb_mask;
|
2021-07-23 11:42:59 +01:00
|
|
|
bool has_multiview;
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 00:05:54 +00:00
|
|
|
};
|
|
|
|
|
2020-07-07 14:56:44 +01:00
|
|
|
struct v3dv_pipeline_cache_stats {
|
|
|
|
uint32_t miss;
|
|
|
|
uint32_t hit;
|
|
|
|
uint32_t count;
|
2022-05-03 12:10:30 +01:00
|
|
|
uint32_t on_disk_hit;
|
2020-07-07 14:56:44 +01:00
|
|
|
};
|
|
|
|
|
2021-03-08 00:13:46 +00:00
|
|
|
/* Equivalent to gl_shader_stage, but including the coordinate shaders
|
|
|
|
*
|
|
|
|
* FIXME: perhaps move to common
|
|
|
|
*/
|
2021-05-23 22:08:07 +01:00
|
|
|
enum broadcom_shader_stage {
|
2021-03-08 00:13:46 +00:00
|
|
|
BROADCOM_SHADER_VERTEX,
|
|
|
|
BROADCOM_SHADER_VERTEX_BIN,
|
2021-06-30 09:11:10 +01:00
|
|
|
BROADCOM_SHADER_GEOMETRY,
|
|
|
|
BROADCOM_SHADER_GEOMETRY_BIN,
|
2021-03-08 00:13:46 +00:00
|
|
|
BROADCOM_SHADER_FRAGMENT,
|
|
|
|
BROADCOM_SHADER_COMPUTE,
|
2021-05-23 22:08:07 +01:00
|
|
|
};
|
2021-03-08 00:13:46 +00:00
|
|
|
|
|
|
|
#define BROADCOM_SHADER_STAGES (BROADCOM_SHADER_COMPUTE + 1)
|
|
|
|
|
2021-03-15 21:27:43 +00:00
|
|
|
/* Assumes that coordinate shaders will be custom-handled by the caller */
|
2021-05-23 22:08:07 +01:00
|
|
|
static inline enum broadcom_shader_stage
|
2021-03-15 21:27:43 +00:00
|
|
|
gl_shader_stage_to_broadcom(gl_shader_stage stage)
|
|
|
|
{
|
|
|
|
switch (stage) {
|
|
|
|
case MESA_SHADER_VERTEX:
|
|
|
|
return BROADCOM_SHADER_VERTEX;
|
2021-06-30 09:11:10 +01:00
|
|
|
case MESA_SHADER_GEOMETRY:
|
|
|
|
return BROADCOM_SHADER_GEOMETRY;
|
2021-03-15 21:27:43 +00:00
|
|
|
case MESA_SHADER_FRAGMENT:
|
|
|
|
return BROADCOM_SHADER_FRAGMENT;
|
|
|
|
case MESA_SHADER_COMPUTE:
|
|
|
|
return BROADCOM_SHADER_COMPUTE;
|
|
|
|
default:
|
|
|
|
unreachable("Unknown gl shader stage");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline gl_shader_stage
|
2021-05-23 22:08:07 +01:00
|
|
|
broadcom_shader_stage_to_gl(enum broadcom_shader_stage stage)
|
2021-03-15 21:27:43 +00:00
|
|
|
{
|
|
|
|
switch (stage) {
|
|
|
|
case BROADCOM_SHADER_VERTEX:
|
|
|
|
case BROADCOM_SHADER_VERTEX_BIN:
|
|
|
|
return MESA_SHADER_VERTEX;
|
2021-06-30 09:11:10 +01:00
|
|
|
case BROADCOM_SHADER_GEOMETRY:
|
|
|
|
case BROADCOM_SHADER_GEOMETRY_BIN:
|
|
|
|
return MESA_SHADER_GEOMETRY;
|
2021-03-15 21:27:43 +00:00
|
|
|
case BROADCOM_SHADER_FRAGMENT:
|
|
|
|
return MESA_SHADER_FRAGMENT;
|
|
|
|
case BROADCOM_SHADER_COMPUTE:
|
|
|
|
return MESA_SHADER_COMPUTE;
|
|
|
|
default:
|
|
|
|
unreachable("Unknown broadcom shader stage");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-06-30 09:39:04 +01:00
|
|
|
static inline bool
|
|
|
|
broadcom_shader_stage_is_binning(enum broadcom_shader_stage stage)
|
|
|
|
{
|
|
|
|
switch (stage) {
|
|
|
|
case BROADCOM_SHADER_VERTEX_BIN:
|
|
|
|
case BROADCOM_SHADER_GEOMETRY_BIN:
|
|
|
|
return true;
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool
|
|
|
|
broadcom_shader_stage_is_render_with_binning(enum broadcom_shader_stage stage)
|
|
|
|
{
|
|
|
|
switch (stage) {
|
|
|
|
case BROADCOM_SHADER_VERTEX:
|
|
|
|
case BROADCOM_SHADER_GEOMETRY:
|
|
|
|
return true;
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline enum broadcom_shader_stage
|
|
|
|
broadcom_binning_shader_stage_for_render_stage(enum broadcom_shader_stage stage)
|
|
|
|
{
|
|
|
|
switch (stage) {
|
|
|
|
case BROADCOM_SHADER_VERTEX:
|
|
|
|
return BROADCOM_SHADER_VERTEX_BIN;
|
|
|
|
case BROADCOM_SHADER_GEOMETRY:
|
|
|
|
return BROADCOM_SHADER_GEOMETRY_BIN;
|
|
|
|
default:
|
|
|
|
unreachable("Invalid shader stage");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-04-14 11:35:03 +01:00
|
|
|
static inline const char *
|
2021-05-23 22:08:07 +01:00
|
|
|
broadcom_shader_stage_name(enum broadcom_shader_stage stage)
|
2021-04-14 11:35:03 +01:00
|
|
|
{
|
|
|
|
switch(stage) {
|
|
|
|
case BROADCOM_SHADER_VERTEX_BIN:
|
|
|
|
return "MESA_SHADER_VERTEX_BIN";
|
2021-06-30 09:11:10 +01:00
|
|
|
case BROADCOM_SHADER_GEOMETRY_BIN:
|
|
|
|
return "MESA_SHADER_GEOMETRY_BIN";
|
2021-04-14 11:35:03 +01:00
|
|
|
default:
|
|
|
|
return gl_shader_stage_name(broadcom_shader_stage_to_gl(stage));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-07-04 12:10:49 +01:00
|
|
|
struct v3dv_pipeline_cache {
|
2020-11-12 15:30:41 +00:00
|
|
|
struct vk_object_base base;
|
2020-07-04 12:10:49 +01:00
|
|
|
|
|
|
|
struct v3dv_device *device;
|
|
|
|
mtx_t mutex;
|
2020-07-07 14:56:44 +01:00
|
|
|
|
|
|
|
struct hash_table *nir_cache;
|
|
|
|
struct v3dv_pipeline_cache_stats nir_stats;
|
2020-07-16 11:41:11 +01:00
|
|
|
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 00:05:54 +00:00
|
|
|
struct hash_table *cache;
|
|
|
|
struct v3dv_pipeline_cache_stats stats;
|
2021-08-14 15:09:23 +01:00
|
|
|
|
|
|
|
/* For VK_EXT_pipeline_creation_cache_control. */
|
|
|
|
bool externally_synchronized;
|
2020-07-04 12:10:49 +01:00
|
|
|
};
|
|
|
|
|
2019-11-29 11:44:40 +00:00
|
|
|
struct v3dv_device {
|
2020-11-12 15:30:41 +00:00
|
|
|
struct vk_device vk;
|
2019-11-29 11:44:40 +00:00
|
|
|
|
|
|
|
struct v3dv_instance *instance;
|
v3dv: move authenticated display fd acquisition to swapchain creation time
So far, we have only been supporting X11, so we assumed that we were running
inside X11 and would always try to get an authenticated fd from Xorg during
device initialization. While this works for desktop Raspbian, it is not
really correct and it is not what we want to do when we start considering
other WSIs.
Initially, one could think we can still do this by guarding the WSI code
under the proper instance extension check. This, however, doesn't work
reliably, as the Vulkan loader can call vkEnumerateDevices without enabling
surface extensions on the instance, which then can lead to us not
initializing any display_fd and failing with VK_ERROR_INITIALIZATION_FAILED,
which is not correct, so while we can try to acquire the display_fd here,
it might not always work, and we should definitely not fail initialization
of the physical device for that.
Instead, with this change we move acquisition of display_fd to swapchain
creation time where required extensions need to be enabled in the instance.
This was also suggested by Daniel Stone during review of a work-in-progress
implementation for the Wayland WSI.
There is a special case to consider though: applications like Zink that
don't use Vulkan's swapchains at all but still allocate images that they
intend to use for WSI. We need to handle these by checking that we have
indeed acquired a display_fd before doing any memory allocation for WSI,
and acquiring one at that time if that's not the case.
This change also removes the render_fd and display_fd fields from the
logical device (which we were copying from the physical device), because
now there is no guarantee that we have acquired a display_fd at the
time we create a logical device. Instead, we now put a reference to the
physical device on the logical device from which we can access these.
Finally, this also fixes a regression introduced with VK_KHR_display, where
if that extension is enabled but we are running inside a compositor, we would
acquire a display_fd that is not authenticated and try to use that instead
of acquiring an authenticated display_fd from the display server.
Fixes: b1188c9451 (v3dv: VK_KHR_display extension support)
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7546>
2020-11-11 08:45:33 +00:00
|
|
|
struct v3dv_physical_device *pdevice;
|
2019-11-29 11:44:40 +00:00
|
|
|
|
|
|
|
struct v3d_device_info devinfo;
|
|
|
|
struct v3dv_queue queue;
|
|
|
|
|
2022-04-04 16:25:15 +01:00
|
|
|
/* Guards query->maybe_available and value for timestamps */
|
|
|
|
mtx_t query_mutex;
|
|
|
|
|
|
|
|
/* Signaled whenever a query is ended */
|
|
|
|
cnd_t query_ended;
|
|
|
|
|
2020-03-31 11:59:44 +01:00
|
|
|
/* Resources used for meta operations */
|
|
|
|
struct {
|
2020-03-31 12:06:55 +01:00
|
|
|
mtx_t mtx;
|
2020-03-31 11:59:44 +01:00
|
|
|
struct {
|
2020-11-17 11:10:59 +00:00
|
|
|
VkPipelineLayout p_layout;
|
2020-03-31 12:06:55 +01:00
|
|
|
struct hash_table *cache; /* v3dv_meta_color_clear_pipeline */
|
2020-03-31 11:59:44 +01:00
|
|
|
} color_clear;
|
2020-07-16 11:34:30 +01:00
|
|
|
struct {
|
2020-11-17 11:10:59 +00:00
|
|
|
VkPipelineLayout p_layout;
|
2020-07-16 11:34:30 +01:00
|
|
|
struct hash_table *cache; /* v3dv_meta_depth_clear_pipeline */
|
|
|
|
} depth_clear;
|
2020-04-21 13:09:23 +01:00
|
|
|
struct {
|
2020-11-17 11:10:59 +00:00
|
|
|
VkDescriptorSetLayout ds_layout;
|
|
|
|
VkPipelineLayout p_layout;
|
2020-04-28 12:36:37 +01:00
|
|
|
struct hash_table *cache[3]; /* v3dv_meta_blit_pipeline for 1d, 2d, 3d */
|
2020-04-21 13:09:23 +01:00
|
|
|
} blit;
|
2020-11-12 09:43:54 +00:00
|
|
|
struct {
|
2020-11-17 11:10:59 +00:00
|
|
|
VkDescriptorSetLayout ds_layout;
|
|
|
|
VkPipelineLayout p_layout;
|
2020-11-12 09:43:54 +00:00
|
|
|
struct hash_table *cache[3]; /* v3dv_meta_texel_buffer_copy_pipeline for 1d, 2d, 3d */
|
|
|
|
} texel_buffer_copy;
|
2020-03-31 11:59:44 +01:00
|
|
|
} meta;
|
v3dv/bo: adding a BO cache
Heavily based on the already existing for the v3d OpenGL driver, but
without references, and with some extra OOM checks (Vulkan CTS has
several OOM tests).
With this commit v3dv_bo_alloc and v3dv_bo_free became frontends to
the bo_cache. The former tries to get a BO from the cache if possible,
and the latter stores the BO on the cache if possible. The former also
adds a new parameter to point if the BO to allocate is private.
As v3d we are only caching private BOs, those created by the driver
for internal use (like CLs, tile_alloc, etc). They are the ones with
the highest change of being reused (for example, CL BOs are always
4KB, so they can always be reused). User-created BOs can have any
size, including some very large ones for buffers and images, which
makes them far less likely to be reused and would add a lot of memory
pressure if we decided to cache them.
In any case, in practice, we found that we could get a performance
improvement by caching also user-created BOs, but that would need more
care and an analysis to decide which ones makes sense. Would also
require to change how the cached BOs are stored by size. Right now
there are an array of list_head, that doesn't work well with big
BOs. If done, that would be handled on a separate commit.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-06-05 11:21:54 +01:00
|
|
|
|
|
|
|
struct v3dv_bo_cache {
|
|
|
|
/** List of struct v3d_bo freed, by age. */
|
|
|
|
struct list_head time_list;
|
|
|
|
/** List of struct v3d_bo freed, per size, by age. */
|
|
|
|
struct list_head *size_list;
|
|
|
|
uint32_t size_list_size;
|
|
|
|
|
|
|
|
mtx_t lock;
|
2020-06-17 00:41:13 +01:00
|
|
|
|
|
|
|
uint32_t cache_size;
|
|
|
|
uint32_t cache_count;
|
|
|
|
uint32_t max_cache_size;
|
v3dv/bo: adding a BO cache
Heavily based on the already existing for the v3d OpenGL driver, but
without references, and with some extra OOM checks (Vulkan CTS has
several OOM tests).
With this commit v3dv_bo_alloc and v3dv_bo_free became frontends to
the bo_cache. The former tries to get a BO from the cache if possible,
and the latter stores the BO on the cache if possible. The former also
adds a new parameter to point if the BO to allocate is private.
As v3d we are only caching private BOs, those created by the driver
for internal use (like CLs, tile_alloc, etc). They are the ones with
the highest change of being reused (for example, CL BOs are always
4KB, so they can always be reused). User-created BOs can have any
size, including some very large ones for buffers and images, which
makes them far less likely to be reused and would add a lot of memory
pressure if we decided to cache them.
In any case, in practice, we found that we could get a performance
improvement by caching also user-created BOs, but that would need more
care and an analysis to decide which ones makes sense. Would also
require to change how the cached BOs are stored by size. Right now
there are an array of list_head, that doesn't work well with big
BOs. If done, that would be handled on a separate commit.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-06-05 11:21:54 +01:00
|
|
|
} bo_cache;
|
|
|
|
|
|
|
|
uint32_t bo_size;
|
|
|
|
uint32_t bo_count;
|
2020-07-22 01:08:06 +01:00
|
|
|
|
2022-10-19 08:48:19 +01:00
|
|
|
/* Event handling resources.
|
|
|
|
*
|
|
|
|
* Our implementation of events uses a BO to store event state (signaled vs
|
|
|
|
* reset) and dispatches compute shaders to handle GPU event functions
|
|
|
|
* (signal, reset, wait). This struct holds all the resources required
|
|
|
|
* by the implementation.
|
|
|
|
*/
|
|
|
|
struct {
|
|
|
|
mtx_t lock;
|
|
|
|
|
|
|
|
/* BO for the event states: signaled (1) or reset (0) */
|
|
|
|
struct v3dv_bo *bo;
|
|
|
|
|
2022-11-29 09:52:33 +00:00
|
|
|
/* We pre-allocate all the events we can fit for the size of the BO we
|
|
|
|
* create to track their states, where each event has an index which is
|
|
|
|
* basically the offset of its state in that BO. We keep a free list with
|
|
|
|
* the pre-allocated events that are available.
|
2022-10-19 08:48:19 +01:00
|
|
|
*/
|
2022-11-29 09:52:33 +00:00
|
|
|
uint32_t event_count;
|
|
|
|
struct v3dv_event *events;
|
2022-10-19 08:48:19 +01:00
|
|
|
struct list_head free_list;
|
|
|
|
|
|
|
|
/* Vulkan resources to access the event BO from shaders. We have a
|
|
|
|
* pipeline that sets the state of an event and another that waits on
|
|
|
|
* a single event. Both pipelines require access to the event state BO,
|
|
|
|
* for which we need to allocate a single descripot set.
|
|
|
|
*/
|
|
|
|
VkBuffer buffer;
|
|
|
|
VkDeviceMemory mem;
|
|
|
|
VkDescriptorSetLayout descriptor_set_layout;
|
|
|
|
VkPipelineLayout pipeline_layout;
|
|
|
|
VkDescriptorPool descriptor_pool;
|
|
|
|
VkDescriptorSet descriptor_set;
|
|
|
|
VkPipeline set_event_pipeline;
|
|
|
|
VkPipeline wait_event_pipeline;
|
|
|
|
} events;
|
|
|
|
|
2022-10-28 11:07:07 +01:00
|
|
|
/* Query handling resources.
|
|
|
|
*
|
|
|
|
* Our implementation of occlusion queries uses a BO per pool to keep track
|
|
|
|
* of the per-query availability state and dispatches compute shaders to
|
|
|
|
* handle GPU query functions that read and write that state. This struct
|
|
|
|
* holds Vulkan resources that can be shared across all query pools to
|
|
|
|
* implement this. This framework may be extended in the future to handle
|
|
|
|
* more query types.
|
|
|
|
*/
|
|
|
|
struct {
|
|
|
|
VkDescriptorSetLayout buf_descriptor_set_layout;
|
|
|
|
|
|
|
|
/* Set query availability */
|
|
|
|
VkPipelineLayout avail_pipeline_layout;
|
|
|
|
VkPipeline avail_pipeline;
|
|
|
|
|
|
|
|
/* Reset query availability and clear occlusion counters */
|
|
|
|
VkPipelineLayout reset_occlusion_pipeline_layout;
|
|
|
|
VkPipeline reset_occlusion_pipeline;
|
|
|
|
|
|
|
|
/* Copy query results */
|
|
|
|
VkPipelineLayout copy_pipeline_layout;
|
2022-11-21 07:36:28 +00:00
|
|
|
VkPipeline copy_pipeline[8];
|
2022-10-28 11:07:07 +01:00
|
|
|
} queries;
|
|
|
|
|
2020-07-22 01:08:06 +01:00
|
|
|
struct v3dv_pipeline_cache default_pipeline_cache;
|
2020-08-27 09:48:29 +01:00
|
|
|
|
2022-11-04 21:04:49 +00:00
|
|
|
/* GL_SHADER_STATE_RECORD needs to specify default attribute values. The
|
v3dv: define a default attribute values with float type
We are providing a BO with the default attribute values for the
GL_SHADER_STATE_RECORD, that contains 16 vec4. Such default value for
each vec4 is (0, 0, 0, 1). As the attribute format could be int or
float, the "1" value needs to take into account the attribute format.
But in the practice, the most common case is all floats. So we create
one default attribute values BO assuming that all attributes will be
floats, and we store it at v3dv_device and only create a new one if a
int format type is defined. That allows to reduce the amount of BOs
needed.
Note that we could still try to reduce the amount of BOs used by the
pipelines if we create a bigger BO, and we just play with the
offsets. But as mentioned, that's not the usual, and would add an
extra complexity,so it is not a priority right now.
This makes the following test passing when disabling the pipeline
cache support:
dEQP-VK.api.object_management.max_concurrent.graphics_pipeline
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9845>
2021-03-25 12:30:55 +00:00
|
|
|
* following covers the most common case, that is all attributes format
|
|
|
|
* being float being float, allowing us to reuse the same BO for all
|
|
|
|
* pipelines matching this requirement. Pipelines that need integer
|
|
|
|
* attributes will create their own BO.
|
|
|
|
*/
|
|
|
|
struct v3dv_bo *default_attribute_float;
|
2022-09-23 08:10:36 +01:00
|
|
|
|
2022-06-27 13:12:25 +01:00
|
|
|
void *device_address_mem_ctx;
|
|
|
|
struct util_dynarray device_address_bo_list; /* Array of struct v3dv_bo * */
|
|
|
|
|
2021-12-08 10:15:38 +00:00
|
|
|
#ifdef ANDROID
|
|
|
|
const void *gralloc;
|
|
|
|
enum {
|
|
|
|
V3DV_GRALLOC_UNKNOWN,
|
|
|
|
V3DV_GRALLOC_CROS,
|
|
|
|
V3DV_GRALLOC_OTHER,
|
|
|
|
} gralloc_type;
|
|
|
|
#endif
|
2019-11-29 11:44:40 +00:00
|
|
|
};
|
|
|
|
|
2019-11-27 21:08:51 +00:00
|
|
|
struct v3dv_device_memory {
|
2020-11-12 15:30:41 +00:00
|
|
|
struct vk_object_base base;
|
|
|
|
|
2019-12-12 10:02:04 +00:00
|
|
|
struct v3dv_bo *bo;
|
2019-12-04 09:39:01 +00:00
|
|
|
const VkMemoryType *type;
|
2020-09-11 11:20:20 +01:00
|
|
|
bool is_for_wsi;
|
2022-06-27 13:12:25 +01:00
|
|
|
bool is_for_device_address;
|
2019-11-27 21:08:51 +00:00
|
|
|
};
|
|
|
|
|
2019-12-02 10:25:28 +00:00
|
|
|
#define V3D_OUTPUT_IMAGE_FORMAT_NO 255
|
2020-02-10 08:42:29 +00:00
|
|
|
#define TEXTURE_DATA_FORMAT_NO 255
|
2019-12-02 10:25:28 +00:00
|
|
|
|
v3dv: add support for multi-planar formats, enable YCbCr
Original patches wrote by Ella Stanforth.
Alejandro Piñeiro main changes (skipping the small fixes/typos):
* Reduced the list of supported formats to
VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and
VK_FORMAT_G8_B8R8_2PLANE_420_UNORM, that are the two only
mandatory by the spec.
* Fix format features exposed with YCbCr:
* Disallow some features not supported with YCbCr (like blitting)
* Disallow storage image support. Not clear if really useful. Even
if there are CTS tests, there is an ongoing discussion about the
possibility to remove them.
* Expose VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT, that is
mandatory for the formats supported.
* Not expose VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Some
CTS tests are failing right now, and it is not mandatory. Likely
to be revisit later.
* We are keeping VK_FORMAT_FEATURE_2_DISJOINT_BIT and
VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Even if they
are optional, it is working with the two formats that we are
exposing. Likely that will need to be refined if we start to
expose more formats.
* create_image_view: don't use hardcoded 0x70, but instead doing an
explicit bit or of VK_IMAGE_ASPECT_PLANE_0/1/2_BIT
* image_format_plane_features: keep how supported aspects and
separate stencil check is done. Even if the change introduced was
correct (not sure about that though), that change is unrelated to
this work
* write_image_descriptor: add additional checks for descriptor type,
to compute properly the offset.
* Cosmetic changes (don't use // for comments, capital letters, etc)
* Main changes coming from the review:
* Not use image aliases. All the info is already on the image
planes, and some points of the code were confusing as it was
using always a hardcoded plane 0.
* Squashed the two original main patches. YCbCr conversion was
leaking on the multi-planar support, as some support needed
info coming from the ycbcr structs.
* Not expose the extension on Android, and explicitly assert that
we expect plane_count to be 1 always.
* For a full list of review changes see MR#19950
Signed-off-by: Ella Stanforth <estanforth@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19950>
2022-07-28 09:15:43 +01:00
|
|
|
#define V3DV_MAX_PLANE_COUNT 3
|
|
|
|
struct v3dv_format_plane {
|
2019-12-02 10:25:28 +00:00
|
|
|
/* One of V3D33_OUTPUT_IMAGE_FORMAT_*, or OUTPUT_IMAGE_FORMAT_NO */
|
|
|
|
uint8_t rt_type;
|
|
|
|
|
|
|
|
/* One of V3D33_TEXTURE_DATA_FORMAT_*. */
|
|
|
|
uint8_t tex_type;
|
|
|
|
|
|
|
|
/* Swizzle to apply to the RGBA shader output for storing to the tile
|
|
|
|
* buffer, to the RGBA tile buffer to produce shader input (for
|
|
|
|
* blending), and for turning the rgba8888 texture sampler return
|
|
|
|
* value into shader rgba values.
|
|
|
|
*/
|
|
|
|
uint8_t swizzle[4];
|
|
|
|
|
|
|
|
/* Whether the return value is 16F/I/UI or 32F/I/UI. */
|
|
|
|
uint8_t return_size;
|
v3dv: add support for multi-planar formats, enable YCbCr
Original patches wrote by Ella Stanforth.
Alejandro Piñeiro main changes (skipping the small fixes/typos):
* Reduced the list of supported formats to
VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and
VK_FORMAT_G8_B8R8_2PLANE_420_UNORM, that are the two only
mandatory by the spec.
* Fix format features exposed with YCbCr:
* Disallow some features not supported with YCbCr (like blitting)
* Disallow storage image support. Not clear if really useful. Even
if there are CTS tests, there is an ongoing discussion about the
possibility to remove them.
* Expose VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT, that is
mandatory for the formats supported.
* Not expose VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Some
CTS tests are failing right now, and it is not mandatory. Likely
to be revisit later.
* We are keeping VK_FORMAT_FEATURE_2_DISJOINT_BIT and
VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Even if they
are optional, it is working with the two formats that we are
exposing. Likely that will need to be refined if we start to
expose more formats.
* create_image_view: don't use hardcoded 0x70, but instead doing an
explicit bit or of VK_IMAGE_ASPECT_PLANE_0/1/2_BIT
* image_format_plane_features: keep how supported aspects and
separate stencil check is done. Even if the change introduced was
correct (not sure about that though), that change is unrelated to
this work
* write_image_descriptor: add additional checks for descriptor type,
to compute properly the offset.
* Cosmetic changes (don't use // for comments, capital letters, etc)
* Main changes coming from the review:
* Not use image aliases. All the info is already on the image
planes, and some points of the code were confusing as it was
using always a hardcoded plane 0.
* Squashed the two original main patches. YCbCr conversion was
leaking on the multi-planar support, as some support needed
info coming from the ycbcr structs.
* Not expose the extension on Android, and explicitly assert that
we expect plane_count to be 1 always.
* For a full list of review changes see MR#19950
Signed-off-by: Ella Stanforth <estanforth@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19950>
2022-07-28 09:15:43 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
struct v3dv_format {
|
|
|
|
/* Non 0 plane count implies supported */
|
|
|
|
uint8_t plane_count;
|
|
|
|
|
|
|
|
struct v3dv_format_plane planes[V3DV_MAX_PLANE_COUNT];
|
2020-04-14 23:56:31 +01:00
|
|
|
|
|
|
|
/* If the format supports (linear) filtering when texturing. */
|
|
|
|
bool supports_filtering;
|
2019-12-02 10:25:28 +00:00
|
|
|
};
|
|
|
|
|
v3dv: add support for multi-planar formats, enable YCbCr
Original patches wrote by Ella Stanforth.
Alejandro Piñeiro main changes (skipping the small fixes/typos):
* Reduced the list of supported formats to
VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and
VK_FORMAT_G8_B8R8_2PLANE_420_UNORM, that are the two only
mandatory by the spec.
* Fix format features exposed with YCbCr:
* Disallow some features not supported with YCbCr (like blitting)
* Disallow storage image support. Not clear if really useful. Even
if there are CTS tests, there is an ongoing discussion about the
possibility to remove them.
* Expose VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT, that is
mandatory for the formats supported.
* Not expose VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Some
CTS tests are failing right now, and it is not mandatory. Likely
to be revisit later.
* We are keeping VK_FORMAT_FEATURE_2_DISJOINT_BIT and
VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Even if they
are optional, it is working with the two formats that we are
exposing. Likely that will need to be refined if we start to
expose more formats.
* create_image_view: don't use hardcoded 0x70, but instead doing an
explicit bit or of VK_IMAGE_ASPECT_PLANE_0/1/2_BIT
* image_format_plane_features: keep how supported aspects and
separate stencil check is done. Even if the change introduced was
correct (not sure about that though), that change is unrelated to
this work
* write_image_descriptor: add additional checks for descriptor type,
to compute properly the offset.
* Cosmetic changes (don't use // for comments, capital letters, etc)
* Main changes coming from the review:
* Not use image aliases. All the info is already on the image
planes, and some points of the code were confusing as it was
using always a hardcoded plane 0.
* Squashed the two original main patches. YCbCr conversion was
leaking on the multi-planar support, as some support needed
info coming from the ycbcr structs.
* Not expose the extension on Android, and explicitly assert that
we expect plane_count to be 1 always.
* For a full list of review changes see MR#19950
Signed-off-by: Ella Stanforth <estanforth@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19950>
2022-07-28 09:15:43 +01:00
|
|
|
/* Note that although VkImageAspectFlags would allow to combine more than one
|
|
|
|
* PLANE bit, for all the use cases we implement that use VkImageAspectFlags,
|
|
|
|
* only one plane is allowed, like for example vkCmdCopyImage:
|
|
|
|
*
|
|
|
|
* "If srcImage has a VkFormat with two planes then for each element of
|
|
|
|
* pRegions, srcSubresource.aspectMask must be VK_IMAGE_ASPECT_PLANE_0_BIT
|
|
|
|
* or VK_IMAGE_ASPECT_PLANE_1_BIT"
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
static uint8_t v3dv_plane_from_aspect(VkImageAspectFlags aspect)
|
|
|
|
{
|
|
|
|
switch (aspect) {
|
|
|
|
case VK_IMAGE_ASPECT_COLOR_BIT:
|
|
|
|
case VK_IMAGE_ASPECT_DEPTH_BIT:
|
|
|
|
case VK_IMAGE_ASPECT_STENCIL_BIT:
|
|
|
|
case VK_IMAGE_ASPECT_DEPTH_BIT | VK_IMAGE_ASPECT_STENCIL_BIT:
|
|
|
|
case VK_IMAGE_ASPECT_PLANE_0_BIT:
|
2023-02-20 22:40:12 +00:00
|
|
|
case VK_IMAGE_ASPECT_MEMORY_PLANE_0_BIT_EXT:
|
v3dv: add support for multi-planar formats, enable YCbCr
Original patches wrote by Ella Stanforth.
Alejandro Piñeiro main changes (skipping the small fixes/typos):
* Reduced the list of supported formats to
VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and
VK_FORMAT_G8_B8R8_2PLANE_420_UNORM, that are the two only
mandatory by the spec.
* Fix format features exposed with YCbCr:
* Disallow some features not supported with YCbCr (like blitting)
* Disallow storage image support. Not clear if really useful. Even
if there are CTS tests, there is an ongoing discussion about the
possibility to remove them.
* Expose VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT, that is
mandatory for the formats supported.
* Not expose VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Some
CTS tests are failing right now, and it is not mandatory. Likely
to be revisit later.
* We are keeping VK_FORMAT_FEATURE_2_DISJOINT_BIT and
VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Even if they
are optional, it is working with the two formats that we are
exposing. Likely that will need to be refined if we start to
expose more formats.
* create_image_view: don't use hardcoded 0x70, but instead doing an
explicit bit or of VK_IMAGE_ASPECT_PLANE_0/1/2_BIT
* image_format_plane_features: keep how supported aspects and
separate stencil check is done. Even if the change introduced was
correct (not sure about that though), that change is unrelated to
this work
* write_image_descriptor: add additional checks for descriptor type,
to compute properly the offset.
* Cosmetic changes (don't use // for comments, capital letters, etc)
* Main changes coming from the review:
* Not use image aliases. All the info is already on the image
planes, and some points of the code were confusing as it was
using always a hardcoded plane 0.
* Squashed the two original main patches. YCbCr conversion was
leaking on the multi-planar support, as some support needed
info coming from the ycbcr structs.
* Not expose the extension on Android, and explicitly assert that
we expect plane_count to be 1 always.
* For a full list of review changes see MR#19950
Signed-off-by: Ella Stanforth <estanforth@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19950>
2022-07-28 09:15:43 +01:00
|
|
|
return 0;
|
|
|
|
case VK_IMAGE_ASPECT_PLANE_1_BIT:
|
2023-02-20 22:40:12 +00:00
|
|
|
case VK_IMAGE_ASPECT_MEMORY_PLANE_1_BIT_EXT:
|
v3dv: add support for multi-planar formats, enable YCbCr
Original patches wrote by Ella Stanforth.
Alejandro Piñeiro main changes (skipping the small fixes/typos):
* Reduced the list of supported formats to
VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and
VK_FORMAT_G8_B8R8_2PLANE_420_UNORM, that are the two only
mandatory by the spec.
* Fix format features exposed with YCbCr:
* Disallow some features not supported with YCbCr (like blitting)
* Disallow storage image support. Not clear if really useful. Even
if there are CTS tests, there is an ongoing discussion about the
possibility to remove them.
* Expose VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT, that is
mandatory for the formats supported.
* Not expose VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Some
CTS tests are failing right now, and it is not mandatory. Likely
to be revisit later.
* We are keeping VK_FORMAT_FEATURE_2_DISJOINT_BIT and
VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Even if they
are optional, it is working with the two formats that we are
exposing. Likely that will need to be refined if we start to
expose more formats.
* create_image_view: don't use hardcoded 0x70, but instead doing an
explicit bit or of VK_IMAGE_ASPECT_PLANE_0/1/2_BIT
* image_format_plane_features: keep how supported aspects and
separate stencil check is done. Even if the change introduced was
correct (not sure about that though), that change is unrelated to
this work
* write_image_descriptor: add additional checks for descriptor type,
to compute properly the offset.
* Cosmetic changes (don't use // for comments, capital letters, etc)
* Main changes coming from the review:
* Not use image aliases. All the info is already on the image
planes, and some points of the code were confusing as it was
using always a hardcoded plane 0.
* Squashed the two original main patches. YCbCr conversion was
leaking on the multi-planar support, as some support needed
info coming from the ycbcr structs.
* Not expose the extension on Android, and explicitly assert that
we expect plane_count to be 1 always.
* For a full list of review changes see MR#19950
Signed-off-by: Ella Stanforth <estanforth@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19950>
2022-07-28 09:15:43 +01:00
|
|
|
return 1;
|
|
|
|
case VK_IMAGE_ASPECT_PLANE_2_BIT:
|
2023-02-20 22:40:12 +00:00
|
|
|
case VK_IMAGE_ASPECT_MEMORY_PLANE_2_BIT_EXT:
|
v3dv: add support for multi-planar formats, enable YCbCr
Original patches wrote by Ella Stanforth.
Alejandro Piñeiro main changes (skipping the small fixes/typos):
* Reduced the list of supported formats to
VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and
VK_FORMAT_G8_B8R8_2PLANE_420_UNORM, that are the two only
mandatory by the spec.
* Fix format features exposed with YCbCr:
* Disallow some features not supported with YCbCr (like blitting)
* Disallow storage image support. Not clear if really useful. Even
if there are CTS tests, there is an ongoing discussion about the
possibility to remove them.
* Expose VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT, that is
mandatory for the formats supported.
* Not expose VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Some
CTS tests are failing right now, and it is not mandatory. Likely
to be revisit later.
* We are keeping VK_FORMAT_FEATURE_2_DISJOINT_BIT and
VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Even if they
are optional, it is working with the two formats that we are
exposing. Likely that will need to be refined if we start to
expose more formats.
* create_image_view: don't use hardcoded 0x70, but instead doing an
explicit bit or of VK_IMAGE_ASPECT_PLANE_0/1/2_BIT
* image_format_plane_features: keep how supported aspects and
separate stencil check is done. Even if the change introduced was
correct (not sure about that though), that change is unrelated to
this work
* write_image_descriptor: add additional checks for descriptor type,
to compute properly the offset.
* Cosmetic changes (don't use // for comments, capital letters, etc)
* Main changes coming from the review:
* Not use image aliases. All the info is already on the image
planes, and some points of the code were confusing as it was
using always a hardcoded plane 0.
* Squashed the two original main patches. YCbCr conversion was
leaking on the multi-planar support, as some support needed
info coming from the ycbcr structs.
* Not expose the extension on Android, and explicitly assert that
we expect plane_count to be 1 always.
* For a full list of review changes see MR#19950
Signed-off-by: Ella Stanforth <estanforth@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19950>
2022-07-28 09:15:43 +01:00
|
|
|
return 2;
|
|
|
|
default:
|
|
|
|
unreachable("invalid image aspect");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-12-03 11:54:30 +00:00
|
|
|
struct v3d_resource_slice {
|
|
|
|
uint32_t offset;
|
|
|
|
uint32_t stride;
|
|
|
|
uint32_t padded_height;
|
|
|
|
/* Size of a single pane of the slice. For 3D textures, there will be
|
|
|
|
* a number of panes equal to the minified, power-of-two-aligned
|
|
|
|
* depth.
|
|
|
|
*/
|
|
|
|
uint32_t size;
|
|
|
|
uint8_t ub_pad;
|
|
|
|
enum v3d_tiling_mode tiling;
|
|
|
|
uint32_t padded_height_of_output_image_in_uif_blocks;
|
|
|
|
};
|
|
|
|
|
2022-01-13 07:55:42 +00:00
|
|
|
bool v3dv_format_swizzle_needs_rb_swap(const uint8_t *swizzle);
|
|
|
|
bool v3dv_format_swizzle_needs_reverse(const uint8_t *swizzle);
|
|
|
|
|
2019-12-03 11:54:30 +00:00
|
|
|
struct v3dv_image {
|
2021-07-26 11:06:17 +01:00
|
|
|
struct vk_image vk;
|
2019-12-03 11:54:30 +00:00
|
|
|
|
|
|
|
const struct v3dv_format *format;
|
|
|
|
bool tiled;
|
|
|
|
|
v3dv: add support for multi-planar formats, enable YCbCr
Original patches wrote by Ella Stanforth.
Alejandro Piñeiro main changes (skipping the small fixes/typos):
* Reduced the list of supported formats to
VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and
VK_FORMAT_G8_B8R8_2PLANE_420_UNORM, that are the two only
mandatory by the spec.
* Fix format features exposed with YCbCr:
* Disallow some features not supported with YCbCr (like blitting)
* Disallow storage image support. Not clear if really useful. Even
if there are CTS tests, there is an ongoing discussion about the
possibility to remove them.
* Expose VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT, that is
mandatory for the formats supported.
* Not expose VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Some
CTS tests are failing right now, and it is not mandatory. Likely
to be revisit later.
* We are keeping VK_FORMAT_FEATURE_2_DISJOINT_BIT and
VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Even if they
are optional, it is working with the two formats that we are
exposing. Likely that will need to be refined if we start to
expose more formats.
* create_image_view: don't use hardcoded 0x70, but instead doing an
explicit bit or of VK_IMAGE_ASPECT_PLANE_0/1/2_BIT
* image_format_plane_features: keep how supported aspects and
separate stencil check is done. Even if the change introduced was
correct (not sure about that though), that change is unrelated to
this work
* write_image_descriptor: add additional checks for descriptor type,
to compute properly the offset.
* Cosmetic changes (don't use // for comments, capital letters, etc)
* Main changes coming from the review:
* Not use image aliases. All the info is already on the image
planes, and some points of the code were confusing as it was
using always a hardcoded plane 0.
* Squashed the two original main patches. YCbCr conversion was
leaking on the multi-planar support, as some support needed
info coming from the ycbcr structs.
* Not expose the extension on Android, and explicitly assert that
we expect plane_count to be 1 always.
* For a full list of review changes see MR#19950
Signed-off-by: Ella Stanforth <estanforth@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19950>
2022-07-28 09:15:43 +01:00
|
|
|
uint8_t plane_count;
|
2019-12-05 09:36:24 +00:00
|
|
|
|
v3dv: add support for multi-planar formats, enable YCbCr
Original patches wrote by Ella Stanforth.
Alejandro Piñeiro main changes (skipping the small fixes/typos):
* Reduced the list of supported formats to
VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and
VK_FORMAT_G8_B8R8_2PLANE_420_UNORM, that are the two only
mandatory by the spec.
* Fix format features exposed with YCbCr:
* Disallow some features not supported with YCbCr (like blitting)
* Disallow storage image support. Not clear if really useful. Even
if there are CTS tests, there is an ongoing discussion about the
possibility to remove them.
* Expose VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT, that is
mandatory for the formats supported.
* Not expose VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Some
CTS tests are failing right now, and it is not mandatory. Likely
to be revisit later.
* We are keeping VK_FORMAT_FEATURE_2_DISJOINT_BIT and
VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Even if they
are optional, it is working with the two formats that we are
exposing. Likely that will need to be refined if we start to
expose more formats.
* create_image_view: don't use hardcoded 0x70, but instead doing an
explicit bit or of VK_IMAGE_ASPECT_PLANE_0/1/2_BIT
* image_format_plane_features: keep how supported aspects and
separate stencil check is done. Even if the change introduced was
correct (not sure about that though), that change is unrelated to
this work
* write_image_descriptor: add additional checks for descriptor type,
to compute properly the offset.
* Cosmetic changes (don't use // for comments, capital letters, etc)
* Main changes coming from the review:
* Not use image aliases. All the info is already on the image
planes, and some points of the code were confusing as it was
using always a hardcoded plane 0.
* Squashed the two original main patches. YCbCr conversion was
leaking on the multi-planar support, as some support needed
info coming from the ycbcr structs.
* Not expose the extension on Android, and explicitly assert that
we expect plane_count to be 1 always.
* For a full list of review changes see MR#19950
Signed-off-by: Ella Stanforth <estanforth@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19950>
2022-07-28 09:15:43 +01:00
|
|
|
/* If 0, this is a multi-plane image with use disjoint memory, where each
|
|
|
|
* plane binds a different device memory. Otherwise, all the planes share
|
|
|
|
* the same device memory and this stores the total size of the image in
|
|
|
|
* bytes.
|
|
|
|
*/
|
|
|
|
uint32_t non_disjoint_size;
|
|
|
|
|
|
|
|
struct {
|
|
|
|
uint32_t cpp;
|
|
|
|
|
|
|
|
struct v3d_resource_slice slices[V3D_MAX_MIP_LEVELS];
|
|
|
|
/* Total size of the plane in bytes. */
|
|
|
|
uint64_t size;
|
|
|
|
uint32_t cube_map_stride;
|
|
|
|
|
|
|
|
/* If not using disjoint memory, mem and mem_offset is the same for all
|
|
|
|
* planes, in which case mem_offset is the offset of plane 0.
|
|
|
|
*/
|
|
|
|
struct v3dv_device_memory *mem;
|
|
|
|
VkDeviceSize mem_offset;
|
|
|
|
uint32_t alignment;
|
|
|
|
|
|
|
|
/* Pre-subsampled per plane width and height
|
|
|
|
*/
|
|
|
|
uint32_t width;
|
|
|
|
uint32_t height;
|
|
|
|
|
|
|
|
/* Even if we can get it from the parent image format, we keep the
|
|
|
|
* format here for convenience
|
|
|
|
*/
|
|
|
|
VkFormat vk_format;
|
|
|
|
} planes[V3DV_MAX_PLANE_COUNT];
|
2021-12-08 10:15:38 +00:00
|
|
|
|
|
|
|
#ifdef ANDROID
|
|
|
|
/* Image is backed by VK_ANDROID_native_buffer, */
|
|
|
|
bool is_native_buffer_memory;
|
|
|
|
#endif
|
2019-12-03 11:54:30 +00:00
|
|
|
};
|
|
|
|
|
2022-08-25 08:01:10 +01:00
|
|
|
VkResult
|
|
|
|
v3dv_image_init(struct v3dv_device *device,
|
|
|
|
const VkImageCreateInfo *pCreateInfo,
|
|
|
|
const VkAllocationCallbacks *pAllocator,
|
|
|
|
struct v3dv_image *image);
|
|
|
|
|
2020-04-28 12:36:37 +01:00
|
|
|
VkImageViewType v3dv_image_type_to_view_type(VkImageType type);
|
|
|
|
|
v3dv: add support for multi-planar formats, enable YCbCr
Original patches wrote by Ella Stanforth.
Alejandro Piñeiro main changes (skipping the small fixes/typos):
* Reduced the list of supported formats to
VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and
VK_FORMAT_G8_B8R8_2PLANE_420_UNORM, that are the two only
mandatory by the spec.
* Fix format features exposed with YCbCr:
* Disallow some features not supported with YCbCr (like blitting)
* Disallow storage image support. Not clear if really useful. Even
if there are CTS tests, there is an ongoing discussion about the
possibility to remove them.
* Expose VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT, that is
mandatory for the formats supported.
* Not expose VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Some
CTS tests are failing right now, and it is not mandatory. Likely
to be revisit later.
* We are keeping VK_FORMAT_FEATURE_2_DISJOINT_BIT and
VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Even if they
are optional, it is working with the two formats that we are
exposing. Likely that will need to be refined if we start to
expose more formats.
* create_image_view: don't use hardcoded 0x70, but instead doing an
explicit bit or of VK_IMAGE_ASPECT_PLANE_0/1/2_BIT
* image_format_plane_features: keep how supported aspects and
separate stencil check is done. Even if the change introduced was
correct (not sure about that though), that change is unrelated to
this work
* write_image_descriptor: add additional checks for descriptor type,
to compute properly the offset.
* Cosmetic changes (don't use // for comments, capital letters, etc)
* Main changes coming from the review:
* Not use image aliases. All the info is already on the image
planes, and some points of the code were confusing as it was
using always a hardcoded plane 0.
* Squashed the two original main patches. YCbCr conversion was
leaking on the multi-planar support, as some support needed
info coming from the ycbcr structs.
* Not expose the extension on Android, and explicitly assert that
we expect plane_count to be 1 always.
* For a full list of review changes see MR#19950
Signed-off-by: Ella Stanforth <estanforth@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19950>
2022-07-28 09:15:43 +01:00
|
|
|
static uint32_t
|
|
|
|
v3dv_image_aspect_to_plane(const struct v3dv_image *image,
|
|
|
|
VkImageAspectFlagBits aspect)
|
|
|
|
{
|
|
|
|
assert(util_bitcount(aspect) == 1 && (aspect & image->vk.aspects));
|
|
|
|
|
|
|
|
/* Because we always put image and view planes in aspect-bit-order, the
|
|
|
|
* plane index is the number of bits in the image aspect before aspect.
|
|
|
|
*/
|
|
|
|
return util_bitcount(image->vk.aspects & (aspect - 1));
|
|
|
|
}
|
|
|
|
|
2021-06-01 09:39:20 +01:00
|
|
|
/* Pre-generating packets needs to consider changes in packet sizes across hw
|
|
|
|
* versions. Keep things simple and allocate enough space for any supported
|
|
|
|
* version. We ensure the size is large enough through static asserts.
|
|
|
|
*/
|
|
|
|
#define V3DV_TEXTURE_SHADER_STATE_LENGTH 32
|
|
|
|
#define V3DV_SAMPLER_STATE_LENGTH 24
|
|
|
|
#define V3DV_BLEND_CFG_LENGTH 5
|
|
|
|
#define V3DV_CFG_BITS_LENGTH 4
|
|
|
|
#define V3DV_GL_SHADER_STATE_RECORD_LENGTH 36
|
|
|
|
#define V3DV_VCM_CACHE_SIZE_LENGTH 2
|
|
|
|
#define V3DV_GL_SHADER_STATE_ATTRIBUTE_RECORD_LENGTH 16
|
|
|
|
#define V3DV_STENCIL_CFG_LENGTH 6
|
|
|
|
|
2019-12-05 11:35:02 +00:00
|
|
|
struct v3dv_image_view {
|
2021-07-26 12:23:30 +01:00
|
|
|
struct vk_image_view vk;
|
2019-12-05 11:35:02 +00:00
|
|
|
|
|
|
|
const struct v3dv_format *format;
|
2020-03-29 15:29:55 +01:00
|
|
|
|
v3dv: add support for multi-planar formats, enable YCbCr
Original patches wrote by Ella Stanforth.
Alejandro Piñeiro main changes (skipping the small fixes/typos):
* Reduced the list of supported formats to
VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and
VK_FORMAT_G8_B8R8_2PLANE_420_UNORM, that are the two only
mandatory by the spec.
* Fix format features exposed with YCbCr:
* Disallow some features not supported with YCbCr (like blitting)
* Disallow storage image support. Not clear if really useful. Even
if there are CTS tests, there is an ongoing discussion about the
possibility to remove them.
* Expose VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT, that is
mandatory for the formats supported.
* Not expose VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Some
CTS tests are failing right now, and it is not mandatory. Likely
to be revisit later.
* We are keeping VK_FORMAT_FEATURE_2_DISJOINT_BIT and
VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Even if they
are optional, it is working with the two formats that we are
exposing. Likely that will need to be refined if we start to
expose more formats.
* create_image_view: don't use hardcoded 0x70, but instead doing an
explicit bit or of VK_IMAGE_ASPECT_PLANE_0/1/2_BIT
* image_format_plane_features: keep how supported aspects and
separate stencil check is done. Even if the change introduced was
correct (not sure about that though), that change is unrelated to
this work
* write_image_descriptor: add additional checks for descriptor type,
to compute properly the offset.
* Cosmetic changes (don't use // for comments, capital letters, etc)
* Main changes coming from the review:
* Not use image aliases. All the info is already on the image
planes, and some points of the code were confusing as it was
using always a hardcoded plane 0.
* Squashed the two original main patches. YCbCr conversion was
leaking on the multi-planar support, as some support needed
info coming from the ycbcr structs.
* Not expose the extension on Android, and explicitly assert that
we expect plane_count to be 1 always.
* For a full list of review changes see MR#19950
Signed-off-by: Ella Stanforth <estanforth@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19950>
2022-07-28 09:15:43 +01:00
|
|
|
uint8_t plane_count;
|
|
|
|
struct {
|
|
|
|
uint8_t image_plane;
|
2020-03-29 15:29:55 +01:00
|
|
|
|
v3dv: add support for multi-planar formats, enable YCbCr
Original patches wrote by Ella Stanforth.
Alejandro Piñeiro main changes (skipping the small fixes/typos):
* Reduced the list of supported formats to
VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and
VK_FORMAT_G8_B8R8_2PLANE_420_UNORM, that are the two only
mandatory by the spec.
* Fix format features exposed with YCbCr:
* Disallow some features not supported with YCbCr (like blitting)
* Disallow storage image support. Not clear if really useful. Even
if there are CTS tests, there is an ongoing discussion about the
possibility to remove them.
* Expose VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT, that is
mandatory for the formats supported.
* Not expose VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Some
CTS tests are failing right now, and it is not mandatory. Likely
to be revisit later.
* We are keeping VK_FORMAT_FEATURE_2_DISJOINT_BIT and
VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Even if they
are optional, it is working with the two formats that we are
exposing. Likely that will need to be refined if we start to
expose more formats.
* create_image_view: don't use hardcoded 0x70, but instead doing an
explicit bit or of VK_IMAGE_ASPECT_PLANE_0/1/2_BIT
* image_format_plane_features: keep how supported aspects and
separate stencil check is done. Even if the change introduced was
correct (not sure about that though), that change is unrelated to
this work
* write_image_descriptor: add additional checks for descriptor type,
to compute properly the offset.
* Cosmetic changes (don't use // for comments, capital letters, etc)
* Main changes coming from the review:
* Not use image aliases. All the info is already on the image
planes, and some points of the code were confusing as it was
using always a hardcoded plane 0.
* Squashed the two original main patches. YCbCr conversion was
leaking on the multi-planar support, as some support needed
info coming from the ycbcr structs.
* Not expose the extension on Android, and explicitly assert that
we expect plane_count to be 1 always.
* For a full list of review changes see MR#19950
Signed-off-by: Ella Stanforth <estanforth@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19950>
2022-07-28 09:15:43 +01:00
|
|
|
bool swap_rb;
|
|
|
|
bool channel_reverse;
|
|
|
|
uint32_t internal_bpp;
|
|
|
|
uint32_t internal_type;
|
|
|
|
uint32_t offset;
|
|
|
|
|
|
|
|
/* Precomputed (composed from createinfo->components and formar swizzle)
|
|
|
|
* swizzles to pass in to the shader key.
|
|
|
|
*
|
|
|
|
* This could be also included on the descriptor bo, but the shader state
|
|
|
|
* packet doesn't need it on a bo, so we can just avoid a memory copy
|
|
|
|
*/
|
|
|
|
uint8_t swizzle[4];
|
|
|
|
|
|
|
|
/* Prepacked TEXTURE_SHADER_STATE. It will be copied to the descriptor info
|
|
|
|
* during UpdateDescriptorSets.
|
|
|
|
*
|
|
|
|
* Empirical tests show that cube arrays need a different shader state
|
|
|
|
* depending on whether they are used with a sampler or not, so for these
|
|
|
|
* we generate two states and select the one to use based on the descriptor
|
|
|
|
* type.
|
|
|
|
*/
|
|
|
|
uint8_t texture_shader_state[2][V3DV_TEXTURE_SHADER_STATE_LENGTH];
|
|
|
|
} planes[V3DV_MAX_PLANE_COUNT];
|
2019-12-05 11:35:02 +00:00
|
|
|
};
|
|
|
|
|
2022-03-25 22:57:37 +00:00
|
|
|
VkResult v3dv_create_image_view(struct v3dv_device *device,
|
|
|
|
const VkImageViewCreateInfo *pCreateInfo,
|
|
|
|
VkImageView *pView);
|
|
|
|
|
v3dv: add support for multi-planar formats, enable YCbCr
Original patches wrote by Ella Stanforth.
Alejandro Piñeiro main changes (skipping the small fixes/typos):
* Reduced the list of supported formats to
VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and
VK_FORMAT_G8_B8R8_2PLANE_420_UNORM, that are the two only
mandatory by the spec.
* Fix format features exposed with YCbCr:
* Disallow some features not supported with YCbCr (like blitting)
* Disallow storage image support. Not clear if really useful. Even
if there are CTS tests, there is an ongoing discussion about the
possibility to remove them.
* Expose VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT, that is
mandatory for the formats supported.
* Not expose VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Some
CTS tests are failing right now, and it is not mandatory. Likely
to be revisit later.
* We are keeping VK_FORMAT_FEATURE_2_DISJOINT_BIT and
VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Even if they
are optional, it is working with the two formats that we are
exposing. Likely that will need to be refined if we start to
expose more formats.
* create_image_view: don't use hardcoded 0x70, but instead doing an
explicit bit or of VK_IMAGE_ASPECT_PLANE_0/1/2_BIT
* image_format_plane_features: keep how supported aspects and
separate stencil check is done. Even if the change introduced was
correct (not sure about that though), that change is unrelated to
this work
* write_image_descriptor: add additional checks for descriptor type,
to compute properly the offset.
* Cosmetic changes (don't use // for comments, capital letters, etc)
* Main changes coming from the review:
* Not use image aliases. All the info is already on the image
planes, and some points of the code were confusing as it was
using always a hardcoded plane 0.
* Squashed the two original main patches. YCbCr conversion was
leaking on the multi-planar support, as some support needed
info coming from the ycbcr structs.
* Not expose the extension on Android, and explicitly assert that
we expect plane_count to be 1 always.
* For a full list of review changes see MR#19950
Signed-off-by: Ella Stanforth <estanforth@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19950>
2022-07-28 09:15:43 +01:00
|
|
|
uint32_t v3dv_layer_offset(const struct v3dv_image *image, uint32_t level, uint32_t layer,
|
|
|
|
uint8_t plane);
|
2019-12-17 07:48:10 +00:00
|
|
|
|
2019-12-09 09:07:36 +00:00
|
|
|
struct v3dv_buffer {
|
2020-11-12 15:30:41 +00:00
|
|
|
struct vk_object_base base;
|
|
|
|
|
2019-12-09 09:07:36 +00:00
|
|
|
VkDeviceSize size;
|
|
|
|
VkBufferUsageFlags usage;
|
|
|
|
uint32_t alignment;
|
2019-12-09 09:40:32 +00:00
|
|
|
|
|
|
|
struct v3dv_device_memory *mem;
|
|
|
|
VkDeviceSize mem_offset;
|
2019-12-09 09:07:36 +00:00
|
|
|
};
|
|
|
|
|
2022-09-06 08:34:46 +01:00
|
|
|
void
|
|
|
|
v3dv_buffer_init(struct v3dv_device *device,
|
|
|
|
const VkBufferCreateInfo *pCreateInfo,
|
2023-01-11 13:04:26 +00:00
|
|
|
struct v3dv_buffer *buffer,
|
|
|
|
uint32_t alignment);
|
2022-09-06 08:34:46 +01:00
|
|
|
|
|
|
|
void
|
|
|
|
v3dv_buffer_bind_memory(const VkBindBufferMemoryInfo *info);
|
|
|
|
|
2020-02-26 08:07:42 +00:00
|
|
|
struct v3dv_buffer_view {
|
2020-11-12 15:30:41 +00:00
|
|
|
struct vk_object_base base;
|
|
|
|
|
2021-06-17 09:53:02 +01:00
|
|
|
struct v3dv_buffer *buffer;
|
2020-02-26 08:07:42 +00:00
|
|
|
|
|
|
|
VkFormat vk_format;
|
|
|
|
const struct v3dv_format *format;
|
|
|
|
uint32_t internal_bpp;
|
|
|
|
uint32_t internal_type;
|
|
|
|
|
|
|
|
uint32_t offset;
|
|
|
|
uint32_t size;
|
|
|
|
uint32_t num_elements;
|
2020-07-28 23:28:28 +01:00
|
|
|
|
|
|
|
/* Prepacked TEXTURE_SHADER_STATE. */
|
2021-06-01 09:39:20 +01:00
|
|
|
uint8_t texture_shader_state[V3DV_TEXTURE_SHADER_STATE_LENGTH];
|
2020-02-26 08:07:42 +00:00
|
|
|
};
|
|
|
|
|
2019-12-09 11:16:35 +00:00
|
|
|
struct v3dv_subpass_attachment {
|
|
|
|
uint32_t attachment;
|
|
|
|
VkImageLayout layout;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct v3dv_subpass {
|
|
|
|
uint32_t input_count;
|
|
|
|
struct v3dv_subpass_attachment *input_attachments;
|
|
|
|
|
|
|
|
uint32_t color_count;
|
|
|
|
struct v3dv_subpass_attachment *color_attachments;
|
|
|
|
struct v3dv_subpass_attachment *resolve_attachments;
|
|
|
|
|
|
|
|
struct v3dv_subpass_attachment ds_attachment;
|
2022-01-27 10:57:08 +00:00
|
|
|
struct v3dv_subpass_attachment ds_resolve_attachment;
|
|
|
|
bool resolve_depth, resolve_stencil;
|
2020-03-18 09:41:19 +00:00
|
|
|
|
2020-09-24 08:23:29 +01:00
|
|
|
/* If we need to emit the clear of the depth/stencil attachment using a
|
|
|
|
* a draw call instead of using the TLB (GFXH-1461).
|
|
|
|
*/
|
|
|
|
bool do_depth_clear_with_draw;
|
|
|
|
bool do_stencil_clear_with_draw;
|
2021-07-20 09:57:12 +01:00
|
|
|
|
|
|
|
/* Multiview */
|
|
|
|
uint32_t view_mask;
|
2019-12-09 11:16:35 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct v3dv_render_pass_attachment {
|
2021-10-28 09:29:33 +01:00
|
|
|
VkAttachmentDescription2 desc;
|
2021-07-23 11:21:38 +01:00
|
|
|
|
2020-01-28 15:53:54 +00:00
|
|
|
uint32_t first_subpass;
|
|
|
|
uint32_t last_subpass;
|
2020-07-31 13:58:42 +01:00
|
|
|
|
2021-07-23 11:21:38 +01:00
|
|
|
/* When multiview is enabled, we no longer care about when a particular
|
|
|
|
* attachment is first or last used in a render pass, since not all views
|
|
|
|
* in the attachment will meet that criteria. Instead, we need to track
|
|
|
|
* each individual view (layer) in each attachment and emit our stores,
|
|
|
|
* loads and clears accordingly.
|
|
|
|
*/
|
|
|
|
struct {
|
|
|
|
uint32_t first_subpass;
|
|
|
|
uint32_t last_subpass;
|
|
|
|
} views[MAX_MULTIVIEW_VIEW_COUNT];
|
|
|
|
|
2022-01-27 10:11:51 +00:00
|
|
|
/* If this is a multisampled attachment that is going to be resolved,
|
|
|
|
* whether we may be able to use the TLB hardware resolve based on the
|
|
|
|
* attachment format.
|
2020-07-31 13:58:42 +01:00
|
|
|
*/
|
2022-01-27 10:11:51 +00:00
|
|
|
bool try_tlb_resolve;
|
2019-12-09 11:16:35 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct v3dv_render_pass {
|
2020-11-12 15:30:41 +00:00
|
|
|
struct vk_object_base base;
|
|
|
|
|
2021-07-20 09:57:12 +01:00
|
|
|
bool multiview_enabled;
|
|
|
|
|
2019-12-09 11:16:35 +00:00
|
|
|
uint32_t attachment_count;
|
|
|
|
struct v3dv_render_pass_attachment *attachments;
|
|
|
|
|
|
|
|
uint32_t subpass_count;
|
|
|
|
struct v3dv_subpass *subpasses;
|
|
|
|
|
|
|
|
struct v3dv_subpass_attachment *subpass_attachments;
|
|
|
|
};
|
|
|
|
|
2019-12-09 12:16:16 +00:00
|
|
|
struct v3dv_framebuffer {
|
2020-11-12 15:30:41 +00:00
|
|
|
struct vk_object_base base;
|
|
|
|
|
2019-12-09 12:16:16 +00:00
|
|
|
uint32_t width;
|
|
|
|
uint32_t height;
|
|
|
|
uint32_t layers;
|
|
|
|
|
2020-10-08 12:24:13 +01:00
|
|
|
/* Typically, edge tiles in the framebuffer have padding depending on the
|
|
|
|
* underlying tiling layout. One consequnce of this is that when the
|
|
|
|
* framebuffer dimensions are not aligned to tile boundaries, tile stores
|
|
|
|
* would still write full tiles on the edges and write to the padded area.
|
|
|
|
* If the framebuffer is aliasing a smaller region of a larger image, then
|
|
|
|
* we need to be careful with this though, as we won't have padding on the
|
|
|
|
* edge tiles (which typically means that we need to load the tile buffer
|
|
|
|
* before we store).
|
|
|
|
*/
|
|
|
|
bool has_edge_padding;
|
|
|
|
|
2020-03-02 16:21:26 +00:00
|
|
|
uint32_t attachment_count;
|
|
|
|
uint32_t color_attachment_count;
|
2022-01-24 12:38:08 +00:00
|
|
|
|
|
|
|
/* Notice that elements in 'attachments' will be NULL if the framebuffer
|
|
|
|
* was created imageless. The driver is expected to access attachment info
|
|
|
|
* from the command buffer state instead.
|
|
|
|
*/
|
2020-03-02 16:21:26 +00:00
|
|
|
struct v3dv_image_view *attachments[0];
|
|
|
|
};
|
|
|
|
|
|
|
|
struct v3dv_frame_tiling {
|
2020-03-03 10:57:59 +00:00
|
|
|
uint32_t width;
|
|
|
|
uint32_t height;
|
2020-07-24 09:33:16 +01:00
|
|
|
uint32_t layers;
|
2020-03-03 10:57:59 +00:00
|
|
|
uint32_t render_target_count;
|
2019-12-13 09:31:05 +00:00
|
|
|
uint32_t internal_bpp;
|
2020-07-24 09:33:16 +01:00
|
|
|
bool msaa;
|
2022-01-05 10:07:59 +00:00
|
|
|
bool double_buffer;
|
2019-12-13 09:31:05 +00:00
|
|
|
uint32_t tile_width;
|
|
|
|
uint32_t tile_height;
|
|
|
|
uint32_t draw_tiles_x;
|
|
|
|
uint32_t draw_tiles_y;
|
2019-12-17 07:51:33 +00:00
|
|
|
uint32_t supertile_width;
|
|
|
|
uint32_t supertile_height;
|
|
|
|
uint32_t frame_width_in_supertiles;
|
|
|
|
uint32_t frame_height_in_supertiles;
|
2019-12-09 12:16:16 +00:00
|
|
|
};
|
|
|
|
|
2021-06-14 10:35:06 +01:00
|
|
|
bool v3dv_subpass_area_is_tile_aligned(struct v3dv_device *device,
|
|
|
|
const VkRect2D *area,
|
2020-10-08 12:24:13 +01:00
|
|
|
struct v3dv_framebuffer *fb,
|
|
|
|
struct v3dv_render_pass *pass,
|
|
|
|
uint32_t subpass_idx);
|
2021-06-14 10:35:06 +01:00
|
|
|
|
2022-01-05 10:07:59 +00:00
|
|
|
/* Checks if we need to emit 2 initial tile clears for double buffer mode.
|
|
|
|
* This happens when we render at least 2 tiles, because in this mode each
|
|
|
|
* tile uses a different half of the tile buffer memory so we can have 2 tiles
|
|
|
|
* in flight (one being stored to memory and the next being rendered). In this
|
|
|
|
* scenario, if we emit a single initial tile clear we would only clear the
|
|
|
|
* first half of the tile buffer.
|
|
|
|
*/
|
|
|
|
static inline bool
|
|
|
|
v3dv_do_double_initial_tile_clear(const struct v3dv_frame_tiling *tiling)
|
|
|
|
{
|
|
|
|
return tiling->double_buffer &&
|
|
|
|
(tiling->draw_tiles_x > 1 || tiling->draw_tiles_y > 1 ||
|
|
|
|
tiling->layers > 1);
|
|
|
|
}
|
|
|
|
|
2019-12-11 10:57:08 +00:00
|
|
|
enum v3dv_cmd_buffer_status {
|
|
|
|
V3DV_CMD_BUFFER_STATUS_NEW = 0,
|
|
|
|
V3DV_CMD_BUFFER_STATUS_INITIALIZED = 1,
|
2019-12-17 08:48:54 +00:00
|
|
|
V3DV_CMD_BUFFER_STATUS_RECORDING = 2,
|
|
|
|
V3DV_CMD_BUFFER_STATUS_EXECUTABLE = 3
|
2019-12-11 10:57:08 +00:00
|
|
|
};
|
|
|
|
|
2019-12-17 07:58:20 +00:00
|
|
|
union v3dv_clear_value {
|
|
|
|
uint32_t color[4];
|
2020-03-17 13:38:57 +00:00
|
|
|
struct {
|
|
|
|
float z;
|
|
|
|
uint8_t s;
|
|
|
|
};
|
2019-12-17 07:58:20 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct v3dv_cmd_buffer_attachment_state {
|
2020-04-02 11:38:10 +01:00
|
|
|
/* The original clear value as provided by the Vulkan API */
|
|
|
|
VkClearValue vk_clear_value;
|
|
|
|
|
|
|
|
/* The hardware clear value */
|
2019-12-17 07:58:20 +00:00
|
|
|
union v3dv_clear_value clear_value;
|
2022-01-24 12:38:08 +00:00
|
|
|
|
|
|
|
/* The underlying image view (from the framebuffer or, if imageless
|
|
|
|
* framebuffer is used, from VkRenderPassAttachmentBeginInfo.
|
|
|
|
*/
|
|
|
|
struct v3dv_image_view *image_view;
|
2022-01-27 10:11:51 +00:00
|
|
|
|
|
|
|
/* If this is a multisampled attachment with a resolve operation. */
|
|
|
|
bool has_resolve;
|
|
|
|
|
|
|
|
/* If this is a multisampled attachment with a resolve operation,
|
|
|
|
* whether we can use the TLB for the resolve.
|
|
|
|
*/
|
|
|
|
bool use_tlb_resolve;
|
2019-12-17 07:58:20 +00:00
|
|
|
};
|
|
|
|
|
2019-12-28 10:59:32 +00:00
|
|
|
struct v3dv_viewport_state {
|
|
|
|
uint32_t count;
|
|
|
|
VkViewport viewports[MAX_VIEWPORTS];
|
2020-01-03 11:27:08 +00:00
|
|
|
float translate[MAX_VIEWPORTS][3];
|
|
|
|
float scale[MAX_VIEWPORTS][3];
|
2019-12-28 10:59:32 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct v3dv_scissor_state {
|
|
|
|
uint32_t count;
|
|
|
|
VkRect2D scissors[MAX_SCISSORS];
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Mostly a v3dv mapping of VkDynamicState, used to track which data as
|
|
|
|
* defined as dynamic
|
|
|
|
*/
|
|
|
|
enum v3dv_dynamic_state_bits {
|
|
|
|
V3DV_DYNAMIC_VIEWPORT = 1 << 0,
|
|
|
|
V3DV_DYNAMIC_SCISSOR = 1 << 1,
|
2020-02-04 16:43:49 +00:00
|
|
|
V3DV_DYNAMIC_STENCIL_COMPARE_MASK = 1 << 2,
|
|
|
|
V3DV_DYNAMIC_STENCIL_WRITE_MASK = 1 << 3,
|
|
|
|
V3DV_DYNAMIC_STENCIL_REFERENCE = 1 << 4,
|
2020-03-18 10:50:47 +00:00
|
|
|
V3DV_DYNAMIC_BLEND_CONSTANTS = 1 << 5,
|
2020-05-13 09:35:30 +01:00
|
|
|
V3DV_DYNAMIC_DEPTH_BIAS = 1 << 6,
|
2020-05-13 11:21:55 +01:00
|
|
|
V3DV_DYNAMIC_LINE_WIDTH = 1 << 7,
|
2021-07-10 21:02:47 +01:00
|
|
|
V3DV_DYNAMIC_COLOR_WRITE_ENABLE = 1 << 8,
|
|
|
|
V3DV_DYNAMIC_ALL = (1 << 9) - 1,
|
2019-12-28 10:59:32 +00:00
|
|
|
};
|
|
|
|
|
v3dv: fix the mess with dynamic state handling
The general idea is that we always emit from our dynamic state, and when
a particular piece of state is not dynamic, we just set our dynamic state
from the pipeline state, however, the implementation was quite confusing:
the mask of dynamic states flagged states that were not dynamic and some
places woud mix dirty flags and dynamic state flags. We also were not
updating the dynamic state mask in the command buffer, etc.
This patch, hopefully, simplifies all this and makes it less confusing,
starting by making the dynamic state mask flag dynamic states, fixing
the places where we would confuse dirty state flags with dynamic state
flags, making sure that our command buffer state is setup correctly
and that we only emit state when it is actually dirty.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-05 09:53:20 +00:00
|
|
|
/* Flags for dirty pipeline state.
|
2019-12-28 10:59:32 +00:00
|
|
|
*/
|
|
|
|
enum v3dv_cmd_dirty_bits {
|
v3dv: fix the mess with dynamic state handling
The general idea is that we always emit from our dynamic state, and when
a particular piece of state is not dynamic, we just set our dynamic state
from the pipeline state, however, the implementation was quite confusing:
the mask of dynamic states flagged states that were not dynamic and some
places woud mix dirty flags and dynamic state flags. We also were not
updating the dynamic state mask in the command buffer, etc.
This patch, hopefully, simplifies all this and makes it less confusing,
starting by making the dynamic state mask flag dynamic states, fixing
the places where we would confuse dirty state flags with dynamic state
flags, making sure that our command buffer state is setup correctly
and that we only emit state when it is actually dirty.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-05 09:53:20 +00:00
|
|
|
V3DV_CMD_DIRTY_VIEWPORT = 1 << 0,
|
|
|
|
V3DV_CMD_DIRTY_SCISSOR = 1 << 1,
|
|
|
|
V3DV_CMD_DIRTY_STENCIL_COMPARE_MASK = 1 << 2,
|
|
|
|
V3DV_CMD_DIRTY_STENCIL_WRITE_MASK = 1 << 3,
|
|
|
|
V3DV_CMD_DIRTY_STENCIL_REFERENCE = 1 << 4,
|
|
|
|
V3DV_CMD_DIRTY_PIPELINE = 1 << 5,
|
2021-01-15 22:07:45 +00:00
|
|
|
V3DV_CMD_DIRTY_COMPUTE_PIPELINE = 1 << 6,
|
|
|
|
V3DV_CMD_DIRTY_VERTEX_BUFFER = 1 << 7,
|
|
|
|
V3DV_CMD_DIRTY_INDEX_BUFFER = 1 << 8,
|
|
|
|
V3DV_CMD_DIRTY_DESCRIPTOR_SETS = 1 << 9,
|
|
|
|
V3DV_CMD_DIRTY_COMPUTE_DESCRIPTOR_SETS = 1 << 10,
|
|
|
|
V3DV_CMD_DIRTY_PUSH_CONSTANTS = 1 << 11,
|
2022-07-15 04:01:22 +01:00
|
|
|
V3DV_CMD_DIRTY_PUSH_CONSTANTS_UBO = 1 << 12,
|
|
|
|
V3DV_CMD_DIRTY_BLEND_CONSTANTS = 1 << 13,
|
|
|
|
V3DV_CMD_DIRTY_OCCLUSION_QUERY = 1 << 14,
|
|
|
|
V3DV_CMD_DIRTY_DEPTH_BIAS = 1 << 15,
|
|
|
|
V3DV_CMD_DIRTY_LINE_WIDTH = 1 << 16,
|
|
|
|
V3DV_CMD_DIRTY_VIEW_INDEX = 1 << 17,
|
|
|
|
V3DV_CMD_DIRTY_COLOR_WRITE_ENABLE = 1 << 18,
|
2019-12-28 10:59:32 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct v3dv_dynamic_state {
|
|
|
|
/**
|
|
|
|
* Bitmask of (1 << VK_DYNAMIC_STATE_*).
|
|
|
|
* Defines the set of saved dynamic state.
|
|
|
|
*/
|
|
|
|
uint32_t mask;
|
|
|
|
|
|
|
|
struct v3dv_viewport_state viewport;
|
|
|
|
|
|
|
|
struct v3dv_scissor_state scissor;
|
2020-02-04 16:43:49 +00:00
|
|
|
|
|
|
|
struct {
|
|
|
|
uint32_t front;
|
|
|
|
uint32_t back;
|
|
|
|
} stencil_compare_mask;
|
|
|
|
|
|
|
|
struct {
|
|
|
|
uint32_t front;
|
|
|
|
uint32_t back;
|
|
|
|
} stencil_write_mask;
|
|
|
|
|
|
|
|
struct {
|
|
|
|
uint32_t front;
|
|
|
|
uint32_t back;
|
|
|
|
} stencil_reference;
|
2020-03-18 10:50:47 +00:00
|
|
|
|
|
|
|
float blend_constants[4];
|
2020-05-13 09:35:30 +01:00
|
|
|
|
|
|
|
struct {
|
|
|
|
float constant_factor;
|
2021-02-09 12:12:03 +00:00
|
|
|
float depth_bias_clamp;
|
2020-05-13 09:35:30 +01:00
|
|
|
float slope_factor;
|
|
|
|
} depth_bias;
|
2020-05-13 11:21:55 +01:00
|
|
|
|
|
|
|
float line_width;
|
2021-07-10 21:02:47 +01:00
|
|
|
|
|
|
|
uint32_t color_write_enable;
|
2019-12-28 10:59:32 +00:00
|
|
|
};
|
|
|
|
|
2020-02-03 11:55:25 +00:00
|
|
|
void v3dv_viewport_compute_xform(const VkViewport *viewport,
|
|
|
|
float scale[3],
|
|
|
|
float translate[3]);
|
|
|
|
|
2020-02-04 09:26:04 +00:00
|
|
|
enum v3dv_ez_state {
|
2021-04-23 09:24:57 +01:00
|
|
|
V3D_EZ_UNDECIDED = 0,
|
|
|
|
V3D_EZ_GT_GE,
|
|
|
|
V3D_EZ_LT_LE,
|
|
|
|
V3D_EZ_DISABLED,
|
2020-02-04 09:26:04 +00:00
|
|
|
};
|
|
|
|
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 09:30:38 +01:00
|
|
|
enum v3dv_job_type {
|
2020-04-20 12:24:09 +01:00
|
|
|
V3DV_JOB_TYPE_GPU_CL = 0,
|
2020-06-02 11:26:50 +01:00
|
|
|
V3DV_JOB_TYPE_GPU_CL_SECONDARY,
|
2020-04-20 12:24:09 +01:00
|
|
|
V3DV_JOB_TYPE_GPU_TFU,
|
2020-05-18 09:41:11 +01:00
|
|
|
V3DV_JOB_TYPE_GPU_CSD,
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 09:30:38 +01:00
|
|
|
V3DV_JOB_TYPE_CPU_RESET_QUERIES,
|
|
|
|
V3DV_JOB_TYPE_CPU_END_QUERY,
|
|
|
|
V3DV_JOB_TYPE_CPU_COPY_QUERY_RESULTS,
|
2020-06-15 15:44:49 +01:00
|
|
|
V3DV_JOB_TYPE_CPU_COPY_BUFFER_TO_IMAGE,
|
2020-06-19 10:56:20 +01:00
|
|
|
V3DV_JOB_TYPE_CPU_CSD_INDIRECT,
|
2020-10-29 10:55:23 +00:00
|
|
|
V3DV_JOB_TYPE_CPU_TIMESTAMP_QUERY,
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 09:30:38 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
struct v3dv_reset_query_cpu_job_info {
|
|
|
|
struct v3dv_query_pool *pool;
|
|
|
|
uint32_t first;
|
|
|
|
uint32_t count;
|
|
|
|
};
|
|
|
|
|
2022-10-28 11:07:07 +01:00
|
|
|
struct v3dv_end_query_info {
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 09:30:38 +01:00
|
|
|
struct v3dv_query_pool *pool;
|
|
|
|
uint32_t query;
|
2021-07-23 13:49:05 +01:00
|
|
|
|
|
|
|
/* This is one unless multiview is used */
|
|
|
|
uint32_t count;
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 09:30:38 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
struct v3dv_copy_query_results_cpu_job_info {
|
|
|
|
struct v3dv_query_pool *pool;
|
|
|
|
uint32_t first;
|
|
|
|
uint32_t count;
|
|
|
|
struct v3dv_buffer *dst;
|
|
|
|
uint32_t offset;
|
|
|
|
uint32_t stride;
|
|
|
|
VkQueryResultFlags flags;
|
|
|
|
};
|
|
|
|
|
2022-03-29 23:52:32 +01:00
|
|
|
struct v3dv_submit_sync_info {
|
|
|
|
/* List of syncs to wait before running a job */
|
|
|
|
uint32_t wait_count;
|
|
|
|
struct vk_sync_wait *waits;
|
2021-11-11 13:54:30 +00:00
|
|
|
|
2022-03-29 23:52:32 +01:00
|
|
|
/* List of syncs to signal when all jobs complete */
|
|
|
|
uint32_t signal_count;
|
|
|
|
struct vk_sync_signal *signals;
|
2021-11-08 15:50:52 +00:00
|
|
|
};
|
|
|
|
|
2020-06-15 15:44:49 +01:00
|
|
|
struct v3dv_copy_buffer_to_image_cpu_job_info {
|
|
|
|
struct v3dv_image *image;
|
|
|
|
struct v3dv_buffer *buffer;
|
|
|
|
uint32_t buffer_offset;
|
|
|
|
uint32_t buffer_stride;
|
|
|
|
uint32_t buffer_layer_stride;
|
|
|
|
VkOffset3D image_offset;
|
|
|
|
VkExtent3D image_extent;
|
|
|
|
uint32_t mip_level;
|
|
|
|
uint32_t base_layer;
|
|
|
|
uint32_t layer_count;
|
v3dv: add support for multi-planar formats, enable YCbCr
Original patches wrote by Ella Stanforth.
Alejandro Piñeiro main changes (skipping the small fixes/typos):
* Reduced the list of supported formats to
VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and
VK_FORMAT_G8_B8R8_2PLANE_420_UNORM, that are the two only
mandatory by the spec.
* Fix format features exposed with YCbCr:
* Disallow some features not supported with YCbCr (like blitting)
* Disallow storage image support. Not clear if really useful. Even
if there are CTS tests, there is an ongoing discussion about the
possibility to remove them.
* Expose VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT, that is
mandatory for the formats supported.
* Not expose VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Some
CTS tests are failing right now, and it is not mandatory. Likely
to be revisit later.
* We are keeping VK_FORMAT_FEATURE_2_DISJOINT_BIT and
VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Even if they
are optional, it is working with the two formats that we are
exposing. Likely that will need to be refined if we start to
expose more formats.
* create_image_view: don't use hardcoded 0x70, but instead doing an
explicit bit or of VK_IMAGE_ASPECT_PLANE_0/1/2_BIT
* image_format_plane_features: keep how supported aspects and
separate stencil check is done. Even if the change introduced was
correct (not sure about that though), that change is unrelated to
this work
* write_image_descriptor: add additional checks for descriptor type,
to compute properly the offset.
* Cosmetic changes (don't use // for comments, capital letters, etc)
* Main changes coming from the review:
* Not use image aliases. All the info is already on the image
planes, and some points of the code were confusing as it was
using always a hardcoded plane 0.
* Squashed the two original main patches. YCbCr conversion was
leaking on the multi-planar support, as some support needed
info coming from the ycbcr structs.
* Not expose the extension on Android, and explicitly assert that
we expect plane_count to be 1 always.
* For a full list of review changes see MR#19950
Signed-off-by: Ella Stanforth <estanforth@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19950>
2022-07-28 09:15:43 +01:00
|
|
|
uint8_t plane;
|
2020-06-15 15:44:49 +01:00
|
|
|
};
|
|
|
|
|
2020-06-19 10:56:20 +01:00
|
|
|
struct v3dv_csd_indirect_cpu_job_info {
|
|
|
|
struct v3dv_buffer *buffer;
|
|
|
|
uint32_t offset;
|
|
|
|
struct v3dv_job *csd_job;
|
|
|
|
uint32_t wg_size;
|
|
|
|
uint32_t *wg_uniform_offsets[3];
|
|
|
|
bool needs_wg_uniform_rewrite;
|
|
|
|
};
|
|
|
|
|
2020-10-29 10:55:23 +00:00
|
|
|
struct v3dv_timestamp_query_cpu_job_info {
|
|
|
|
struct v3dv_query_pool *pool;
|
|
|
|
uint32_t query;
|
2021-07-23 13:49:05 +01:00
|
|
|
|
|
|
|
/* This is one unless multiview is used */
|
|
|
|
uint32_t count;
|
2020-10-29 10:55:23 +00:00
|
|
|
};
|
|
|
|
|
2021-11-23 22:29:48 +00:00
|
|
|
/* Number of perfmons required to handle all supported performance counters */
|
|
|
|
#define V3DV_MAX_PERFMONS DIV_ROUND_UP(V3D_PERFCNT_NUM, \
|
|
|
|
DRM_V3D_MAX_PERF_COUNTERS)
|
|
|
|
|
|
|
|
struct v3dv_perf_query {
|
|
|
|
uint32_t kperfmon_ids[V3DV_MAX_PERFMONS];
|
|
|
|
|
|
|
|
/* A DRM syncobj to wait on the GPU jobs for which we are collecting
|
|
|
|
* performance data.
|
|
|
|
*/
|
|
|
|
struct vk_sync *last_job_sync;
|
|
|
|
};
|
|
|
|
|
2020-01-08 10:14:35 +00:00
|
|
|
struct v3dv_job {
|
|
|
|
struct list_head list_link;
|
|
|
|
|
2020-05-26 11:05:43 +01:00
|
|
|
/* We only create job clones when executing secondary command buffers into
|
|
|
|
* primaries. These clones don't make deep copies of the original object
|
|
|
|
* so we want to flag them to avoid freeing resources they don't own.
|
|
|
|
*/
|
|
|
|
bool is_clone;
|
|
|
|
|
v3dv: consume barriers at the right stages
Until now, we have always consumed barriers with the next GPU job
recorded into the command buffer after the barrier even if the job
was not the target of the barrier itself. This works based on the
idea that when we consume a barrier in a job we serialize it against
all queues, so effectively we are ensuring that whatever came
before it has completed, so if the barrier was intended for an
even later job, it would have served its purpose anyway.
It should be noted that CL jobs are special because they are actually
split in two different queues: the binning queue and the render
queue, with a dependency between them to ensure render runs after
binning. With our current implementation, if we have 3 jobs (A, B,
C) and we have a barrier after job A which is intended to block job C
on A's completion, with our implementation we would instead block
B on A's completion. If C is a CL job, and the barrier was targetting
the binning stage then we can have the following scenarios:
1. If B) is a CL job, it will consume the barrier at its binning
stage, so we know that B's binning will not start until A has
completed. Then C's binning will not start until B's binning
has completed, and thus, will not start until A has completed,
as intended.
2. If B) is not a CL job, it will consume the barrier and will not
start until A has completed, however, C's binning job will be
submitted to the binning queue without any sync requirements
and since B did not put any jobs in the binning queue it will
start as soon as A's binning has completed, but not A's render,
which would be incorrect.
Further, since a981ac0539 we now skip consumming BCL barriers if
a job does not have draw calls that can be affected by them. In the
same scenarios as before, now case 1) would also be problematic,
since B may skip the binning sync in that case and start immediately,
and since C's binning would be allowe to start immediately after B's
binning, there is no guarantee that this doesn't happen in parallel
with A's render.
With this patch we fix this situation by tracking the intended
consumer of each barrier: graphics, compute or transfer, and we make
sure to consume them only with jobs that match those semantics.
This fixes flakyness in dEQP-VK.device_group.*
Fixes: a981ac0539 ('v3dv: skip binning sync if binning shaders don't access external resources')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-25 12:56:33 +01:00
|
|
|
/* If the job executes on the transfer stage of the pipeline */
|
|
|
|
bool is_transfer;
|
|
|
|
|
2022-06-27 13:12:25 +01:00
|
|
|
/* VK_KHR_buffer_device_address allows shaders to use pointers that can
|
|
|
|
* dereference memory in any buffer that has been flagged with
|
|
|
|
* VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT_KHR. These buffers may not
|
|
|
|
* be bound via descriptor sets, so we need to make sure that a job that
|
|
|
|
* uses this functionality includes all these buffers in its kernel
|
|
|
|
* submission.
|
|
|
|
*/
|
|
|
|
bool uses_buffer_device_address;
|
|
|
|
|
2022-07-22 08:45:10 +01:00
|
|
|
/* True if we have not identified anything that would be incompatible
|
|
|
|
* with double-buffer (like MSAA) or that would make double-buffer mode
|
|
|
|
* not efficient (like tile loads or not having any stores).
|
|
|
|
*/
|
|
|
|
bool can_use_double_buffer;
|
|
|
|
|
2022-07-27 10:42:01 +01:00
|
|
|
/* This structure keeps track of various scores to inform a heuristic
|
|
|
|
* for double-buffer mode.
|
|
|
|
*/
|
|
|
|
struct {
|
|
|
|
/* Cost of geometry shading */
|
|
|
|
uint32_t geom;
|
|
|
|
/* Cost of shader rendering */
|
|
|
|
uint32_t render;
|
|
|
|
} double_buffer_score;
|
|
|
|
|
2022-07-27 09:06:50 +01:00
|
|
|
/* We only need to allocate tile state for all layers if the binner
|
|
|
|
* writes primitives to layers other than the first. This can only be
|
|
|
|
* done using layered rendering (writing gl_Layer from a geometry shader),
|
|
|
|
* so for other cases of multilayered framebuffers (typically with
|
|
|
|
* meta copy/clear operations) that won't use layered rendering, we only
|
|
|
|
* need one layer worth of of tile state for the binner.
|
|
|
|
*/
|
|
|
|
bool allocate_tile_state_for_all_layers;
|
|
|
|
|
2022-07-27 10:42:01 +01:00
|
|
|
/* A pointer to the location of the TILE_BINNING_MODE_CFG packet so we can
|
|
|
|
* rewrite it to enable double-buffer mode by the time we have enough info
|
|
|
|
* about the job to make that decision.
|
|
|
|
*/
|
|
|
|
struct v3dv_cl_out *bcl_tile_binning_mode_ptr;
|
|
|
|
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 09:30:38 +01:00
|
|
|
enum v3dv_job_type type;
|
|
|
|
|
2020-03-13 10:35:06 +00:00
|
|
|
struct v3dv_device *device;
|
|
|
|
|
2020-01-08 10:14:35 +00:00
|
|
|
struct v3dv_cmd_buffer *cmd_buffer;
|
|
|
|
|
|
|
|
struct v3dv_cl bcl;
|
|
|
|
struct v3dv_cl rcl;
|
|
|
|
struct v3dv_cl indirect;
|
|
|
|
|
|
|
|
/* Set of all BOs referenced by the job. This will be used for making
|
|
|
|
* the list of BOs that the kernel will need to have paged in to
|
|
|
|
* execute our job.
|
|
|
|
*/
|
|
|
|
struct set *bos;
|
|
|
|
uint32_t bo_count;
|
2021-04-14 08:08:36 +01:00
|
|
|
uint64_t bo_handle_mask;
|
2020-01-08 10:14:35 +00:00
|
|
|
|
|
|
|
struct v3dv_bo *tile_alloc;
|
|
|
|
struct v3dv_bo *tile_state;
|
|
|
|
|
|
|
|
bool tmu_dirty_rcl;
|
2020-01-10 10:31:51 +00:00
|
|
|
|
|
|
|
uint32_t first_subpass;
|
2020-02-04 09:26:04 +00:00
|
|
|
|
v3dv: implement vkCmdClearAttachments
For now this only implements a fast path using the tile buffer, so it
can only be used when clearing full images, but this is good enough
for VkRunner.
The implementation is a bit tricky because this command executes
inside a render pass, and yet, since we are using the tile buffer to
clear, this needs to go in its own job. This means that with this, we
need to be able to split a subpass into multiple jobs which creates
some issues.
For example, certain operations, such as the subpass load operation
(particularly if it is a clear) should only happen on the first job of
the subpass and subsequent jobs in the same subpass should always
load.
Similarly, we should not discard the last store on an attachment
unless we know it is the last job for the last subpass that uses the
attachment.
To handle these cases we add two new flags to the job, one to know if
the job is not the first in a subpass (is_subpass_continue) and
another one to know if a job is the last in a subpass
(is_subpass_finish).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-06 11:39:48 +00:00
|
|
|
/* When the current subpass is split into multiple jobs, this flag is set
|
|
|
|
* to true for any jobs after the first in the same subpass.
|
|
|
|
*/
|
|
|
|
bool is_subpass_continue;
|
|
|
|
|
|
|
|
/* If this job is the last job emitted for a subpass. */
|
|
|
|
bool is_subpass_finish;
|
|
|
|
|
2020-03-02 16:21:26 +00:00
|
|
|
struct v3dv_frame_tiling frame_tiling;
|
|
|
|
|
2020-02-04 09:26:04 +00:00
|
|
|
enum v3dv_ez_state ez_state;
|
|
|
|
enum v3dv_ez_state first_ez_state;
|
2020-03-13 10:35:06 +00:00
|
|
|
|
2021-01-21 10:39:58 +00:00
|
|
|
/* If we have already decided if we need to disable Early Z/S completely
|
|
|
|
* for this job.
|
|
|
|
*/
|
|
|
|
bool decided_global_ez_enable;
|
|
|
|
|
2022-05-31 10:16:35 +01:00
|
|
|
/* If the job emitted any draw calls with Early Z/S enabled */
|
|
|
|
bool has_ez_draws;
|
|
|
|
|
2021-01-20 09:31:01 +00:00
|
|
|
/* If this job has been configured to use early Z/S clear */
|
|
|
|
bool early_zs_clear;
|
|
|
|
|
2020-03-18 09:00:31 +00:00
|
|
|
/* Number of draw calls recorded into the job */
|
|
|
|
uint32_t draw_count;
|
|
|
|
|
|
|
|
/* A flag indicating whether we want to flush every draw separately. This
|
|
|
|
* can be used for debugging, or for cases where special circumstances
|
|
|
|
* require this behavior.
|
|
|
|
*/
|
|
|
|
bool always_flush;
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 09:30:38 +01:00
|
|
|
|
v3dv: limit sync for barriers to hw queues selected by source mask
Until know when we consumed a barrier we would implement it by
setting the serialize flag on a job, which would cause it to
be serialized across all hardware queues (CL, CSD, TFU). However,
now that we track the source(s) of the barrier, we can restrict this
to only the relevant queue(s) instead (multisync path only).
It should be noted that we can implement transfers via TFU or CL
jobs, so if the source of a barrier is a transfer, we currently
synchronize against both the TFU and the CL queues, however, we
may be able to more effectively track this in the future to
restrict this to just one of the queues.
Also, for secondary command buffers we are taking the easy way
out and always synchronize against all queues, but we should
be able to do the same for secondaries without too much effort.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-30 08:12:22 +01:00
|
|
|
/* A mask of V3DV_BARRIER_* indicating the source(s) of the barrier. We
|
|
|
|
* can use this to select the hw queues where we need to serialize the job.
|
|
|
|
*/
|
|
|
|
uint8_t serialize;
|
2020-07-08 08:56:44 +01:00
|
|
|
|
|
|
|
/* If this is a CL job, whether we should sync before binning */
|
|
|
|
bool needs_bcl_sync;
|
|
|
|
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 09:30:38 +01:00
|
|
|
/* Job specs for CPU jobs */
|
|
|
|
union {
|
2020-06-15 15:44:49 +01:00
|
|
|
struct v3dv_reset_query_cpu_job_info query_reset;
|
2022-10-28 11:07:07 +01:00
|
|
|
struct v3dv_end_query_info query_end;
|
2020-06-15 15:44:49 +01:00
|
|
|
struct v3dv_copy_query_results_cpu_job_info query_copy_results;
|
|
|
|
struct v3dv_copy_buffer_to_image_cpu_job_info copy_buffer_to_image;
|
2020-06-19 10:56:20 +01:00
|
|
|
struct v3dv_csd_indirect_cpu_job_info csd_indirect;
|
2020-10-29 10:55:23 +00:00
|
|
|
struct v3dv_timestamp_query_cpu_job_info query_timestamp;
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 09:30:38 +01:00
|
|
|
} cpu;
|
2020-04-20 12:24:09 +01:00
|
|
|
|
2020-06-18 12:53:51 +01:00
|
|
|
/* Job specs for TFU jobs */
|
2020-04-20 12:24:09 +01:00
|
|
|
struct drm_v3d_submit_tfu tfu;
|
2020-06-18 12:53:51 +01:00
|
|
|
|
|
|
|
/* Job specs for CSD jobs */
|
|
|
|
struct {
|
|
|
|
struct v3dv_bo *shared_memory;
|
2020-06-19 10:56:20 +01:00
|
|
|
uint32_t wg_count[3];
|
2021-05-27 08:06:00 +01:00
|
|
|
uint32_t wg_base[3];
|
2020-06-18 12:53:51 +01:00
|
|
|
struct drm_v3d_submit_csd submit;
|
|
|
|
} csd;
|
2021-11-23 22:29:48 +00:00
|
|
|
|
|
|
|
/* Perfmons with last job sync for CSD and CL jobs */
|
|
|
|
struct v3dv_perf_query *perf;
|
2020-01-08 10:14:35 +00:00
|
|
|
};
|
|
|
|
|
2020-03-13 10:35:06 +00:00
|
|
|
void v3dv_job_init(struct v3dv_job *job,
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 09:30:38 +01:00
|
|
|
enum v3dv_job_type type,
|
2020-03-13 10:35:06 +00:00
|
|
|
struct v3dv_device *device,
|
|
|
|
struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
int32_t subpass_idx);
|
|
|
|
void v3dv_job_destroy(struct v3dv_job *job);
|
2021-04-13 11:21:08 +01:00
|
|
|
|
2020-01-08 10:14:35 +00:00
|
|
|
void v3dv_job_add_bo(struct v3dv_job *job, struct v3dv_bo *bo);
|
2021-04-13 11:21:08 +01:00
|
|
|
void v3dv_job_add_bo_unchecked(struct v3dv_job *job, struct v3dv_bo *bo);
|
|
|
|
|
2020-03-13 10:35:06 +00:00
|
|
|
void v3dv_job_start_frame(struct v3dv_job *job,
|
|
|
|
uint32_t width,
|
|
|
|
uint32_t height,
|
|
|
|
uint32_t layers,
|
2021-07-16 07:23:11 +01:00
|
|
|
bool allocate_tile_state_for_all_layers,
|
2022-07-27 09:21:44 +01:00
|
|
|
bool allocate_tile_state_now,
|
2020-03-13 10:35:06 +00:00
|
|
|
uint32_t render_target_count,
|
2020-07-24 09:33:16 +01:00
|
|
|
uint8_t max_internal_bpp,
|
|
|
|
bool msaa);
|
2021-06-14 22:36:45 +01:00
|
|
|
|
2022-01-03 13:55:37 +00:00
|
|
|
bool v3dv_job_type_is_gpu(struct v3dv_job *job);
|
|
|
|
|
2021-06-14 22:36:45 +01:00
|
|
|
struct v3dv_job *
|
|
|
|
v3dv_job_clone_in_cmd_buffer(struct v3dv_job *job,
|
|
|
|
struct v3dv_cmd_buffer *cmd_buffer);
|
|
|
|
|
2020-06-02 11:26:50 +01:00
|
|
|
struct v3dv_job *v3dv_cmd_buffer_create_cpu_job(struct v3dv_device *device,
|
|
|
|
enum v3dv_job_type type,
|
|
|
|
struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
uint32_t subpass_idx);
|
2020-01-08 10:14:35 +00:00
|
|
|
|
2021-06-14 22:36:45 +01:00
|
|
|
void
|
|
|
|
v3dv_cmd_buffer_ensure_array_state(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
uint32_t slot_size,
|
|
|
|
uint32_t used_count,
|
|
|
|
uint32_t *alloc_count,
|
|
|
|
void **ptr);
|
|
|
|
|
2022-05-03 08:05:19 +01:00
|
|
|
void v3dv_cmd_buffer_emit_pre_draw(struct v3dv_cmd_buffer *cmd_buffer,
|
2022-07-27 10:42:01 +01:00
|
|
|
bool indexed, bool indirect,
|
|
|
|
uint32_t vertex_count);
|
2021-06-14 22:36:45 +01:00
|
|
|
|
2022-07-27 09:06:50 +01:00
|
|
|
bool v3dv_job_allocate_tile_state(struct v3dv_job *job);
|
|
|
|
|
2021-06-14 22:36:45 +01:00
|
|
|
/* FIXME: only used on v3dv_cmd_buffer and v3dvx_cmd_buffer, perhaps move to a
|
|
|
|
* cmd_buffer specific header?
|
|
|
|
*/
|
|
|
|
struct v3dv_draw_info {
|
|
|
|
uint32_t vertex_count;
|
|
|
|
uint32_t instance_count;
|
|
|
|
uint32_t first_vertex;
|
|
|
|
uint32_t first_instance;
|
|
|
|
};
|
|
|
|
|
2020-07-31 00:11:39 +01:00
|
|
|
struct v3dv_vertex_binding {
|
|
|
|
struct v3dv_buffer *buffer;
|
|
|
|
VkDeviceSize offset;
|
|
|
|
};
|
|
|
|
|
v3dv: initial descriptor set support
Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.
This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.
Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.
We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).
Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-01-20 14:29:38 +00:00
|
|
|
struct v3dv_descriptor_state {
|
v3dv/descriptor_set: support for array of ubo/ssbo
For that we include the array_index when asking for a ubo/ssbo index
from the descriptor_map.
Until now, array_index was not included, but the descriptor_map took
into account the array_size. This had the advantage that you only need
a entry on the descriptor map, and the index was properly return.
But this make it complex to get back the set, binding and array_index
back from the ubo/ssbo binding. So it was more easy to just add
array_index. Somehow now the "key" on the descriptor map is the
combination of (set, binding, array_index).
Note that this also make sense as the vulkan api identifies each array
index as a descriptor, so for example, from spec,
VkDescriptorSetLayoutBinding:descriptorCount
"descriptorCount is the number of descriptors contained in the
binding, accessed in a shader as an array"
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-13 21:22:18 +00:00
|
|
|
struct v3dv_descriptor_set *descriptor_sets[MAX_SETS];
|
v3dv: initial descriptor set support
Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.
This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.
Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.
We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).
Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-01-20 14:29:38 +00:00
|
|
|
uint32_t valid;
|
2020-02-24 10:32:57 +00:00
|
|
|
uint32_t dynamic_offsets[MAX_DYNAMIC_BUFFERS];
|
v3dv: initial descriptor set support
Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.
This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.
Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.
We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).
Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-01-20 14:29:38 +00:00
|
|
|
};
|
|
|
|
|
2021-01-15 22:07:45 +00:00
|
|
|
struct v3dv_cmd_pipeline_state {
|
|
|
|
struct v3dv_pipeline *pipeline;
|
|
|
|
|
|
|
|
struct v3dv_descriptor_state descriptor_state;
|
|
|
|
};
|
|
|
|
|
v3dv: consume barriers at the right stages
Until now, we have always consumed barriers with the next GPU job
recorded into the command buffer after the barrier even if the job
was not the target of the barrier itself. This works based on the
idea that when we consume a barrier in a job we serialize it against
all queues, so effectively we are ensuring that whatever came
before it has completed, so if the barrier was intended for an
even later job, it would have served its purpose anyway.
It should be noted that CL jobs are special because they are actually
split in two different queues: the binning queue and the render
queue, with a dependency between them to ensure render runs after
binning. With our current implementation, if we have 3 jobs (A, B,
C) and we have a barrier after job A which is intended to block job C
on A's completion, with our implementation we would instead block
B on A's completion. If C is a CL job, and the barrier was targetting
the binning stage then we can have the following scenarios:
1. If B) is a CL job, it will consume the barrier at its binning
stage, so we know that B's binning will not start until A has
completed. Then C's binning will not start until B's binning
has completed, and thus, will not start until A has completed,
as intended.
2. If B) is not a CL job, it will consume the barrier and will not
start until A has completed, however, C's binning job will be
submitted to the binning queue without any sync requirements
and since B did not put any jobs in the binning queue it will
start as soon as A's binning has completed, but not A's render,
which would be incorrect.
Further, since a981ac0539 we now skip consumming BCL barriers if
a job does not have draw calls that can be affected by them. In the
same scenarios as before, now case 1) would also be problematic,
since B may skip the binning sync in that case and start immediately,
and since C's binning would be allowe to start immediately after B's
binning, there is no guarantee that this doesn't happen in parallel
with A's render.
With this patch we fix this situation by tracking the intended
consumer of each barrier: graphics, compute or transfer, and we make
sure to consume them only with jobs that match those semantics.
This fixes flakyness in dEQP-VK.device_group.*
Fixes: a981ac0539 ('v3dv: skip binning sync if binning shaders don't access external resources')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-25 12:56:33 +01:00
|
|
|
enum {
|
|
|
|
V3DV_BARRIER_GRAPHICS_BIT = (1 << 0),
|
|
|
|
V3DV_BARRIER_COMPUTE_BIT = (1 << 1),
|
|
|
|
V3DV_BARRIER_TRANSFER_BIT = (1 << 2),
|
|
|
|
};
|
v3dv: limit sync for barriers to hw queues selected by source mask
Until know when we consumed a barrier we would implement it by
setting the serialize flag on a job, which would cause it to
be serialized across all hardware queues (CL, CSD, TFU). However,
now that we track the source(s) of the barrier, we can restrict this
to only the relevant queue(s) instead (multisync path only).
It should be noted that we can implement transfers via TFU or CL
jobs, so if the source of a barrier is a transfer, we currently
synchronize against both the TFU and the CL queues, however, we
may be able to more effectively track this in the future to
restrict this to just one of the queues.
Also, for secondary command buffers we are taking the easy way
out and always synchronize against all queues, but we should
be able to do the same for secondaries without too much effort.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-30 08:12:22 +01:00
|
|
|
#define V3DV_BARRIER_ALL (V3DV_BARRIER_GRAPHICS_BIT | \
|
|
|
|
V3DV_BARRIER_TRANSFER_BIT | \
|
|
|
|
V3DV_BARRIER_COMPUTE_BIT);
|
v3dv: consume barriers at the right stages
Until now, we have always consumed barriers with the next GPU job
recorded into the command buffer after the barrier even if the job
was not the target of the barrier itself. This works based on the
idea that when we consume a barrier in a job we serialize it against
all queues, so effectively we are ensuring that whatever came
before it has completed, so if the barrier was intended for an
even later job, it would have served its purpose anyway.
It should be noted that CL jobs are special because they are actually
split in two different queues: the binning queue and the render
queue, with a dependency between them to ensure render runs after
binning. With our current implementation, if we have 3 jobs (A, B,
C) and we have a barrier after job A which is intended to block job C
on A's completion, with our implementation we would instead block
B on A's completion. If C is a CL job, and the barrier was targetting
the binning stage then we can have the following scenarios:
1. If B) is a CL job, it will consume the barrier at its binning
stage, so we know that B's binning will not start until A has
completed. Then C's binning will not start until B's binning
has completed, and thus, will not start until A has completed,
as intended.
2. If B) is not a CL job, it will consume the barrier and will not
start until A has completed, however, C's binning job will be
submitted to the binning queue without any sync requirements
and since B did not put any jobs in the binning queue it will
start as soon as A's binning has completed, but not A's render,
which would be incorrect.
Further, since a981ac0539 we now skip consumming BCL barriers if
a job does not have draw calls that can be affected by them. In the
same scenarios as before, now case 1) would also be problematic,
since B may skip the binning sync in that case and start immediately,
and since C's binning would be allowe to start immediately after B's
binning, there is no guarantee that this doesn't happen in parallel
with A's render.
With this patch we fix this situation by tracking the intended
consumer of each barrier: graphics, compute or transfer, and we make
sure to consume them only with jobs that match those semantics.
This fixes flakyness in dEQP-VK.device_group.*
Fixes: a981ac0539 ('v3dv: skip binning sync if binning shaders don't access external resources')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-25 12:56:33 +01:00
|
|
|
|
2022-05-30 07:31:17 +01:00
|
|
|
struct v3dv_barrier_state {
|
|
|
|
/* Mask of V3DV_BARRIER_* indicating where we consume a barrier. */
|
|
|
|
uint8_t dst_mask;
|
|
|
|
|
2022-05-30 07:52:31 +01:00
|
|
|
/* For each possible consumer of a barrier, a mask of V3DV_BARRIER_*
|
|
|
|
* indicating the sources of the dependency.
|
|
|
|
*/
|
|
|
|
uint8_t src_mask_graphics;
|
|
|
|
uint8_t src_mask_transfer;
|
|
|
|
uint8_t src_mask_compute;
|
|
|
|
|
2022-05-30 07:31:17 +01:00
|
|
|
/* For graphics barriers, access masks involved. Used to decide if we need
|
|
|
|
* to execute a binning or render barrier.
|
|
|
|
*/
|
2022-08-26 08:26:41 +01:00
|
|
|
VkAccessFlags2 bcl_buffer_access;
|
|
|
|
VkAccessFlags2 bcl_image_access;
|
2022-05-30 07:31:17 +01:00
|
|
|
};
|
|
|
|
|
2019-12-13 09:48:12 +00:00
|
|
|
struct v3dv_cmd_buffer_state {
|
2020-03-31 11:59:44 +01:00
|
|
|
struct v3dv_render_pass *pass;
|
|
|
|
struct v3dv_framebuffer *framebuffer;
|
2019-12-17 07:58:20 +00:00
|
|
|
VkRect2D render_area;
|
|
|
|
|
2020-01-09 11:50:43 +00:00
|
|
|
/* Current job being recorded */
|
|
|
|
struct v3dv_job *job;
|
2019-12-18 10:44:35 +00:00
|
|
|
|
2019-12-17 07:58:20 +00:00
|
|
|
uint32_t subpass_idx;
|
2019-12-18 14:38:21 +00:00
|
|
|
|
2021-01-15 22:07:45 +00:00
|
|
|
struct v3dv_cmd_pipeline_state gfx;
|
|
|
|
struct v3dv_cmd_pipeline_state compute;
|
2019-12-28 10:59:32 +00:00
|
|
|
|
|
|
|
struct v3dv_dynamic_state dynamic;
|
2021-04-16 09:14:23 +01:00
|
|
|
|
2019-12-28 10:59:32 +00:00
|
|
|
uint32_t dirty;
|
2021-04-16 09:14:23 +01:00
|
|
|
VkShaderStageFlagBits dirty_descriptor_stages;
|
2021-04-16 11:50:00 +01:00
|
|
|
VkShaderStageFlagBits dirty_push_constants_stages;
|
2019-12-30 12:01:44 +00:00
|
|
|
|
2020-04-01 09:17:22 +01:00
|
|
|
/* Current clip window. We use this to check whether we have an active
|
|
|
|
* scissor, since in that case we can't use TLB clears and need to fallback
|
|
|
|
* to drawing rects.
|
|
|
|
*/
|
|
|
|
VkRect2D clip_window;
|
|
|
|
|
2020-04-02 11:38:10 +01:00
|
|
|
/* Whether our render area is aligned to tile boundaries. If this is false
|
|
|
|
* then we have tiles that are only partially covered by the render area,
|
|
|
|
* and therefore, we need to be careful with our loads and stores so we don't
|
|
|
|
* modify pixels for the tile area that is not covered by the render area.
|
|
|
|
* This means, for example, that we can't use the TLB to clear, since that
|
|
|
|
* always clears full tiles.
|
|
|
|
*/
|
|
|
|
bool tile_aligned_render_area;
|
|
|
|
|
2022-07-13 11:44:45 +01:00
|
|
|
/* FIXME: we have just one client-side BO for the push constants,
|
|
|
|
* independently of the stageFlags in vkCmdPushConstants, and the
|
|
|
|
* pipelineBindPoint in vkCmdBindPipeline. We could probably do more stage
|
|
|
|
* tunning in the future if it makes sense.
|
|
|
|
*/
|
|
|
|
uint32_t push_constants_size;
|
|
|
|
uint32_t push_constants_data[MAX_PUSH_CONSTANTS_SIZE / 4];
|
|
|
|
|
2020-06-02 12:13:43 +01:00
|
|
|
uint32_t attachment_alloc_count;
|
2020-01-09 11:50:43 +00:00
|
|
|
struct v3dv_cmd_buffer_attachment_state *attachments;
|
2020-07-31 00:11:39 +01:00
|
|
|
|
|
|
|
struct v3dv_vertex_binding vertex_bindings[MAX_VBS];
|
2020-02-07 09:10:39 +00:00
|
|
|
|
2020-06-11 10:59:24 +01:00
|
|
|
struct {
|
|
|
|
VkBuffer buffer;
|
|
|
|
VkDeviceSize offset;
|
|
|
|
uint8_t index_size;
|
|
|
|
} index_buffer;
|
2020-03-12 10:59:04 +00:00
|
|
|
|
2020-11-19 08:45:16 +00:00
|
|
|
/* Current uniforms */
|
|
|
|
struct {
|
|
|
|
struct v3dv_cl_reloc vs_bin;
|
|
|
|
struct v3dv_cl_reloc vs;
|
2021-07-01 08:08:02 +01:00
|
|
|
struct v3dv_cl_reloc gs_bin;
|
|
|
|
struct v3dv_cl_reloc gs;
|
2020-11-19 08:45:16 +00:00
|
|
|
struct v3dv_cl_reloc fs;
|
|
|
|
} uniforms;
|
|
|
|
|
2021-07-23 08:41:14 +01:00
|
|
|
/* Current view index for multiview rendering */
|
|
|
|
uint32_t view_index;
|
|
|
|
|
2020-03-12 10:59:04 +00:00
|
|
|
/* Used to flag OOM conditions during command buffer recording */
|
|
|
|
bool oom;
|
2020-03-31 11:59:44 +01:00
|
|
|
|
v3dv: consume barriers at the right stages
Until now, we have always consumed barriers with the next GPU job
recorded into the command buffer after the barrier even if the job
was not the target of the barrier itself. This works based on the
idea that when we consume a barrier in a job we serialize it against
all queues, so effectively we are ensuring that whatever came
before it has completed, so if the barrier was intended for an
even later job, it would have served its purpose anyway.
It should be noted that CL jobs are special because they are actually
split in two different queues: the binning queue and the render
queue, with a dependency between them to ensure render runs after
binning. With our current implementation, if we have 3 jobs (A, B,
C) and we have a barrier after job A which is intended to block job C
on A's completion, with our implementation we would instead block
B on A's completion. If C is a CL job, and the barrier was targetting
the binning stage then we can have the following scenarios:
1. If B) is a CL job, it will consume the barrier at its binning
stage, so we know that B's binning will not start until A has
completed. Then C's binning will not start until B's binning
has completed, and thus, will not start until A has completed,
as intended.
2. If B) is not a CL job, it will consume the barrier and will not
start until A has completed, however, C's binning job will be
submitted to the binning queue without any sync requirements
and since B did not put any jobs in the binning queue it will
start as soon as A's binning has completed, but not A's render,
which would be incorrect.
Further, since a981ac0539 we now skip consumming BCL barriers if
a job does not have draw calls that can be affected by them. In the
same scenarios as before, now case 1) would also be problematic,
since B may skip the binning sync in that case and start immediately,
and since C's binning would be allowe to start immediately after B's
binning, there is no guarantee that this doesn't happen in parallel
with A's render.
With this patch we fix this situation by tracking the intended
consumer of each barrier: graphics, compute or transfer, and we make
sure to consume them only with jobs that match those semantics.
This fixes flakyness in dEQP-VK.device_group.*
Fixes: a981ac0539 ('v3dv: skip binning sync if binning shaders don't access external resources')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-25 12:56:33 +01:00
|
|
|
/* If we are currently recording job(s) for a transfer operation */
|
|
|
|
bool is_transfer;
|
|
|
|
|
|
|
|
/* Barrier state tracking */
|
2022-05-30 07:31:17 +01:00
|
|
|
struct v3dv_barrier_state barrier;
|
2020-07-08 08:56:44 +01:00
|
|
|
|
2020-10-30 08:12:38 +00:00
|
|
|
/* Secondary command buffer state */
|
|
|
|
struct {
|
|
|
|
bool occlusion_query_enable;
|
|
|
|
} inheritance;
|
|
|
|
|
2020-03-31 11:59:44 +01:00
|
|
|
/* Command buffer state saved during a meta operation */
|
|
|
|
struct {
|
|
|
|
uint32_t subpass_idx;
|
|
|
|
VkRenderPass pass;
|
|
|
|
VkFramebuffer framebuffer;
|
2020-04-03 08:41:45 +01:00
|
|
|
|
|
|
|
uint32_t attachment_alloc_count;
|
|
|
|
uint32_t attachment_count;
|
|
|
|
struct v3dv_cmd_buffer_attachment_state *attachments;
|
|
|
|
|
|
|
|
bool tile_aligned_render_area;
|
|
|
|
VkRect2D render_area;
|
|
|
|
|
|
|
|
struct v3dv_dynamic_state dynamic;
|
2020-04-22 07:27:58 +01:00
|
|
|
|
2021-01-15 22:07:45 +00:00
|
|
|
struct v3dv_cmd_pipeline_state gfx;
|
2020-06-25 08:30:04 +01:00
|
|
|
bool has_descriptor_state;
|
2020-04-22 08:26:27 +01:00
|
|
|
|
|
|
|
uint32_t push_constants[MAX_PUSH_CONSTANTS_SIZE / 4];
|
2022-07-13 10:29:02 +01:00
|
|
|
uint32_t push_constants_size;
|
2020-03-31 11:59:44 +01:00
|
|
|
} meta;
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 09:30:38 +01:00
|
|
|
|
|
|
|
/* Command buffer state for queries */
|
|
|
|
struct {
|
|
|
|
/* A list of vkCmdQueryEnd commands recorded in the command buffer during
|
|
|
|
* a render pass. We queue these here and then schedule the corresponding
|
|
|
|
* CPU jobs for them at the time we finish the GPU job in which they have
|
|
|
|
* been recorded.
|
|
|
|
*/
|
|
|
|
struct {
|
|
|
|
uint32_t used_count;
|
|
|
|
uint32_t alloc_count;
|
2022-10-28 11:07:07 +01:00
|
|
|
struct v3dv_end_query_info *states;
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 09:30:38 +01:00
|
|
|
} end;
|
|
|
|
|
2021-04-14 12:34:00 +01:00
|
|
|
struct {
|
2021-11-23 22:29:48 +00:00
|
|
|
/* This BO is not NULL if we have an active occlusion query, that is,
|
|
|
|
* we have called vkCmdBeginQuery but not vkCmdEndQuery.
|
|
|
|
*/
|
2021-04-14 12:34:00 +01:00
|
|
|
struct v3dv_bo *bo;
|
|
|
|
uint32_t offset;
|
2023-03-27 10:11:24 +01:00
|
|
|
/* When the driver emits draw calls to implement other operations in
|
|
|
|
* the middle of a render pass (such as an attachment clear), we need
|
|
|
|
* to pause occlusion query recording and resume it later so that
|
|
|
|
* these draw calls don't register in occlussion counters. We use
|
|
|
|
* this to store the BO reference in which we should resume occlusion
|
|
|
|
* query counters after the driver is done emitting its draw calls.
|
|
|
|
*/
|
|
|
|
struct v3dv_bo *paused_bo;
|
2021-11-23 22:29:48 +00:00
|
|
|
|
|
|
|
/* This pointer is not NULL if we have an active performance query */
|
|
|
|
struct v3dv_perf_query *perf;
|
2021-04-14 12:34:00 +01:00
|
|
|
} active_query;
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 09:30:38 +01:00
|
|
|
} query;
|
2019-12-13 09:48:12 +00:00
|
|
|
};
|
|
|
|
|
2022-09-02 07:49:12 +01:00
|
|
|
void
|
|
|
|
v3dv_cmd_buffer_state_get_viewport_z_xform(struct v3dv_cmd_buffer_state *state,
|
|
|
|
uint32_t vp_idx,
|
|
|
|
float *translate_z, float *scale_z);
|
|
|
|
|
v3dv/descriptor: add general bo on descriptor pool
So far we were saving all the descriptor info on the host memory. With
this commit we do the equivalent that other mesa vulkan drivers (Anvil
and Turnip) and create a bo on the descriptor pool that would be
suballocated for each descriptor.
This would allow to clean up individual bos from some vulkan objects,
reducing device memory fragmentation, and allowing to avoid to alloc
bos for that info. After all, pre-allocating needed memory is one of
the purposes of the descriptor pool.
This commit introduces all the infrastructure, but doesn't use it for
any descriptor yet, as if no descriptor needed data uploaded to a bo.
The idea to decide which info goes to the descriptor pool bo is info
that we would need to upload to a bo in any case, as it is referenced
as an address by any packet.
We could be more aggressive with that general rule, but that would be
enough for now. If in the future we support
VK_EXT_descriptor_indexing, we probably would need to store more info,
as under that extension, descriptors can be updated after being bound.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-06-03 00:10:01 +01:00
|
|
|
/* The following struct represents the info from a descriptor that we store on
|
|
|
|
* the host memory. They are mostly links to other existing vulkan objects,
|
|
|
|
* like the image_view in order to access to swizzle info, or the buffer used
|
|
|
|
* for a UBO/SSBO, for example.
|
|
|
|
*
|
|
|
|
* FIXME: revisit if makes sense to just move everything that would be needed
|
|
|
|
* from a descriptor to the bo.
|
|
|
|
*/
|
2020-09-11 22:26:07 +01:00
|
|
|
struct v3dv_descriptor {
|
2020-03-29 15:29:55 +01:00
|
|
|
VkDescriptorType type;
|
|
|
|
|
|
|
|
union {
|
|
|
|
struct {
|
|
|
|
struct v3dv_image_view *image_view;
|
|
|
|
struct v3dv_sampler *sampler;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct {
|
|
|
|
struct v3dv_buffer *buffer;
|
v3dv: implement VK_EXT_inline_uniform_block
Inline uniform blocks store their contents in pool memory rather
than a separate buffer, and are intended to provide a way in which
some platforms may provide more efficient access to the uniform
data, similar to push constants but with more flexible size
constraints.
We implement these in a similar way as push constants: for constant
access we copy the data in the uniform stream (using the new
QUNIFORM_UNIFORM_UBO_*) enums to identify the inline buffer from
which we need to copy and for indirect access we fallback to
regular UBO access.
Because at NIR level there is no distinction between inline and
regular UBOs and the compiler isn't aware of Vulkan descriptor
sets, we use the UBO index on UBO load intrinsics to identify
inline UBOs, just like we do for push constants. Particularly,
we reserve indices 1..MAX_INLINE_UNIFORM_BUFFERS for this,
however, unlike push constants, inline buffers are accessed
through descriptor sets, and therefore we need to make sure
they are located in the first slots of the UBO descriptor map.
This means we store them in the first MAX_INLINE_UNIFORM_BUFFERS
slots of the map, with regular UBOs always coming after these
slots.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15575>
2022-03-24 09:05:17 +00:00
|
|
|
size_t offset;
|
|
|
|
size_t range;
|
2020-03-29 15:29:55 +01:00
|
|
|
};
|
2020-07-28 23:28:28 +01:00
|
|
|
|
|
|
|
struct v3dv_buffer_view *buffer_view;
|
2020-03-29 15:29:55 +01:00
|
|
|
};
|
2020-09-11 22:26:07 +01:00
|
|
|
};
|
|
|
|
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 09:30:38 +01:00
|
|
|
struct v3dv_query {
|
2022-10-28 11:07:07 +01:00
|
|
|
/* Used by queries where we implement result copying in the CPU so we can
|
|
|
|
* tell if the relevant jobs have been submitted for execution. Currently
|
|
|
|
* these are all but occlusion queries.
|
|
|
|
*/
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 09:30:38 +01:00
|
|
|
bool maybe_available;
|
2022-10-28 11:07:07 +01:00
|
|
|
|
2020-10-29 10:55:23 +00:00
|
|
|
union {
|
2022-10-28 11:07:07 +01:00
|
|
|
/* Used by occlusion queries */
|
2021-04-14 12:34:00 +01:00
|
|
|
struct {
|
2022-10-28 11:07:07 +01:00
|
|
|
/* Offset of this query in the occlusion query counter BO */
|
2021-04-14 12:34:00 +01:00
|
|
|
uint32_t offset;
|
2022-10-28 11:07:07 +01:00
|
|
|
} occlusion;
|
|
|
|
|
2021-04-14 12:34:00 +01:00
|
|
|
/* Used by CPU queries (timestamp) */
|
|
|
|
uint64_t value;
|
2021-11-23 22:29:48 +00:00
|
|
|
|
|
|
|
/* Used by performance queries */
|
|
|
|
struct v3dv_perf_query perf;
|
2020-10-29 10:55:23 +00:00
|
|
|
};
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 09:30:38 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
struct v3dv_query_pool {
|
2020-11-12 15:30:41 +00:00
|
|
|
struct vk_object_base base;
|
|
|
|
|
2022-10-28 11:07:07 +01:00
|
|
|
/* Per-pool Vulkan resources required to implement GPU-side query
|
|
|
|
* functions (only occlusion queries for now).
|
|
|
|
*/
|
|
|
|
struct {
|
2022-11-15 12:47:07 +00:00
|
|
|
/* Buffer to access the BO with the occlusion query results and
|
|
|
|
* availability info.
|
|
|
|
*/
|
|
|
|
VkBuffer buf;
|
|
|
|
VkDeviceMemory mem;
|
2022-10-28 11:07:07 +01:00
|
|
|
|
2022-11-15 12:47:07 +00:00
|
|
|
/* Descriptor set for accessing the buffer from a pipeline. */
|
2022-10-28 11:07:07 +01:00
|
|
|
VkDescriptorPool descriptor_pool;
|
2022-11-15 12:47:07 +00:00
|
|
|
VkDescriptorSet descriptor_set;
|
2022-10-28 11:07:07 +01:00
|
|
|
} meta;
|
|
|
|
|
|
|
|
/* Only used with occlusion queries */
|
|
|
|
struct {
|
2022-11-15 12:47:07 +00:00
|
|
|
/* BO with the occlusion counters and query availability */
|
2022-10-28 11:07:07 +01:00
|
|
|
struct v3dv_bo *bo;
|
2022-11-15 12:47:07 +00:00
|
|
|
/* Offset of the availability info in the BO */
|
|
|
|
uint32_t avail_offset;
|
2022-10-28 11:07:07 +01:00
|
|
|
} occlusion;
|
2021-04-14 12:34:00 +01:00
|
|
|
|
2021-11-23 22:29:48 +00:00
|
|
|
/* Only used with performance queries */
|
|
|
|
struct {
|
|
|
|
uint32_t ncounters;
|
|
|
|
uint8_t counters[V3D_PERFCNT_NUM];
|
|
|
|
|
|
|
|
/* V3D has a limit on the number of counters we can track in a
|
|
|
|
* single performance monitor, so if too many counters are requested
|
|
|
|
* we need to create multiple monitors to record all of them. This
|
|
|
|
* field represents the number of monitors required for the number
|
|
|
|
* of counters requested.
|
|
|
|
*/
|
|
|
|
uint8_t nperfmons;
|
|
|
|
} perfmon;
|
|
|
|
|
2020-10-29 10:55:23 +00:00
|
|
|
VkQueryType query_type;
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 09:30:38 +01:00
|
|
|
uint32_t query_count;
|
|
|
|
struct v3dv_query *queries;
|
|
|
|
};
|
|
|
|
|
2022-10-28 11:07:07 +01:00
|
|
|
VkResult
|
|
|
|
v3dv_query_allocate_resources(struct v3dv_device *decice);
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 09:30:38 +01:00
|
|
|
|
2022-10-28 11:07:07 +01:00
|
|
|
void
|
|
|
|
v3dv_query_free_resources(struct v3dv_device *decice);
|
|
|
|
|
|
|
|
VkResult v3dv_get_query_pool_results_cpu(struct v3dv_device *device,
|
|
|
|
struct v3dv_query_pool *pool,
|
|
|
|
uint32_t first,
|
|
|
|
uint32_t count,
|
|
|
|
void *data,
|
|
|
|
VkDeviceSize stride,
|
|
|
|
VkQueryResultFlags flags);
|
|
|
|
|
|
|
|
void v3dv_reset_query_pool_cpu(struct v3dv_device *device,
|
|
|
|
struct v3dv_query_pool *query_pool,
|
|
|
|
uint32_t first,
|
|
|
|
uint32_t last);
|
|
|
|
|
|
|
|
void v3dv_cmd_buffer_emit_set_query_availability(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
struct v3dv_query_pool *pool,
|
|
|
|
uint32_t query, uint32_t count,
|
|
|
|
uint8_t availability);
|
2021-10-12 17:58:33 +01:00
|
|
|
|
2020-04-29 08:13:00 +01:00
|
|
|
typedef void (*v3dv_cmd_buffer_private_obj_destroy_cb)(VkDevice device,
|
2020-05-14 08:23:40 +01:00
|
|
|
uint64_t pobj,
|
2020-04-29 08:13:00 +01:00
|
|
|
VkAllocationCallbacks *alloc);
|
|
|
|
struct v3dv_cmd_buffer_private_obj {
|
|
|
|
struct list_head list_link;
|
2020-05-14 08:23:40 +01:00
|
|
|
uint64_t obj;
|
2020-04-29 08:13:00 +01:00
|
|
|
v3dv_cmd_buffer_private_obj_destroy_cb destroy_cb;
|
|
|
|
};
|
|
|
|
|
2022-09-02 10:32:59 +01:00
|
|
|
extern const struct vk_command_buffer_ops v3dv_cmd_buffer_ops;
|
|
|
|
|
2019-12-10 08:33:13 +00:00
|
|
|
struct v3dv_cmd_buffer {
|
2021-04-06 13:13:14 +01:00
|
|
|
struct vk_command_buffer vk;
|
2019-12-10 08:33:13 +00:00
|
|
|
|
|
|
|
struct v3dv_device *device;
|
|
|
|
|
|
|
|
VkCommandBufferUsageFlags usage_flags;
|
2019-12-11 09:14:10 +00:00
|
|
|
|
2019-12-11 10:57:08 +00:00
|
|
|
enum v3dv_cmd_buffer_status status;
|
2019-12-13 09:48:12 +00:00
|
|
|
|
|
|
|
struct v3dv_cmd_buffer_state state;
|
|
|
|
|
2022-07-13 11:44:45 +01:00
|
|
|
/* Buffer where we upload push constant data to resolve indirect indexing */
|
2021-01-21 13:18:14 +00:00
|
|
|
struct v3dv_cl_reloc push_constants_resource;
|
2020-09-11 22:26:07 +01:00
|
|
|
|
2020-04-29 08:13:00 +01:00
|
|
|
/* Collection of Vulkan objects created internally by the driver (typically
|
|
|
|
* during recording of meta operations) that are part of the command buffer
|
|
|
|
* and should be destroyed with it.
|
|
|
|
*/
|
|
|
|
struct list_head private_objs; /* v3dv_cmd_buffer_private_obj */
|
|
|
|
|
2020-04-29 08:42:01 +01:00
|
|
|
/* Per-command buffer resources for meta operations. */
|
|
|
|
struct {
|
|
|
|
struct {
|
2020-10-26 09:39:29 +00:00
|
|
|
/* The current descriptor pool for blit sources */
|
2020-04-29 08:42:01 +01:00
|
|
|
VkDescriptorPool dspool;
|
|
|
|
} blit;
|
2020-11-12 09:43:54 +00:00
|
|
|
struct {
|
|
|
|
/* The current descriptor pool for texel buffer copy sources */
|
|
|
|
VkDescriptorPool dspool;
|
|
|
|
} texel_buffer_copy;
|
2022-10-28 11:07:07 +01:00
|
|
|
struct {
|
|
|
|
/* The current descriptor pool for the copy query results output buffer */
|
|
|
|
VkDescriptorPool dspool;
|
|
|
|
} query;
|
2020-04-29 08:42:01 +01:00
|
|
|
} meta;
|
|
|
|
|
2020-05-26 11:05:43 +01:00
|
|
|
/* List of jobs in the command buffer. For primary command buffers it
|
|
|
|
* represents the jobs we want to submit to the GPU. For secondary command
|
|
|
|
* buffers it represents jobs that will be merged into a primary command
|
|
|
|
* buffer via vkCmdExecuteCommands.
|
|
|
|
*/
|
|
|
|
struct list_head jobs;
|
2019-12-10 08:33:13 +00:00
|
|
|
};
|
|
|
|
|
v3dv: implement vkCmdClearAttachments
For now this only implements a fast path using the tile buffer, so it
can only be used when clearing full images, but this is good enough
for VkRunner.
The implementation is a bit tricky because this command executes
inside a render pass, and yet, since we are using the tile buffer to
clear, this needs to go in its own job. This means that with this, we
need to be able to split a subpass into multiple jobs which creates
some issues.
For example, certain operations, such as the subpass load operation
(particularly if it is a clear) should only happen on the first job of
the subpass and subsequent jobs in the same subpass should always
load.
Similarly, we should not discard the last store on an attachment
unless we know it is the last job for the last subpass that uses the
attachment.
To handle these cases we add two new flags to the job, one to know if
the job is not the first in a subpass (is_subpass_continue) and
another one to know if a job is the last in a subpass
(is_subpass_finish).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-06 11:39:48 +00:00
|
|
|
struct v3dv_job *v3dv_cmd_buffer_start_job(struct v3dv_cmd_buffer *cmd_buffer,
|
2020-06-02 11:26:50 +01:00
|
|
|
int32_t subpass_idx,
|
|
|
|
enum v3dv_job_type type);
|
2020-01-08 10:14:35 +00:00
|
|
|
void v3dv_cmd_buffer_finish_job(struct v3dv_cmd_buffer *cmd_buffer);
|
2019-12-13 09:48:12 +00:00
|
|
|
|
2020-03-31 11:59:44 +01:00
|
|
|
struct v3dv_job *v3dv_cmd_buffer_subpass_start(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
uint32_t subpass_idx);
|
2020-04-03 13:19:40 +01:00
|
|
|
struct v3dv_job *v3dv_cmd_buffer_subpass_resume(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
uint32_t subpass_idx);
|
2020-03-31 11:59:44 +01:00
|
|
|
|
|
|
|
void v3dv_cmd_buffer_subpass_finish(struct v3dv_cmd_buffer *cmd_buffer);
|
|
|
|
|
2020-04-22 07:27:58 +01:00
|
|
|
void v3dv_cmd_buffer_meta_state_push(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
bool push_descriptor_state);
|
2020-04-03 08:41:45 +01:00
|
|
|
void v3dv_cmd_buffer_meta_state_pop(struct v3dv_cmd_buffer *cmd_buffer,
|
2020-07-16 11:34:30 +01:00
|
|
|
bool needs_subpass_resume);
|
2020-03-31 11:59:44 +01:00
|
|
|
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 09:30:38 +01:00
|
|
|
void v3dv_cmd_buffer_begin_query(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
struct v3dv_query_pool *pool,
|
|
|
|
uint32_t query,
|
|
|
|
VkQueryControlFlags flags);
|
|
|
|
|
2023-03-27 10:11:24 +01:00
|
|
|
void v3dv_cmd_buffer_pause_occlusion_query(struct v3dv_cmd_buffer *cmd_buffer);
|
|
|
|
void v3dv_cmd_buffer_resume_occlusion_query(struct v3dv_cmd_buffer *cmd_buffer);
|
|
|
|
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 09:30:38 +01:00
|
|
|
void v3dv_cmd_buffer_end_query(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
struct v3dv_query_pool *pool,
|
|
|
|
uint32_t query);
|
|
|
|
|
|
|
|
void v3dv_cmd_buffer_copy_query_results(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
struct v3dv_query_pool *pool,
|
|
|
|
uint32_t first,
|
|
|
|
uint32_t count,
|
|
|
|
struct v3dv_buffer *dst,
|
|
|
|
uint32_t offset,
|
|
|
|
uint32_t stride,
|
|
|
|
VkQueryResultFlags flags);
|
|
|
|
|
2020-04-20 12:24:09 +01:00
|
|
|
void v3dv_cmd_buffer_add_tfu_job(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
struct drm_v3d_submit_tfu *tfu);
|
|
|
|
|
2020-06-19 10:56:20 +01:00
|
|
|
void v3dv_cmd_buffer_rewrite_indirect_csd_job(struct v3dv_csd_indirect_cpu_job_info *info,
|
|
|
|
const uint32_t *wg_counts);
|
|
|
|
|
2020-04-29 08:13:00 +01:00
|
|
|
void v3dv_cmd_buffer_add_private_obj(struct v3dv_cmd_buffer *cmd_buffer,
|
2020-05-14 08:23:40 +01:00
|
|
|
uint64_t obj,
|
2020-04-29 08:13:00 +01:00
|
|
|
v3dv_cmd_buffer_private_obj_destroy_cb destroy_cb);
|
|
|
|
|
2022-06-13 09:35:12 +01:00
|
|
|
void v3dv_cmd_buffer_merge_barrier_state(struct v3dv_barrier_state *dst,
|
|
|
|
struct v3dv_barrier_state *src);
|
|
|
|
|
2023-02-07 12:06:48 +00:00
|
|
|
void v3dv_cmd_buffer_consume_bcl_sync(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
struct v3dv_job *job);
|
|
|
|
|
2022-07-22 08:41:47 +01:00
|
|
|
bool v3dv_cmd_buffer_check_needs_load(const struct v3dv_cmd_buffer_state *state,
|
|
|
|
VkImageAspectFlags aspect,
|
|
|
|
uint32_t first_subpass_idx,
|
2022-09-13 07:52:58 +01:00
|
|
|
VkAttachmentLoadOp load_op,
|
|
|
|
uint32_t last_subpass_idx,
|
|
|
|
VkAttachmentStoreOp store_op);
|
2022-07-22 08:41:47 +01:00
|
|
|
|
|
|
|
bool v3dv_cmd_buffer_check_needs_store(const struct v3dv_cmd_buffer_state *state,
|
|
|
|
VkImageAspectFlags aspect,
|
|
|
|
uint32_t last_subpass_idx,
|
|
|
|
VkAttachmentStoreOp store_op);
|
|
|
|
|
2022-11-03 08:14:51 +00:00
|
|
|
void v3dv_cmd_buffer_emit_pipeline_barrier(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
const VkDependencyInfoKHR *info);
|
|
|
|
|
2020-02-26 08:36:27 +00:00
|
|
|
struct v3dv_event {
|
2020-11-12 15:30:41 +00:00
|
|
|
struct vk_object_base base;
|
2022-10-19 08:48:19 +01:00
|
|
|
|
2022-11-29 09:52:33 +00:00
|
|
|
/* Link in the device list of pre-allocated free events */
|
|
|
|
struct list_head link;
|
|
|
|
|
2022-10-19 08:48:19 +01:00
|
|
|
/* Each event gets a different index, which we use to compute the offset
|
|
|
|
* in the BO we use to track their state (signaled vs reset).
|
|
|
|
*/
|
|
|
|
uint32_t index;
|
2020-02-26 08:36:27 +00:00
|
|
|
};
|
|
|
|
|
2022-11-02 07:51:23 +00:00
|
|
|
VkResult
|
2022-10-28 10:05:39 +01:00
|
|
|
v3dv_event_allocate_resources(struct v3dv_device *device);
|
|
|
|
|
|
|
|
void
|
|
|
|
v3dv_event_free_resources(struct v3dv_device *device);
|
|
|
|
|
2020-03-24 11:18:10 +00:00
|
|
|
struct v3dv_shader_variant {
|
2021-05-23 22:08:07 +01:00
|
|
|
enum broadcom_shader_stage stage;
|
2020-07-16 11:41:11 +01:00
|
|
|
|
2020-03-24 11:18:10 +00:00
|
|
|
union {
|
|
|
|
struct v3d_prog_data *base;
|
|
|
|
struct v3d_vs_prog_data *vs;
|
2021-06-30 09:43:54 +01:00
|
|
|
struct v3d_gs_prog_data *gs;
|
2020-03-24 11:18:10 +00:00
|
|
|
struct v3d_fs_prog_data *fs;
|
2020-06-18 10:06:00 +01:00
|
|
|
struct v3d_compute_prog_data *cs;
|
2020-03-24 11:18:10 +00:00
|
|
|
} prog_data;
|
|
|
|
|
2020-07-16 11:41:11 +01:00
|
|
|
/* We explicitly save the prog_data_size as it would make easier to
|
|
|
|
* serialize
|
|
|
|
*/
|
|
|
|
uint32_t prog_data_size;
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 00:05:54 +00:00
|
|
|
|
|
|
|
/* The assembly for this variant will be uploaded to a BO shared with all
|
|
|
|
* other shader stages in that pipeline. This is the offset in that BO.
|
2020-03-24 11:18:10 +00:00
|
|
|
*/
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 00:05:54 +00:00
|
|
|
uint32_t assembly_offset;
|
|
|
|
|
2022-09-30 12:32:41 +01:00
|
|
|
/* Note: don't assume qpu_insts to be always NULL or not-NULL. In general
|
|
|
|
* we will try to free it as soon as we upload it to the shared bo while we
|
|
|
|
* compile the different stages. But we can decide to keep it around based
|
|
|
|
* on some pipeline creation flags, like
|
|
|
|
* VK_PIPELINE_CREATE_CAPTURE_INTERNAL_REPRESENTATIONS_BIT.
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 00:05:54 +00:00
|
|
|
*/
|
|
|
|
uint64_t *qpu_insts;
|
2020-07-16 11:41:11 +01:00
|
|
|
uint32_t qpu_insts_size;
|
2020-03-24 11:18:10 +00:00
|
|
|
};
|
|
|
|
|
2019-12-02 12:59:04 +00:00
|
|
|
/*
|
2019-12-30 12:01:44 +00:00
|
|
|
* Per-stage info for each stage, useful so shader_module_compile_to_nir and
|
|
|
|
* other methods doesn't have so many parameters.
|
2019-12-02 12:59:04 +00:00
|
|
|
*
|
|
|
|
* FIXME: for the case of the coordinate shader and the vertex shader, module,
|
|
|
|
* entrypoint, spec_info and nir are the same. There are also info only
|
|
|
|
* relevant to some stages. But seemed too much a hassle to create a new
|
|
|
|
* struct only to handle that. Revisit if such kind of info starts to grow.
|
|
|
|
*/
|
|
|
|
struct v3dv_pipeline_stage {
|
|
|
|
struct v3dv_pipeline *pipeline;
|
|
|
|
|
2021-05-23 22:08:07 +01:00
|
|
|
enum broadcom_shader_stage stage;
|
2019-12-02 12:59:04 +00:00
|
|
|
|
2021-03-10 22:50:00 +00:00
|
|
|
const struct vk_shader_module *module;
|
2019-12-02 12:59:04 +00:00
|
|
|
const char *entrypoint;
|
|
|
|
const VkSpecializationInfo *spec_info;
|
|
|
|
|
|
|
|
nir_shader *nir;
|
|
|
|
|
2020-07-07 14:56:44 +01:00
|
|
|
/* The following is the combined hash of module+entrypoint+spec_info+nir */
|
|
|
|
unsigned char shader_sha1[20];
|
|
|
|
|
2019-12-02 12:59:04 +00:00
|
|
|
/** A name for this program, so you can track it in shader-db output. */
|
|
|
|
uint32_t program_id;
|
2021-08-02 23:13:25 +01:00
|
|
|
|
2022-07-01 13:04:28 +01:00
|
|
|
VkPipelineCreationFeedback feedback;
|
2022-09-27 12:02:45 +01:00
|
|
|
|
|
|
|
struct vk_pipeline_robustness_state robustness;
|
2019-12-02 12:59:04 +00:00
|
|
|
};
|
|
|
|
|
v3dv/descriptor: add general bo on descriptor pool
So far we were saving all the descriptor info on the host memory. With
this commit we do the equivalent that other mesa vulkan drivers (Anvil
and Turnip) and create a bo on the descriptor pool that would be
suballocated for each descriptor.
This would allow to clean up individual bos from some vulkan objects,
reducing device memory fragmentation, and allowing to avoid to alloc
bos for that info. After all, pre-allocating needed memory is one of
the purposes of the descriptor pool.
This commit introduces all the infrastructure, but doesn't use it for
any descriptor yet, as if no descriptor needed data uploaded to a bo.
The idea to decide which info goes to the descriptor pool bo is info
that we would need to upload to a bo in any case, as it is referenced
as an address by any packet.
We could be more aggressive with that general rule, but that would be
enough for now. If in the future we support
VK_EXT_descriptor_indexing, we probably would need to store more info,
as under that extension, descriptors can be updated after being bound.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-06-03 00:10:01 +01:00
|
|
|
/* We are using the descriptor pool entry for two things:
|
|
|
|
* * Track the allocated sets, so we can properly free it if needed
|
|
|
|
* * Track the suballocated pool bo regions, so if some descriptor set is
|
|
|
|
* freed, the gap could be reallocated later.
|
|
|
|
*
|
|
|
|
* Those only make sense if the pool was not created with the flag
|
|
|
|
* VK_DESCRIPTOR_POOL_CREATE_FREE_DESCRIPTOR_SET_BIT
|
|
|
|
*/
|
v3dv: initial descriptor set support
Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.
This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.
Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.
We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).
Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-01-20 14:29:38 +00:00
|
|
|
struct v3dv_descriptor_pool_entry
|
|
|
|
{
|
|
|
|
struct v3dv_descriptor_set *set;
|
v3dv/descriptor: add general bo on descriptor pool
So far we were saving all the descriptor info on the host memory. With
this commit we do the equivalent that other mesa vulkan drivers (Anvil
and Turnip) and create a bo on the descriptor pool that would be
suballocated for each descriptor.
This would allow to clean up individual bos from some vulkan objects,
reducing device memory fragmentation, and allowing to avoid to alloc
bos for that info. After all, pre-allocating needed memory is one of
the purposes of the descriptor pool.
This commit introduces all the infrastructure, but doesn't use it for
any descriptor yet, as if no descriptor needed data uploaded to a bo.
The idea to decide which info goes to the descriptor pool bo is info
that we would need to upload to a bo in any case, as it is referenced
as an address by any packet.
We could be more aggressive with that general rule, but that would be
enough for now. If in the future we support
VK_EXT_descriptor_indexing, we probably would need to store more info,
as under that extension, descriptors can be updated after being bound.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-06-03 00:10:01 +01:00
|
|
|
/* Offset and size of the subregion allocated for this entry from the
|
|
|
|
* pool->bo
|
|
|
|
*/
|
|
|
|
uint32_t offset;
|
|
|
|
uint32_t size;
|
v3dv: initial descriptor set support
Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.
This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.
Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.
We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).
Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-01-20 14:29:38 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct v3dv_descriptor_pool {
|
2020-11-12 15:30:41 +00:00
|
|
|
struct vk_object_base base;
|
|
|
|
|
2022-10-27 09:03:14 +01:00
|
|
|
/* A list with all descriptor sets allocated from the pool. */
|
|
|
|
struct list_head set_list;
|
|
|
|
|
2020-12-01 10:52:28 +00:00
|
|
|
/* If this descriptor pool has been allocated for the driver for internal
|
|
|
|
* use, typically to implement meta operations.
|
|
|
|
*/
|
|
|
|
bool is_driver_internal;
|
|
|
|
|
v3dv/descriptor: add general bo on descriptor pool
So far we were saving all the descriptor info on the host memory. With
this commit we do the equivalent that other mesa vulkan drivers (Anvil
and Turnip) and create a bo on the descriptor pool that would be
suballocated for each descriptor.
This would allow to clean up individual bos from some vulkan objects,
reducing device memory fragmentation, and allowing to avoid to alloc
bos for that info. After all, pre-allocating needed memory is one of
the purposes of the descriptor pool.
This commit introduces all the infrastructure, but doesn't use it for
any descriptor yet, as if no descriptor needed data uploaded to a bo.
The idea to decide which info goes to the descriptor pool bo is info
that we would need to upload to a bo in any case, as it is referenced
as an address by any packet.
We could be more aggressive with that general rule, but that would be
enough for now. If in the future we support
VK_EXT_descriptor_indexing, we probably would need to store more info,
as under that extension, descriptors can be updated after being bound.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-06-03 00:10:01 +01:00
|
|
|
struct v3dv_bo *bo;
|
|
|
|
/* Current offset at the descriptor bo. 0 means that we didn't use it for
|
|
|
|
* any descriptor. If the descriptor bo is NULL, current offset is
|
|
|
|
* meaningless
|
|
|
|
*/
|
|
|
|
uint32_t current_offset;
|
|
|
|
|
|
|
|
/* If VK_DESCRIPTOR_POOL_CREATE_FREE_DESCRIPTOR_SET_BIT is not set the
|
|
|
|
* descriptor sets are handled as a whole as pool memory and handled by the
|
|
|
|
* following pointers. If set, they are not used, and individually
|
|
|
|
* descriptor sets are allocated/freed.
|
|
|
|
*/
|
v3dv: initial descriptor set support
Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.
This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.
Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.
We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).
Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-01-20 14:29:38 +00:00
|
|
|
uint8_t *host_memory_base;
|
|
|
|
uint8_t *host_memory_ptr;
|
|
|
|
uint8_t *host_memory_end;
|
|
|
|
|
|
|
|
uint32_t entry_count;
|
|
|
|
uint32_t max_entry_count;
|
|
|
|
struct v3dv_descriptor_pool_entry entries[0];
|
|
|
|
};
|
|
|
|
|
|
|
|
struct v3dv_descriptor_set {
|
2020-11-12 15:30:41 +00:00
|
|
|
struct vk_object_base base;
|
|
|
|
|
2022-10-27 09:03:14 +01:00
|
|
|
/* List link into the list of all sets allocated from the pool */
|
|
|
|
struct list_head pool_link;
|
|
|
|
|
v3dv: initial descriptor set support
Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.
This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.
Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.
We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).
Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-01-20 14:29:38 +00:00
|
|
|
struct v3dv_descriptor_pool *pool;
|
|
|
|
|
2022-03-29 08:02:06 +01:00
|
|
|
struct v3dv_descriptor_set_layout *layout;
|
v3dv: initial descriptor set support
Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.
This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.
Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.
We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).
Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-01-20 14:29:38 +00:00
|
|
|
|
v3dv/descriptor: add general bo on descriptor pool
So far we were saving all the descriptor info on the host memory. With
this commit we do the equivalent that other mesa vulkan drivers (Anvil
and Turnip) and create a bo on the descriptor pool that would be
suballocated for each descriptor.
This would allow to clean up individual bos from some vulkan objects,
reducing device memory fragmentation, and allowing to avoid to alloc
bos for that info. After all, pre-allocating needed memory is one of
the purposes of the descriptor pool.
This commit introduces all the infrastructure, but doesn't use it for
any descriptor yet, as if no descriptor needed data uploaded to a bo.
The idea to decide which info goes to the descriptor pool bo is info
that we would need to upload to a bo in any case, as it is referenced
as an address by any packet.
We could be more aggressive with that general rule, but that would be
enough for now. If in the future we support
VK_EXT_descriptor_indexing, we probably would need to store more info,
as under that extension, descriptors can be updated after being bound.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-06-03 00:10:01 +01:00
|
|
|
/* Offset relative to the descriptor pool bo for this set */
|
|
|
|
uint32_t base_offset;
|
|
|
|
|
v3dv: initial descriptor set support
Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.
This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.
Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.
We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).
Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-01-20 14:29:38 +00:00
|
|
|
/* The descriptors below can be indexed (set/binding) using the set_layout
|
|
|
|
*/
|
|
|
|
struct v3dv_descriptor descriptors[0];
|
|
|
|
};
|
|
|
|
|
|
|
|
struct v3dv_descriptor_set_binding_layout {
|
|
|
|
VkDescriptorType type;
|
|
|
|
|
|
|
|
/* Number of array elements in this binding */
|
|
|
|
uint32_t array_size;
|
|
|
|
|
2022-11-04 21:04:49 +00:00
|
|
|
/* Index into the flattened descriptor set */
|
v3dv: initial descriptor set support
Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.
This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.
Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.
We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).
Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-01-20 14:29:38 +00:00
|
|
|
uint32_t descriptor_index;
|
2020-02-24 10:32:57 +00:00
|
|
|
|
|
|
|
uint32_t dynamic_offset_count;
|
|
|
|
uint32_t dynamic_offset_index;
|
2020-04-02 12:24:13 +01:00
|
|
|
|
v3dv/descriptor: add general bo on descriptor pool
So far we were saving all the descriptor info on the host memory. With
this commit we do the equivalent that other mesa vulkan drivers (Anvil
and Turnip) and create a bo on the descriptor pool that would be
suballocated for each descriptor.
This would allow to clean up individual bos from some vulkan objects,
reducing device memory fragmentation, and allowing to avoid to alloc
bos for that info. After all, pre-allocating needed memory is one of
the purposes of the descriptor pool.
This commit introduces all the infrastructure, but doesn't use it for
any descriptor yet, as if no descriptor needed data uploaded to a bo.
The idea to decide which info goes to the descriptor pool bo is info
that we would need to upload to a bo in any case, as it is referenced
as an address by any packet.
We could be more aggressive with that general rule, but that would be
enough for now. If in the future we support
VK_EXT_descriptor_indexing, we probably would need to store more info,
as under that extension, descriptors can be updated after being bound.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-06-03 00:10:01 +01:00
|
|
|
/* Offset into the descriptor set where this descriptor lives (final offset
|
|
|
|
* on the descriptor bo need to take into account set->base_offset)
|
|
|
|
*/
|
|
|
|
uint32_t descriptor_offset;
|
|
|
|
|
2020-04-02 12:24:13 +01:00
|
|
|
/* Offset in the v3dv_descriptor_set_layout of the immutable samplers, or 0
|
|
|
|
* if there are no immutable samplers.
|
|
|
|
*/
|
|
|
|
uint32_t immutable_samplers_offset;
|
v3dv: add support for multi-planar formats, enable YCbCr
Original patches wrote by Ella Stanforth.
Alejandro Piñeiro main changes (skipping the small fixes/typos):
* Reduced the list of supported formats to
VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and
VK_FORMAT_G8_B8R8_2PLANE_420_UNORM, that are the two only
mandatory by the spec.
* Fix format features exposed with YCbCr:
* Disallow some features not supported with YCbCr (like blitting)
* Disallow storage image support. Not clear if really useful. Even
if there are CTS tests, there is an ongoing discussion about the
possibility to remove them.
* Expose VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT, that is
mandatory for the formats supported.
* Not expose VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Some
CTS tests are failing right now, and it is not mandatory. Likely
to be revisit later.
* We are keeping VK_FORMAT_FEATURE_2_DISJOINT_BIT and
VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Even if they
are optional, it is working with the two formats that we are
exposing. Likely that will need to be refined if we start to
expose more formats.
* create_image_view: don't use hardcoded 0x70, but instead doing an
explicit bit or of VK_IMAGE_ASPECT_PLANE_0/1/2_BIT
* image_format_plane_features: keep how supported aspects and
separate stencil check is done. Even if the change introduced was
correct (not sure about that though), that change is unrelated to
this work
* write_image_descriptor: add additional checks for descriptor type,
to compute properly the offset.
* Cosmetic changes (don't use // for comments, capital letters, etc)
* Main changes coming from the review:
* Not use image aliases. All the info is already on the image
planes, and some points of the code were confusing as it was
using always a hardcoded plane 0.
* Squashed the two original main patches. YCbCr conversion was
leaking on the multi-planar support, as some support needed
info coming from the ycbcr structs.
* Not expose the extension on Android, and explicitly assert that
we expect plane_count to be 1 always.
* For a full list of review changes see MR#19950
Signed-off-by: Ella Stanforth <estanforth@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19950>
2022-07-28 09:15:43 +01:00
|
|
|
|
|
|
|
/* Descriptors for multiplanar combined image samplers are larger.
|
|
|
|
* For mutable descriptors, this is always 1.
|
|
|
|
*/
|
|
|
|
uint8_t plane_stride;
|
v3dv: initial descriptor set support
Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.
This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.
Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.
We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).
Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-01-20 14:29:38 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct v3dv_descriptor_set_layout {
|
2020-11-12 15:30:41 +00:00
|
|
|
struct vk_object_base base;
|
|
|
|
|
v3dv: initial descriptor set support
Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.
This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.
Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.
We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).
Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-01-20 14:29:38 +00:00
|
|
|
VkDescriptorSetLayoutCreateFlags flags;
|
|
|
|
|
|
|
|
/* Number of bindings in this descriptor set */
|
|
|
|
uint32_t binding_count;
|
|
|
|
|
v3dv/descriptor: add general bo on descriptor pool
So far we were saving all the descriptor info on the host memory. With
this commit we do the equivalent that other mesa vulkan drivers (Anvil
and Turnip) and create a bo on the descriptor pool that would be
suballocated for each descriptor.
This would allow to clean up individual bos from some vulkan objects,
reducing device memory fragmentation, and allowing to avoid to alloc
bos for that info. After all, pre-allocating needed memory is one of
the purposes of the descriptor pool.
This commit introduces all the infrastructure, but doesn't use it for
any descriptor yet, as if no descriptor needed data uploaded to a bo.
The idea to decide which info goes to the descriptor pool bo is info
that we would need to upload to a bo in any case, as it is referenced
as an address by any packet.
We could be more aggressive with that general rule, but that would be
enough for now. If in the future we support
VK_EXT_descriptor_indexing, we probably would need to store more info,
as under that extension, descriptors can be updated after being bound.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-06-03 00:10:01 +01:00
|
|
|
/* Total bo size needed for this descriptor set
|
|
|
|
*/
|
|
|
|
uint32_t bo_size;
|
2020-03-29 15:29:55 +01:00
|
|
|
|
v3dv: initial descriptor set support
Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.
This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.
Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.
We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).
Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-01-20 14:29:38 +00:00
|
|
|
/* Shader stages affected by this descriptor set */
|
|
|
|
uint16_t shader_stages;
|
|
|
|
|
|
|
|
/* Number of descriptors in this descriptor set */
|
|
|
|
uint32_t descriptor_count;
|
|
|
|
|
2020-02-24 10:32:57 +00:00
|
|
|
/* Number of dynamic offsets used by this descriptor set */
|
|
|
|
uint16_t dynamic_offset_count;
|
|
|
|
|
2022-03-29 08:02:06 +01:00
|
|
|
/* Descriptor set layouts can be destroyed even if they are still being
|
|
|
|
* used.
|
|
|
|
*/
|
|
|
|
uint32_t ref_cnt;
|
|
|
|
|
v3dv: initial descriptor set support
Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.
This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.
Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.
We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).
Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-01-20 14:29:38 +00:00
|
|
|
/* Bindings in this descriptor set */
|
|
|
|
struct v3dv_descriptor_set_binding_layout binding[0];
|
|
|
|
};
|
|
|
|
|
2022-03-29 08:02:06 +01:00
|
|
|
void
|
|
|
|
v3dv_descriptor_set_layout_destroy(struct v3dv_device *device,
|
|
|
|
struct v3dv_descriptor_set_layout *set_layout);
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
v3dv_descriptor_set_layout_ref(struct v3dv_descriptor_set_layout *set_layout)
|
|
|
|
{
|
|
|
|
assert(set_layout && set_layout->ref_cnt >= 1);
|
|
|
|
p_atomic_inc(&set_layout->ref_cnt);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
v3dv_descriptor_set_layout_unref(struct v3dv_device *device,
|
|
|
|
struct v3dv_descriptor_set_layout *set_layout)
|
|
|
|
{
|
|
|
|
assert(set_layout && set_layout->ref_cnt >= 1);
|
|
|
|
if (p_atomic_dec_zero(&set_layout->ref_cnt))
|
|
|
|
v3dv_descriptor_set_layout_destroy(device, set_layout);
|
|
|
|
}
|
|
|
|
|
v3dv: initial descriptor set support
Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.
This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.
Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.
We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).
Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-01-20 14:29:38 +00:00
|
|
|
struct v3dv_pipeline_layout {
|
2020-11-12 15:30:41 +00:00
|
|
|
struct vk_object_base base;
|
|
|
|
|
v3dv: initial descriptor set support
Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.
This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.
Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.
We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).
Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-01-20 14:29:38 +00:00
|
|
|
struct {
|
|
|
|
struct v3dv_descriptor_set_layout *layout;
|
|
|
|
uint32_t dynamic_offset_start;
|
|
|
|
} set[MAX_SETS];
|
|
|
|
|
|
|
|
uint32_t num_sets;
|
2020-03-04 14:38:55 +00:00
|
|
|
|
2021-01-05 08:02:13 +00:00
|
|
|
/* Shader stages that are declared to use descriptors from this layout */
|
|
|
|
uint32_t shader_stages;
|
|
|
|
|
|
|
|
uint32_t dynamic_offset_count;
|
2020-03-04 14:38:55 +00:00
|
|
|
uint32_t push_constant_size;
|
2022-05-03 11:48:10 +01:00
|
|
|
|
2022-08-25 07:23:27 +01:00
|
|
|
/* Pipeline layouts can be destroyed after creating pipelines since
|
|
|
|
* maintenance4.
|
|
|
|
*/
|
|
|
|
uint32_t ref_cnt;
|
|
|
|
|
2022-05-03 11:48:10 +01:00
|
|
|
unsigned char sha1[20];
|
v3dv: initial descriptor set support
Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.
This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.
Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.
We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).
Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-01-20 14:29:38 +00:00
|
|
|
};
|
|
|
|
|
2022-08-25 07:12:29 +01:00
|
|
|
void
|
|
|
|
v3dv_pipeline_layout_destroy(struct v3dv_device *device,
|
|
|
|
struct v3dv_pipeline_layout *layout,
|
|
|
|
const VkAllocationCallbacks *alloc);
|
|
|
|
|
2022-08-25 07:23:27 +01:00
|
|
|
static inline void
|
|
|
|
v3dv_pipeline_layout_ref(struct v3dv_pipeline_layout *layout)
|
|
|
|
{
|
|
|
|
assert(layout && layout->ref_cnt >= 1);
|
|
|
|
p_atomic_inc(&layout->ref_cnt);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
v3dv_pipeline_layout_unref(struct v3dv_device *device,
|
|
|
|
struct v3dv_pipeline_layout *layout,
|
|
|
|
const VkAllocationCallbacks *alloc)
|
|
|
|
{
|
|
|
|
assert(layout && layout->ref_cnt >= 1);
|
|
|
|
if (p_atomic_dec_zero(&layout->ref_cnt))
|
|
|
|
v3dv_pipeline_layout_destroy(device, layout, alloc);
|
|
|
|
}
|
|
|
|
|
2021-04-13 22:19:23 +01:00
|
|
|
/*
|
|
|
|
* We are using descriptor maps for ubo/ssbo and texture/samplers, so we need
|
|
|
|
* it to be big enough to include the max value for all of them.
|
|
|
|
*
|
|
|
|
* FIXME: one alternative would be to allocate the map as big as you need for
|
|
|
|
* each descriptor type. That would means more individual allocations.
|
|
|
|
*/
|
v3dv: implement VK_EXT_inline_uniform_block
Inline uniform blocks store their contents in pool memory rather
than a separate buffer, and are intended to provide a way in which
some platforms may provide more efficient access to the uniform
data, similar to push constants but with more flexible size
constraints.
We implement these in a similar way as push constants: for constant
access we copy the data in the uniform stream (using the new
QUNIFORM_UNIFORM_UBO_*) enums to identify the inline buffer from
which we need to copy and for indirect access we fallback to
regular UBO access.
Because at NIR level there is no distinction between inline and
regular UBOs and the compiler isn't aware of Vulkan descriptor
sets, we use the UBO index on UBO load intrinsics to identify
inline UBOs, just like we do for push constants. Particularly,
we reserve indices 1..MAX_INLINE_UNIFORM_BUFFERS for this,
however, unlike push constants, inline buffers are accessed
through descriptor sets, and therefore we need to make sure
they are located in the first slots of the UBO descriptor map.
This means we store them in the first MAX_INLINE_UNIFORM_BUFFERS
slots of the map, with regular UBOs always coming after these
slots.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15575>
2022-03-24 09:05:17 +00:00
|
|
|
#define DESCRIPTOR_MAP_SIZE MAX3(V3D_MAX_TEXTURE_SAMPLERS, \
|
|
|
|
MAX_UNIFORM_BUFFERS + MAX_INLINE_UNIFORM_BUFFERS, \
|
2021-04-13 22:19:23 +01:00
|
|
|
MAX_STORAGE_BUFFERS)
|
|
|
|
|
|
|
|
|
v3dv: initial descriptor set support
Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.
This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.
Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.
We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).
Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-01-20 14:29:38 +00:00
|
|
|
struct v3dv_descriptor_map {
|
2022-10-21 13:14:41 +01:00
|
|
|
/* FIXME: avoid fixed size array/justify the size */
|
v3dv/descriptor_set: support for array of ubo/ssbo
For that we include the array_index when asking for a ubo/ssbo index
from the descriptor_map.
Until now, array_index was not included, but the descriptor_map took
into account the array_size. This had the advantage that you only need
a entry on the descriptor map, and the index was properly return.
But this make it complex to get back the set, binding and array_index
back from the ubo/ssbo binding. So it was more easy to just add
array_index. Somehow now the "key" on the descriptor map is the
combination of (set, binding, array_index).
Note that this also make sense as the vulkan api identifies each array
index as a descriptor, so for example, from spec,
VkDescriptorSetLayoutBinding:descriptorCount
"descriptorCount is the number of descriptors contained in the
binding, accessed in a shader as an array"
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-13 21:22:18 +00:00
|
|
|
unsigned num_desc; /* Number of descriptors */
|
2021-04-13 22:19:23 +01:00
|
|
|
int set[DESCRIPTOR_MAP_SIZE];
|
|
|
|
int binding[DESCRIPTOR_MAP_SIZE];
|
|
|
|
int array_index[DESCRIPTOR_MAP_SIZE];
|
|
|
|
int array_size[DESCRIPTOR_MAP_SIZE];
|
v3dv: add support for multi-planar formats, enable YCbCr
Original patches wrote by Ella Stanforth.
Alejandro Piñeiro main changes (skipping the small fixes/typos):
* Reduced the list of supported formats to
VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and
VK_FORMAT_G8_B8R8_2PLANE_420_UNORM, that are the two only
mandatory by the spec.
* Fix format features exposed with YCbCr:
* Disallow some features not supported with YCbCr (like blitting)
* Disallow storage image support. Not clear if really useful. Even
if there are CTS tests, there is an ongoing discussion about the
possibility to remove them.
* Expose VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT, that is
mandatory for the formats supported.
* Not expose VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Some
CTS tests are failing right now, and it is not mandatory. Likely
to be revisit later.
* We are keeping VK_FORMAT_FEATURE_2_DISJOINT_BIT and
VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Even if they
are optional, it is working with the two formats that we are
exposing. Likely that will need to be refined if we start to
expose more formats.
* create_image_view: don't use hardcoded 0x70, but instead doing an
explicit bit or of VK_IMAGE_ASPECT_PLANE_0/1/2_BIT
* image_format_plane_features: keep how supported aspects and
separate stencil check is done. Even if the change introduced was
correct (not sure about that though), that change is unrelated to
this work
* write_image_descriptor: add additional checks for descriptor type,
to compute properly the offset.
* Cosmetic changes (don't use // for comments, capital letters, etc)
* Main changes coming from the review:
* Not use image aliases. All the info is already on the image
planes, and some points of the code were confusing as it was
using always a hardcoded plane 0.
* Squashed the two original main patches. YCbCr conversion was
leaking on the multi-planar support, as some support needed
info coming from the ycbcr structs.
* Not expose the extension on Android, and explicitly assert that
we expect plane_count to be 1 always.
* For a full list of review changes see MR#19950
Signed-off-by: Ella Stanforth <estanforth@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19950>
2022-07-28 09:15:43 +01:00
|
|
|
uint8_t plane[DESCRIPTOR_MAP_SIZE];
|
v3dv: implement VK_EXT_inline_uniform_block
Inline uniform blocks store their contents in pool memory rather
than a separate buffer, and are intended to provide a way in which
some platforms may provide more efficient access to the uniform
data, similar to push constants but with more flexible size
constraints.
We implement these in a similar way as push constants: for constant
access we copy the data in the uniform stream (using the new
QUNIFORM_UNIFORM_UBO_*) enums to identify the inline buffer from
which we need to copy and for indirect access we fallback to
regular UBO access.
Because at NIR level there is no distinction between inline and
regular UBOs and the compiler isn't aware of Vulkan descriptor
sets, we use the UBO index on UBO load intrinsics to identify
inline UBOs, just like we do for push constants. Particularly,
we reserve indices 1..MAX_INLINE_UNIFORM_BUFFERS for this,
however, unlike push constants, inline buffers are accessed
through descriptor sets, and therefore we need to make sure
they are located in the first slots of the UBO descriptor map.
This means we store them in the first MAX_INLINE_UNIFORM_BUFFERS
slots of the map, with regular UBOs always coming after these
slots.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15575>
2022-03-24 09:05:17 +00:00
|
|
|
bool used[DESCRIPTOR_MAP_SIZE];
|
2020-08-19 22:34:30 +01:00
|
|
|
|
2020-11-10 11:33:37 +00:00
|
|
|
/* NOTE: the following is only for sampler, but this is the easier place to
|
|
|
|
* put it.
|
2020-08-19 22:34:30 +01:00
|
|
|
*/
|
2021-04-13 22:19:23 +01:00
|
|
|
uint8_t return_size[DESCRIPTOR_MAP_SIZE];
|
v3dv: initial descriptor set support
Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.
This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.
Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.
We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).
Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-01-20 14:29:38 +00:00
|
|
|
};
|
|
|
|
|
2020-03-29 15:29:55 +01:00
|
|
|
struct v3dv_sampler {
|
2020-11-12 15:30:41 +00:00
|
|
|
struct vk_object_base base;
|
v3dv: add support for multi-planar formats, enable YCbCr
Original patches wrote by Ella Stanforth.
Alejandro Piñeiro main changes (skipping the small fixes/typos):
* Reduced the list of supported formats to
VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and
VK_FORMAT_G8_B8R8_2PLANE_420_UNORM, that are the two only
mandatory by the spec.
* Fix format features exposed with YCbCr:
* Disallow some features not supported with YCbCr (like blitting)
* Disallow storage image support. Not clear if really useful. Even
if there are CTS tests, there is an ongoing discussion about the
possibility to remove them.
* Expose VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT, that is
mandatory for the formats supported.
* Not expose VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Some
CTS tests are failing right now, and it is not mandatory. Likely
to be revisit later.
* We are keeping VK_FORMAT_FEATURE_2_DISJOINT_BIT and
VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Even if they
are optional, it is working with the two formats that we are
exposing. Likely that will need to be refined if we start to
expose more formats.
* create_image_view: don't use hardcoded 0x70, but instead doing an
explicit bit or of VK_IMAGE_ASPECT_PLANE_0/1/2_BIT
* image_format_plane_features: keep how supported aspects and
separate stencil check is done. Even if the change introduced was
correct (not sure about that though), that change is unrelated to
this work
* write_image_descriptor: add additional checks for descriptor type,
to compute properly the offset.
* Cosmetic changes (don't use // for comments, capital letters, etc)
* Main changes coming from the review:
* Not use image aliases. All the info is already on the image
planes, and some points of the code were confusing as it was
using always a hardcoded plane 0.
* Squashed the two original main patches. YCbCr conversion was
leaking on the multi-planar support, as some support needed
info coming from the ycbcr structs.
* Not expose the extension on Android, and explicitly assert that
we expect plane_count to be 1 always.
* For a full list of review changes see MR#19950
Signed-off-by: Ella Stanforth <estanforth@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19950>
2022-07-28 09:15:43 +01:00
|
|
|
struct vk_ycbcr_conversion *conversion;
|
2020-11-12 15:30:41 +00:00
|
|
|
|
v3dv/descriptor_set: combine texture and sampler indices
OpenGL doesn't have the concept of individual texture and sampler, so
texture and sampler indexes have the same value. v3d compiler uses
this assumption, so for example, the texture info at the v3d key
include values that you need to use the texture format and the sampler
to fill (like the return_size).
One option would be to adapt the v3d compiler to handle both, but then
we would need to adapt to the lowerings it uses, like nir_lower_tex,
that also take the same assumption.
We deal with this on the Vulkan driver, by reassigning the texture and
sampler index to a combined one. We add a hash table to map the
combined texture idx and sampler idx to this combined idx, and a
simple array to the opposite map. On the driver we work with the
separate indices to fill up the data, while the v3d compiler works
with the combined one.
As mentioned, this is needed to properly fill up the texture return
size, so as we are here, we fix that. This gets tests like the
following working:
dEQP-VK.glsl.texture_gather.basic.2d.depth32f.base_level.level_2
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-06 23:33:14 +01:00
|
|
|
bool compare_enable;
|
2020-07-01 13:21:09 +01:00
|
|
|
bool unnormalized_coordinates;
|
v3dv/descriptor_set: combine texture and sampler indices
OpenGL doesn't have the concept of individual texture and sampler, so
texture and sampler indexes have the same value. v3d compiler uses
this assumption, so for example, the texture info at the v3d key
include values that you need to use the texture format and the sampler
to fill (like the return_size).
One option would be to adapt the v3d compiler to handle both, but then
we would need to adapt to the lowerings it uses, like nir_lower_tex,
that also take the same assumption.
We deal with this on the Vulkan driver, by reassigning the texture and
sampler index to a combined one. We add a hash table to map the
combined texture idx and sampler idx to this combined idx, and a
simple array to the opposite map. On the driver we work with the
separate indices to fill up the data, while the v3d compiler works
with the combined one.
As mentioned, this is needed to properly fill up the texture return
size, so as we are here, we fix that. This gets tests like the
following working:
dEQP-VK.glsl.texture_gather.basic.2d.depth32f.base_level.level_2
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-06 23:33:14 +01:00
|
|
|
|
v3dv: add support for multi-planar formats, enable YCbCr
Original patches wrote by Ella Stanforth.
Alejandro Piñeiro main changes (skipping the small fixes/typos):
* Reduced the list of supported formats to
VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and
VK_FORMAT_G8_B8R8_2PLANE_420_UNORM, that are the two only
mandatory by the spec.
* Fix format features exposed with YCbCr:
* Disallow some features not supported with YCbCr (like blitting)
* Disallow storage image support. Not clear if really useful. Even
if there are CTS tests, there is an ongoing discussion about the
possibility to remove them.
* Expose VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT, that is
mandatory for the formats supported.
* Not expose VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Some
CTS tests are failing right now, and it is not mandatory. Likely
to be revisit later.
* We are keeping VK_FORMAT_FEATURE_2_DISJOINT_BIT and
VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Even if they
are optional, it is working with the two formats that we are
exposing. Likely that will need to be refined if we start to
expose more formats.
* create_image_view: don't use hardcoded 0x70, but instead doing an
explicit bit or of VK_IMAGE_ASPECT_PLANE_0/1/2_BIT
* image_format_plane_features: keep how supported aspects and
separate stencil check is done. Even if the change introduced was
correct (not sure about that though), that change is unrelated to
this work
* write_image_descriptor: add additional checks for descriptor type,
to compute properly the offset.
* Cosmetic changes (don't use // for comments, capital letters, etc)
* Main changes coming from the review:
* Not use image aliases. All the info is already on the image
planes, and some points of the code were confusing as it was
using always a hardcoded plane 0.
* Squashed the two original main patches. YCbCr conversion was
leaking on the multi-planar support, as some support needed
info coming from the ycbcr structs.
* Not expose the extension on Android, and explicitly assert that
we expect plane_count to be 1 always.
* For a full list of review changes see MR#19950
Signed-off-by: Ella Stanforth <estanforth@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19950>
2022-07-28 09:15:43 +01:00
|
|
|
/* Prepacked per plane SAMPLER_STATE, that is referenced as part of the tmu
|
2020-06-03 00:22:48 +01:00
|
|
|
* configuration. If needed it will be copied to the descriptor info during
|
|
|
|
* UpdateDescriptorSets
|
2020-03-29 15:29:55 +01:00
|
|
|
*/
|
v3dv: add support for multi-planar formats, enable YCbCr
Original patches wrote by Ella Stanforth.
Alejandro Piñeiro main changes (skipping the small fixes/typos):
* Reduced the list of supported formats to
VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and
VK_FORMAT_G8_B8R8_2PLANE_420_UNORM, that are the two only
mandatory by the spec.
* Fix format features exposed with YCbCr:
* Disallow some features not supported with YCbCr (like blitting)
* Disallow storage image support. Not clear if really useful. Even
if there are CTS tests, there is an ongoing discussion about the
possibility to remove them.
* Expose VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT, that is
mandatory for the formats supported.
* Not expose VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Some
CTS tests are failing right now, and it is not mandatory. Likely
to be revisit later.
* We are keeping VK_FORMAT_FEATURE_2_DISJOINT_BIT and
VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Even if they
are optional, it is working with the two formats that we are
exposing. Likely that will need to be refined if we start to
expose more formats.
* create_image_view: don't use hardcoded 0x70, but instead doing an
explicit bit or of VK_IMAGE_ASPECT_PLANE_0/1/2_BIT
* image_format_plane_features: keep how supported aspects and
separate stencil check is done. Even if the change introduced was
correct (not sure about that though), that change is unrelated to
this work
* write_image_descriptor: add additional checks for descriptor type,
to compute properly the offset.
* Cosmetic changes (don't use // for comments, capital letters, etc)
* Main changes coming from the review:
* Not use image aliases. All the info is already on the image
planes, and some points of the code were confusing as it was
using always a hardcoded plane 0.
* Squashed the two original main patches. YCbCr conversion was
leaking on the multi-planar support, as some support needed
info coming from the ycbcr structs.
* Not expose the extension on Android, and explicitly assert that
we expect plane_count to be 1 always.
* For a full list of review changes see MR#19950
Signed-off-by: Ella Stanforth <estanforth@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19950>
2022-07-28 09:15:43 +01:00
|
|
|
uint8_t plane_count;
|
2021-06-01 09:39:20 +01:00
|
|
|
uint8_t sampler_state[V3DV_SAMPLER_STATE_LENGTH];
|
2020-03-29 15:29:55 +01:00
|
|
|
};
|
|
|
|
|
2020-11-10 11:33:37 +00:00
|
|
|
/* We keep two special values for the sampler idx that represents exactly when a
|
2020-11-10 21:11:11 +00:00
|
|
|
* sampler is not needed/provided. The main use is that even if we don't have
|
|
|
|
* sampler, we still need to do the output unpacking (through
|
2020-11-10 11:33:37 +00:00
|
|
|
* nir_lower_tex). The easier way to do this is to add those special "no
|
|
|
|
* sampler" in the sampler_map, and then use the proper unpacking for that
|
2020-11-10 21:11:11 +00:00
|
|
|
* case.
|
2020-11-10 11:33:37 +00:00
|
|
|
*
|
|
|
|
* We have one when we want a 16bit output size, and other when we want a
|
|
|
|
* 32bit output size. We use the info coming from the RelaxedPrecision
|
|
|
|
* decoration to decide between one and the other.
|
2020-11-10 21:11:11 +00:00
|
|
|
*/
|
2020-11-10 11:33:37 +00:00
|
|
|
#define V3DV_NO_SAMPLER_16BIT_IDX 0
|
|
|
|
#define V3DV_NO_SAMPLER_32BIT_IDX 1
|
2020-04-11 13:50:50 +01:00
|
|
|
|
v3dv/descriptor_set: combine texture and sampler indices
OpenGL doesn't have the concept of individual texture and sampler, so
texture and sampler indexes have the same value. v3d compiler uses
this assumption, so for example, the texture info at the v3d key
include values that you need to use the texture format and the sampler
to fill (like the return_size).
One option would be to adapt the v3d compiler to handle both, but then
we would need to adapt to the lowerings it uses, like nir_lower_tex,
that also take the same assumption.
We deal with this on the Vulkan driver, by reassigning the texture and
sampler index to a combined one. We add a hash table to map the
combined texture idx and sampler idx to this combined idx, and a
simple array to the opposite map. On the driver we work with the
separate indices to fill up the data, while the v3d compiler works
with the combined one.
As mentioned, this is needed to properly fill up the texture return
size, so as we are here, we fix that. This gets tests like the
following working:
dEQP-VK.glsl.texture_gather.basic.2d.depth32f.base_level.level_2
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-06 23:33:14 +01:00
|
|
|
/*
|
|
|
|
* Following two methods are using on the combined to/from texture/sampler
|
|
|
|
* indices maps at v3dv_pipeline.
|
|
|
|
*/
|
|
|
|
static inline uint32_t
|
|
|
|
v3dv_pipeline_combined_index_key_create(uint32_t texture_index,
|
|
|
|
uint32_t sampler_index)
|
|
|
|
{
|
|
|
|
return texture_index << 24 | sampler_index;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
v3dv_pipeline_combined_index_key_unpack(uint32_t combined_index_key,
|
|
|
|
uint32_t *texture_index,
|
|
|
|
uint32_t *sampler_index)
|
|
|
|
{
|
|
|
|
uint32_t texture = combined_index_key >> 24;
|
|
|
|
uint32_t sampler = combined_index_key & 0xffffff;
|
|
|
|
|
|
|
|
if (texture_index)
|
|
|
|
*texture_index = texture;
|
|
|
|
|
|
|
|
if (sampler_index)
|
|
|
|
*sampler_index = sampler;
|
|
|
|
}
|
|
|
|
|
v3dv/pipeline: track descriptor maps per stage, not per pipeline
One of the conclusions of our recent clean up on the limits was that
the pipeline limits needed to be the per-stage limits multiplied by
the number of stages.
But until now we only have a set of descriptor maps for the full
pipeline. That would work if we could set the same limit per pipeline
that per stage, but that is not the case. So if, for example, we have
the fragment shader using V3D_MAX_TEXTURE_SAMPLERS textures, and then
the vertex shader, with a different descriptor set, using one texture,
we would get an index greater that V3D_MAX_TEXTURE_SAMPLERS. We assert
that index as an error on the vulkan backend, but fwiw, it would be
also asserted on the compiler.
With this commit we track and allocate a descriptor map per stage,
although we reuse the vertex shader descriptor map for the vertex bin.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10272>
2021-04-16 00:06:34 +01:00
|
|
|
struct v3dv_descriptor_maps {
|
|
|
|
struct v3dv_descriptor_map ubo_map;
|
|
|
|
struct v3dv_descriptor_map ssbo_map;
|
|
|
|
struct v3dv_descriptor_map sampler_map;
|
|
|
|
struct v3dv_descriptor_map texture_map;
|
|
|
|
};
|
|
|
|
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 00:05:54 +00:00
|
|
|
/* The structure represents data shared between different objects, like the
|
|
|
|
* pipeline and the pipeline cache, so we ref count it to know when it should
|
|
|
|
* be freed.
|
|
|
|
*/
|
|
|
|
struct v3dv_pipeline_shared_data {
|
|
|
|
uint32_t ref_cnt;
|
|
|
|
|
|
|
|
unsigned char sha1_key[20];
|
|
|
|
|
v3dv/pipeline: track descriptor maps per stage, not per pipeline
One of the conclusions of our recent clean up on the limits was that
the pipeline limits needed to be the per-stage limits multiplied by
the number of stages.
But until now we only have a set of descriptor maps for the full
pipeline. That would work if we could set the same limit per pipeline
that per stage, but that is not the case. So if, for example, we have
the fragment shader using V3D_MAX_TEXTURE_SAMPLERS textures, and then
the vertex shader, with a different descriptor set, using one texture,
we would get an index greater that V3D_MAX_TEXTURE_SAMPLERS. We assert
that index as an error on the vulkan backend, but fwiw, it would be
also asserted on the compiler.
With this commit we track and allocate a descriptor map per stage,
although we reuse the vertex shader descriptor map for the vertex bin.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10272>
2021-04-16 00:06:34 +01:00
|
|
|
struct v3dv_descriptor_maps *maps[BROADCOM_SHADER_STAGES];
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 00:05:54 +00:00
|
|
|
struct v3dv_shader_variant *variants[BROADCOM_SHADER_STAGES];
|
|
|
|
|
|
|
|
struct v3dv_bo *assembly_bo;
|
|
|
|
};
|
|
|
|
|
2022-05-05 11:51:05 +01:00
|
|
|
struct v3dv_pipeline_executable_data {
|
|
|
|
enum broadcom_shader_stage stage;
|
|
|
|
char *nir_str;
|
|
|
|
char *qpu_str;
|
|
|
|
};
|
|
|
|
|
2019-12-02 12:59:04 +00:00
|
|
|
struct v3dv_pipeline {
|
2020-11-12 15:30:41 +00:00
|
|
|
struct vk_object_base base;
|
|
|
|
|
2019-12-02 12:59:04 +00:00
|
|
|
struct v3dv_device *device;
|
|
|
|
|
|
|
|
VkShaderStageFlags active_stages;
|
2022-09-30 12:32:41 +01:00
|
|
|
VkPipelineCreateFlags flags;
|
2019-12-02 12:59:04 +00:00
|
|
|
|
2020-03-17 11:10:58 +00:00
|
|
|
struct v3dv_render_pass *pass;
|
2019-12-02 12:59:04 +00:00
|
|
|
struct v3dv_subpass *subpass;
|
|
|
|
|
2022-09-29 14:03:27 +01:00
|
|
|
struct v3dv_pipeline_stage *stages[BROADCOM_SHADER_STAGES];
|
2019-12-28 11:11:48 +00:00
|
|
|
|
2021-06-30 09:43:54 +01:00
|
|
|
/* Flags for whether optional pipeline stages are present, for convenience */
|
|
|
|
bool has_gs;
|
|
|
|
|
2022-06-27 13:12:25 +01:00
|
|
|
/* Whether any stage in this pipeline uses VK_KHR_buffer_device_address */
|
|
|
|
bool uses_buffer_device_address;
|
|
|
|
|
2020-06-26 11:45:09 +01:00
|
|
|
/* Spilling memory requirements */
|
|
|
|
struct {
|
|
|
|
struct v3dv_bo *bo;
|
|
|
|
uint32_t size_per_thread;
|
|
|
|
} spill;
|
|
|
|
|
2019-12-28 11:11:48 +00:00
|
|
|
struct v3dv_dynamic_state dynamic_state;
|
2020-01-05 00:51:04 +00:00
|
|
|
|
2020-02-24 10:32:57 +00:00
|
|
|
struct v3dv_pipeline_layout *layout;
|
|
|
|
|
2021-01-19 07:54:52 +00:00
|
|
|
/* Whether this pipeline enables depth writes */
|
|
|
|
bool z_updates_enable;
|
|
|
|
|
2020-02-04 09:26:04 +00:00
|
|
|
enum v3dv_ez_state ez_state;
|
|
|
|
|
2022-05-30 10:28:50 +01:00
|
|
|
/* If ez_state is V3D_EZ_DISABLED, if the reason for disabling is that the
|
|
|
|
* pipeline selects an incompatible depth test function.
|
|
|
|
*/
|
|
|
|
bool incompatible_ez_test;
|
|
|
|
|
v3dv: handle multisample rasterization with empty framebuffers
If the framebuffer has no attachments then multisample rasterization
is enabled based on the rasterizationSamples multisample state of
the pipelines. It should be noted that since we don't support
the variableMultisampleRate feature, all pipelines in the same
subpass must have matching number of samples.
V3D requires that we specifically setup our frames to enable
multisampling or not, and we do this when we create jobs inside
a subpass. Since we create the first job for a subpass as soon as
the subpas starts, this is problematic: if we don't have any
attachments, we don't won't enable MSAA at this point, but later
on we might bind an MSAA pipeline, since pipelines can be bound
at any point in the lifespan of a command buffer.
Here, we fix this by testing if the first draw call in a job uses
an MSAA pipeline but the job the was setup to not use MSAA, and in
that case we re-start the job with MSAA enabled.
We also take care of a corner case that seems to be tested by CTS
where a framebuffer with no attachments doesn't bind any pipelines
with MSAA enabled (so according to the Vulkan spec, multisample
rasterization must be disabled) but the fragment shader in use
reads gl_SampleID (which enables per-sample shading). This would
lead to enabling per-sample shading with single-sample rasterization,
which doesn't make sense and makes the simulator complain, so we just
disable per-sample shading in that case.
Fixes:
dEQP-VK.pipeline.multisample.mixed_count.*
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-08-04 12:11:10 +01:00
|
|
|
bool msaa;
|
2020-07-30 08:00:07 +01:00
|
|
|
bool sample_rate_shading;
|
2020-07-24 09:42:43 +01:00
|
|
|
uint32_t sample_mask;
|
|
|
|
|
2020-02-18 10:08:44 +00:00
|
|
|
bool primitive_restart;
|
2022-09-02 07:49:12 +01:00
|
|
|
bool negative_one_to_one;
|
2020-02-18 10:08:44 +00:00
|
|
|
|
2020-07-31 00:11:39 +01:00
|
|
|
/* Accessed by binding. So vb[binding]->stride is the stride of the vertex
|
|
|
|
* array with such binding
|
|
|
|
*/
|
|
|
|
struct v3dv_pipeline_vertex_binding {
|
|
|
|
uint32_t stride;
|
|
|
|
uint32_t instance_divisor;
|
|
|
|
} vb[MAX_VBS];
|
|
|
|
uint32_t vb_count;
|
|
|
|
|
|
|
|
/* Note that a lot of info from VkVertexInputAttributeDescription is
|
2020-07-07 07:22:31 +01:00
|
|
|
* already prepacked, so here we are only storing those that need recheck
|
|
|
|
* later. The array must be indexed by driver location, since that is the
|
|
|
|
* order in which we need to emit the attributes.
|
2020-07-31 00:11:39 +01:00
|
|
|
*/
|
|
|
|
struct v3dv_pipeline_vertex_attrib {
|
|
|
|
uint32_t binding;
|
|
|
|
uint32_t offset;
|
2020-01-14 15:17:09 +00:00
|
|
|
VkFormat vk_format;
|
2020-07-31 00:11:39 +01:00
|
|
|
} va[MAX_VERTEX_ATTRIBS];
|
|
|
|
uint32_t va_count;
|
|
|
|
|
2021-03-10 13:23:33 +00:00
|
|
|
enum pipe_prim_type topology;
|
|
|
|
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 00:05:54 +00:00
|
|
|
struct v3dv_pipeline_shared_data *shared_data;
|
2020-03-10 11:34:00 +00:00
|
|
|
|
2022-05-03 11:48:10 +01:00
|
|
|
/* It is the combined stages sha1, layout sha1, plus the pipeline key sha1. */
|
2021-11-22 23:46:48 +00:00
|
|
|
unsigned char sha1[20];
|
|
|
|
|
v3dv: define a default attribute values with float type
We are providing a BO with the default attribute values for the
GL_SHADER_STATE_RECORD, that contains 16 vec4. Such default value for
each vec4 is (0, 0, 0, 1). As the attribute format could be int or
float, the "1" value needs to take into account the attribute format.
But in the practice, the most common case is all floats. So we create
one default attribute values BO assuming that all attributes will be
floats, and we store it at v3dv_device and only create a new one if a
int format type is defined. That allows to reduce the amount of BOs
needed.
Note that we could still try to reduce the amount of BOs used by the
pipelines if we create a bigger BO, and we just play with the
offsets. But as mentioned, that's not the usual, and would add an
extra complexity,so it is not a priority right now.
This makes the following test passing when disabling the pipeline
cache support:
dEQP-VK.api.object_management.max_concurrent.graphics_pipeline
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9845>
2021-03-25 12:30:55 +00:00
|
|
|
/* In general we can reuse v3dv_device->default_attribute_float, so note
|
|
|
|
* that the following can be NULL.
|
|
|
|
*
|
|
|
|
* FIXME: the content of this BO will be small, so it could be improved to
|
|
|
|
* be uploaded to a common BO. But as in most cases it will be NULL, it is
|
|
|
|
* not a priority.
|
2020-01-14 15:17:09 +00:00
|
|
|
*/
|
|
|
|
struct v3dv_bo *default_attribute_values;
|
|
|
|
|
2020-01-09 12:54:22 +00:00
|
|
|
struct vpm_config vpm_cfg;
|
|
|
|
struct vpm_config vpm_cfg_bin;
|
2020-01-29 15:35:39 +00:00
|
|
|
|
|
|
|
/* If the pipeline should emit any of the stencil configuration packets */
|
|
|
|
bool emit_stencil_cfg[2];
|
|
|
|
|
2020-03-17 11:10:58 +00:00
|
|
|
/* Blend state */
|
|
|
|
struct {
|
|
|
|
/* Per-RT bit mask with blend enables */
|
|
|
|
uint8_t enables;
|
|
|
|
/* Per-RT prepacked blend config packets */
|
2021-06-01 09:39:20 +01:00
|
|
|
uint8_t cfg[V3D_MAX_DRAW_BUFFERS][V3DV_BLEND_CFG_LENGTH];
|
2020-03-17 11:10:58 +00:00
|
|
|
/* Flag indicating whether the blend factors in use require
|
|
|
|
* color constants.
|
|
|
|
*/
|
|
|
|
bool needs_color_constants;
|
|
|
|
/* Mask with enabled color channels for each RT (4 bits per RT) */
|
|
|
|
uint32_t color_write_masks;
|
|
|
|
} blend;
|
|
|
|
|
2020-05-13 09:35:30 +01:00
|
|
|
/* Depth bias */
|
|
|
|
struct {
|
|
|
|
bool enabled;
|
|
|
|
bool is_z16;
|
|
|
|
} depth_bias;
|
|
|
|
|
2022-05-05 11:51:05 +01:00
|
|
|
struct {
|
|
|
|
void *mem_ctx;
|
|
|
|
struct util_dynarray data; /* Array of v3dv_pipeline_executable_data */
|
|
|
|
} executables;
|
|
|
|
|
2020-01-05 00:51:04 +00:00
|
|
|
/* Packets prepacked during pipeline creation
|
|
|
|
*/
|
2021-06-01 09:39:20 +01:00
|
|
|
uint8_t cfg_bits[V3DV_CFG_BITS_LENGTH];
|
|
|
|
uint8_t shader_state_record[V3DV_GL_SHADER_STATE_RECORD_LENGTH];
|
|
|
|
uint8_t vcm_cache_size[V3DV_VCM_CACHE_SIZE_LENGTH];
|
|
|
|
uint8_t vertex_attrs[V3DV_GL_SHADER_STATE_ATTRIBUTE_RECORD_LENGTH *
|
2020-03-06 11:21:34 +00:00
|
|
|
MAX_VERTEX_ATTRIBS];
|
2021-06-01 09:39:20 +01:00
|
|
|
uint8_t stencil_cfg[2][V3DV_STENCIL_CFG_LENGTH];
|
2019-12-02 12:59:04 +00:00
|
|
|
};
|
|
|
|
|
2020-06-18 11:14:58 +01:00
|
|
|
static inline VkPipelineBindPoint
|
|
|
|
v3dv_pipeline_get_binding_point(struct v3dv_pipeline *pipeline)
|
|
|
|
{
|
|
|
|
assert(pipeline->active_stages == VK_SHADER_STAGE_COMPUTE_BIT ||
|
|
|
|
!(pipeline->active_stages & VK_SHADER_STAGE_COMPUTE_BIT));
|
|
|
|
return pipeline->active_stages == VK_SHADER_STAGE_COMPUTE_BIT ?
|
|
|
|
VK_PIPELINE_BIND_POINT_COMPUTE : VK_PIPELINE_BIND_POINT_GRAPHICS;
|
|
|
|
}
|
|
|
|
|
2021-01-15 22:07:45 +00:00
|
|
|
static inline struct v3dv_descriptor_state*
|
|
|
|
v3dv_cmd_buffer_get_descriptor_state(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
struct v3dv_pipeline *pipeline)
|
|
|
|
{
|
|
|
|
if (v3dv_pipeline_get_binding_point(pipeline) == VK_PIPELINE_BIND_POINT_COMPUTE)
|
|
|
|
return &cmd_buffer->state.compute.descriptor_state;
|
|
|
|
else
|
|
|
|
return &cmd_buffer->state.gfx.descriptor_state;
|
|
|
|
}
|
|
|
|
|
2020-03-31 11:59:44 +01:00
|
|
|
const nir_shader_compiler_options *v3dv_pipeline_get_nir_options(void);
|
|
|
|
|
2020-07-04 00:32:11 +01:00
|
|
|
uint32_t v3dv_physical_device_vendor_id(struct v3dv_physical_device *dev);
|
|
|
|
uint32_t v3dv_physical_device_device_id(struct v3dv_physical_device *dev);
|
2019-11-25 15:29:12 +00:00
|
|
|
|
2020-01-15 07:48:07 +00:00
|
|
|
#define v3dv_debug_ignored_stype(sType) \
|
2022-01-12 12:16:18 +00:00
|
|
|
mesa_logd("%s: ignored VkStructureType %u:%s\n\n", __func__, (sType), vk_StructureType_to_str(sType))
|
2020-01-15 07:48:07 +00:00
|
|
|
|
v3dv: add support for multi-planar formats, enable YCbCr
Original patches wrote by Ella Stanforth.
Alejandro Piñeiro main changes (skipping the small fixes/typos):
* Reduced the list of supported formats to
VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and
VK_FORMAT_G8_B8R8_2PLANE_420_UNORM, that are the two only
mandatory by the spec.
* Fix format features exposed with YCbCr:
* Disallow some features not supported with YCbCr (like blitting)
* Disallow storage image support. Not clear if really useful. Even
if there are CTS tests, there is an ongoing discussion about the
possibility to remove them.
* Expose VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT, that is
mandatory for the formats supported.
* Not expose VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Some
CTS tests are failing right now, and it is not mandatory. Likely
to be revisit later.
* We are keeping VK_FORMAT_FEATURE_2_DISJOINT_BIT and
VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT. Even if they
are optional, it is working with the two formats that we are
exposing. Likely that will need to be refined if we start to
expose more formats.
* create_image_view: don't use hardcoded 0x70, but instead doing an
explicit bit or of VK_IMAGE_ASPECT_PLANE_0/1/2_BIT
* image_format_plane_features: keep how supported aspects and
separate stencil check is done. Even if the change introduced was
correct (not sure about that though), that change is unrelated to
this work
* write_image_descriptor: add additional checks for descriptor type,
to compute properly the offset.
* Cosmetic changes (don't use // for comments, capital letters, etc)
* Main changes coming from the review:
* Not use image aliases. All the info is already on the image
planes, and some points of the code were confusing as it was
using always a hardcoded plane 0.
* Squashed the two original main patches. YCbCr conversion was
leaking on the multi-planar support, as some support needed
info coming from the ycbcr structs.
* Not expose the extension on Android, and explicitly assert that
we expect plane_count to be 1 always.
* For a full list of review changes see MR#19950
Signed-off-by: Ella Stanforth <estanforth@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19950>
2022-07-28 09:15:43 +01:00
|
|
|
const uint8_t *v3dv_get_format_swizzle(struct v3dv_device *device, VkFormat f,
|
|
|
|
uint8_t plane);
|
2020-12-01 09:12:54 +00:00
|
|
|
const struct v3dv_format *
|
2021-06-14 10:35:06 +01:00
|
|
|
v3dv_get_compatible_tfu_format(struct v3dv_device *device,
|
2020-12-01 09:12:54 +00:00
|
|
|
uint32_t bpp, VkFormat *out_vk_format);
|
2021-06-14 10:35:06 +01:00
|
|
|
bool v3dv_buffer_format_supports_features(struct v3dv_device *device,
|
|
|
|
VkFormat vk_format,
|
2022-07-01 13:04:28 +01:00
|
|
|
VkFormatFeatureFlags2 features);
|
2019-12-03 11:54:30 +00:00
|
|
|
|
2020-01-03 11:43:35 +00:00
|
|
|
struct v3dv_cl_reloc v3dv_write_uniforms(struct v3dv_cmd_buffer *cmd_buffer,
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 00:05:54 +00:00
|
|
|
struct v3dv_pipeline *pipeline,
|
|
|
|
struct v3dv_shader_variant *variant);
|
|
|
|
|
2020-06-19 10:56:20 +01:00
|
|
|
struct v3dv_cl_reloc v3dv_write_uniforms_wg_offsets(struct v3dv_cmd_buffer *cmd_buffer,
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 00:05:54 +00:00
|
|
|
struct v3dv_pipeline *pipeline,
|
|
|
|
struct v3dv_shader_variant *variant,
|
2020-06-19 10:56:20 +01:00
|
|
|
uint32_t **wg_count_offsets);
|
2020-01-03 11:43:35 +00:00
|
|
|
|
2020-03-25 10:50:16 +00:00
|
|
|
struct v3dv_shader_variant *
|
|
|
|
v3dv_get_shader_variant(struct v3dv_pipeline_stage *p_stage,
|
2020-07-16 11:41:11 +01:00
|
|
|
struct v3dv_pipeline_cache *cache,
|
2020-03-25 10:50:16 +00:00
|
|
|
struct v3d_key *key,
|
2020-04-29 14:58:10 +01:00
|
|
|
size_t key_size,
|
|
|
|
const VkAllocationCallbacks *pAllocator,
|
|
|
|
VkResult *out_vk_result);
|
2020-03-25 10:50:16 +00:00
|
|
|
|
2020-07-16 11:41:11 +01:00
|
|
|
struct v3dv_shader_variant *
|
|
|
|
v3dv_shader_variant_create(struct v3dv_device *device,
|
2021-05-23 22:08:07 +01:00
|
|
|
enum broadcom_shader_stage stage,
|
2020-07-16 11:41:11 +01:00
|
|
|
struct v3d_prog_data *prog_data,
|
|
|
|
uint32_t prog_data_size,
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 00:05:54 +00:00
|
|
|
uint32_t assembly_offset,
|
|
|
|
uint64_t *qpu_insts,
|
2020-07-16 11:41:11 +01:00
|
|
|
uint32_t qpu_insts_size,
|
|
|
|
VkResult *out_vk_result);
|
|
|
|
|
2020-07-18 01:40:00 +01:00
|
|
|
void
|
|
|
|
v3dv_shader_variant_destroy(struct v3dv_device *device,
|
|
|
|
struct v3dv_shader_variant *variant);
|
|
|
|
|
|
|
|
static inline void
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 00:05:54 +00:00
|
|
|
v3dv_pipeline_shared_data_ref(struct v3dv_pipeline_shared_data *shared_data)
|
2020-07-18 01:40:00 +01:00
|
|
|
{
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 00:05:54 +00:00
|
|
|
assert(shared_data && shared_data->ref_cnt >= 1);
|
|
|
|
p_atomic_inc(&shared_data->ref_cnt);
|
2020-07-18 01:40:00 +01:00
|
|
|
}
|
|
|
|
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 00:05:54 +00:00
|
|
|
void
|
|
|
|
v3dv_pipeline_shared_data_destroy(struct v3dv_device *device,
|
|
|
|
struct v3dv_pipeline_shared_data *shared_data);
|
|
|
|
|
2020-07-18 01:40:00 +01:00
|
|
|
static inline void
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 00:05:54 +00:00
|
|
|
v3dv_pipeline_shared_data_unref(struct v3dv_device *device,
|
|
|
|
struct v3dv_pipeline_shared_data *shared_data)
|
2020-07-18 01:40:00 +01:00
|
|
|
{
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 00:05:54 +00:00
|
|
|
assert(shared_data && shared_data->ref_cnt >= 1);
|
|
|
|
if (p_atomic_dec_zero(&shared_data->ref_cnt))
|
|
|
|
v3dv_pipeline_shared_data_destroy(device, shared_data);
|
2020-07-18 01:40:00 +01:00
|
|
|
}
|
|
|
|
|
2020-03-25 10:50:16 +00:00
|
|
|
struct v3dv_descriptor *
|
|
|
|
v3dv_descriptor_map_get_descriptor(struct v3dv_descriptor_state *descriptor_state,
|
|
|
|
struct v3dv_descriptor_map *map,
|
|
|
|
struct v3dv_pipeline_layout *pipeline_layout,
|
|
|
|
uint32_t index,
|
|
|
|
uint32_t *dynamic_offset);
|
|
|
|
|
v3dv: implement VK_EXT_inline_uniform_block
Inline uniform blocks store their contents in pool memory rather
than a separate buffer, and are intended to provide a way in which
some platforms may provide more efficient access to the uniform
data, similar to push constants but with more flexible size
constraints.
We implement these in a similar way as push constants: for constant
access we copy the data in the uniform stream (using the new
QUNIFORM_UNIFORM_UBO_*) enums to identify the inline buffer from
which we need to copy and for indirect access we fallback to
regular UBO access.
Because at NIR level there is no distinction between inline and
regular UBOs and the compiler isn't aware of Vulkan descriptor
sets, we use the UBO index on UBO load intrinsics to identify
inline UBOs, just like we do for push constants. Particularly,
we reserve indices 1..MAX_INLINE_UNIFORM_BUFFERS for this,
however, unlike push constants, inline buffers are accessed
through descriptor sets, and therefore we need to make sure
they are located in the first slots of the UBO descriptor map.
This means we store them in the first MAX_INLINE_UNIFORM_BUFFERS
slots of the map, with regular UBOs always coming after these
slots.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15575>
2022-03-24 09:05:17 +00:00
|
|
|
struct v3dv_cl_reloc
|
|
|
|
v3dv_descriptor_map_get_descriptor_bo(struct v3dv_device *device,
|
|
|
|
struct v3dv_descriptor_state *descriptor_state,
|
|
|
|
struct v3dv_descriptor_map *map,
|
|
|
|
struct v3dv_pipeline_layout *pipeline_layout,
|
|
|
|
uint32_t index,
|
|
|
|
VkDescriptorType *out_type);
|
|
|
|
|
2020-04-06 23:32:49 +01:00
|
|
|
const struct v3dv_sampler *
|
|
|
|
v3dv_descriptor_map_get_sampler(struct v3dv_descriptor_state *descriptor_state,
|
|
|
|
struct v3dv_descriptor_map *map,
|
|
|
|
struct v3dv_pipeline_layout *pipeline_layout,
|
|
|
|
uint32_t index);
|
|
|
|
|
2020-06-03 00:22:48 +01:00
|
|
|
struct v3dv_cl_reloc
|
2021-06-01 09:41:00 +01:00
|
|
|
v3dv_descriptor_map_get_sampler_state(struct v3dv_device *device,
|
|
|
|
struct v3dv_descriptor_state *descriptor_state,
|
2020-06-03 00:22:48 +01:00
|
|
|
struct v3dv_descriptor_map *map,
|
|
|
|
struct v3dv_pipeline_layout *pipeline_layout,
|
|
|
|
uint32_t index);
|
|
|
|
|
|
|
|
struct v3dv_cl_reloc
|
2021-06-01 09:41:00 +01:00
|
|
|
v3dv_descriptor_map_get_texture_shader_state(struct v3dv_device *device,
|
|
|
|
struct v3dv_descriptor_state *descriptor_state,
|
2020-06-03 00:22:48 +01:00
|
|
|
struct v3dv_descriptor_map *map,
|
|
|
|
struct v3dv_pipeline_layout *pipeline_layout,
|
|
|
|
uint32_t index);
|
|
|
|
|
2020-07-28 23:28:28 +01:00
|
|
|
struct v3dv_bo*
|
|
|
|
v3dv_descriptor_map_get_texture_bo(struct v3dv_descriptor_state *descriptor_state,
|
|
|
|
struct v3dv_descriptor_map *map,
|
|
|
|
struct v3dv_pipeline_layout *pipeline_layout,
|
|
|
|
uint32_t index);
|
|
|
|
|
2020-04-02 12:24:13 +01:00
|
|
|
static inline const struct v3dv_sampler *
|
|
|
|
v3dv_immutable_samplers(const struct v3dv_descriptor_set_layout *set,
|
|
|
|
const struct v3dv_descriptor_set_binding_layout *binding)
|
|
|
|
{
|
|
|
|
assert(binding->immutable_samplers_offset);
|
|
|
|
return (const struct v3dv_sampler *) ((const char *) set + binding->immutable_samplers_offset);
|
|
|
|
}
|
|
|
|
|
2020-07-22 01:08:06 +01:00
|
|
|
void v3dv_pipeline_cache_init(struct v3dv_pipeline_cache *cache,
|
|
|
|
struct v3dv_device *device,
|
2021-08-14 15:09:23 +01:00
|
|
|
VkPipelineCacheCreateFlags,
|
2020-07-22 01:08:06 +01:00
|
|
|
bool cache_enabled);
|
|
|
|
|
|
|
|
void v3dv_pipeline_cache_finish(struct v3dv_pipeline_cache *cache);
|
|
|
|
|
2020-07-07 14:56:44 +01:00
|
|
|
void v3dv_pipeline_cache_upload_nir(struct v3dv_pipeline *pipeline,
|
|
|
|
struct v3dv_pipeline_cache *cache,
|
|
|
|
nir_shader *nir,
|
|
|
|
unsigned char sha1_key[20]);
|
|
|
|
|
|
|
|
nir_shader* v3dv_pipeline_cache_search_for_nir(struct v3dv_pipeline *pipeline,
|
|
|
|
struct v3dv_pipeline_cache *cache,
|
|
|
|
const nir_shader_compiler_options *nir_options,
|
|
|
|
unsigned char sha1_key[20]);
|
|
|
|
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 00:05:54 +00:00
|
|
|
struct v3dv_pipeline_shared_data *
|
|
|
|
v3dv_pipeline_cache_search_for_pipeline(struct v3dv_pipeline_cache *cache,
|
2021-08-02 23:13:25 +01:00
|
|
|
unsigned char sha1_key[20],
|
|
|
|
bool *cache_hit);
|
2020-07-16 11:41:11 +01:00
|
|
|
|
|
|
|
void
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 00:05:54 +00:00
|
|
|
v3dv_pipeline_cache_upload_pipeline(struct v3dv_pipeline *pipeline,
|
|
|
|
struct v3dv_pipeline_cache *cache);
|
2020-07-16 11:41:11 +01:00
|
|
|
|
v3dv: define a default attribute values with float type
We are providing a BO with the default attribute values for the
GL_SHADER_STATE_RECORD, that contains 16 vec4. Such default value for
each vec4 is (0, 0, 0, 1). As the attribute format could be int or
float, the "1" value needs to take into account the attribute format.
But in the practice, the most common case is all floats. So we create
one default attribute values BO assuming that all attributes will be
floats, and we store it at v3dv_device and only create a new one if a
int format type is defined. That allows to reduce the amount of BOs
needed.
Note that we could still try to reduce the amount of BOs used by the
pipelines if we create a bigger BO, and we just play with the
offsets. But as mentioned, that's not the usual, and would add an
extra complexity,so it is not a priority right now.
This makes the following test passing when disabling the pipeline
cache support:
dEQP-VK.api.object_management.max_concurrent.graphics_pipeline
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9845>
2021-03-25 12:30:55 +00:00
|
|
|
struct v3dv_bo *
|
|
|
|
v3dv_pipeline_create_default_attribute_values(struct v3dv_device *device,
|
|
|
|
struct v3dv_pipeline *pipeline);
|
|
|
|
|
2022-10-28 11:29:06 +01:00
|
|
|
VkResult
|
|
|
|
v3dv_create_compute_pipeline_from_nir(struct v3dv_device *device,
|
|
|
|
nir_shader *nir,
|
|
|
|
VkPipelineLayout pipeline_layout,
|
|
|
|
VkPipeline *pipeline);
|
|
|
|
|
2019-11-25 15:29:12 +00:00
|
|
|
#define V3DV_FROM_HANDLE(__v3dv_type, __name, __handle) \
|
2021-09-29 14:30:24 +01:00
|
|
|
VK_FROM_HANDLE(__v3dv_type, __name, __handle)
|
|
|
|
|
|
|
|
VK_DEFINE_HANDLE_CASTS(v3dv_cmd_buffer, vk.base, VkCommandBuffer,
|
|
|
|
VK_OBJECT_TYPE_COMMAND_BUFFER)
|
|
|
|
VK_DEFINE_HANDLE_CASTS(v3dv_device, vk.base, VkDevice, VK_OBJECT_TYPE_DEVICE)
|
|
|
|
VK_DEFINE_HANDLE_CASTS(v3dv_instance, vk.base, VkInstance,
|
|
|
|
VK_OBJECT_TYPE_INSTANCE)
|
|
|
|
VK_DEFINE_HANDLE_CASTS(v3dv_physical_device, vk.base, VkPhysicalDevice,
|
|
|
|
VK_OBJECT_TYPE_PHYSICAL_DEVICE)
|
|
|
|
VK_DEFINE_HANDLE_CASTS(v3dv_queue, vk.base, VkQueue, VK_OBJECT_TYPE_QUEUE)
|
|
|
|
|
|
|
|
VK_DEFINE_NONDISP_HANDLE_CASTS(v3dv_buffer, base, VkBuffer,
|
|
|
|
VK_OBJECT_TYPE_BUFFER)
|
|
|
|
VK_DEFINE_NONDISP_HANDLE_CASTS(v3dv_buffer_view, base, VkBufferView,
|
|
|
|
VK_OBJECT_TYPE_BUFFER_VIEW)
|
|
|
|
VK_DEFINE_NONDISP_HANDLE_CASTS(v3dv_device_memory, base, VkDeviceMemory,
|
|
|
|
VK_OBJECT_TYPE_DEVICE_MEMORY)
|
|
|
|
VK_DEFINE_NONDISP_HANDLE_CASTS(v3dv_descriptor_pool, base, VkDescriptorPool,
|
|
|
|
VK_OBJECT_TYPE_DESCRIPTOR_POOL)
|
|
|
|
VK_DEFINE_NONDISP_HANDLE_CASTS(v3dv_descriptor_set, base, VkDescriptorSet,
|
|
|
|
VK_OBJECT_TYPE_DESCRIPTOR_SET)
|
|
|
|
VK_DEFINE_NONDISP_HANDLE_CASTS(v3dv_descriptor_set_layout, base,
|
|
|
|
VkDescriptorSetLayout,
|
|
|
|
VK_OBJECT_TYPE_DESCRIPTOR_SET_LAYOUT)
|
|
|
|
VK_DEFINE_NONDISP_HANDLE_CASTS(v3dv_event, base, VkEvent, VK_OBJECT_TYPE_EVENT)
|
|
|
|
VK_DEFINE_NONDISP_HANDLE_CASTS(v3dv_framebuffer, base, VkFramebuffer,
|
|
|
|
VK_OBJECT_TYPE_FRAMEBUFFER)
|
|
|
|
VK_DEFINE_NONDISP_HANDLE_CASTS(v3dv_image, vk.base, VkImage,
|
|
|
|
VK_OBJECT_TYPE_IMAGE)
|
|
|
|
VK_DEFINE_NONDISP_HANDLE_CASTS(v3dv_image_view, vk.base, VkImageView,
|
|
|
|
VK_OBJECT_TYPE_IMAGE_VIEW)
|
|
|
|
VK_DEFINE_NONDISP_HANDLE_CASTS(v3dv_pipeline, base, VkPipeline,
|
|
|
|
VK_OBJECT_TYPE_PIPELINE)
|
|
|
|
VK_DEFINE_NONDISP_HANDLE_CASTS(v3dv_pipeline_cache, base, VkPipelineCache,
|
|
|
|
VK_OBJECT_TYPE_PIPELINE_CACHE)
|
|
|
|
VK_DEFINE_NONDISP_HANDLE_CASTS(v3dv_pipeline_layout, base, VkPipelineLayout,
|
|
|
|
VK_OBJECT_TYPE_PIPELINE_LAYOUT)
|
|
|
|
VK_DEFINE_NONDISP_HANDLE_CASTS(v3dv_query_pool, base, VkQueryPool,
|
|
|
|
VK_OBJECT_TYPE_QUERY_POOL)
|
|
|
|
VK_DEFINE_NONDISP_HANDLE_CASTS(v3dv_render_pass, base, VkRenderPass,
|
|
|
|
VK_OBJECT_TYPE_RENDER_PASS)
|
|
|
|
VK_DEFINE_NONDISP_HANDLE_CASTS(v3dv_sampler, base, VkSampler,
|
|
|
|
VK_OBJECT_TYPE_SAMPLER)
|
2019-11-25 15:29:12 +00:00
|
|
|
|
2019-11-29 12:55:38 +00:00
|
|
|
static inline int
|
|
|
|
v3dv_ioctl(int fd, unsigned long request, void *arg)
|
|
|
|
{
|
|
|
|
if (using_v3d_simulator)
|
|
|
|
return v3d_simulator_ioctl(fd, request, arg);
|
|
|
|
else
|
|
|
|
return drmIoctl(fd, request, arg);
|
|
|
|
}
|
|
|
|
|
2020-05-15 09:46:13 +01:00
|
|
|
/* Flags OOM conditions in command buffer state.
|
|
|
|
*
|
|
|
|
* Note: notice that no-op jobs don't have a command buffer reference.
|
|
|
|
*/
|
|
|
|
static inline void
|
|
|
|
v3dv_flag_oom(struct v3dv_cmd_buffer *cmd_buffer, struct v3dv_job *job)
|
|
|
|
{
|
|
|
|
if (cmd_buffer) {
|
|
|
|
cmd_buffer->state.oom = true;
|
|
|
|
} else {
|
|
|
|
assert(job);
|
|
|
|
if (job->cmd_buffer)
|
|
|
|
job->cmd_buffer->state.oom = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#define v3dv_return_if_oom(_cmd_buffer, _job) do { \
|
|
|
|
const struct v3dv_cmd_buffer *__cmd_buffer = _cmd_buffer; \
|
|
|
|
if (__cmd_buffer && __cmd_buffer->state.oom) \
|
|
|
|
return; \
|
|
|
|
const struct v3dv_job *__job = _job; \
|
|
|
|
if (__job && __job->cmd_buffer && __job->cmd_buffer->state.oom) \
|
|
|
|
return; \
|
|
|
|
} while(0) \
|
|
|
|
|
2020-08-26 07:38:41 +01:00
|
|
|
static inline uint32_t
|
|
|
|
u64_hash(const void *key)
|
|
|
|
{
|
|
|
|
return _mesa_hash_data(key, sizeof(uint64_t));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool
|
|
|
|
u64_compare(const void *key1, const void *key2)
|
|
|
|
{
|
|
|
|
return memcmp(key1, key2, sizeof(uint64_t)) == 0;
|
|
|
|
}
|
|
|
|
|
2022-11-04 21:04:49 +00:00
|
|
|
/* Helper to call hw ver specific functions */
|
v3dv: start to move and wrap hw-version code with v3dv_queue
The idea would be to move all the code that uses cl_emit,
cl_emit_with_prepack, v3dx_pack, and any enum/structure definition
defined on the v3d pack headers.
All those methods would be defined on v3dvx_private (that would be the
equivalent to v3dx_context.h on v3d).
This commit includes the definition of v3dX for the current version
supported (42), a function calling wrapper, and the move for v3dv_queue
methods as a reference.
About the function calling wrapper, I took the idea from anv. We don't
have on v3d, but we added it because we foresee that we will need that
functionality more often. So without that macro, in order to call the
correct version of the method from the general code we would need to
do like we do on v3d, and doing something like this:
if (devinfo->ver >= 42)
return v3d42_pack_sampler_state(sampler, pCreateInfo);
else
return v3d33_pack_sampler_state(sampler, pCreateInfo);
So with the macro we can just do this:
v3dv_X(device, pack_sampler_state)(sampler, pCreateInfo).
Note that as mentioned, that is to be used on the general code, so a
runtime decision. If we are already on version-dependant code (so at
v3dx_queue for example) we just use v3dX, as at that point is a build
time decision.
Also, fwiw, I don't like too much the name of that macro, but I was
not able to think on a better one.
v2: merge job_emit_noop_bin and job_emit_noop_render (Iago)
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11310>
2021-06-10 12:39:35 +01:00
|
|
|
#define v3dv_X(device, thing) ({ \
|
|
|
|
__typeof(&v3d42_##thing) v3d_X_thing; \
|
|
|
|
switch (device->devinfo.ver) { \
|
|
|
|
case 42: \
|
|
|
|
v3d_X_thing = &v3d42_##thing; \
|
|
|
|
break; \
|
|
|
|
default: \
|
|
|
|
unreachable("Unsupported hardware generation"); \
|
|
|
|
} \
|
|
|
|
v3d_X_thing; \
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
|
|
/* v3d_macros from common requires v3dX and V3DX definitions. Below we need to
|
|
|
|
* define v3dX for each version supported, because when we compile code that
|
|
|
|
* is not version-specific, all version-specific macros need to be already
|
|
|
|
* defined.
|
|
|
|
*/
|
|
|
|
#ifdef v3dX
|
|
|
|
# include "v3dvx_private.h"
|
|
|
|
#else
|
|
|
|
# define v3dX(x) v3d42_##x
|
|
|
|
# include "v3dvx_private.h"
|
|
|
|
# undef v3dX
|
|
|
|
#endif
|
|
|
|
|
2021-12-08 10:15:38 +00:00
|
|
|
#ifdef ANDROID
|
|
|
|
VkResult
|
|
|
|
v3dv_gralloc_info(struct v3dv_device *device,
|
|
|
|
const VkNativeBufferANDROID *gralloc_info,
|
|
|
|
int *out_dmabuf,
|
|
|
|
int *out_stride,
|
|
|
|
int *out_size,
|
|
|
|
uint64_t *out_modifier);
|
|
|
|
|
|
|
|
VkResult
|
|
|
|
v3dv_import_native_buffer_fd(VkDevice device_h,
|
|
|
|
int dma_buf,
|
|
|
|
const VkAllocationCallbacks *alloc,
|
|
|
|
VkImage image_h);
|
|
|
|
#endif /* ANDROID */
|
|
|
|
|
2019-11-25 15:29:12 +00:00
|
|
|
#endif /* V3DV_PRIVATE_H */
|