Reviewed-by: Josh Simonot
On Mon, 16 Oct 2023 at 14:42, Gurchetan Singh
wrote:
> drm_virtgpu_context_set_param defines both param and
> value to be u64s.
>
> Signed-off-by: Gurchetan Singh
> ---
> drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 ++--
> 1 file change
Reviewed-by: Josh Simonot
On Mon, 16 Oct 2023 at 14:42, Gurchetan Singh
wrote:
> 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_NAM
Reviewed-by: Josh Simonot
On Mon, 16 Oct 2023 at 14:42, Gurchetan Singh
wrote:
> This allows setting the debug name during CONTEXT_INIT.
>
> Signed-off-by: Gurchetan Singh
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 4 +++
> drivers/gpu/drm/virtio/vi
It looks like the virtio-gpu flush should be fenced, but on the host side the
received flush cmd doesn't have the fence flag set, and no fence_id. So, I
have to reply right away instead of waiting for scanout to complete. Is that
expected? then what's the right way to vsync the guest?
At the
> If virgl=true (which means blob=false at the moment), then things work
> very differently.
Yes, we're using virglrenderer. The flushed resources are backed by host
allocated buffers. We tried posting the flushed resource directly to the
display and replied to the flush immediately (since not f
