From ff886cbdcc44334b5f876721cf65428aa955948b Mon Sep 17 00:00:00 2001 From: Gerd Hoffmann Date: Wed, 23 Sep 2020 17:31:58 -0700 Subject: virtio-gpu api: blob resources A blob resource is a container for: - VIRTIO_GPU_BLOB_MEM_GUEST: a guest memory allocation (referred to as a "guest-only blob resource") - VIRTIO_GPU_BLOB_MEM_HOST3D: a host3d memory allocation (referred to as a "host-only blob resource") - VIRTIO_GPU_BLOB_MEM_HOST3D_GUEST: a guest + host3d memory allocation (referred to as a "default blob resource"). The memory properties of the blob resource must be described by `blob_mem`. For default and guest only blob resources set, `nents` guest system pages are assigned to the resource. For default blob resources, these guest pages are used for transfer operations. Attach/detach is also possible to allow swap-in/swap-out, but isn't required since it may not be applicable to future blob mem types (shared guest/guest vram). Host allocations depend on whether the 3D is supported. If 3D is not supported, the only valid field for `blob_mem` is VIRTIO_GPU_BLOB_MEM_GUEST. If 3D is supported, the virtio-gpu resource is created from the context local object identified by the `blob_id`. The actual host allocation done by the CMD_SUBMIT_3D. Userspace must specify if the blob resource is intended to be used for userspace mapping, sharing between virtio-gpu contexts and/or sharing between virtio devices. This is done via `blob_flags`. For 3D hosts, both VIRTIO_GPU_CMD_TRANSFER_TO_HOST_3D and VIRTIO_GPU_CMD_TRANSFER_FROM_HOST_3D may be used to update the host resource. There is no restriction on the image/buffer view the guest/host userspace has on the blob resource. VIRTIO_GPU_CMD_SET_SCANOUT_BLOB / VIRTIO_GPU_CMD_RESOURCE_FLUSH may be used with blob resources as well. The modifier is intentionally left out of SCANOUT_BLOB, and auxilary blobs are also left out as a simplification. The use case for blob resources is zero-copy, needed for coherent memory in virglrenderer. Host only blob resources are not mappable without the feature described in the next patch, but are shareable. Future work: - Emulated coherent `blob_mem` type for QEMU/vhost-user - A `blob_mem` type for guest-only resources imported in cache-coherent FOSS GPU/display drivers. - Display integration involving the blob model using seamless Wayland windows. Signed-off-by: Gerd Hoffmann Acked-by: Tomeu Vizoso Acked-by: Chia-I Wu Acked-by: Lingfeng Yang Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-3-gurchetansingh@chromium.org Co-developed-by: Gurchetan Singh Signed-off-by: Gurchetan Singh --- include/uapi/linux/virtio_gpu.h | 43 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) (limited to 'include/uapi') diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h index 747a5c5cc4e6..4ddf2fe342ed 100644 --- a/include/uapi/linux/virtio_gpu.h +++ b/include/uapi/linux/virtio_gpu.h @@ -55,6 +55,11 @@ */ #define VIRTIO_GPU_F_RESOURCE_UUID 2 +/* + * VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB + */ +#define VIRTIO_GPU_F_RESOURCE_BLOB 3 + enum virtio_gpu_ctrl_type { VIRTIO_GPU_UNDEFINED = 0, @@ -71,6 +76,8 @@ enum virtio_gpu_ctrl_type { VIRTIO_GPU_CMD_GET_CAPSET, VIRTIO_GPU_CMD_GET_EDID, VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID, + VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB, + VIRTIO_GPU_CMD_SET_SCANOUT_BLOB, /* 3d commands */ VIRTIO_GPU_CMD_CTX_CREATE = 0x0200, @@ -359,4 +366,40 @@ struct virtio_gpu_resp_resource_uuid { __u8 uuid[16]; }; +/* VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB */ +struct virtio_gpu_resource_create_blob { + struct virtio_gpu_ctrl_hdr hdr; + __le32 resource_id; +#define VIRTIO_GPU_BLOB_MEM_GUEST 0x0001 +#define VIRTIO_GPU_BLOB_MEM_HOST3D 0x0002 +#define VIRTIO_GPU_BLOB_MEM_HOST3D_GUEST 0x0003 + +#define VIRTIO_GPU_BLOB_FLAG_USE_MAPPABLE 0x0001 +#define VIRTIO_GPU_BLOB_FLAG_USE_SHAREABLE 0x0002 +#define VIRTIO_GPU_BLOB_FLAG_USE_CROSS_DEVICE 0x0004 + /* zero is invalid blob mem */ + __le32 blob_mem; + __le32 blob_flags; + __le64 blob_id; + __le64 size; + __le32 nr_entries; + /* + * sizeof(nr_entries * virtio_gpu_mem_entry) bytes follow + */ +}; + +/* VIRTIO_GPU_CMD_SET_SCANOUT_BLOB */ +struct virtio_gpu_set_scanout_blob { + struct virtio_gpu_ctrl_hdr hdr; + struct virtio_gpu_rect r; + __le32 scanout_id; + __le32 resource_id; + __le32 width; + __le32 height; + __le32 format; + __le32 padding; + __le32 strides[4]; + __le32 offsets[4]; +}; + #endif -- cgit v1.2.3 From e5cd6cbe025570f6135f48538cb450254f8fbdd3 Mon Sep 17 00:00:00 2001 From: Gerd Hoffmann Date: Wed, 23 Sep 2020 17:31:59 -0700 Subject: virtio-gpu api: host visible feature This patch adds a new virtgpu feature that allows directly mapping host allocated resources. This is based on virtio shared memory regions, which allows querying for memory regions using PCI transport. Each shared memory region has an associated "shmid", the meaning of which is device specific. For virtio-gpu, we can define the shared memory region with id VIRTIO_GPU_SHM_ID_HOST_VISIBLE to be the "host visible memory region". The presence of the host visible memory region means the following hypercalls are supported: 1) VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB This hypercall tells the host to inject the host resource's mapping in an offset into virtio-gpu's PCI address space. This is typically done via KVM_SET_USER_MEMORY_REGION on Linux hosts. On success, VIRTIO_GPU_RESP_OK_MAP_INFO is returned, which specifies the host buffer's caching type and possibly in the future performance hints about the buffer.. 2) VIRTIO_GPU_CMD_RESOURCE_UNMAP_BLOB This hypercall tells the host to remove the host resource's mapping from the guest VM. Signed-off-by: Gerd Hoffmann Acked-by: Tomeu Vizoso Acked-by: Lingfeng Yang Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-4-gurchetansingh@chromium.org Co-developed-by: Gurchetan Singh Signed-off-by: Gurchetan Singh --- include/uapi/linux/virtio_gpu.h | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) (limited to 'include/uapi') diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h index 4ddf2fe342ed..fa2ae4a1da5f 100644 --- a/include/uapi/linux/virtio_gpu.h +++ b/include/uapi/linux/virtio_gpu.h @@ -88,6 +88,8 @@ enum virtio_gpu_ctrl_type { VIRTIO_GPU_CMD_TRANSFER_TO_HOST_3D, VIRTIO_GPU_CMD_TRANSFER_FROM_HOST_3D, VIRTIO_GPU_CMD_SUBMIT_3D, + VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB, + VIRTIO_GPU_CMD_RESOURCE_UNMAP_BLOB, /* cursor commands */ VIRTIO_GPU_CMD_UPDATE_CURSOR = 0x0300, @@ -100,6 +102,7 @@ enum virtio_gpu_ctrl_type { VIRTIO_GPU_RESP_OK_CAPSET, VIRTIO_GPU_RESP_OK_EDID, VIRTIO_GPU_RESP_OK_RESOURCE_UUID, + VIRTIO_GPU_RESP_OK_MAP_INFO, /* error responses */ VIRTIO_GPU_RESP_ERR_UNSPEC = 0x1200, @@ -110,6 +113,11 @@ enum virtio_gpu_ctrl_type { VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER, }; +enum virtio_gpu_shm_id { + VIRTIO_GPU_SHM_ID_UNDEFINED = 0, + VIRTIO_GPU_SHM_ID_HOST_VISIBLE = 1 +}; + #define VIRTIO_GPU_FLAG_FENCE (1 << 0) struct virtio_gpu_ctrl_hdr { @@ -402,4 +410,31 @@ struct virtio_gpu_set_scanout_blob { __le32 offsets[4]; }; +/* VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB */ +struct virtio_gpu_resource_map_blob { + struct virtio_gpu_ctrl_hdr hdr; + __le32 resource_id; + __le32 padding; + __le64 offset; +}; + +/* VIRTIO_GPU_RESP_OK_MAP_INFO */ +#define VIRTIO_GPU_MAP_CACHE_MASK 0x0f +#define VIRTIO_GPU_MAP_CACHE_NONE 0x00 +#define VIRTIO_GPU_MAP_CACHE_CACHED 0x01 +#define VIRTIO_GPU_MAP_CACHE_UNCACHED 0x02 +#define VIRTIO_GPU_MAP_CACHE_WC 0x03 +struct virtio_gpu_resp_map_info { + struct virtio_gpu_ctrl_hdr hdr; + __u32 map_info; + __u32 padding; +}; + +/* VIRTIO_GPU_CMD_RESOURCE_UNMAP_BLOB */ +struct virtio_gpu_resource_unmap_blob { + struct virtio_gpu_ctrl_hdr hdr; + __le32 resource_id; + __le32 padding; +}; + #endif -- cgit v1.2.3 From eda3e1018f786f8f3db93001fb2da757b193ed1a Mon Sep 17 00:00:00 2001 From: Gurchetan Singh Date: Wed, 23 Sep 2020 17:32:00 -0700 Subject: drm/virtgpu api: blob resources This makes blob resources available to guest userspace. They are needed for GL4.5, Vulkan and zero-copy virtio-gpu. For Mesa, blob resources have been tested with Piglit's ARB_buffer_storage tests and apitraces. Apitraces of GL4.5 games show we're between 70% to 80% of host performance on Iris, based on a apitrace of a 2013 GL4.5 game: 11.204 FPS (guest) 15.947 FPS (host) This is still better than the status quo, when said game was unplayable with Virgl due to an inefficient GL4.3 fallback. But there's still room for improvement if we want to match HW-assisted virtualization. For Vulkan, blob resources have been tested with dEQP.vk.memory* and running Vulkan applications in production with the "Cuttlefish" virtual Android device. This has been done with Lingfeng Yang's "gfxstream" Vulkan implementation, which virtualizes Vulkan across many Google products. Signed-off-by: Gurchetan Singh Acked-by: Tomeu Vizoso Acked-by: Chia-I Wu Acked-by: Lingfeng Yang Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-5-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann --- include/uapi/drm/virtgpu_drm.h | 37 ++++++++++++++++++++++++++++++++++++- 1 file changed, 36 insertions(+), 1 deletion(-) (limited to 'include/uapi') diff --git a/include/uapi/drm/virtgpu_drm.h b/include/uapi/drm/virtgpu_drm.h index f06a789f34cd..bb224f604c9e 100644 --- a/include/uapi/drm/virtgpu_drm.h +++ b/include/uapi/drm/virtgpu_drm.h @@ -46,6 +46,7 @@ extern "C" { #define DRM_VIRTGPU_TRANSFER_TO_HOST 0x07 #define DRM_VIRTGPU_WAIT 0x08 #define DRM_VIRTGPU_GET_CAPS 0x09 +#define DRM_VIRTGPU_RESOURCE_CREATE_BLOB 0x0a #define VIRTGPU_EXECBUF_FENCE_FD_IN 0x01 #define VIRTGPU_EXECBUF_FENCE_FD_OUT 0x02 @@ -71,6 +72,7 @@ struct drm_virtgpu_execbuffer { #define VIRTGPU_PARAM_3D_FEATURES 1 /* do we have 3D features in the hw */ #define VIRTGPU_PARAM_CAPSET_QUERY_FIX 2 /* do we have the capset fix */ +#define VIRTGPU_PARAM_RESOURCE_BLOB 3 /* DRM_VIRTGPU_RESOURCE_CREATE_BLOB */ struct drm_virtgpu_getparam { __u64 param; @@ -100,7 +102,7 @@ struct drm_virtgpu_resource_info { __u32 bo_handle; __u32 res_handle; __u32 size; - __u32 stride; + __u32 blob_mem; }; struct drm_virtgpu_3d_box { @@ -117,6 +119,8 @@ struct drm_virtgpu_3d_transfer_to_host { struct drm_virtgpu_3d_box box; __u32 level; __u32 offset; + __u32 stride; + __u32 layer_stride; }; struct drm_virtgpu_3d_transfer_from_host { @@ -124,6 +128,8 @@ struct drm_virtgpu_3d_transfer_from_host { struct drm_virtgpu_3d_box box; __u32 level; __u32 offset; + __u32 stride; + __u32 layer_stride; }; #define VIRTGPU_WAIT_NOWAIT 1 /* like it */ @@ -140,6 +146,31 @@ struct drm_virtgpu_get_caps { __u32 pad; }; +struct drm_virtgpu_resource_create_blob { +#define VIRTGPU_BLOB_MEM_GUEST 0x0001 +#define VIRTGPU_BLOB_MEM_HOST3D 0x0002 +#define VIRTGPU_BLOB_MEM_HOST3D_GUEST 0x0003 + +#define VIRTGPU_BLOB_FLAG_USE_MAPPABLE 0x0001 +#define VIRTGPU_BLOB_FLAG_USE_SHAREABLE 0x0002 +#define VIRTGPU_BLOB_FLAG_USE_CROSS_DEVICE 0x0004 + /* zero is invalid blob_mem */ + __u32 blob_mem; + __u32 blob_flags; + __u32 bo_handle; + __u32 res_handle; + __u64 size; + + /* + * for 3D contexts with VIRTGPU_BLOB_MEM_HOST3D_GUEST and + * VIRTGPU_BLOB_MEM_HOST3D otherwise, must be zero. + */ + __u32 pad; + __u32 cmd_size; + __u64 cmd; + __u64 blob_id; +}; + #define DRM_IOCTL_VIRTGPU_MAP \ DRM_IOWR(DRM_COMMAND_BASE + DRM_VIRTGPU_MAP, struct drm_virtgpu_map) @@ -175,6 +206,10 @@ struct drm_virtgpu_get_caps { DRM_IOWR(DRM_COMMAND_BASE + DRM_VIRTGPU_GET_CAPS, \ struct drm_virtgpu_get_caps) +#define DRM_IOCTL_VIRTGPU_RESOURCE_CREATE_BLOB \ + DRM_IOWR(DRM_COMMAND_BASE + DRM_VIRTGPU_RESOURCE_CREATE_BLOB, \ + struct drm_virtgpu_resource_create_blob) + #if defined(__cplusplus) } #endif -- cgit v1.2.3 From 7a571c76ddce5928f872cdfd707ba5c7193e088c Mon Sep 17 00:00:00 2001 From: Gurchetan Singh Date: Wed, 23 Sep 2020 17:32:01 -0700 Subject: drm/virtgpu api: host visible feature This exposes the host visible feature to userspace. Without it, it is an error to specify BLOB_MEM_HOST3D with BLOG_FLAG_USE_MAPPABLE. Signed-off-by: Gurchetan Singh Acked-by: Tomeu Vizoso Acked-by: Lingfeng Yang Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-6-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann --- include/uapi/drm/virtgpu_drm.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/uapi') diff --git a/include/uapi/drm/virtgpu_drm.h b/include/uapi/drm/virtgpu_drm.h index bb224f604c9e..e1b1518f9acc 100644 --- a/include/uapi/drm/virtgpu_drm.h +++ b/include/uapi/drm/virtgpu_drm.h @@ -73,6 +73,7 @@ struct drm_virtgpu_execbuffer { #define VIRTGPU_PARAM_3D_FEATURES 1 /* do we have 3D features in the hw */ #define VIRTGPU_PARAM_CAPSET_QUERY_FIX 2 /* do we have the capset fix */ #define VIRTGPU_PARAM_RESOURCE_BLOB 3 /* DRM_VIRTGPU_RESOURCE_CREATE_BLOB */ +#define VIRTGPU_PARAM_HOST_VISIBLE 4 /* Host blob resources are mappable */ struct drm_virtgpu_getparam { __u64 param; -- cgit v1.2.3 From bf36dea17623b65cfbbe6219bfea1326255a89b6 Mon Sep 17 00:00:00 2001 From: Gurchetan Singh Date: Wed, 23 Sep 2020 17:32:02 -0700 Subject: drm/virtgpu api: cross-device feature This feature was recently added to virtio-gpu, lets make it userspace queryable. It's an error to use BLOB_FLAG_USE_CROSS_DEVICE when this feature is not present. Signed-off-by: Gurchetan Singh Acked-by: Tomeu Vizoso Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-7-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann --- include/uapi/drm/virtgpu_drm.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/uapi') diff --git a/include/uapi/drm/virtgpu_drm.h b/include/uapi/drm/virtgpu_drm.h index e1b1518f9acc..b9ec26e9c646 100644 --- a/include/uapi/drm/virtgpu_drm.h +++ b/include/uapi/drm/virtgpu_drm.h @@ -74,6 +74,7 @@ struct drm_virtgpu_execbuffer { #define VIRTGPU_PARAM_CAPSET_QUERY_FIX 2 /* do we have the capset fix */ #define VIRTGPU_PARAM_RESOURCE_BLOB 3 /* DRM_VIRTGPU_RESOURCE_CREATE_BLOB */ #define VIRTGPU_PARAM_HOST_VISIBLE 4 /* Host blob resources are mappable */ +#define VIRTGPU_PARAM_CROSS_DEVICE 5 /* Cross virtio-device resource sharing */ struct drm_virtgpu_getparam { __u64 param; -- cgit v1.2.3 From 91e515c2f0f68d4ce137c9182eb03af4858f362e Mon Sep 17 00:00:00 2001 From: Alistair Delva Date: Tue, 29 Sep 2020 14:53:33 -0700 Subject: virtio-gpu api: fix 64/32 compat issue with blob implementation We encountered this issue when booting blob with a 32-bit kernel. The implementation doesn't match v6 of the virtio-spec change, so fix this. Fixes: ff886cbdcc44 ("virtio-gpu api: blob resources") Signed-off-by: Alistair Delva Link: http://patchwork.freedesktop.org/patch/msgid/20200929215333.1241-1-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann --- include/uapi/linux/virtio_gpu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'include/uapi') diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h index fa2ae4a1da5f..0ec6b610402c 100644 --- a/include/uapi/linux/virtio_gpu.h +++ b/include/uapi/linux/virtio_gpu.h @@ -388,9 +388,9 @@ struct virtio_gpu_resource_create_blob { /* zero is invalid blob mem */ __le32 blob_mem; __le32 blob_flags; + __le32 nr_entries; __le64 blob_id; __le64 size; - __le32 nr_entries; /* * sizeof(nr_entries * virtio_gpu_mem_entry) bytes follow */ -- cgit v1.2.3 From ec5722adb8b23d851a77412004e8faae4f83dfd0 Mon Sep 17 00:00:00 2001 From: Simon Ser Date: Wed, 24 Jun 2020 13:01:31 +0000 Subject: drm/fourcc: document modifier uniqueness requirements MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit There have suggestions to bake pitch alignment, address alignment, contiguous memory or other placement (hidden VRAM, GTT/BAR, etc) constraints into modifiers. Last time this was brought up it seemed like the consensus was to not allow this. Document this in drm_fourcc.h. There are several reasons for this. - Encoding all of these constraints in the modifiers would explode the search space pretty quickly (we only have 64 bits to work with). - Modifiers need to be unambiguous: a buffer can only have a single modifier. - Modifier users aren't expected to parse modifiers (except drivers). v2: add paragraph about aliases (Daniel) v3: fix unrelated changes sent with the patch v4: disambiguate users between driver and higher-level programs (Brian, Daniel) v5: fix AFBC example (Brian, Daniel) v6: remove duplicated paragraph (Daniel) Signed-off-by: Simon Ser Reviewed-by: Daniel Vetter Reviewed-by: Brian Starkey Cc: Daniel Stone Cc: Bas Nieuwenhuizen Cc: Dave Airlie Cc: Marek Olšák Cc: Alex Deucher Cc: Neil Armstrong Cc: Michel Dänzer Link: https://patchwork.freedesktop.org/patch/msgid/MGwgeXojKNdNXjCxuMhRlwcJM4vdYph_WJcMeGPPGMcRKtHV41XAXlh2tCc-pPJZCAhS3gwbWMWTd8f03NBA2ZYKfr0QxLhcPivpopr5c6M=@emersion.fr --- include/uapi/drm/drm_fourcc.h | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) (limited to 'include/uapi') diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h index 82f327801267..6f0628eb13a6 100644 --- a/include/uapi/drm/drm_fourcc.h +++ b/include/uapi/drm/drm_fourcc.h @@ -58,6 +58,30 @@ extern "C" { * may preserve meaning - such as number of planes - from the fourcc code, * whereas others may not. * + * Modifiers must uniquely encode buffer layout. In other words, a buffer must + * match only a single modifier. A modifier must not be a subset of layouts of + * another modifier. For instance, it's incorrect to encode pitch alignment in + * a modifier: a buffer may match a 64-pixel aligned modifier and a 32-pixel + * aligned modifier. That said, modifiers can have implicit minimal + * requirements. + * + * For modifiers where the combination of fourcc code and modifier can alias, + * a canonical pair needs to be defined and used by all drivers. Preferred + * combinations are also encouraged where all combinations might lead to + * confusion and unnecessarily reduced interoperability. An example for the + * latter is AFBC, where the ABGR layouts are preferred over ARGB layouts. + * + * There are two kinds of modifier users: + * + * - Kernel and user-space drivers: for drivers it's important that modifiers + * don't alias, otherwise two drivers might support the same format but use + * different aliases, preventing them from sharing buffers in an efficient + * format. + * - Higher-level programs interfacing with KMS/GBM/EGL/Vulkan/etc: these users + * see modifiers as opaque tokens they can check for equality and intersect. + * These users musn't need to know to reason about the modifier value + * (i.e. they are not expected to extract information out of the modifier). + * * Vendors should document their modifier usage in as much detail as * possible, to ensure maximum compatibility across devices, drivers and * applications. -- cgit v1.2.3 From 47170f89f76b28c55f359b4766da41d6b91d9ffe Mon Sep 17 00:00:00 2001 From: Matteo Franchin Date: Mon, 12 Oct 2020 17:40:43 +0100 Subject: drm/fourcc: Add AXBXGXRX106106106106 format Add ABGR format with 10-bit components packed in 64-bit per pixel. This format can be used to handle VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 on little-endian architectures. Signed-off-by: Matteo Franchin Reviewed-by: Brian Starkey Acked-by: Daniel Vetter Signed-off-by: Liviu Dudau Link: https://patchwork.freedesktop.org/patch/msgid/20201012164043.23630-1-matteo.franchin@arm.com --- include/uapi/drm/drm_fourcc.h | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'include/uapi') diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h index 6f0628eb13a6..d720f1e8ae5e 100644 --- a/include/uapi/drm/drm_fourcc.h +++ b/include/uapi/drm/drm_fourcc.h @@ -179,6 +179,12 @@ extern "C" { #define DRM_FORMAT_ARGB16161616F fourcc_code('A', 'R', '4', 'H') /* [63:0] A:R:G:B 16:16:16:16 little endian */ #define DRM_FORMAT_ABGR16161616F fourcc_code('A', 'B', '4', 'H') /* [63:0] A:B:G:R 16:16:16:16 little endian */ +/* + * RGBA format with 10-bit components packed in 64-bit per pixel, with 6 bits + * of unused padding per component: + */ +#define DRM_FORMAT_AXBXGXRX106106106106 fourcc_code('A', 'B', '1', '0') /* [63:0] A:x:B:x:G:x:R:x 10:6:10:6:10:6:10:6 little endian */ + /* packed YCbCr */ #define DRM_FORMAT_YUYV fourcc_code('Y', 'U', 'Y', 'V') /* [31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */ #define DRM_FORMAT_YVYU fourcc_code('Y', 'V', 'Y', 'U') /* [31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */ -- cgit v1.2.3 From 70bb9193728627e84e02eb0960b0aa138ae2cef5 Mon Sep 17 00:00:00 2001 From: Simon Ser Date: Mon, 26 Oct 2020 14:12:30 +0100 Subject: drm: deprecate DRM_FORMAT_MOD_NONE DRM_FORMAT_MOD_NONE is in the list of vendors, which is pretty confusing. We already have DRM_FORMAT_MOD_VENDOR_NONE. Move it down in the list of format modifiers. DRM_FORMAT_MOD_NONE is an alias for DRM_FORMAT_MOD_LINEAR, however the name is confusing: NONE doesn't mean that the modifier is implicit, instead it means that the layout is linear. Deprecate it. Signed-off-by: Simon Ser Reviewed-by: Bas Nieuwenhuizen Reviewed-by: Pekka Paalanen Acked-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/a2j8KTgc26k5QniSAhDSTgCw4XWZhmsNHwG8UVa6U@cp4-web-014.plabs.ch --- include/uapi/drm/drm_fourcc.h | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) (limited to 'include/uapi') diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h index d720f1e8ae5e..9f7e19c9416c 100644 --- a/include/uapi/drm/drm_fourcc.h +++ b/include/uapi/drm/drm_fourcc.h @@ -350,7 +350,6 @@ extern "C" { */ /* Vendor Ids: */ -#define DRM_FORMAT_MOD_NONE 0 #define DRM_FORMAT_MOD_VENDOR_NONE 0 #define DRM_FORMAT_MOD_VENDOR_INTEL 0x01 #define DRM_FORMAT_MOD_VENDOR_AMD 0x02 @@ -422,6 +421,16 @@ extern "C" { */ #define DRM_FORMAT_MOD_LINEAR fourcc_mod_code(NONE, 0) +/* + * Deprecated: use DRM_FORMAT_MOD_LINEAR instead + * + * The "none" format modifier doesn't actually mean that the modifier is + * implicit, instead it means that the layout is linear. Whether modifiers are + * used is out-of-band information carried in an API-specific way (e.g. in a + * flag for drm_mode_fb_cmd2). + */ +#define DRM_FORMAT_MOD_NONE 0 + /* Intel framebuffer modifiers */ /* -- cgit v1.2.3