Displaying 3 results from an estimated 3 matches for "virtio_ioctl_resource_wait".
2019 Jul 04
2
[PATCH v6 08/18] drm/virtio: rework virtio_gpu_execbuffer_ioctl fencing
Hi,
> > if (fence)
> > virtio_gpu_fence_emit(vgdev, hdr, fence);
> > + if (vbuf->objs) {
> > + virtio_gpu_array_add_fence(vbuf->objs, &fence->f);
> > + virtio_gpu_array_unlock_resv(vbuf->objs);
> > + }
> This is with the spinlock held. Maybe we should move the
>
2019 Jul 04
2
[PATCH v6 08/18] drm/virtio: rework virtio_gpu_execbuffer_ioctl fencing
Hi,
> > if (fence)
> > virtio_gpu_fence_emit(vgdev, hdr, fence);
> > + if (vbuf->objs) {
> > + virtio_gpu_array_add_fence(vbuf->objs, &fence->f);
> > + virtio_gpu_array_unlock_resv(vbuf->objs);
> > + }
> This is with the spinlock held. Maybe we should move the
>
2019 Jul 04
0
[PATCH v6 08/18] drm/virtio: rework virtio_gpu_execbuffer_ioctl fencing
...competing for
> virtio buffers I guess? Maybe we should have larger virtqueues?
The game was single-threaded. I guess it was the game and Xorg
competing for virtio buffers. That was also on an older kernel
without explicit fences. The userspace had to create dummy resources
frequently to do VIRTIO_IOCTL_RESOURCE_WAIT.
I think this is fine for now as far as I am concerned. I can look
into this more closely after this series lands.
>
> cheers,
> Gerd
>