Prior versions:

https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg05801.html

https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg02341.html

https://patchew.org/QEMU/20230421011223.718-1-gurchetansingh@chromium.org/

Changes since v2:
- Incorporated review feedback

How to build both rutabaga and gfxstream guest/host libs:

https://crosvm.dev/book/appendix/rutabaga_gfx.html

Branch containing this patch series:

https://gitlab.freedesktop.org/gurchetansingh/qemu-gfxstream/-/commits/qemu-gfxstream-v3

Antonio Caggiano (2):
  virtio-gpu: CONTEXT_INIT feature
  virtio-gpu: blob prep

Dr. David Alan Gilbert (1):
  virtio: Add shared memory capability

Gerd Hoffmann (1):
  virtio-gpu: hostmem

Gurchetan Singh (5):
  gfxstream + rutabaga prep: added need defintions, fields, and options
  gfxstream + rutabaga: add initial support for gfxstream
  gfxstream + rutabaga: meson support
  gfxstream + rutabaga: enable rutabaga
  docs/system: add basic virtio-gpu documentation

 docs/system/device-emulation.rst     |    1 +
 docs/system/devices/virtio-gpu.rst   |  115 +++
 hw/display/meson.build               |   22 +
 hw/display/virtio-gpu-base.c         |    6 +-
 hw/display/virtio-gpu-pci-rutabaga.c |   48 ++
 hw/display/virtio-gpu-pci.c          |   14 +
 hw/display/virtio-gpu-rutabaga.c     | 1121 ++++++++++++++++++++++++++
 hw/display/virtio-gpu.c              |   17 +-
 hw/display/virtio-vga-rutabaga.c     |   51 ++
 hw/display/virtio-vga.c              |   33 +-
 hw/virtio/virtio-pci.c               |   18 +
 include/hw/virtio/virtio-gpu-bswap.h |   18 +
 include/hw/virtio/virtio-gpu.h       |   41 +
 include/hw/virtio/virtio-pci.h       |    4 +
 meson.build                          |    7 +
 meson_options.txt                    |    2 +
 scripts/meson-buildoptions.sh        |    3 +
 softmmu/qdev-monitor.c               |    3 +
 softmmu/vl.c                         |    1 +
 19 files changed, 1505 insertions(+), 20 deletions(-)
 create mode 100644 docs/system/devices/virtio-gpu.rst
 create mode 100644 hw/display/virtio-gpu-pci-rutabaga.c
 create mode 100644 hw/display/virtio-gpu-rutabaga.c
 create mode 100644 hw/display/virtio-vga-rutabaga.c

-- 
2.41.0.585.gd2178a4bd4-goog

Hello,

On 04/08/2023 01:54, Gurchetan Singh wrote:
> Prior versions:
> 
> https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg05801.html
> 
> https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg02341.html
> 
> https://patchew.org/QEMU/20230421011223.718-1-gurchetansingh@chromium.org/
> 
> Changes since v2:
> - Incorporated review feedback
> 
> How to build both rutabaga and gfxstream guest/host libs:
> 
> https://crosvm.dev/book/appendix/rutabaga_gfx.html
> 
> Branch containing this patch series:
> 
> https://gitlab.freedesktop.org/gurchetansingh/qemu-gfxstream/-/commits/qemu-gfxstream-v3

I tried this on Fedora with a Fedora guest and I was able to get Vulkan
headless applications as well as Wayland proxy with sommelier to work.
If you don't mind, I have a few questions.
I was not able to run Vulkan applications over the Wayland proxy, only
unaccelerated apps. This seems to be unsupported yet; is actually
unsupported for now or was something missing in my setup?

Also apparently GL/GLES is only supported on Android right now as you
mentioned, since on Linux the gfxstream guest only installs the Vulkan
library and icd. What is the plan to support GL on Linux; provide
gfxstream GL guest libraries later or enable Zink or some other solution?
Then if I understand correctly, Mesa virgl is not used at all with the
gfxstream solution, so I guess we would need to find a way to ship the
gfxstream guest libraries too on distributions?
Also I wonder about including all of the the dependencies required to
get this to build on distributions as well to enable the feature on
distribution-provided qemu, but I guess we can figure this out later...

And finally out of curiosity, I see that rutabaga also has a
virgl_renderer (and virgl_renderer_next) backend which would then not
use gfxstream but virglrenderer instead. I wonder if there would be any
benefit/features in enabling that with qemu later compared to the
current qemu virtio/virglrenderer implementation (if that would make
sense at all)?

Thanks

Erico

On Mon, Aug 7, 2023 at 7:24 AM Erico Nunes <ernunes@redhat.com> wrote:

> Hello,
>
> On 04/08/2023 01:54, Gurchetan Singh wrote:
> > Prior versions:
> >
> > https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg05801.html
> >
> > https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg02341.html
> >
> >
> https://patchew.org/QEMU/20230421011223.718-1-gurchetansingh@chromium.org/
> >
> > Changes since v2:
> > - Incorporated review feedback
> >
> > How to build both rutabaga and gfxstream guest/host libs:
> >
> > https://crosvm.dev/book/appendix/rutabaga_gfx.html
> >
> > Branch containing this patch series:
> >
> >
> https://gitlab.freedesktop.org/gurchetansingh/qemu-gfxstream/-/commits/qemu-gfxstream-v3
>
> I tried this on Fedora with a Fedora guest and I was able to get Vulkan
> headless applications as well as Wayland proxy with sommelier to work.
> If you don't mind, I have a few questions.
> I was not able to run Vulkan applications over the Wayland proxy, only
> unaccelerated apps. This seems to be unsupported yet; is actually
> unsupported for now or was something missing in my setup?
>

Yes, currently this is unsupported.  In the near future, I do imagine 3D
accelerated rendering over cross-domain to be a thing (among many context
types, not just gfxstream VK).

Re: using gfxstream VK in Linux distros, depends on your use case.  If you
are looking for best performance over virtio on open-source Linux
platforms, perhaps gfxstream Vulkan (or any API virtualization solution) is
not your best bet.  The Mesa native context work looks particularly
exciting there:

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658

We are interested in running gfxstream VK in Linux guests, but we envisage
that for reference and testing.  For all embedded use cases, using the host
driver in the guest will predominate due to performance considerations
(either through virtio or HW direct / mediated passthru).

Also apparently GL/GLES is only supported on Android right now as you
> mentioned, since on Linux the gfxstream guest only installs the Vulkan
> library and icd. What is the plan to support GL on Linux; provide
> gfxstream GL guest libraries later or enable Zink or some other solution?
> Then if I understand correctly, Mesa virgl is not used at all with the
> gfxstream solution, so I guess we would need to find a way to ship the
> gfxstream guest libraries too on distributions?



Also I wonder about including all of the the dependencies required to
> get this to build on distributions as well to enable the feature on
> distribution-provided qemu, but I guess we can figure this out later...
>
> And finally out of curiosity, I see that rutabaga also has a
> virgl_renderer (and virgl_renderer_next) backend which would then not
> use gfxstream but virglrenderer instead. I wonder if there would be any
> benefit/features in enabling that with qemu later compared to the
> current qemu virtio/virglrenderer implementation (if that would make
> sense at all)?
>

Yeah, maybe later if there's developer interest,  rutabaga FFI can build
its virglrenderer bindings in a subsequent release.  So far I don't have
time to test, and the most important use case is gfxstream + Android for
Emulator.  As ever, patches are welcome.

Thanks
>
> Erico
>
>

On Wed, Aug 09, 2023 at 09:50:29AM +0800, Gurchetan Singh wrote:
>    On Mon, Aug 7, 2023 at 7:24 AM Erico Nunes <[1]ernunes@redhat.com>
>    wrote:
> 
>      Hello,
>      On 04/08/2023 01:54, Gurchetan Singh wrote:
>      > Prior versions:
>      >
>      >
>      [2]https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg05801.ht
>      ml
>      >
>      >
>      [3]https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg02341.ht
>      ml
>      >
>      >
>      [4]https://patchew.org/QEMU/20230421011223.718-1-gurchetansingh@chro
>      mium.org/
>      >
>      > Changes since v2:
>      > - Incorporated review feedback
>      >
>      > How to build both rutabaga and gfxstream guest/host libs:
>      >
>      > [5]https://crosvm.dev/book/appendix/rutabaga_gfx.html
>      >
>      > Branch containing this patch series:
>      >
>      >
>      [6]https://gitlab.freedesktop.org/gurchetansingh/qemu-gfxstream/-/co
>      mmits/qemu-gfxstream-v3
>      I tried this on Fedora with a Fedora guest and I was able to get
>      Vulkan
>      headless applications as well as Wayland proxy with sommelier to
>      work.
>      If you don't mind, I have a few questions.
>      I was not able to run Vulkan applications over the Wayland proxy,
>      only
>      unaccelerated apps. This seems to be unsupported yet; is actually
>      unsupported for now or was something missing in my setup?
> 
>    Yes, currently this is unsupported.  In the near future, I do imagine
>    3D accelerated rendering over cross-domain to be a thing (among many
>    context types, not just gfxstream VK).
>    Re: using gfxstream VK in Linux distros, depends on your use case.  If
>    you are looking for best performance over virtio on open-source Linux
>    platforms, perhaps gfxstream Vulkan (or any API virtualization
>    solution) is not your best bet.  The Mesa native context work looks
>    particularly exciting there:
>    [7]https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658

In fact, we will introduce both venus and virtio native context next step
with qemu. :-)

I am cleanning up the codes will send out the qemu very soon.

Thanks,
Ray

>    We are interested in running gfxstream VK in Linux guests, but we
>    envisage that for reference and testing.  For all embedded use cases,
>    using the host driver in the guest will predominate due to performance
>    considerations (either through virtio or HW direct / mediated
>    passthru).
> 
>      Also apparently GL/GLES is only supported on Android right now as
>      you
>      mentioned, since on Linux the gfxstream guest only installs the
>      Vulkan
>      library and icd. What is the plan to support GL on Linux; provide
>      gfxstream GL guest libraries later or enable Zink or some other
>      solution?
>      Then if I understand correctly, Mesa virgl is not used at all with
>      the
>      gfxstream solution, so I guess we would need to find a way to ship
>      the
>      gfxstream guest libraries too on distributions?
> 
> 
> 
>      Also I wonder about including all of the the dependencies required
>      to
>      get this to build on distributions as well to enable the feature on
>      distribution-provided qemu, but I guess we can figure this out
>      later...
>      And finally out of curiosity, I see that rutabaga also has a
>      virgl_renderer (and virgl_renderer_next) backend which would then
>      not
>      use gfxstream but virglrenderer instead. I wonder if there would be
>      any
>      benefit/features in enabling that with qemu later compared to the
>      current qemu virtio/virglrenderer implementation (if that would make
>      sense at all)?
> 
>    Yeah, maybe later if there's developer interest,  rutabaga FFI can
>    build its virglrenderer bindings in a subsequent release.  So far I
>    don't have time to test, and the most important use case is gfxstream +
>    Android for Emulator.  As ever, patches are welcome.
> 
>      Thanks
>      Erico
> 
> References
> 
>    1. mailto:ernunes@redhat.com
>    2. https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg05801.html
>    3. https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg02341.html
>    4. https://patchew.org/QEMU/20230421011223.718-1-gurchetansingh@chromium.org/
>    5. https://crosvm.dev/book/appendix/rutabaga_gfx.html
>    6. https://gitlab.freedesktop.org/gurchetansingh/qemu-gfxstream/-/commits/qemu-gfxstream-v3
>    7. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658