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]ernu...@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:ernu...@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-gurchetansi...@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

Reply via email to