Gerd Hoffmann
2019-Feb-01 07:23 UTC
[PATCH v2 5/6] drm/virtio: drop fencing in virtio_gpu_resource_create_ioctl
On Thu, Jan 31, 2019 at 11:04:31AM -0800, Gurchetan Singh wrote:> On Wed, Jan 30, 2019 at 1:43 AM Gerd Hoffmann <kraxel at redhat.com> wrote: > > > > There is no need to wait for completion here. > > > > The host will process commands in submit order, so commands can > > reference the new resource just fine even when queued up before > > completion. > > Does virtio_gpu_execbuffer_ioctl also wait for completion for a host response?No. But you pass in a list of objects (drm_virtgpu_execbuffer->bo_handles) used. They will all get reserved, so you can use DRM_IOCTL_VIRTGPU_WAIT on any of these objects to wait for completion. Recently the driver got support for returning a fence fd for the execbuffer, which you can also use to wait for completion in case your kernel is new enough.> From the guest driver perspective, a fence is just implemented has a > virtio 3D resource. > > https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c#L787 > > The DRM_IOCTL_VIRTGPU_WAIT ioctl essentially waits for the reservation > objects associated with that fence resource to become available. So > the flow is: > > virtio_gpu_execbuffer_ioctl > virtio_gpu_resource_create_ioctl with fence resource > virtio_gpu_wait_ioctl with that fence resource --> associated with a > GL wait on the host sideOh. /me looks surprised. Wasn't aware that userspace is doing *that*.> Does this change modify this sequence of events?Yes. DRM_IOCTL_VIRTGPU_WAIT will not wait any more. Guess I have to scratch the patch then ... cheers, Gerd
Reasonably Related Threads
- [PATCH 3/5] update virtio gpu driver: add 3d/virgl support
- [PATCH 3/5] update virtio gpu driver: add 3d/virgl support
- [PATCH v3 4/7] virtio-gpu: add 3d/virgl support
- [PATCH v3 4/7] virtio-gpu: add 3d/virgl support
- [PATCH v2 4/6] virtio-gpu: add 3d/virgl support