drm/uapi: add explicit virtgpu context debug name

There are two problems with the current method of determining the
virtio-gpu debug name.

1) TASK_COMM_LEN is defined to be 16 bytes only, and this

drm/uapi: add explicit virtgpu context debug name

There are two problems with the current method of determining the
virtio-gpu debug name.

1) TASK_COMM_LEN is defined to be 16 bytes only, and this is a
Linux kernel idiom (see PR_SET_NAME + PR_GET_NAME). Though,
Android/FreeBSD get around this via setprogname(..)/getprogname(..)
in libc.

On Android, names longer than 16 bytes are common. For example,
one often encounters a program like "com.android.systemui".

The virtio-gpu spec allows the debug name to be up to 64 bytes, so
ideally userspace should be able to set debug names up to 64 bytes.

2) The current implementation determines the debug name using whatever
task initiated virtgpu. This is could be a "RenderThread" of a
larger program, when we actually want to propagate the debug name
of the program.

To fix these issues, add a new CONTEXT_INIT param that allows userspace
to set the debug name when creating a context.

It takes a null-terminated C-string as the param value. The length of the
string (excluding the terminator) **should** be <= 64 bytes. Otherwise,
the debug_name will be truncated to 64 bytes.

Link to open-source userspace:
https://android-review.googlesource.com/c/platform/hardware/google/gfxstream/+/2787176

Signed-off-by: Gurchetan Singh <[email protected]>
Reviewed-by: Josh Simonot <[email protected]>
Reviewed-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Dmitry Osipenko <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/virtio: Support sync objects

Add sync object DRM UAPI support to VirtIO-GPU driver. Sync objects
support is needed by native context VirtIO-GPU Mesa drivers, it also will
be used by Venus and Vi

drm/virtio: Support sync objects

Add sync object DRM UAPI support to VirtIO-GPU driver. Sync objects
support is needed by native context VirtIO-GPU Mesa drivers, it also will
be used by Venus and Virgl contexts.

Reviewed-by; Emil Velikov <[email protected]>
Signed-off-by: Dmitry Osipenko <[email protected]>
Tested-by: Pierre-Eric Pelloux-Prayer <[email protected]> # amdgpu nctx
Tested-by: Rob Clark <[email protected]> # freedreno nctx
Reviewed-by: Rob Clark <[email protected]>
Acked-by: Gurchetan Singh <[email protected]>
Acked-by: Gerd Hoffmann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/virtio: exbuf->fence_fd unmodified on interrupted wait

An interrupted dma_fence_wait() becomes an -ERESTARTSYS returned
to userspace ioctl(DRM_IOCTL_VIRTGPU_EXECBUFFER) calls, prompting to
retry

drm/virtio: exbuf->fence_fd unmodified on interrupted wait

An interrupted dma_fence_wait() becomes an -ERESTARTSYS returned
to userspace ioctl(DRM_IOCTL_VIRTGPU_EXECBUFFER) calls, prompting to
retry the ioctl(), but the passed exbuf->fence_fd has been reset to -1,
making the retry attempt fail at sync_file_get_fence().

The uapi for DRM_IOCTL_VIRTGPU_EXECBUFFER is changed to retain the
passed value for exbuf->fence_fd when returning anything besides a
successful result from the ioctl.

Fixes: 2cd7b6f08bc4 ("drm/virtio: add in/out fence support for explicit synchronization")
Signed-off-by: Ryan Neph <[email protected]>
Reviewed-by: Rob Clark <[email protected]>
Reviewed-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Dmitry Osipenko <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

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 D

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 <[email protected]>
Signed-off-by: Gurchetan Singh <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Gerd Hoffmann <[email protected]>

show more ...

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_CONTE

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 <[email protected]>
Acked-by: Lingfeng Yang <[email protected]>
Acked-by: Nicholas Verne <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Gerd Hoffmann <[email protected]>

show more ...

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 presen

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 <[email protected]>
Acked-by: Tomeu Vizoso <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Gerd Hoffmann <[email protected]>

show more ...

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: Gurcheta

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 <[email protected]>
Acked-by: Tomeu Vizoso <[email protected]>
Acked-by: Lingfeng Yang <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Gerd Hoffmann <[email protected]>

show more ...

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 Pi

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 <[email protected]>
Acked-by: Tomeu Vizoso <[email protected]>
Acked-by: Chia-I Wu <[email protected]>
Acked-by: Lingfeng Yang <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Gerd Hoffmann <[email protected]>

show more ...

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 d

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 <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Suggested-by: Rob Herring <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Signed-off-by: Gerd Hoffmann <[email protected]>

show more ...

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

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 <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Gerd Hoffmann <[email protected]>

show more ...

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:

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 <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Gerd Hoffmann <[email protected]>

show more ...

drm/virgl: add extern C guard for the UAPI header

Cc: Dave Airlie <[email protected]>
Cc: Gerd Hoffmann <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>

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 import

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 <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
CC: Emil Velikov <[email protected]>
CC: Mikko Rapeli <[email protected]>

show more ...

drm: use __u{32,64} instead of uint{32,64}_t in virtgpu_drm.h

Signed-off-by: Gabriel Laskar <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
CC: Emil Velikov <emil.l.velik

drm: use __u{32,64} instead of uint{32,64}_t in virtgpu_drm.h

Signed-off-by: Gabriel Laskar <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
CC: Emil Velikov <[email protected]>
CC: Mikko Rapeli <[email protected]>

show more ...

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 <[email protected]>
Signed-off-by

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 <[email protected]>
Signed-off-by: Gerd Hoffmann <[email protected]>

show more ...