Re: [PATCH v3 0/9] gfxstream + rutabaga_gfx

[Gurchetan Singh]

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