OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[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 Mo, 2016-05-09 at 15:43 +0100, Stefan Hajnoczi wrote:
> 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.

No, it can be used for completion notification.

> I guess a non-fenced command only completes when the operation has
> finished, too (so that a meaningful success/error value can be
> produced)?

When stuff is processed asynchronously the command can complete before
the operation actually completed.  Current qemu implementation does that
only in 3d mode, when offloading stuff to the hardware (and verifies
stuff beforehand, so if you try to kick 3d rendering with an invalid
context id qemu will throw an error).

I'll try to make that more clear in the text.

> Are there any interactions between the two queues?

None, except the one already described in the cursor section (must
create cursors as 64x64 resources using controlq before using them via

> I guess the
> resource_id namespace includes both queues.


> The 64x64 cursor would be
> initialized on the controlq.


> and VIRTIO_GPU_CMD_MOVE_CURSOR can be sent via either queue.

No, cursor queue only.  They are described in the "Device Operation:
cursorq" section because of that.

> The
> cursorq does not accept any commands other than



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]