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 <kra...@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?
signature.asc
Description: PGP signature
