kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-10-18 19:12:56 +00:00
Code Issues Releases Packages Activity
linux/include/uapi/drm/virtgpu_drm.h

253 lines
7.1 KiB
Raw Normal View History

virtio-gpu: add 3d/virgl support Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-10-28 12:48:00 +01:00
drm: fix inclusion of drm.h in virtgpu_drm.h Using `#include "drm.h"` instead of `#include <drm/drm.h>` allow drm headers to be moved in another directory without changes, like for the libdrm imports. Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> CC: Emil Velikov <emil.l.velikov@gmail.com> CC: Mikko Rapeli <mikko.rapeli@iki.fi>
2015-11-30 15:10:55 +01:00
virtio-gpu: add 3d/virgl support Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-10-28 12:48:00 +01:00
drm/virgl: add extern C guard for the UAPI header Cc: Dave Airlie <airlied@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
2016-04-07 19:38:49 +01:00
virtio-gpu: add 3d/virgl support Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-10-28 12:48:00 +01:00
drm: use __u{32,64} instead of uint{32,64}_t in virtgpu_drm.h Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> CC: Emil Velikov <emil.l.velikov@gmail.com> CC: Mikko Rapeli <mikko.rapeli@iki.fi>
2015-11-30 15:10:39 +01:00
virtio-gpu: add 3d/virgl support Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-10-28 12:48:00 +01:00
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 <gurchetansingh@chromium.org> Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Chia-I Wu <olvaffe@gmail.com> Acked-by: Lingfeng Yang <lfy@google.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-5-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-09-23 17:32:00 -07:00
drm/virtgpu api: create context init feature This change allows creating contexts of depending on set of context parameters. The meaning of each of the parameters is listed below: 1) VIRTGPU_CONTEXT_PARAM_CAPSET_ID This determines the type of a context based on the capability set ID. For example, the current capsets: VIRTIO_GPU_CAPSET_VIRGL VIRTIO_GPU_CAPSET_VIRGL2 define a Gallium, TGSI based "virgl" context. We only need 1 capset ID per context type, though virgl has two due a bug that has since been fixed. The use case is the "gfxstream" rendering library and "venus" renderer. gfxstream doesn't do Gallium/TGSI translation and mostly relies on auto-generated API streaming. Certain users prefer gfxstream over virgl for GLES on GLES emulation. {gfxstream vk}/{venus} are also required for Vulkan emulation. The maximum capset ID is 63. The goal is for guest userspace to choose the optimal context type depending on the situation/hardware. 2) VIRTGPU_CONTEXT_PARAM_NUM_RINGS This tells the number of independent command rings that the context will use. This value may be zero and is inferred to be zero if VIRTGPU_CONTEXT_PARAM_NUM_RINGS is not passed in. This is for backwards compatibility for virgl, which has one big giant command ring for all commands. The maxiumum number of rings is 64. In practice, multi-queue or multi-ring submission is used for powerful dGPUs and virtio-gpu may not be the best option in that case (see PCI passthrough or rendernode forwarding). 3) VIRTGPU_CONTEXT_PARAM_POLL_RING_IDX_MASK This is a mask of ring indices for which the DRM fd is pollable. For example, if VIRTGPU_CONTEXT_PARAM_NUM_RINGS is 2, then the mask may be: [ring idx] | [1 << ring_idx] | final mask ------------------------------------------- 0 1 1 1 2 3 The "Sommelier" guest Wayland proxy uses this to poll for events from the host compositor. Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Acked-by: Lingfeng Yang <lfy@google.com> Acked-by: Nicholas Verne <nverne@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-3-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-09-21 16:20:14 -07:00
virtio-gpu: add 3d/virgl support Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-10-28 12:48:00 +01:00
drm/virtio: add uapi for in and out explicit fences Add a new field called fence_fd that will be used by userspace to send in-fences to the kernel and receive out-fences created by the kernel. This uapi enables virtio to take advantage of explicit synchronization of dma-bufs. There are two new flags: * VIRTGPU_EXECBUF_FENCE_FD_IN to be used when passing an in-fence fd. * VIRTGPU_EXECBUF_FENCE_FD_OUT to be used when requesting an out-fence fd The execbuffer IOCTL is now read-write to allow the userspace to read the out-fence. On error -1 should be returned in the fence_fd field. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Robert Foss <robert.foss@collabora.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20181112165157.32765-3-robert.foss@collabora.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-11-12 17:51:55 +01:00
drm/virtgpu api: create context init feature This change allows creating contexts of depending on set of context parameters. The meaning of each of the parameters is listed below: 1) VIRTGPU_CONTEXT_PARAM_CAPSET_ID This determines the type of a context based on the capability set ID. For example, the current capsets: VIRTIO_GPU_CAPSET_VIRGL VIRTIO_GPU_CAPSET_VIRGL2 define a Gallium, TGSI based "virgl" context. We only need 1 capset ID per context type, though virgl has two due a bug that has since been fixed. The use case is the "gfxstream" rendering library and "venus" renderer. gfxstream doesn't do Gallium/TGSI translation and mostly relies on auto-generated API streaming. Certain users prefer gfxstream over virgl for GLES on GLES emulation. {gfxstream vk}/{venus} are also required for Vulkan emulation. The maximum capset ID is 63. The goal is for guest userspace to choose the optimal context type depending on the situation/hardware. 2) VIRTGPU_CONTEXT_PARAM_NUM_RINGS This tells the number of independent command rings that the context will use. This value may be zero and is inferred to be zero if VIRTGPU_CONTEXT_PARAM_NUM_RINGS is not passed in. This is for backwards compatibility for virgl, which has one big giant command ring for all commands. The maxiumum number of rings is 64. In practice, multi-queue or multi-ring submission is used for powerful dGPUs and virtio-gpu may not be the best option in that case (see PCI passthrough or rendernode forwarding). 3) VIRTGPU_CONTEXT_PARAM_POLL_RING_IDX_MASK This is a mask of ring indices for which the DRM fd is pollable. For example, if VIRTGPU_CONTEXT_PARAM_NUM_RINGS is 2, then the mask may be: [ring idx] | [1 << ring_idx] | final mask ------------------------------------------- 0 1 1 1 2 3 The "Sommelier" guest Wayland proxy uses this to poll for events from the host compositor. Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Acked-by: Lingfeng Yang <lfy@google.com> Acked-by: Nicholas Verne <nverne@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-3-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-09-21 16:20:14 -07:00
drm/virtio: add uapi for in and out explicit fences Add a new field called fence_fd that will be used by userspace to send in-fences to the kernel and receive out-fences created by the kernel. This uapi enables virtio to take advantage of explicit synchronization of dma-bufs. There are two new flags: * VIRTGPU_EXECBUF_FENCE_FD_IN to be used when passing an in-fence fd. * VIRTGPU_EXECBUF_FENCE_FD_OUT to be used when requesting an out-fence fd The execbuffer IOCTL is now read-write to allow the userspace to read the out-fence. On error -1 should be returned in the fence_fd field. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Robert Foss <robert.foss@collabora.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20181112165157.32765-3-robert.foss@collabora.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-11-12 17:51:55 +01:00
drm/virtgpu api: create context init feature This change allows creating contexts of depending on set of context parameters. The meaning of each of the parameters is listed below: 1) VIRTGPU_CONTEXT_PARAM_CAPSET_ID This determines the type of a context based on the capability set ID. For example, the current capsets: VIRTIO_GPU_CAPSET_VIRGL VIRTIO_GPU_CAPSET_VIRGL2 define a Gallium, TGSI based "virgl" context. We only need 1 capset ID per context type, though virgl has two due a bug that has since been fixed. The use case is the "gfxstream" rendering library and "venus" renderer. gfxstream doesn't do Gallium/TGSI translation and mostly relies on auto-generated API streaming. Certain users prefer gfxstream over virgl for GLES on GLES emulation. {gfxstream vk}/{venus} are also required for Vulkan emulation. The maximum capset ID is 63. The goal is for guest userspace to choose the optimal context type depending on the situation/hardware. 2) VIRTGPU_CONTEXT_PARAM_NUM_RINGS This tells the number of independent command rings that the context will use. This value may be zero and is inferred to be zero if VIRTGPU_CONTEXT_PARAM_NUM_RINGS is not passed in. This is for backwards compatibility for virgl, which has one big giant command ring for all commands. The maxiumum number of rings is 64. In practice, multi-queue or multi-ring submission is used for powerful dGPUs and virtio-gpu may not be the best option in that case (see PCI passthrough or rendernode forwarding). 3) VIRTGPU_CONTEXT_PARAM_POLL_RING_IDX_MASK This is a mask of ring indices for which the DRM fd is pollable. For example, if VIRTGPU_CONTEXT_PARAM_NUM_RINGS is 2, then the mask may be: [ring idx] | [1 << ring_idx] | final mask ------------------------------------------- 0 1 1 1 2 3 The "Sommelier" guest Wayland proxy uses this to poll for events from the host compositor. Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Acked-by: Lingfeng Yang <lfy@google.com> Acked-by: Nicholas Verne <nverne@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-3-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-09-21 16:20:14 -07:00
drm/virtio: add uapi for in and out explicit fences Add a new field called fence_fd that will be used by userspace to send in-fences to the kernel and receive out-fences created by the kernel. This uapi enables virtio to take advantage of explicit synchronization of dma-bufs. There are two new flags: * VIRTGPU_EXECBUF_FENCE_FD_IN to be used when passing an in-fence fd. * VIRTGPU_EXECBUF_FENCE_FD_OUT to be used when requesting an out-fence fd The execbuffer IOCTL is now read-write to allow the userspace to read the out-fence. On error -1 should be returned in the fence_fd field. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Robert Foss <robert.foss@collabora.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20181112165157.32765-3-robert.foss@collabora.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-11-12 17:51:55 +01:00
virtio-gpu: add 3d/virgl support Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-10-28 12:48:00 +01:00
drm: use __u{32,64} instead of uint{32,64}_t in virtgpu_drm.h Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> CC: Emil Velikov <emil.l.velikov@gmail.com> CC: Mikko Rapeli <mikko.rapeli@iki.fi>
2015-11-30 15:10:39 +01:00
virtio-gpu: add 3d/virgl support Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-10-28 12:48:00 +01:00
drm/virtio: add uapi for in and out explicit fences Add a new field called fence_fd that will be used by userspace to send in-fences to the kernel and receive out-fences created by the kernel. This uapi enables virtio to take advantage of explicit synchronization of dma-bufs. There are two new flags: * VIRTGPU_EXECBUF_FENCE_FD_IN to be used when passing an in-fence fd. * VIRTGPU_EXECBUF_FENCE_FD_OUT to be used when requesting an out-fence fd The execbuffer IOCTL is now read-write to allow the userspace to read the out-fence. On error -1 should be returned in the fence_fd field. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Robert Foss <robert.foss@collabora.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20181112165157.32765-3-robert.foss@collabora.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-11-12 17:51:55 +01:00
drm: use __u{32,64} instead of uint{32,64}_t in virtgpu_drm.h Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> CC: Emil Velikov <emil.l.velikov@gmail.com> CC: Mikko Rapeli <mikko.rapeli@iki.fi>
2015-11-30 15:10:39 +01:00
drm/virtio: add in/out fence support for explicit synchronization When the execbuf call receives an in-fence it will get the dma_fence related to that fence fd and wait on it before submitting the draw call. On the out-fence side we get fence returned by the submitted draw call and attach it to a sync_file and send the sync_file fd to userspace. On error -1 is returned to userspace. VIRTGPU_EXECBUF_FENCE_FD_IN & VIRTGPU_EXECBUF_FENCE_FD_OUT are supported at the simultaneously and can be flagged for simultaneously. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Robert Foss <robert.foss@collabora.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20181112165157.32765-4-robert.foss@collabora.com Suggested-by: Rob Herring <robh@kernel.org> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-11-12 17:51:56 +01:00
drm/virtgpu api: create context init feature This change allows creating contexts of depending on set of context parameters. The meaning of each of the parameters is listed below: 1) VIRTGPU_CONTEXT_PARAM_CAPSET_ID This determines the type of a context based on the capability set ID. For example, the current capsets: VIRTIO_GPU_CAPSET_VIRGL VIRTIO_GPU_CAPSET_VIRGL2 define a Gallium, TGSI based "virgl" context. We only need 1 capset ID per context type, though virgl has two due a bug that has since been fixed. The use case is the "gfxstream" rendering library and "venus" renderer. gfxstream doesn't do Gallium/TGSI translation and mostly relies on auto-generated API streaming. Certain users prefer gfxstream over virgl for GLES on GLES emulation. {gfxstream vk}/{venus} are also required for Vulkan emulation. The maximum capset ID is 63. The goal is for guest userspace to choose the optimal context type depending on the situation/hardware. 2) VIRTGPU_CONTEXT_PARAM_NUM_RINGS This tells the number of independent command rings that the context will use. This value may be zero and is inferred to be zero if VIRTGPU_CONTEXT_PARAM_NUM_RINGS is not passed in. This is for backwards compatibility for virgl, which has one big giant command ring for all commands. The maxiumum number of rings is 64. In practice, multi-queue or multi-ring submission is used for powerful dGPUs and virtio-gpu may not be the best option in that case (see PCI passthrough or rendernode forwarding). 3) VIRTGPU_CONTEXT_PARAM_POLL_RING_IDX_MASK This is a mask of ring indices for which the DRM fd is pollable. For example, if VIRTGPU_CONTEXT_PARAM_NUM_RINGS is 2, then the mask may be: [ring idx] | [1 << ring_idx] | final mask ------------------------------------------- 0 1 1 1 2 3 The "Sommelier" guest Wayland proxy uses this to poll for events from the host compositor. Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Acked-by: Lingfeng Yang <lfy@google.com> Acked-by: Nicholas Verne <nverne@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-3-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-09-21 16:20:14 -07:00
virtio-gpu: add 3d/virgl support Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-10-28 12:48:00 +01:00
virtio-gpu: fix ioctl and expose the fixed status to userspace. This exposes to mesa that it can use the fixed ioctl for querying later cap sets, cap set 1 is forever frozen in time. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/20180221015003.22884-1-airlied@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-02-21 11:50:03 +10:00
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 <gurchetansingh@chromium.org> Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Chia-I Wu <olvaffe@gmail.com> Acked-by: Lingfeng Yang <lfy@google.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-5-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-09-23 17:32:00 -07:00
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 <gurchetansingh@chromium.org> Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Lingfeng Yang <lfy@google.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-6-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-09-23 17:32:01 -07:00
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 <gurchetansingh@chromium.org> Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-7-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-09-23 17:32:02 -07:00
drm/virtgpu api: create context init feature This change allows creating contexts of depending on set of context parameters. The meaning of each of the parameters is listed below: 1) VIRTGPU_CONTEXT_PARAM_CAPSET_ID This determines the type of a context based on the capability set ID. For example, the current capsets: VIRTIO_GPU_CAPSET_VIRGL VIRTIO_GPU_CAPSET_VIRGL2 define a Gallium, TGSI based "virgl" context. We only need 1 capset ID per context type, though virgl has two due a bug that has since been fixed. The use case is the "gfxstream" rendering library and "venus" renderer. gfxstream doesn't do Gallium/TGSI translation and mostly relies on auto-generated API streaming. Certain users prefer gfxstream over virgl for GLES on GLES emulation. {gfxstream vk}/{venus} are also required for Vulkan emulation. The maximum capset ID is 63. The goal is for guest userspace to choose the optimal context type depending on the situation/hardware. 2) VIRTGPU_CONTEXT_PARAM_NUM_RINGS This tells the number of independent command rings that the context will use. This value may be zero and is inferred to be zero if VIRTGPU_CONTEXT_PARAM_NUM_RINGS is not passed in. This is for backwards compatibility for virgl, which has one big giant command ring for all commands. The maxiumum number of rings is 64. In practice, multi-queue or multi-ring submission is used for powerful dGPUs and virtio-gpu may not be the best option in that case (see PCI passthrough or rendernode forwarding). 3) VIRTGPU_CONTEXT_PARAM_POLL_RING_IDX_MASK This is a mask of ring indices for which the DRM fd is pollable. For example, if VIRTGPU_CONTEXT_PARAM_NUM_RINGS is 2, then the mask may be: [ring idx] | [1 << ring_idx] | final mask ------------------------------------------- 0 1 1 1 2 3 The "Sommelier" guest Wayland proxy uses this to poll for events from the host compositor. Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Acked-by: Lingfeng Yang <lfy@google.com> Acked-by: Nicholas Verne <nverne@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-3-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-09-21 16:20:14 -07:00
virtio-gpu: add 3d/virgl support Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-10-28 12:48:00 +01:00
drm: use __u{32,64} instead of uint{32,64}_t in virtgpu_drm.h Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> CC: Emil Velikov <emil.l.velikov@gmail.com> CC: Mikko Rapeli <mikko.rapeli@iki.fi>
2015-11-30 15:10:39 +01:00
virtio-gpu: add 3d/virgl support Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-10-28 12:48:00 +01:00
drm: use __u{32,64} instead of uint{32,64}_t in virtgpu_drm.h Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> CC: Emil Velikov <emil.l.velikov@gmail.com> CC: Mikko Rapeli <mikko.rapeli@iki.fi>
2015-11-30 15:10:39 +01:00
virtio-gpu: add 3d/virgl support Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-10-28 12:48:00 +01:00
drm: use __u{32,64} instead of uint{32,64}_t in virtgpu_drm.h Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> CC: Emil Velikov <emil.l.velikov@gmail.com> CC: Mikko Rapeli <mikko.rapeli@iki.fi>
2015-11-30 15:10:39 +01:00
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 <gurchetansingh@chromium.org> Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Chia-I Wu <olvaffe@gmail.com> Acked-by: Lingfeng Yang <lfy@google.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-5-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-09-23 17:32:00 -07:00
virtio-gpu: add 3d/virgl support Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-10-28 12:48:00 +01:00
drm: use __u{32,64} instead of uint{32,64}_t in virtgpu_drm.h Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> CC: Emil Velikov <emil.l.velikov@gmail.com> CC: Mikko Rapeli <mikko.rapeli@iki.fi>
2015-11-30 15:10:39 +01:00
virtio-gpu: add 3d/virgl support Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-10-28 12:48:00 +01:00
drm: use __u{32,64} instead of uint{32,64}_t in virtgpu_drm.h Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> CC: Emil Velikov <emil.l.velikov@gmail.com> CC: Mikko Rapeli <mikko.rapeli@iki.fi>
2015-11-30 15:10:39 +01:00
virtio-gpu: add 3d/virgl support Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-10-28 12:48:00 +01:00
drm: use __u{32,64} instead of uint{32,64}_t in virtgpu_drm.h Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> CC: Emil Velikov <emil.l.velikov@gmail.com> CC: Mikko Rapeli <mikko.rapeli@iki.fi>
2015-11-30 15:10:39 +01:00
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 <gurchetansingh@chromium.org> Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Chia-I Wu <olvaffe@gmail.com> Acked-by: Lingfeng Yang <lfy@google.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-5-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-09-23 17:32:00 -07:00
virtio-gpu: add 3d/virgl support Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-10-28 12:48:00 +01:00
drm: use __u{32,64} instead of uint{32,64}_t in virtgpu_drm.h Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> CC: Emil Velikov <emil.l.velikov@gmail.com> CC: Mikko Rapeli <mikko.rapeli@iki.fi>
2015-11-30 15:10:39 +01:00
virtio-gpu: add 3d/virgl support Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-10-28 12:48:00 +01:00
drm: use __u{32,64} instead of uint{32,64}_t in virtgpu_drm.h Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> CC: Emil Velikov <emil.l.velikov@gmail.com> CC: Mikko Rapeli <mikko.rapeli@iki.fi>
2015-11-30 15:10:39 +01:00
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 <gurchetansingh@chromium.org> Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Chia-I Wu <olvaffe@gmail.com> Acked-by: Lingfeng Yang <lfy@google.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-5-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-09-23 17:32:00 -07:00
virtio-gpu: add 3d/virgl support Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-10-28 12:48:00 +01:00
drm: use __u{32,64} instead of uint{32,64}_t in virtgpu_drm.h Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> CC: Emil Velikov <emil.l.velikov@gmail.com> CC: Mikko Rapeli <mikko.rapeli@iki.fi>
2015-11-30 15:10:39 +01:00
virtio-gpu: add 3d/virgl support Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-10-28 12:48:00 +01:00
drm: use __u{32,64} instead of uint{32,64}_t in virtgpu_drm.h Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> CC: Emil Velikov <emil.l.velikov@gmail.com> CC: Mikko Rapeli <mikko.rapeli@iki.fi>
2015-11-30 15:10:39 +01:00
virtio-gpu: add 3d/virgl support Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-10-28 12:48:00 +01:00
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 <gurchetansingh@chromium.org> Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Chia-I Wu <olvaffe@gmail.com> Acked-by: Lingfeng Yang <lfy@google.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-5-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-09-23 17:32:00 -07:00
drm/virtgpu api: create context init feature This change allows creating contexts of depending on set of context parameters. The meaning of each of the parameters is listed below: 1) VIRTGPU_CONTEXT_PARAM_CAPSET_ID This determines the type of a context based on the capability set ID. For example, the current capsets: VIRTIO_GPU_CAPSET_VIRGL VIRTIO_GPU_CAPSET_VIRGL2 define a Gallium, TGSI based "virgl" context. We only need 1 capset ID per context type, though virgl has two due a bug that has since been fixed. The use case is the "gfxstream" rendering library and "venus" renderer. gfxstream doesn't do Gallium/TGSI translation and mostly relies on auto-generated API streaming. Certain users prefer gfxstream over virgl for GLES on GLES emulation. {gfxstream vk}/{venus} are also required for Vulkan emulation. The maximum capset ID is 63. The goal is for guest userspace to choose the optimal context type depending on the situation/hardware. 2) VIRTGPU_CONTEXT_PARAM_NUM_RINGS This tells the number of independent command rings that the context will use. This value may be zero and is inferred to be zero if VIRTGPU_CONTEXT_PARAM_NUM_RINGS is not passed in. This is for backwards compatibility for virgl, which has one big giant command ring for all commands. The maxiumum number of rings is 64. In practice, multi-queue or multi-ring submission is used for powerful dGPUs and virtio-gpu may not be the best option in that case (see PCI passthrough or rendernode forwarding). 3) VIRTGPU_CONTEXT_PARAM_POLL_RING_IDX_MASK This is a mask of ring indices for which the DRM fd is pollable. For example, if VIRTGPU_CONTEXT_PARAM_NUM_RINGS is 2, then the mask may be: [ring idx] | [1 << ring_idx] | final mask ------------------------------------------- 0 1 1 1 2 3 The "Sommelier" guest Wayland proxy uses this to poll for events from the host compositor. Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Acked-by: Lingfeng Yang <lfy@google.com> Acked-by: Nicholas Verne <nverne@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-3-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-09-21 16:20:14 -07:00
drm/virtgpu api: define a dummy fence signaled event The current virtgpu implementation of poll(..) drops events when VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK is enabled (otherwise it's like a normal DRM driver). This is because paravirtualized userspaces receives responses in a buffer of type BLOB_MEM_GUEST, not by read(..). To be in line with other DRM drivers and avoid specialized behavior, it is possible to define a dummy event for virtgpu. Paravirtualized userspace will now have to call read(..) on the DRM fd to receive the dummy event. Fixes: b10790434cf2 ("drm/virtgpu api: create context init feature") Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20211122232210.602-2-gurchetansingh@google.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-11-22 15:22:09 -08:00
virtio-gpu: add 3d/virgl support Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-10-28 12:48:00 +01:00
drm/virtio: add uapi for in and out explicit fences Add a new field called fence_fd that will be used by userspace to send in-fences to the kernel and receive out-fences created by the kernel. This uapi enables virtio to take advantage of explicit synchronization of dma-bufs. There are two new flags: * VIRTGPU_EXECBUF_FENCE_FD_IN to be used when passing an in-fence fd. * VIRTGPU_EXECBUF_FENCE_FD_OUT to be used when requesting an out-fence fd The execbuffer IOCTL is now read-write to allow the userspace to read the out-fence. On error -1 should be returned in the fence_fd field. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Robert Foss <robert.foss@collabora.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20181112165157.32765-3-robert.foss@collabora.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-11-12 17:51:55 +01:00
virtio-gpu: add 3d/virgl support Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-10-28 12:48:00 +01:00
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 <gurchetansingh@chromium.org> Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Chia-I Wu <olvaffe@gmail.com> Acked-by: Lingfeng Yang <lfy@google.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-5-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-09-23 17:32:00 -07:00
drm/virtgpu api: create context init feature This change allows creating contexts of depending on set of context parameters. The meaning of each of the parameters is listed below: 1) VIRTGPU_CONTEXT_PARAM_CAPSET_ID This determines the type of a context based on the capability set ID. For example, the current capsets: VIRTIO_GPU_CAPSET_VIRGL VIRTIO_GPU_CAPSET_VIRGL2 define a Gallium, TGSI based "virgl" context. We only need 1 capset ID per context type, though virgl has two due a bug that has since been fixed. The use case is the "gfxstream" rendering library and "venus" renderer. gfxstream doesn't do Gallium/TGSI translation and mostly relies on auto-generated API streaming. Certain users prefer gfxstream over virgl for GLES on GLES emulation. {gfxstream vk}/{venus} are also required for Vulkan emulation. The maximum capset ID is 63. The goal is for guest userspace to choose the optimal context type depending on the situation/hardware. 2) VIRTGPU_CONTEXT_PARAM_NUM_RINGS This tells the number of independent command rings that the context will use. This value may be zero and is inferred to be zero if VIRTGPU_CONTEXT_PARAM_NUM_RINGS is not passed in. This is for backwards compatibility for virgl, which has one big giant command ring for all commands. The maxiumum number of rings is 64. In practice, multi-queue or multi-ring submission is used for powerful dGPUs and virtio-gpu may not be the best option in that case (see PCI passthrough or rendernode forwarding). 3) VIRTGPU_CONTEXT_PARAM_POLL_RING_IDX_MASK This is a mask of ring indices for which the DRM fd is pollable. For example, if VIRTGPU_CONTEXT_PARAM_NUM_RINGS is 2, then the mask may be: [ring idx] | [1 << ring_idx] | final mask ------------------------------------------- 0 1 1 1 2 3 The "Sommelier" guest Wayland proxy uses this to poll for events from the host compositor. Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Acked-by: Lingfeng Yang <lfy@google.com> Acked-by: Nicholas Verne <nverne@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-3-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-09-21 16:20:14 -07:00
drm/virgl: add extern C guard for the UAPI header Cc: Dave Airlie <airlied@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
2016-04-07 19:38:49 +01:00
virtio-gpu: add 3d/virgl support Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-10-28 12:48:00 +01:00