On Mon, Aug 7, 2023 at 7:24 AM Erico Nunes <ernu...@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-gurchetansi...@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 > >
