| Message ID | 20230803235502.373-1-gurchetansingh@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | gfxstream + rutabaga_gfx | expand |
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