Re: [Qemu-devel] [virtio-dev] [PATCH] Add virtio gpu device specification.

[Michael S. Tsirkin]

On Wed, Jun 27, 2018 at 08:15:08AM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > > > > >   
> > > > > > https://www.kraxel.org/virtio/virtio-v1.0-cs03-virtio-gpu.html#x1-287
> 
> > Is there a chance you could rebase and post?
> > This is used widely, I think we shoould have it in 1.1
> > if at all possible.
> 
> https://www.kraxel.org/virtio/virtio-v1.0-cs04-virtio-gpu.html#x1-3150007
> 
> Repost will follow in a moment.
> 
> For virtio-input I don't have the latest version at hand,
> Ladi worked on it last.
> 
> cheers,
>   Gerd

Resent to you in a private mail.

> 
> -
> To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org

Re: [Qemu-devel] [virtio-dev] [PATCH] Add virtio gpu device specification.

[Gerd Hoffmann]

  Hi,

> > > > >   
> > > > > https://www.kraxel.org/virtio/virtio-v1.0-cs03-virtio-gpu.html#x1-287

> Is there a chance you could rebase and post?
> This is used widely, I think we shoould have it in 1.1
> if at all possible.

https://www.kraxel.org/virtio/virtio-v1.0-cs04-virtio-gpu.html#x1-3150007

Repost will follow in a moment.

For virtio-input I don't have the latest version at hand,
Ladi worked on it last.

cheers,
  Gerd

Re: [Qemu-devel] [virtio-dev] [PATCH] Add virtio gpu device specification.

[Michael S. Tsirkin]

On Tue, May 10, 2016 at 01:25:37PM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > > > 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-287
> 
> > > 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.
> 
> Updated now.
> 
> cheers,
>   Gerd

Is there a chance you could rebase and post?
This is used widely, I think we shoould have it in 1.1
if at all possible.


> 
> -
> To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org

Re: [Qemu-devel] [virtio-dev] [PATCH] Add virtio gpu device specification.

[Gerd Hoffmann]

  Hi,

> > > 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-287

> > 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.

Updated now.

cheers,
  Gerd

Re: [Qemu-devel] [virtio-dev] [PATCH] Add virtio gpu device specification.

[Gerd Hoffmann]

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-287
> > 
> > Signed-off-by: Gerd Hoffmann 
> > ---
> >  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
cursorq).

> I guess the
> resource_id namespace includes both queues.

Yes.

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

Yes.

> The actual VIRTIO_GPU_CMD_UPDATE_CURSOR
> 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
> VIRTIO_GPU_CMD_UPDATE_CURSOR and VIRTIO_GPU_CMD_MOVE_CURSOR?

Yes.

cheers,
  Gerd

Re: [Qemu-devel] [virtio-dev] [PATCH] Add virtio gpu device specification.

[Stefan Hajnoczi]

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-287
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  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