[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] [PATCH] Add virtio gpu device specification.
On Wed, May 04, 2016 at 03:05:34PM +0200, Gerd Hoffmann wrote: > Resuming the effort to get the gpu device specs merged. > > Support for 2d mode (3d/virgl mode is not covered by this patch) has > been added to the linux kernel version 4.2 and to qemu version 2.4. > > git branch: > https://www.kraxel.org/cgit/virtio-spec/commit/?h=virtio-gpu > > Rendered versions are available here: > https://www.kraxel.org/virtio/virtio-v1.0-cs03-virtio-gpu.pdf > https://www.kraxel.org/virtio/virtio-v1.0-cs03-virtio-gpu.html#x1-2800007 > > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> > --- > content.tex | 2 + > virtio-gpu.tex | 467 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 469 insertions(+) > create mode 100644 virtio-gpu.tex Please add a command execution model section that explains the command lifecycle and interactions between commands. From reading through the spec once I've gathered the fence flag can be used to force execution. I guess a non-fenced command only completes when the operation has finished, too (so that a meaningful success/error value can be produced)? Are there any interactions between the two queues? I guess the resource_id namespace includes both queues. The 64x64 cursor would be initialized on the controlq. The actual VIRTIO_GPU_CMD_UPDATE_CURSOR and VIRTIO_GPU_CMD_MOVE_CURSOR can be sent via either queue. The cursorq does not accept any commands other than VIRTIO_GPU_CMD_UPDATE_CURSOR and VIRTIO_GPU_CMD_MOVE_CURSOR?
Attachment:
signature.asc
Description: PGP signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]