All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Gerd Hoffmann <kraxel@redhat.com>,
	Gurchetan Singh <gurchetansingh@chromium.org>,
	David Stevens <stevensd@chromium.org>
Cc: virtio-dev@lists.oasis-open.org, stratos-dev@op-lists.linaro.org,
	Peter Griffin <peter.griffin@linaro.org>
Subject: [virtio-dev] Question on VirGL/virtio-gpu features
Date: Fri, 04 Jun 2021 10:55:57 +0100	[thread overview]
Message-ID: <87lf7p7wez.fsf@linaro.org> (raw)


Hi All,

I was having a discussion the other day with an external team looking at
using virtualised graphics for a production platform. They had some
questions about features I couldn't answer due to my imperfect
understanding of all the moving parts. Does anyone know of any work
being done on the following:

Alternate pixel formats
-----------------------

I believe this is related to pixel data being expressed in different
colour spaces. I see that VIRTIO_GPU_CMD_RESOURCE_CREATE_2D has the
notion of different RGB layouts for pixel data. For 3D pixel data is
this something that is ever visible to the virtio layer or is this all
handled from within the OpenGL interface? I see there is a
VIRTIO_GPU_CMD_SET_SCANOUT_BLOB for defining resources that can get
referenced but that is still restricted to the same virtio_gpu_formats.

Overlay planes
--------------

As I understand it these are used for compositing multiple graphics
sources. We currently working on a virtualised virtio-video backend and
at some point we'll want to consider how you might overlay a 3D view
from one VM with a video source from a second VM and either do the
compositing in the host system or potentially a 3rd VM. Is anyone aware
of any work being done in this direction yet?

vsync
-----

The existing virtio-gpu spec doesn't mention vsync at all. My last
experience with active vsync synchronisation was back in the days of the
Atari ST so I'm a little behind on how it works with modern 3D. Is this
something that ever needs to be exposed to the guest or is it preserve
of the host system to ensure newly drawn frames are swapped out at the
right time to avoid tearing? The Khronos pages refer to Swap Interval
being a platform specific extension. Does this mean it needs to be
something specifically handled by VirGL? 

DRM
---

Probably the least interesting problem from an open source point of view
but I guess for media consumers their needs to be a solution for DRM
protected streams to leave a VM and be handled "somewhere" else. Are
there any proposals for exposing DRM via VirtIO that anyone is aware of?

Any pointers gratefully received! Thanks in advance,

-- 
Alex Bennée

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


                 reply	other threads:[~2021-06-04 10:32 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lf7p7wez.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=gurchetansingh@chromium.org \
    --cc=kraxel@redhat.com \
    --cc=peter.griffin@linaro.org \
    --cc=stevensd@chromium.org \
    --cc=stratos-dev@op-lists.linaro.org \
    --cc=virtio-dev@lists.oasis-open.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.