From: "Alex Bennée" <alex.bennee@linaro.org>
To: "Marc-André Lureau" <marcandre.lureau@gmail.com>
Cc: qemu-devel@nongnu.org,
"Manos Pitsidianakis" <manos.pitsidianakis@linaro.org>,
"Dmitry Osipenko" <dmitry.osipenko@collabora.com>,
"Akihiko Odaki" <akihiko.odaki@daynix.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>
Subject: Re: [RFC PATCH] subprojects: add a wrapper for libvirglrenderer
Date: Wed, 05 Jun 2024 15:05:56 +0100 [thread overview]
Message-ID: <878qzjfprv.fsf@draig.linaro.org> (raw)
In-Reply-To: <CAJ+F1CKdme8dKCO3iMEZLU-uWLfk-PPCfMNwh6-vCbCLyJvYiw@mail.gmail.com> ("Marc-André Lureau"'s message of "Wed, 5 Jun 2024 17:50:41 +0400")
Marc-André Lureau <marcandre.lureau@gmail.com> writes:
> Hi
>
> On Wed, Jun 5, 2024 at 5:35 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>
> As the latest features for virtio-gpu need a pretty recent version of
> libvirglrenderer. When it is not available on the system we can use a
> meson wrapper and provide it when --download is specified in
> configure.
>
> We have to take some additional care as currently QEMU will hang
> libvirglrenderer fails to exec the render server. As the error isn't
> back propagated we make sure we at least test we have a path to an
> executable before tweaking the environment.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Cc: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> Cc: Akihiko Odaki <akihiko.odaki@daynix.com>
> ---
> meson.build | 7 ++++++-
> hw/display/virtio-gpu-virgl.c | 24 ++++++++++++++++++++++++
> subprojects/virglrenderer.wrap | 6 ++++++
> 3 files changed, 36 insertions(+), 1 deletion(-)
> create mode 100644 subprojects/virglrenderer.wrap
>
> diff --git a/meson.build b/meson.build
> index 1d7346b703..e4e270df78 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1203,7 +1203,8 @@ have_vhost_user_gpu = have_tools and host_os == 'linux' and pixman.found()
> if not get_option('virglrenderer').auto() or have_system or have_vhost_user_gpu
> virgl = dependency('virglrenderer',
> method: 'pkg-config',
> - required: get_option('virglrenderer'))
> + required: get_option('virglrenderer'),
> + default_options: ['default_library=static', 'render-server=true', 'venus=true'])
>
> So the subproject won't be used unless virgl-devel is missing on the system. Is it really so useful? maybe, I am just used to
> installing my bleeding edge libraries with stow..
While I've been messing with the VirtIO GPU stuff I've had a special
build dir with the latest version of the various components and suitable
PKG_CONFIG_PATH and LD_LIBRARY_PATH hacks to use them. It did however
keep breaking when there was a re-configure and I'd forgotten to set the
env variables.
Judging by the number of questions I keep seeing from people about
getting virtio-gpu working it does seem a bit wobly (and thats before
you start talking about the extra libs rutabaga requires).
Bundling the library with a wrapper (which I think it only does when it
can't find a new enough system one) seems a lot simpler.
So yes this is a build from source convenience that mostly helps
developers and early adopters but we can get rid of it once our baseline
distros have caught up with the latest libvirglrenderer.
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
next prev parent reply other threads:[~2024-06-05 14:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-05 13:35 [RFC PATCH] subprojects: add a wrapper for libvirglrenderer Alex Bennée
2024-06-05 13:50 ` Marc-André Lureau
2024-06-05 14:05 ` Alex Bennée [this message]
2024-06-05 14:32 ` Manos Pitsidianakis
2024-06-05 14:57 ` Alex Bennée
2024-06-05 20:05 ` Akihiko Odaki
2024-06-17 10:35 ` Alex Bennée
2024-06-17 11:48 ` Akihiko Odaki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878qzjfprv.fsf@draig.linaro.org \
--to=alex.bennee@linaro.org \
--cc=akihiko.odaki@daynix.com \
--cc=berrange@redhat.com \
--cc=dmitry.osipenko@collabora.com \
--cc=kraxel@redhat.com \
--cc=manos.pitsidianakis@linaro.org \
--cc=marcandre.lureau@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.