[Buildroot] [PATCH RESEND v5 5/5] package/qemu: add virglrenderer support

[Romain Naour]

Hello Joseph, All,

Le 13/05/2026 à 20:16, Joseph Kogut a écrit :
> Hello Romain,
> 
> On Wed, May 13, 2026 at 10:17 AM Romain Naour <romain.naour at smile.fr> wrote:
>>
>>> +config BR2_PACKAGE_QEMU_VIRGLRENDERER
>>> +     bool "Enable virglrenderer"
>>> +     depends on BR2_PACKAGE_HAS_LIBEGL || BR2_PACKAGE_HAS_LIBGL
>>> +     select BR2_PACKAGE_QEMU_OPENGL
>>> +     select BR2_PACKAGE_VIRGLRENDERER
>>
>> All this effort to build virglrenderer without egl or gl to use it (select it)
>> under an option that depends on egl or gl?
>>
>> I'll have a second look.
>>
> 
> Indeed, virglrenderer is used by more than just qemu. It's also used
> by muvm/libkrun, and other VMMs like crosvm for compute/graphics. The
> rutabaga_gfx backend in qemu can also optionally use virglrenderer.
> 
> For qemu, there's currently a dependency on the display having GL
> enabled to use virglrenderer with the virtio-gpu device. I believe
> this is a historical relic. As the name suggests, virglrenderer was
> created to expose a virtual GPU to guests giving them hardware
> accelerated GL through a renderer on the host. Therefore, it was
> reasonable for the host's display frontend to also depend on libGL.
> 
> Later, virglrenderer grew more capable, gaining support for Vulkan,
> and later host native context. This allowed guests to run the Mesa
> UMDs directly, without any assumption of host rendering capabilities.
> 
> Patches [0] on the qemu-devel mailing list aim to decouple
> compute/rendering in the guest from the host's display pipeline. This
> means we could run qemu on a host without libGL and still do
> compute/rendering inside the guest.
> 
> Projects like muvm already work with headless graphics/compute in
> guests through virglrenderer. This change supports these kinds of
> applications and use cases.

Thanks for the explanation!

Sorry I'm not familiar with virtio-gpu / virgl stack (at last I have a better
understanding thanks to your patch series)

> 
> You followed up while I was drafting my own reply. :)
> 
> On Wed, May 13, 2026 at 11:06 AM Romain Naour <romain.naour at smile.fr> wrote:
>>
>> Ok I get it, building libepoxy without egl or gl dependency makes sens while
>> building with only venus (vulkan). libepoxy is a mandatory dependency of
>> virglrenderer even if only venus (vulkan) is enabled in the defconfig.
>>
>> The BR2_PACKAGE_VIRGLRENDERER_VENUS option is not used by Qemu but could be used
>> in by another package or defconfig.
> 
> Exactly, virglrenderer always depends on libepoxy, which can be built
> without GL/EGL. We may want to build virglrenderer with Venus and/or
> DRM support, which would enable guests to do compute/rendering either
> headless, or for display on the host through Vulkan.
> 
> The virglrenderer package defaults VirGL support to y when libGL is
> present. This is the case when we select virglrenderer support in
> qemu, as explained above.

Yes but even if it's the default, BR2_PACKAGE_QEMU_VIRGLRENDERER option should
select BR2_PACKAGE_VIRGLRENDERER_VIRGL. BR2_PACKAGE_VIRGLRENDERER_VIRGL can
still be disabled from menuconfig.

What happen if BR2_PACKAGE_QEMU_VIRGLRENDERER is selected and
BR2_PACKAGE_VIRGLRENDERER_VIRGL disabled?

> 
> Perhaps we could clarify this by expanding the help message under
> qemu's virglrenderer config to explain that virglrenderer itself has
> additional options.

First, we should improve the libepoxy help text to explain why it's fine to use
libepoxy without EGL and GL.

Then, BR2_PACKAGE_QEMU_VIRGLRENDERER should not only select
BR2_PACKAGE_VIRGLRENDERER without enabling any suboption.

Best regards,
Romain

> 
> Best regards,
> Joseph
> 
> [0] https://lore.kernel.org/qemu-devel/20260317182049.33848-1-lucaaamaral@gmail.com/