On Tue, Sep 12, 2023 at 6:59 AM Marc-André Lureau < marcandre.lur...@gmail.com> wrote:
> Hi Gurchetan > > On Wed, Sep 6, 2023 at 5:22 AM Gurchetan Singh > <gurchetansi...@chromium.org> wrote: > > > > > > > > On Wed, Aug 30, 2023 at 7:26 PM Huang Rui <ray.hu...@amd.com> wrote: > >> > >> On Tue, Aug 29, 2023 at 08:36:20AM +0800, Gurchetan Singh wrote: > >> > From: Gurchetan Singh <gurchetansi...@google.com> > >> > > >> > Changes since v12: > >> > - Added r-b tags from Antonio Caggiano and Akihiko Odaki > >> > - Removed review version from commit messages > >> > - I think we're good to merge since we've had multiple people test > and review this series?? > >> > > >> > 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.com/gurchetansingh/qemu/-/commits/qemu-gfxstream-v13 > >> > > >> > 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 > >> > >> Patch 1 -> 4 are > >> > >> Acked-and-Tested-by: Huang Rui <ray.hu...@amd.com> > > > > > > Thanks Ray, I've rebased > https://gitlab.com/gurchetansingh/qemu/-/commits/qemu-gfxstream-v13 and > added the additional acks in the commit message. > > > > UI/gfx maintainers, since everything is reviewed and there hasn't been > any additional review comments, may we merge the gfxstream + rutabaga_gfx > series? Thank you! > > > > > > Packaging aemu and gfxstream is a bit problematic. I have some WIP > Fedora packages. > > AEMU: > - installs files under /usr/include/host-common and > /usr/include/snapshot. Can this be moved under /usr/include/aemu > instead? > - builds only static versions of libaemu-host-common.a and > liblogging-base.a (distros don't like static libs much) > - could liblogging-base(.a,.so,..) also have "aemu" name in it? > - libaemu-base.so is not versioned > - I can't find a release tarball, nor the (v0.1.2) release tag > - could have a README file > > I am not very familiar with cmake, so it's not obvious how to make the > required changes. Would you like me to open an issue (where?) or try > to make some patches? > I filed an internal bug with all the issues you listed: Android side should fix this internally. I see a few options for packaging: 1) Punt on gfxstream/AEMU packaging, just do rutabaga gfxstream is mostly useful for Android guests, and I didn't expect anyone to actually package it at this point since most here are interested in Linux guests (where gfxstream VK is headless only right now). Plus ioctl-fowarding > API forwarding for security and performance, so I'm not sure if it'll have any sticking power even if everything is supported (outside of a few niche use cases). Though, I sense interest in Wayland passthrough for dual Linux use cases. I put up: crrev.com/c/4860836 <http://crrev.com/c4860836> that'll allow packaging on rutabaga_gfx and even CI testing without gfxstream, since it is designed to function without it. We could issue another rutabaga-release tag, or you can simply add a patch (a common packaging practice) on the Fedora package with the "UPSTEAM label". 2) Actually package gfxstream only Probably an intermediate solution that doesn't introduce versioning/static library issues would be just to have a copy of AEMU in the gfxstream repo, and link it statically. Will need another release tag/commit of gfxstream. 3) Don't package at all For my particular use case since we have to build QEMU for sources, this is fine. If upstream breaks virtio-gpu-rutabaga.c, we'll send a patch and fix it. Being in-tree is most important. Let me know what you prefer! > > gfxstream: > - libgfxtream_backend.so is not versioned > - I can't find a release tarball, nor the (v0.1.2) release tag > https://android-review.googlesource.com/c/platform/hardware/google/gfxstream/+/2749095 > > > (packaging is important so we can build the new code in CI too!) > > thanks > > -- > Marc-André Lureau >
