[Buildroot] [PATCH RESEND v5 0/5] Add virglrenderer support

[Buildroot] [PATCH RESEND v5 0/5] Add virglrenderer support

[Joseph Kogut]

Hello,

This patch series adds support for building the virglrenderer library in
buildroot.

Virglrenderer is a userspace library used to support rendering and
compute in virtual machines over virtio-gpu. Virglrenderer supports
serialized API level access to OpenGL and Vulkan through virgl and venus
respectively, as well as mediated DRM level access using host native
context [0]. Notably libkrun [1] and rutabaga_gfx [2] are also capable of
utilizing virglrenderer.

The first patch removes libepoxy's dependency on EGL/GL(X), as it may
have depended on them in the past, but now builds without any EGL/GLX
support. This allows virglrenderer to build with its libepoxy
dependency, without actually depending on EGL/GLX.

This enables, for example, headless compute through Vulkan using Venus
or host native context inside virtual machines.

I'm interested in feedback on this change in particular, as it may have
second order effects on other packages.

The second patch adds the new virglrenderer package. Optional configs
enable VirGL (API-level OpenGL passthrough), Venus (API-level Vulkan
passthrough), hardware accelerated video encode/decode through VA-API,
and DRM driver specific backends for host native context support.

The third patch adds a patch from upstream virglrenderer that fixes a
build issue with glibc 2.43.

The fourth patch adds an OpenGL config for qemu.

The fifth patch adds a qemu virglrenderer config that selects OpenGL
support, as virgl/venus support in qemu currently requires a GL
accelerated display frontend (a patch series on the mailing list [3] is
proposing decoupling display GL support from Venus). Other VMMs
such as libkrun don't suffer from the same coupling currently.

For v4 of the series, I realized enabling DRM backends with the optional
dependency on specific Mesa drivers didn't make sense. Host native
context depends on specific *host kernel* interfaces, and the host may
or may not have Mesa at all.

If the host does have Mesa, and a specific DRM consumer (i.e. a vendor's
gallium/vulkan driver) is enabled, it's reasonable to assume that the
host supports that DRM interface, and we should enable the corresponding
DRM backend. For cases where the guest alone runs mesa (headless
compute), I introduced explicit configs to enable DRM backends.

Tested with llama-bench running with the vulkan backend in a nested VM.
As seen below, the nested guest is sending commands to the host through
virtio-gpu twice.

        # llama-bench -m llama-2-7b.Q4_0.gguf -ngl 100
        ggml_vulkan: Found 1 Vulkan devices:
        ggml_vulkan: 0 = Virtio-GPU Venus (Virtio-GPU Venus (AMD Radeon RX 6900 XT (RADV NAVI21))) (venus) | uma: 0 | fp16: 1 | warp size: 64 | shared memory: 65536 | int dot: 1 | matrix cores: none
        | model                          |       size |     params | backend    | ngl |            test |                  t/s |
        | ------------------------------ | ---------: | ---------: | ---------- | --: | --------------: | -------------------: |
        | llama 7B Q4_0                  |   3.56 GiB |     6.74 B | Vulkan     | 100 |           pp512 |      1220.99 ± 10.12 |
        | llama 7B Q4_0                  |   3.56 GiB |     6.74 B | Vulkan     | 100 |           tg128 |         82.24 ± 1.00 |

        build: unknown (0)

More information about the benchmark and results from other hardware on
the llama.cpp GitHub discussion here [4].

Build tested with several configs, to ensure correct dependencies and
configuration. Not all toolchains build every configuration
successfully, but every configuration has multiple passing builds.
Failures generally are from warnings treated as errors by default.

-- qemu-virgl-egl --
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_SOFTPIPE=y
BR2_PACKAGE_MESA3D_OPENGL_EGL=y
BR2_PACKAGE_QEMU=y
BR2_PACKAGE_QEMU_SYSTEM=y
BR2_PACKAGE_QEMU_SYSTEM_TCG=y
BR2_PACKAGE_QEMU_VIRGLRENDERER=y

-- qemu-virgl-glx --
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_SOFTPIPE=y
BR2_PACKAGE_MESA3D_OPENGL_GLX=y
BR2_PACKAGE_QEMU=y
BR2_PACKAGE_QEMU_SYSTEM=y
BR2_PACKAGE_QEMU_SYSTEM_TCG=y
BR2_PACKAGE_QEMU_VIRGLRENDERER=y
BR2_PACKAGE_XORG7=y

-- virglrenderer-venus --
BR2_PACKAGE_VIRGLRENDERER=y
BR2_PACKAGE_VIRGLRENDERER_VENUS=y

-- virglrenderer-drm-amdgpu --
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_VULKAN_DRIVER_AMD=y
BR2_PACKAGE_VIRGLRENDERER=y

Feedback welcome.

[0] https://www.collabora.com/news-and-blog/blog/2025/01/15/the-state-of-gfx-virtualization-using-virglrenderer/
[1] https://github.com/containers/libkrun
[2] https://github.com/magma-gpu/rutabaga_gfx
[3] https://lore.kernel.org/qemu-devel/20260317182049.33848-1-lucaaamaral@gmail.com/
[4] https://github.com/ggml-org/llama.cpp/discussions/10879

Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
---
Changes in v5:
- Fixed authorship, Signed-off-by, and sent from address
- Link to v4: https://lore.kernel.org/r/20260317-virglrenderer-v4-0-ed223e222bb6@gmail.com

Changes in v4:
- Removed libepoxy dependency on GL/EGL
- Introduce explicit configs for virglrenderer DRM backends, virgl
  (see above note)
- Moved virglrenderer Kconfig from Libraries -> Graphics to 'Graphics
  libraries and applications' (next to mesa3d && X.org)
- Add a patch from upstream virglrenderer to fix glibc 2.43 builds
- select libdrm in virglrenderer only when required (drm backends,
  video)
- BR2_PACKAGE_VIRGLRENDERER_DRM_BACKEND_MSM depends on !BR2_arm
- Explicitly configure GLX and/or EGL when
  BR2_PACKAGE_VIRGLRENDERER_VIRGL=y
- Separate comments for qemu GL/virglrenderer [Romain]
- Split up qemu feature configs into separate commits [Romain]
- Link to v3: https://lore.kernel.org/buildroot/20260219-virglrenderer-v3-0-e2ff1a23be3f@gmail.com/

Changes in v3:
- Bump version to v1.3.0
- Add optional deps for panfrost and i915 native context (new)
- Add config for vaapi support
- Remove GLX in favor of EGL
- Update qemu docs links, as previous ones 404 [Romain]
- Fix invalid config reference in BR2_PACKAGE_QEMU_VIRGLRENDERER
  [Romain]
- Select libepoxy when enabling OpenGL support in qemu [Romain]
- Add depends on gcc >= 4.1 to virglrenderer (from meson.build)
- Add depends on libgbm to virglrenderer [Romain]
- Add comments for missing dependencies to virglrenderer Kconfig
- Select vulkan-headers when venus is enabled [Romain]
- Disable venus explicitly when the symbol isn't selected
- Link to v2: https://lore.kernel.org/buildroot/20251203-virglrenderer-v2-v2-0-2846fc1a579a@gmail.com

Changes in v2:
- Rebase onto next (python-glslang patch merged)
- Bump version to v1.2.0
- Remove hidden configs for virglrenderer vDRM backends [Romain]
- Fixed typo in qemu/Config.in [Romain]
- Split up configs for qemu OpenGL and virglrenderer support [Romain]
- More detailed qemu config help messages
- Link to v1: https://lore.kernel.org/r/20250618-virglrenderer-upstream-v1-0-57525ac8406e@gmail.com

---
Joseph Kogut (5):
      package/libepoxy: remove gl/egl dependency
      package/virglrenderer: new package
      package/virglrenderer: Fix build with glibc 2.43
      package/qemu: add OpenGL config
      package/qemu: add virglrenderer support

 DEVELOPERS                                         |   1 +
 package/Config.in                                  |   1 +
 package/libepoxy/Config.in                         |   4 -
 package/qemu/Config.in                             |  31 +++++++
 package/qemu/qemu.mk                               |  15 ++-
 .../0001-fix-build-with-glibc-2.43.patch           |  39 ++++++++
 package/virglrenderer/Config.in                    | 101 +++++++++++++++++++++
 package/virglrenderer/virglrenderer.hash           |   5 +
 package/virglrenderer/virglrenderer.mk             |  60 ++++++++++++
 9 files changed, 252 insertions(+), 5 deletions(-)
---
base-commit: e555590b94532097c1319b9450ac84fab06b758b
change-id: 20260219-virglrenderer-c4dad969ad89

Best regards,
-- 
Joseph Kogut <joseph.kogut@gmail.com>

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH RESEND v5 1/5] package/libepoxy: remove gl/egl dependency

[Joseph Kogut]

Libepoxy is a library for handling OpenGL function pointer management.

It has backends for egl/glx, which may at one point have been mandatory
to enable, but the library now builds with none of the above enabled
features, as seen below.

  libepoxy 1.5.10

    User defined options
      Cross files            : /home/joseph/br-test-pkg/arm-aarch64/build/libepoxy-1.5.10//buildroot-build/cross-compilation.conf
      b_pie                  : false
      b_staticpic            : true
      buildtype              : release
      build.cmake_prefix_path: /home/joseph/br-test-pkg/arm-aarch64/host/lib/cmake
      default_library        : shared
      docs                   : false
      egl                    : no
      glx                    : no
      libdir                 : lib
      build.pkg_config_path  : /home/joseph/br-test-pkg/arm-aarch64/host/lib/pkgconfig
      prefix                 : /usr
      strip                  : false
      tests                  : false
      x11                    : false

Removing these dependencies allows for some applications that require it
as a build dependency, but otherwise can run headless or without GL, to
build and function.

Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
---
 package/libepoxy/Config.in | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/package/libepoxy/Config.in b/package/libepoxy/Config.in
index 9da190b895..27d2b968d2 100644
--- a/package/libepoxy/Config.in
+++ b/package/libepoxy/Config.in
@@ -1,12 +1,8 @@
 config BR2_PACKAGE_LIBEPOXY
 	bool "libepoxy"
-	depends on BR2_PACKAGE_HAS_LIBEGL || BR2_PACKAGE_HAS_LIBGL
 	select BR2_PACKAGE_XUTIL_UTIL_MACROS
 	help
 	  Epoxy is a library for handling OpenGL function pointer
 	  management for you.
 
 	  https://github.com/anholt/libepoxy
-
-comment "libepoxy needs an OpenGL and/or OpenGL EGL backend"
-	depends on !BR2_PACKAGE_HAS_LIBEGL && !BR2_PACKAGE_HAS_LIBGL

-- 
2.54.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH RESEND v5 1/5] package/libepoxy: remove gl/egl dependency

[Romain Naour via buildroot]

Hello Joseph, All,

Le 12/05/2026 à 21:36, Joseph Kogut a écrit :
> Libepoxy is a library for handling OpenGL function pointer management.
> 
> It has backends for egl/glx, which may at one point have been mandatory
> to enable, but the library now builds with none of the above enabled
> features, as seen below.
> 
>   libepoxy 1.5.10
> 
>     User defined options
>       Cross files            : /home/joseph/br-test-pkg/arm-aarch64/build/libepoxy-1.5.10//buildroot-build/cross-compilation.conf
>       b_pie                  : false
>       b_staticpic            : true
>       buildtype              : release
>       build.cmake_prefix_path: /home/joseph/br-test-pkg/arm-aarch64/host/lib/cmake
>       default_library        : shared
>       docs                   : false
>       egl                    : no
>       glx                    : no
>       libdir                 : lib
>       build.pkg_config_path  : /home/joseph/br-test-pkg/arm-aarch64/host/lib/pkgconfig
>       prefix                 : /usr
>       strip                  : false
>       tests                  : false
>       x11                    : false
> 
> Removing these dependencies allows for some applications that require it
> as a build dependency, but otherwise can run headless or without GL, to
> build and function.

I'm not sure about this change. Having egl or glx backend still seems highly
recommended. Ok it builds but why using libepoxy in this case (headless)?

It would create a library that reply false or 0 to the following functions:

epoxy_has_gl_extension()
epoxy_is_desktop_gl()
epoxy_gl_version()
epoxy_glsl_version()

Note: The github CI workflow of libepoxy disable all backend but probably to
perform a build test only:
https://github.com/anholt/libepoxy/blob/master/.github/workflows/linux.yml#L16

Yocto's libepoxy recipe enable at least egl backend by default (not sure if
anyone disable egl without enabling x11).

https://github.com/openembedded/openembedded-core/blob/3724b93538d3acbec9f48d4c524b51d166071708/meta/recipes-graphics/libepoxy/libepoxy_1.5.10.bb#L21

Best regards,
Romain

> 
> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
> ---
>  package/libepoxy/Config.in | 4 ----
>  1 file changed, 4 deletions(-)
> 
> diff --git a/package/libepoxy/Config.in b/package/libepoxy/Config.in
> index 9da190b895..27d2b968d2 100644
> --- a/package/libepoxy/Config.in
> +++ b/package/libepoxy/Config.in
> @@ -1,12 +1,8 @@
>  config BR2_PACKAGE_LIBEPOXY
>  	bool "libepoxy"
> -	depends on BR2_PACKAGE_HAS_LIBEGL || BR2_PACKAGE_HAS_LIBGL
>  	select BR2_PACKAGE_XUTIL_UTIL_MACROS
>  	help
>  	  Epoxy is a library for handling OpenGL function pointer
>  	  management for you.
>  
>  	  https://github.com/anholt/libepoxy
> -
> -comment "libepoxy needs an OpenGL and/or OpenGL EGL backend"
> -	depends on !BR2_PACKAGE_HAS_LIBEGL && !BR2_PACKAGE_HAS_LIBGL
> 

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH RESEND v5 1/5] package/libepoxy: remove gl/egl dependency

[Joseph Kogut]

Hello Romain,

On Wed, May 13, 2026 at 8:35 AM Romain Naour <romain.naour@smile.fr> wrote:
>
> Hello Joseph, All,
>
> Le 12/05/2026 à 21:36, Joseph Kogut a écrit :
> > Libepoxy is a library for handling OpenGL function pointer management.
> >
> > It has backends for egl/glx, which may at one point have been mandatory
> > to enable, but the library now builds with none of the above enabled
> > features, as seen below.
> >
> >   libepoxy 1.5.10
> >
> >     User defined options
> >       Cross files            : /home/joseph/br-test-pkg/arm-aarch64/build/libepoxy-1.5.10//buildroot-build/cross-compilation.conf
> >       b_pie                  : false
> >       b_staticpic            : true
> >       buildtype              : release
> >       build.cmake_prefix_path: /home/joseph/br-test-pkg/arm-aarch64/host/lib/cmake
> >       default_library        : shared
> >       docs                   : false
> >       egl                    : no
> >       glx                    : no
> >       libdir                 : lib
> >       build.pkg_config_path  : /home/joseph/br-test-pkg/arm-aarch64/host/lib/pkgconfig
> >       prefix                 : /usr
> >       strip                  : false
> >       tests                  : false
> >       x11                    : false
> >
> > Removing these dependencies allows for some applications that require it
> > as a build dependency, but otherwise can run headless or without GL, to
> > build and function.
>
> I'm not sure about this change. Having egl or glx backend still seems highly
> recommended. Ok it builds but why using libepoxy in this case (headless)?

It seems a clean way for applications to support various GL
configurations (GL/GLX, GL/EGL, GLES/EGL) at runtime. I suppose "none
of the above" is one valid configuration.

For virglrenderer, that's still a useful configuration. If we attempt
to build a minimal target that can run a VMM like qemu or libkrun with
hardware accelerated graphics/compute, this cuts out most or all of
the host's graphics stack, depending on our need to display frames
locally on the host. I could envision a virtualized guest using e.g.
moonlight [0] to stream graphical output to another machine.

Looking at other users of libepoxy, Weston can use pixman, GL, or
Vulkan for rendering, and can use DRM, x11, wayland, or vnc as display
backends, or even run headless. No GL/EGL is again a valid
configuration here, it just gracefully disables GL at runtime.

I don't know about libcamera-apps, libgtk3, libgtk3, webkitgtk, or
wpewebkit. Currently, they will all retain their dependency on
HAS_LIBGL || HAS_LIBEGL. I suppose if these dependencies were removed,
it might be possible to build some applications in pointless
configurations that lack desired functionality.

[0] https://moonlight-stream.org/

Best,
Joseph
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH RESEND v5 1/5] package/libepoxy: remove gl/egl dependency

[Romain Naour via buildroot]

Hello Joseph,

Le 13/05/2026 à 20:35, Joseph Kogut a écrit :
> Hello Romain,
> 
> On Wed, May 13, 2026 at 8:35 AM Romain Naour <romain.naour@smile.fr> wrote:
>>
>> Hello Joseph, All,
>>
>> Le 12/05/2026 à 21:36, Joseph Kogut a écrit :
>>> Libepoxy is a library for handling OpenGL function pointer management.
>>>
>>> It has backends for egl/glx, which may at one point have been mandatory
>>> to enable, but the library now builds with none of the above enabled
>>> features, as seen below.
>>>
>>>   libepoxy 1.5.10
>>>
>>>     User defined options
>>>       Cross files            : /home/joseph/br-test-pkg/arm-aarch64/build/libepoxy-1.5.10//buildroot-build/cross-compilation.conf
>>>       b_pie                  : false
>>>       b_staticpic            : true
>>>       buildtype              : release
>>>       build.cmake_prefix_path: /home/joseph/br-test-pkg/arm-aarch64/host/lib/cmake
>>>       default_library        : shared
>>>       docs                   : false
>>>       egl                    : no
>>>       glx                    : no
>>>       libdir                 : lib
>>>       build.pkg_config_path  : /home/joseph/br-test-pkg/arm-aarch64/host/lib/pkgconfig
>>>       prefix                 : /usr
>>>       strip                  : false
>>>       tests                  : false
>>>       x11                    : false
>>>
>>> Removing these dependencies allows for some applications that require it
>>> as a build dependency, but otherwise can run headless or without GL, to
>>> build and function.
>>
>> I'm not sure about this change. Having egl or glx backend still seems highly
>> recommended. Ok it builds but why using libepoxy in this case (headless)?
> 
> It seems a clean way for applications to support various GL
> configurations (GL/GLX, GL/EGL, GLES/EGL) at runtime. I suppose "none
> of the above" is one valid configuration.

Yes, that's why it's confusing :)

> 
> For virglrenderer, that's still a useful configuration. If we attempt
> to build a minimal target that can run a VMM like qemu or libkrun with
> hardware accelerated graphics/compute, this cuts out most or all of
> the host's graphics stack, depending on our need to display frames
> locally on the host. I could envision a virtualized guest using e.g.
> moonlight [0] to stream graphical output to another machine.
> 
> Looking at other users of libepoxy, Weston can use pixman, GL, or
> Vulkan for rendering, and can use DRM, x11, wayland, or vnc as display
> backends, or even run headless. No GL/EGL is again a valid
> configuration here, it just gracefully disables GL at runtime.

Ok, I'm convinced.

> 
> I don't know about libcamera-apps, libgtk3, libgtk3, webkitgtk, or
> wpewebkit. Currently, they will all retain their dependency on
> HAS_LIBGL || HAS_LIBEGL. I suppose if these dependencies were removed,
> it might be possible to build some applications in pointless
> configurations that lack desired functionality.

I'm fine if we keep HAS_LIBGL || HAS_LIBEGL dependencies for these packages but
at least you should update the comment about libepoxy dependency

-  depends on BR2_PACKAGE_HAS_LIBEGL || BR2_PACKAGE_HAS_LIBGL # libepoxy
+  depends on BR2_PACKAGE_HAS_LIBEGL || BR2_PACKAGE_HAS_LIBGL # needs libepoxy
w/ EGL or GL

Can you resend a v6 with improved comments?

> 
> [0] https://moonlight-stream.org/
> 
> Best,
> Joseph

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH RESEND v5 1/5] package/libepoxy: remove gl/egl dependency

[Joseph Kogut]

On Wed, May 13, 2026 at 2:13 PM Romain Naour <romain.naour@smile.fr> wrote:
>
> Hello Joseph,
>
> Le 13/05/2026 à 20:35, Joseph Kogut a écrit :
> > Hello Romain,
> >
> > On Wed, May 13, 2026 at 8:35 AM Romain Naour <romain.naour@smile.fr> wrote:
> >>
> >> Hello Joseph, All,
> >>
> >> Le 12/05/2026 à 21:36, Joseph Kogut a écrit :
> >>> Libepoxy is a library for handling OpenGL function pointer management.
> >>>
> >>> It has backends for egl/glx, which may at one point have been mandatory
> >>> to enable, but the library now builds with none of the above enabled
> >>> features, as seen below.
> >>>
> >>>   libepoxy 1.5.10
> >>>
> >>>     User defined options
> >>>       Cross files            : /home/joseph/br-test-pkg/arm-aarch64/build/libepoxy-1.5.10//buildroot-build/cross-compilation.conf
> >>>       b_pie                  : false
> >>>       b_staticpic            : true
> >>>       buildtype              : release
> >>>       build.cmake_prefix_path: /home/joseph/br-test-pkg/arm-aarch64/host/lib/cmake
> >>>       default_library        : shared
> >>>       docs                   : false
> >>>       egl                    : no
> >>>       glx                    : no
> >>>       libdir                 : lib
> >>>       build.pkg_config_path  : /home/joseph/br-test-pkg/arm-aarch64/host/lib/pkgconfig
> >>>       prefix                 : /usr
> >>>       strip                  : false
> >>>       tests                  : false
> >>>       x11                    : false
> >>>
> >>> Removing these dependencies allows for some applications that require it
> >>> as a build dependency, but otherwise can run headless or without GL, to
> >>> build and function.
> >>
> >> I'm not sure about this change. Having egl or glx backend still seems highly
> >> recommended. Ok it builds but why using libepoxy in this case (headless)?
> >
> > It seems a clean way for applications to support various GL
> > configurations (GL/GLX, GL/EGL, GLES/EGL) at runtime. I suppose "none
> > of the above" is one valid configuration.
>
> Yes, that's why it's confusing :)
>
> >
> > For virglrenderer, that's still a useful configuration. If we attempt
> > to build a minimal target that can run a VMM like qemu or libkrun with
> > hardware accelerated graphics/compute, this cuts out most or all of
> > the host's graphics stack, depending on our need to display frames
> > locally on the host. I could envision a virtualized guest using e.g.
> > moonlight [0] to stream graphical output to another machine.
> >
> > Looking at other users of libepoxy, Weston can use pixman, GL, or
> > Vulkan for rendering, and can use DRM, x11, wayland, or vnc as display
> > backends, or even run headless. No GL/EGL is again a valid
> > configuration here, it just gracefully disables GL at runtime.
>
> Ok, I'm convinced.
>
> >
> > I don't know about libcamera-apps, libgtk3, libgtk3, webkitgtk, or
> > wpewebkit. Currently, they will all retain their dependency on
> > HAS_LIBGL || HAS_LIBEGL. I suppose if these dependencies were removed,
> > it might be possible to build some applications in pointless
> > configurations that lack desired functionality.
>
> I'm fine if we keep HAS_LIBGL || HAS_LIBEGL dependencies for these packages but
> at least you should update the comment about libepoxy dependency
>
> -  depends on BR2_PACKAGE_HAS_LIBEGL || BR2_PACKAGE_HAS_LIBGL # libepoxy
> +  depends on BR2_PACKAGE_HAS_LIBEGL || BR2_PACKAGE_HAS_LIBGL # needs libepoxy
> w/ EGL or GL
>
> Can you resend a v6 with improved comments?
>

Absolutely, and thanks so much for taking the time to work through
this with me. :)

> >
> > [0] https://moonlight-stream.org/
> >
> > Best,
> > Joseph
>
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH RESEND v5 2/5] package/virglrenderer: new package

[Joseph Kogut]

Add virglrenderer, an optional dependency of QEMU, which facilitates
acceleration of rendering and optionally video decode through
virtio-gpu.

Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
---
 DEVELOPERS                               |   1 +
 package/Config.in                        |   1 +
 package/virglrenderer/Config.in          | 101 +++++++++++++++++++++++++++++++
 package/virglrenderer/virglrenderer.hash |   5 ++
 package/virglrenderer/virglrenderer.mk   |  60 ++++++++++++++++++
 5 files changed, 168 insertions(+)

diff --git a/DEVELOPERS b/DEVELOPERS
index 88a684d9ac..a34cf57923 100644
--- a/DEVELOPERS
+++ b/DEVELOPERS
@@ -1766,6 +1766,7 @@ F:	package/python-xlib/
 F:	package/sentry-cli/
 F:	package/sentry-native/
 F:	package/unclutter-xfixes/
+F:	package/virglrenderer/
 
 N:	Joshua Henderson <joshua.henderson@microchip.com>
 F:	package/qt5/qt5wayland/
diff --git a/package/Config.in b/package/Config.in
index 371a1c33e1..da54fc2704 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -366,6 +366,7 @@ comment "Graphic libraries"
 	source "package/sdl2_ttf/Config.in"
 	source "package/spirv-headers/Config.in"
 	source "package/tk/Config.in"
+	source "package/virglrenderer/Config.in"
 	source "package/vulkan-headers/Config.in"
 	source "package/vulkan-loader/Config.in"
 	source "package/vulkan-sdk/Config.in"
diff --git a/package/virglrenderer/Config.in b/package/virglrenderer/Config.in
new file mode 100644
index 0000000000..fdf785288b
--- /dev/null
+++ b/package/virglrenderer/Config.in
@@ -0,0 +1,101 @@
+config BR2_PACKAGE_VIRGLRENDERER
+	bool "virglrenderer"
+	depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_9
+	depends on BR2_TOOLCHAIN_HAS_THREADS
+	depends on BR2_USE_MMU # fork()
+	select BR2_PACKAGE_LIBEPOXY
+	help
+	  A library for accelerated graphics and compute in
+	  virtualized guests.
+
+	  https://qemu.readthedocs.io/en/v10.0.3/system/devices/virtio-gpu.html#virtio-gpu-virglrenderer
+
+if BR2_PACKAGE_VIRGLRENDERER
+config BR2_PACKAGE_VIRGLRENDERER_VIRGL
+	bool "virgl"
+	default y
+	depends on (BR2_PACKAGE_HAS_LIBEGL && BR2_PACKAGE_HAS_LIBGBM) \
+		|| BR2_PACKAGE_HAS_LIBGL
+	help
+	  Enable API-level OpenGL acceleration over virtio-gpu.
+
+	  Say 'y' if you want to run applications with OpenGL
+	  acceleration in virtualized guests. Requires host
+	  support for OpenGL.
+
+	  https://docs.mesa3d.org/drivers/virgl.html
+
+comment "virgl needs OpenGL or OpenGL EGL and libgbm"
+	depends on !((BR2_PACKAGE_HAS_LIBEGL && BR2_PACKAGE_HAS_LIBGBM) \
+		|| BR2_PACKAGE_HAS_LIBGL) \
+
+config BR2_PACKAGE_VIRGLRENDERER_VENUS
+	bool "venus"
+	default y if BR2_PACKAGE_MESA3D_VULKAN_DRIVER
+	depends on BR2_INSTALL_LIBSTDCPP # vulkan-loader
+	depends on !BR2_STATIC_LIBS # vulkan-loader
+	depends on BR2_TOOLCHAIN_HAS_THREADS # vulkan-loader
+	select BR2_PACKAGE_VULKAN_HEADERS
+	select BR2_PACKAGE_VULKAN_LOADER
+	help
+	  Enable API-level Vulkan acceleration over virtio-gpu.
+
+	  Say 'y' if you want to run applications with Vulkan
+	  acceleration in virtualized guests. Requires host
+	  support for Vulkan.
+
+	  https://docs.mesa3d.org/drivers/venus.html
+
+config BR2_PACKAGE_VIRGLRENDERER_VAAPI
+	bool "vaapi support"
+	depends on BR2_PACKAGE_LIBGBM_HAS_FEATURE_DMA_BUF
+	select BR2_PACKAGE_LIBDRM
+	select BR2_PACKAGE_LIBVA
+	help
+	  Enable hardware accelerated video encode/decode through
+	  libva over virtio-gpu.
+
+comment "DRM backends"
+
+config BR2_PACKAGE_VIRGLRENDERER_DRM_BACKEND_AMDGPU
+	bool "amdgpu"
+	default y if BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_RADEONSI
+	default y if BR2_PACKAGE_MESA3D_VULKAN_DRIVER_AMD
+	select BR2_PACKAGE_LIBDRM
+	select BR2_PACKAGE_LIBDRM_AMDGPU
+	help
+	  Enable DRM backend for amdgpu, used by Gallium radeonsi
+	  and RADV vulkan drivers.
+
+config BR2_PACKAGE_VIRGLRENDERER_DRM_BACKEND_INTEL
+	bool "intel"
+	default y if BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_I915
+	default y if BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_IRIS
+	default y if BR2_PACKAGE_MESA3D_VULKAN_DRIVER_INTEL
+	select BR2_PACKAGE_LIBDRM
+	help
+	  Enable DRM backend for i915, used by Gallium i915/Iris
+	  and Intel vulkan drivers.
+
+config BR2_PACKAGE_VIRGLRENDERER_DRM_BACKEND_MSM
+	bool "msm"
+	default y if BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_FREEDRENO
+	depends on !BR2_arm
+	select BR2_PACKAGE_LIBDRM
+	help
+	  Enable DRM backend for msm, used by Gallium freedreno
+	  driver.
+
+config BR2_PACKAGE_VIRGLRENDERER_DRM_BACKEND_PANFROST
+	bool "panfrost"
+	default y if BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_PANFROST
+	default y if BR2_PACKAGE_MESA3D_VULKAN_DRIVER_PANFROST
+	select BR2_PACKAGE_LIBDRM
+	help
+	  Enable DRM backend for Panfrost, used by the panfrost
+	  Gallium/vulkan drivers.
+
+endif
+
+comment "virglrenderer needs a toolchain w/ gcc >= 4.9"
+	depends on !BR2_TOOLCHAIN_GCC_AT_LEAST_4_9
diff --git a/package/virglrenderer/virglrenderer.hash b/package/virglrenderer/virglrenderer.hash
new file mode 100644
index 0000000000..03da595091
--- /dev/null
+++ b/package/virglrenderer/virglrenderer.hash
@@ -0,0 +1,5 @@
+# Locally calculated
+sha256  065bc56e89e6f631f96101cd62eba0748e48eb888b434edc86e89d05395e76f3  virglrenderer-1.3.0.tar.gz
+
+# License
+sha256  3b32caf16e2402c2aff2b716858713f3e1feded85c25e71bf829816ee5009402  COPYING
diff --git a/package/virglrenderer/virglrenderer.mk b/package/virglrenderer/virglrenderer.mk
new file mode 100644
index 0000000000..4e7bcbb849
--- /dev/null
+++ b/package/virglrenderer/virglrenderer.mk
@@ -0,0 +1,60 @@
+################################################################################
+#
+# virglrenderer
+#
+################################################################################
+
+VIRGLRENDERER_VERSION = 1.3.0
+VIRGLRENDERER_SITE = https://gitlab.freedesktop.org/virgl/virglrenderer/-/archive/$(VIRGLRENDERER_VERSION)
+VIRGLRENDERER_LICENSE = MIT
+VIRGLRENDERER_LICENSE_FILES = COPYING
+VIRGLRENDERER_INSTALL_STAGING = YES
+VIRGLRENDERER_DEPENDENCIES = \
+	libepoxy \
+	host-pkgconf \
+	host-python3 \
+	host-python-pyyaml
+VIRGLRENDERER_CPE_ID_VALID = YES
+
+ifeq ($(BR2_PACKAGE_VIRGLRENDERER_VIRGL),y)
+ifeq ($(BR2_PACKAGE_HAS_LIBEGL)$(BR2_PACKAGE_HAS_LIBGBM),yy)
+VIRGLRENDERER_PLATFORMS += egl
+VIRGLRENDERER_DEPENDENCIES += libegl \
+			      libgbm
+endif
+
+ifeq ($(BR2_PACKAGE_HAS_LIBGL),y)
+VIRGLRENDERER_PLATFORMS += glx
+VIRGLRENDERER_DEPENDENCIES += libgl
+endif
+endif # BR2_PACKAGE_VIRGLRENDERER_VIRGL
+
+VIRGLRENDERER_CONF_OPTS += -Dplatforms=$(subst $(space),$(comma),$(VIRGLRENDERER_PLATFORMS))
+
+ifeq ($(BR2_PACKAGE_VIRGLRENDERER_VENUS),y)
+VIRGLRENDERER_CONF_OPTS += -Dvenus=true
+VIRGLRENDERER_DEPENDENCIES += vulkan-headers \
+			      vulkan-loader
+else
+VIRGLRENDERER_CONF_OPTS += -Dvenus=false
+endif
+
+VIRGLRENDERER_DRM_BACKENDS-$(BR2_PACKAGE_VIRGLRENDERER_DRM_BACKEND_AMDGPU) += amdgpu-experimental
+VIRGLRENDERER_DRM_BACKENDS-$(BR2_PACKAGE_VIRGLRENDERER_DRM_BACKEND_INTEL) += i915-experimental
+VIRGLRENDERER_DRM_BACKENDS-$(BR2_PACKAGE_VIRGLRENDERER_DRM_BACKEND_MSM) += msm
+VIRGLRENDERER_DRM_BACKENDS-$(BR2_PACKAGE_VIRGLRENDERER_DRM_BACKEND_PANFROST) += panfrost-experimental
+
+VIRGLRENDERER_CONF_OPTS += -Ddrm-renderers=$(subst $(space),$(comma),$(VIRGLRENDERER_DRM_BACKENDS-y))
+
+ifneq ($(VIRGLRENDERER_DRM_BACKENDS-y),)
+VIRGLRENDERER_DEPENDENCIES += libdrm
+endif
+
+ifeq ($(BR2_PACKAGE_VIRGLRENDERER_VAAPI),y)
+VIRGLRENDERER_CONF_OPTS += -Dvideo=true
+VIRGLRENDERER_DEPENDENCIES += libva libdrm
+else
+VIRGLRENDERER_CONF_OPTS += -Dvideo=false
+endif
+
+$(eval $(meson-package))

-- 
2.54.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH RESEND v5 3/5] package/virglrenderer: Fix build with glibc 2.43

[Joseph Kogut]

Add an upstream patch to fix the build with glibc 2.43, not present in a
stable release yet.

Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
---
 .../0001-fix-build-with-glibc-2.43.patch           | 39 ++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/package/virglrenderer/0001-fix-build-with-glibc-2.43.patch b/package/virglrenderer/0001-fix-build-with-glibc-2.43.patch
new file mode 100644
index 0000000000..fda1d9b218
--- /dev/null
+++ b/package/virglrenderer/0001-fix-build-with-glibc-2.43.patch
@@ -0,0 +1,39 @@
+From 986b5fc57b07c06b5e0b3a3694d06898ebc80163 Mon Sep 17 00:00:00 2001
+From: Maximilian Hofmann <maxi@maxiicodes.dev>
+Date: Thu, 26 Feb 2026 23:28:58 +0100
+Subject: [PATCH] fix: build with glibc 2.43
+
+Several glibc functions now return a const pointer if the input is a
+const pointer and a non-const pointer if the input is non-const, causing
+a build failure.
+
+Fix this by declaring the output pointers as const if they are never
+modified, and for the lone failure where the output is modified, instead
+make the input non-const.
+
+Signed-off-by: Maximilian Hofmann <maxi@maxiicodes.dev>
+Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1599>
+
+Upstream: https://gitlab.freedesktop.org/virgl/virglrenderer/-/commit/986b5fc57b07c06b5e0b3a3694d06898ebc80163
+
+Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
+---
+ src/gallium/auxiliary/tgsi/tgsi_text.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c b/src/gallium/auxiliary/tgsi/tgsi_text.c
+index db7d7b95..7e37bf79 100644
+--- a/src/gallium/auxiliary/tgsi/tgsi_text.c
++++ b/src/gallium/auxiliary/tgsi/tgsi_text.c
+@@ -84,7 +84,7 @@ streq_nocase_uprcase(const char *str1,
+ static inline bool skip_n_chars(const char **pcur,
+                                    int n)
+ {
+-   char* str = memchr(*pcur, '\0', n);
++   const char* str = memchr(*pcur, '\0', n);
+    if (unlikely(str)) {
+       *pcur = str;
+       return false;
+-- 
+2.53.0
+

-- 
2.54.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH RESEND v5 4/5] package/qemu: add OpenGL config

[Joseph Kogut]

Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
---
 package/qemu/Config.in | 14 ++++++++++++++
 package/qemu/qemu.mk   |  8 +++++++-
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/package/qemu/Config.in b/package/qemu/Config.in
index e16eafe446..e4e8eb3b63 100644
--- a/package/qemu/Config.in
+++ b/package/qemu/Config.in
@@ -116,6 +116,20 @@ config BR2_PACKAGE_QEMU_SDL
 	  Say 'y' to enable the SDL frontend, that is, a graphical
 	  window presenting the VM's display.
 
+config BR2_PACKAGE_QEMU_OPENGL
+	bool "Enable OpenGL"
+	depends on BR2_PACKAGE_HAS_LIBEGL || BR2_PACKAGE_HAS_LIBGL # libepoxy
+	select BR2_PACKAGE_LIBEPOXY
+	help
+	  Say 'y' to enable OpenGL accelerated display frontend support.
+	  This is necessary to efficiently display frames rendered in a
+	  guest on the host.
+
+	  Run qemu with `-display sdl,gl=on`
+
+comment "OpenGL support needs an OpenGL and/or OpenGL EGL backend"
+	depends on !(BR2_PACKAGE_HAS_LIBEGL || BR2_PACKAGE_HAS_LIBGL)
+
 config BR2_PACKAGE_QEMU_FDT
 	bool "Enable FDT"
 	select BR2_PACKAGE_DTC
diff --git a/package/qemu/qemu.mk b/package/qemu/qemu.mk
index 97f8e22091..9b780797fa 100644
--- a/package/qemu/qemu.mk
+++ b/package/qemu/qemu.mk
@@ -274,6 +274,13 @@ else
 QEMU_OPTS += --disable-usb-redir
 endif
 
+ifeq ($(BR2_PACKAGE_QEMU_OPENGL),y)
+QEMU_OPTS += --enable-opengl
+QEMU_DEPENDENCIES += libepoxy
+else
+QEMU_OPTS += --disable-opengl
+endif
+
 ifeq ($(BR2_STATIC_LIBS),y)
 QEMU_OPTS += --static
 endif
@@ -330,7 +337,6 @@ define QEMU_CONFIGURE_CMDS
 			--disable-membarrier \
 			--disable-mpath \
 			--disable-netmap \
-			--disable-opengl \
 			--disable-oss \
 			--disable-pa \
 			--disable-plugins \

-- 
2.54.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH RESEND v5 4/5] package/qemu: add OpenGL config

[Romain Naour via buildroot]

Hello Joseph, All,

Le 12/05/2026 à 21:36, Joseph Kogut a écrit :
> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
> ---
>  package/qemu/Config.in | 14 ++++++++++++++
>  package/qemu/qemu.mk   |  8 +++++++-
>  2 files changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/package/qemu/Config.in b/package/qemu/Config.in
> index e16eafe446..e4e8eb3b63 100644
> --- a/package/qemu/Config.in
> +++ b/package/qemu/Config.in
> @@ -116,6 +116,20 @@ config BR2_PACKAGE_QEMU_SDL
>  	  Say 'y' to enable the SDL frontend, that is, a graphical
>  	  window presenting the VM's display.
>  
> +config BR2_PACKAGE_QEMU_OPENGL
> +	bool "Enable OpenGL"
> +	depends on BR2_PACKAGE_HAS_LIBEGL || BR2_PACKAGE_HAS_LIBGL # libepoxy

With patch 1/5 removing egl or gl dependencies in libepoxy, the comment about
this egl or gl dependency for the Qemu opengl option is no longer true.

It's the Qemu opengl option itself that require egl or gl.

Best regards,
Romain

> +	select BR2_PACKAGE_LIBEPOXY
> +	help
> +	  Say 'y' to enable OpenGL accelerated display frontend support.
> +	  This is necessary to efficiently display frames rendered in a
> +	  guest on the host.
> +
> +	  Run qemu with `-display sdl,gl=on`
> +
> +comment "OpenGL support needs an OpenGL and/or OpenGL EGL backend"
> +	depends on !(BR2_PACKAGE_HAS_LIBEGL || BR2_PACKAGE_HAS_LIBGL)
> +
>  config BR2_PACKAGE_QEMU_FDT
>  	bool "Enable FDT"
>  	select BR2_PACKAGE_DTC
> diff --git a/package/qemu/qemu.mk b/package/qemu/qemu.mk
> index 97f8e22091..9b780797fa 100644
> --- a/package/qemu/qemu.mk
> +++ b/package/qemu/qemu.mk
> @@ -274,6 +274,13 @@ else
>  QEMU_OPTS += --disable-usb-redir
>  endif
>  
> +ifeq ($(BR2_PACKAGE_QEMU_OPENGL),y)
> +QEMU_OPTS += --enable-opengl
> +QEMU_DEPENDENCIES += libepoxy
> +else
> +QEMU_OPTS += --disable-opengl
> +endif
> +
>  ifeq ($(BR2_STATIC_LIBS),y)
>  QEMU_OPTS += --static
>  endif
> @@ -330,7 +337,6 @@ define QEMU_CONFIGURE_CMDS
>  			--disable-membarrier \
>  			--disable-mpath \
>  			--disable-netmap \
> -			--disable-opengl \
>  			--disable-oss \
>  			--disable-pa \
>  			--disable-plugins \
> 

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Joseph Kogut]

Add optional virglrenderer support, along with enabling OpenGL when
necessary.

https://qemu.readthedocs.io/en/v10.0.3/system/devices/virtio-gpu.html#virtio-gpu-virglrenderer

Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
---
 package/qemu/Config.in | 17 +++++++++++++++++
 package/qemu/qemu.mk   |  7 +++++++
 2 files changed, 24 insertions(+)

diff --git a/package/qemu/Config.in b/package/qemu/Config.in
index e4e8eb3b63..599bcb11bb 100644
--- a/package/qemu/Config.in
+++ b/package/qemu/Config.in
@@ -130,6 +130,23 @@ config BR2_PACKAGE_QEMU_OPENGL
 comment "OpenGL support needs an OpenGL and/or OpenGL EGL backend"
 	depends on !(BR2_PACKAGE_HAS_LIBEGL || BR2_PACKAGE_HAS_LIBGL)
 
+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
+	help
+	  Say 'y' to enable virglrenderer, enabling GL and Vulkan
+	  passthrough from the host to the guest through virtio-gpu.
+	  This enables the guest to have accelerated GL and/or Vulkan.
+
+	  Run qemu with `-device virtio-gpu-gl`
+
+	  https://qemu.readthedocs.io/en/v10.0.3/system/devices/virtio-gpu.html#virtio-gpu-virglrenderer
+
+comment "virglrenderer needs OpenGL accelerated display frontend support"
+	depends on !(BR2_PACKAGE_HAS_LIBEGL || BR2_PACKAGE_HAS_LIBGL)
+
 config BR2_PACKAGE_QEMU_FDT
 	bool "Enable FDT"
 	select BR2_PACKAGE_DTC
diff --git a/package/qemu/qemu.mk b/package/qemu/qemu.mk
index 9b780797fa..e250128dfa 100644
--- a/package/qemu/qemu.mk
+++ b/package/qemu/qemu.mk
@@ -281,6 +281,13 @@ else
 QEMU_OPTS += --disable-opengl
 endif
 
+ifeq ($(BR2_PACKAGE_QEMU_VIRGLRENDERER),y)
+QEMU_OPTS += --enable-virglrenderer
+QEMU_DEPENDENCIES += virglrenderer
+else
+QEMU_OPTS += --disable-virglrenderer
+endif
+
 ifeq ($(BR2_STATIC_LIBS),y)
 QEMU_OPTS += --static
 endif

-- 
2.54.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Romain Naour via buildroot]

Hello Joseph, All,

Le 12/05/2026 à 21:36, Joseph Kogut a écrit :
> Add optional virglrenderer support, along with enabling OpenGL when
> necessary.
> 
> https://qemu.readthedocs.io/en/v10.0.3/system/devices/virtio-gpu.html#virtio-gpu-virglrenderer
> 
> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
> ---
>  package/qemu/Config.in | 17 +++++++++++++++++
>  package/qemu/qemu.mk   |  7 +++++++
>  2 files changed, 24 insertions(+)
> 
> diff --git a/package/qemu/Config.in b/package/qemu/Config.in
> index e4e8eb3b63..599bcb11bb 100644
> --- a/package/qemu/Config.in
> +++ b/package/qemu/Config.in
> @@ -130,6 +130,23 @@ config BR2_PACKAGE_QEMU_OPENGL
>  comment "OpenGL support needs an OpenGL and/or OpenGL EGL backend"
>  	depends on !(BR2_PACKAGE_HAS_LIBEGL || BR2_PACKAGE_HAS_LIBGL)
>  
> +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.

Best regards,
Romain

> +	help
> +	  Say 'y' to enable virglrenderer, enabling GL and Vulkan
> +	  passthrough from the host to the guest through virtio-gpu.
> +	  This enables the guest to have accelerated GL and/or Vulkan.
> +
> +	  Run qemu with `-device virtio-gpu-gl`
> +
> +	  https://qemu.readthedocs.io/en/v10.0.3/system/devices/virtio-gpu.html#virtio-gpu-virglrenderer
> +
> +comment "virglrenderer needs OpenGL accelerated display frontend support"
> +	depends on !(BR2_PACKAGE_HAS_LIBEGL || BR2_PACKAGE_HAS_LIBGL)
> +
>  config BR2_PACKAGE_QEMU_FDT
>  	bool "Enable FDT"
>  	select BR2_PACKAGE_DTC
> diff --git a/package/qemu/qemu.mk b/package/qemu/qemu.mk
> index 9b780797fa..e250128dfa 100644
> --- a/package/qemu/qemu.mk
> +++ b/package/qemu/qemu.mk
> @@ -281,6 +281,13 @@ else
>  QEMU_OPTS += --disable-opengl
>  endif
>  
> +ifeq ($(BR2_PACKAGE_QEMU_VIRGLRENDERER),y)
> +QEMU_OPTS += --enable-virglrenderer
> +QEMU_DEPENDENCIES += virglrenderer
> +else
> +QEMU_OPTS += --disable-virglrenderer
> +endif
> +
>  ifeq ($(BR2_STATIC_LIBS),y)
>  QEMU_OPTS += --static
>  endif
> 

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Romain Naour via buildroot]

Le 13/05/2026 à 19:17, Romain Naour a écrit :
> Hello Joseph, All,
> 
> Le 12/05/2026 à 21:36, Joseph Kogut a écrit :
>> Add optional virglrenderer support, along with enabling OpenGL when
>> necessary.
>>
>> https://qemu.readthedocs.io/en/v10.0.3/system/devices/virtio-gpu.html#virtio-gpu-virglrenderer
>>
>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
>> ---
>>  package/qemu/Config.in | 17 +++++++++++++++++
>>  package/qemu/qemu.mk   |  7 +++++++
>>  2 files changed, 24 insertions(+)
>>
>> diff --git a/package/qemu/Config.in b/package/qemu/Config.in
>> index e4e8eb3b63..599bcb11bb 100644
>> --- a/package/qemu/Config.in
>> +++ b/package/qemu/Config.in
>> @@ -130,6 +130,23 @@ config BR2_PACKAGE_QEMU_OPENGL
>>  comment "OpenGL support needs an OpenGL and/or OpenGL EGL backend"
>>  	depends on !(BR2_PACKAGE_HAS_LIBEGL || BR2_PACKAGE_HAS_LIBGL)
>>  
>> +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

I guess Qemu virglrenderer should select BR2_PACKAGE_VIRGLRENDERER_VIRGL in this
case. BR2_PACKAGE_VIRGLRENDERER_VIRGL is indeed selected by default but can be
manually disabled from menuconfig.

> 
> 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.

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.

Best regards,
Romain

> 
> Best regards,
> Romain
> 
>> +	help
>> +	  Say 'y' to enable virglrenderer, enabling GL and Vulkan
>> +	  passthrough from the host to the guest through virtio-gpu.
>> +	  This enables the guest to have accelerated GL and/or Vulkan.
>> +
>> +	  Run qemu with `-device virtio-gpu-gl`
>> +
>> +	  https://qemu.readthedocs.io/en/v10.0.3/system/devices/virtio-gpu.html#virtio-gpu-virglrenderer
>> +
>> +comment "virglrenderer needs OpenGL accelerated display frontend support"
>> +	depends on !(BR2_PACKAGE_HAS_LIBEGL || BR2_PACKAGE_HAS_LIBGL)
>> +
>>  config BR2_PACKAGE_QEMU_FDT
>>  	bool "Enable FDT"
>>  	select BR2_PACKAGE_DTC
>> diff --git a/package/qemu/qemu.mk b/package/qemu/qemu.mk
>> index 9b780797fa..e250128dfa 100644
>> --- a/package/qemu/qemu.mk
>> +++ b/package/qemu/qemu.mk
>> @@ -281,6 +281,13 @@ else
>>  QEMU_OPTS += --disable-opengl
>>  endif
>>  
>> +ifeq ($(BR2_PACKAGE_QEMU_VIRGLRENDERER),y)
>> +QEMU_OPTS += --enable-virglrenderer
>> +QEMU_DEPENDENCIES += virglrenderer
>> +else
>> +QEMU_OPTS += --disable-virglrenderer
>> +endif
>> +
>>  ifeq ($(BR2_STATIC_LIBS),y)
>>  QEMU_OPTS += --static
>>  endif
>>
> 

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Joseph Kogut]

Hello Romain,

On Wed, May 13, 2026 at 10:17 AM Romain Naour <romain.naour@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.

You followed up while I was drafting my own reply. :)

On Wed, May 13, 2026 at 11:06 AM Romain Naour <romain.naour@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.

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

Best regards,
Joseph

[0] https://lore.kernel.org/qemu-devel/20260317182049.33848-1-lucaaamaral@gmail.com/
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Romain Naour via buildroot]

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@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@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/

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Joseph Kogut]

Hello Romain,

On Wed, May 13, 2026 at 2:04 PM Romain Naour <romain.naour@smile.fr> wrote:
>
> 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)

No problem, this is a fast-evolving and fascinating facet of an
already complex niche. It's taken me some time to wrap my own brain
around it.

> >
> > You followed up while I was drafting my own reply. :)
> >
> > On Wed, May 13, 2026 at 11:06 AM Romain Naour <romain.naour@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?
>

VirGL -> Graphics API-level mediated OpenGL
Venus -> Graphics API-level mediated Vulkan
Host native context -> mediated kernel DRM uAPI

When VirGL is enabled in virglrenderer, Mesa in the guest uses a virgl
UMD to expose an OpenGL API to guest applications, and on the backend
converts those API calls to a gallium-like command stream that's
forwarded over virtio-gpu to the host for execution using the native
UMD. Venus is similar, but for Vulkan. Both of these are very
portable, as they only require the host to have a graphics stack that
supports these APIs. Users could also enable only Venus and still have
GL support in the guest, e.g. using Zink [0], which implements GL on
top of Vulkan.

The host native context backend provides mediated access to the host
kernel's DRM uAPI. When enabled for supported hardware, the native UMD
runs in the guest, and the DRM commands are forwarded to the host
kernel. This allows, e.g., running radeonsi and radv drivers for GL
and Vulkan respectively on AMD hardware inside a virtual machine, on
top of enabling features like hardware-accelerated video decode in
guests. Host native context has the lowest overhead, because rather
than emulating a GPU, the guest just uses the DRM uAPI proxied over
virtio-gpu. However, it requires small modifications to the Mesa UMD
and virglrenderer for each driver, so it's not as widely supported.

To answer your question succinctly, selecting virglrenderer without
virgl still leaves Venus and DRM drivers, and any combination of these
can provide the guest with graphics and compute capabilities. Building
virglrenderer without virgl, venus, or DRM probably (?) results in a
qemu build that works as expected, but lacks graphics/compute for
guests.

We turn on VirGL by default when the host has libGL, and likewise turn
on Venus by default when a mesa Vulkan driver is enabled. We also turn
on DRM backends by default when their corresponding UMDs are selected,
more on that below.

> >
> > 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.

That's a reasonable next step.

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

This is a bit tricky. Earlier versions in this series attempted to
implicitly enable virglrenderer DRM backends based on the presence of
a Mesa UMD, the consumer of the DRM API. So if we had
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_RADEONSI or
BR2_PACKAGE_MESA3D_VULKAN_DRIVER_AMD, we would enable the amdgpu DRM
backend in virglrenderer.

The initial assumption was that having these UMDs enabled implies we
also have the corresponding KMD. However, I realized that another very
valid config is to have no UMD enabled on the host, in which case we
need an explicit config to enable the DRM backend for virglrenderer.
This works in coordination with a mesa config to enable virtio as a
backend for various UMDs, which is part of a separate series [1] (This
mesa build is intended to run in a guest environment).

I'm open to thoughts and ideas on the best way to handle this.

Best,
Joseph

[0] https://docs.mesa3d.org/drivers/zink.html
[1] https://lore.kernel.org/buildroot/20260512-mesa3d-amdgpu-virtio-v2-0-30678b797df9@anodize.com/T/#t
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Romain Naour via buildroot]

Hello Joseph,

Le 14/05/2026 à 00:09, Joseph Kogut a écrit :
> Hello Romain,
> 
> On Wed, May 13, 2026 at 2:04 PM Romain Naour <romain.naour@smile.fr> wrote:
>>
>> 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)
> 
> No problem, this is a fast-evolving and fascinating facet of an
> already complex niche. It's taken me some time to wrap my own brain
> around it.
> 
>>>
>>> You followed up while I was drafting my own reply. :)
>>>
>>> On Wed, May 13, 2026 at 11:06 AM Romain Naour <romain.naour@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?
>>
> 
> VirGL -> Graphics API-level mediated OpenGL
> Venus -> Graphics API-level mediated Vulkan
> Host native context -> mediated kernel DRM uAPI
> 
> When VirGL is enabled in virglrenderer, Mesa in the guest uses a virgl
> UMD to expose an OpenGL API to guest applications, and on the backend
> converts those API calls to a gallium-like command stream that's
> forwarded over virtio-gpu to the host for execution using the native
> UMD. Venus is similar, but for Vulkan. Both of these are very
> portable, as they only require the host to have a graphics stack that
> supports these APIs. Users could also enable only Venus and still have
> GL support in the guest, e.g. using Zink [0], which implements GL on
> top of Vulkan.
> 
> The host native context backend provides mediated access to the host
> kernel's DRM uAPI. When enabled for supported hardware, the native UMD
> runs in the guest, and the DRM commands are forwarded to the host
> kernel. This allows, e.g., running radeonsi and radv drivers for GL
> and Vulkan respectively on AMD hardware inside a virtual machine, on
> top of enabling features like hardware-accelerated video decode in
> guests. Host native context has the lowest overhead, because rather
> than emulating a GPU, the guest just uses the DRM uAPI proxied over
> virtio-gpu. However, it requires small modifications to the Mesa UMD
> and virglrenderer for each driver, so it's not as widely supported.
> 
> To answer your question succinctly, selecting virglrenderer without
> virgl still leaves Venus and DRM drivers, and any combination of these
> can provide the guest with graphics and compute capabilities. Building
> virglrenderer without virgl, venus, or DRM probably (?) results in a
> qemu build that works as expected, but lacks graphics/compute for
> guests.

Indeed, virglrenderer build (at least) without any virgl, venus, or DRM (this
case may be non-functional though):

virglrenderer 1.3.0

  Directories
    prefix                 : /usr
    libdir                 : lib

  Configuration
    c_args                 : -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -O2 -g0 -D_FORTIFY_SOURCE=1
    egl                    : false
    glx                    : false
    gbm                    : false
    venus                  : false
    drm-amdgpu             : false
    drm-asahi              : false
    drm-i915               : false
    drm-panfrost           : false
    drm-msm                : false
    render server worker   : none
    video                  : false
    tests                  : false
    fuzzer                 : false
    tracing                : none
    unstable-apis          : false

Even if it will prevent any use of graphics/compute for Qemu guests.

> 
> We turn on VirGL by default when the host has libGL, and likewise turn
> on Venus by default when a mesa Vulkan driver is enabled. We also turn
> on DRM backends by default when their corresponding UMDs are selected,
> more on that below.

I'm agree with that but using "default y if" still allows the user to disable
the option (because it's an user visible kconfig option):

config BR2_PACKAGE_VIRGLRENDERER_VIRGL
	bool "virgl"
	default y

I'm tkinking about this case for the sake of our autobuilder testing that can
select or disable randomly any kconfig option when it generate the defconfig to
build.

I guess you could try using hidden options like for waffle package:

https://gitlab.com/buildroot.org/buildroot/-/blob/master/package/waffle/Config.in?ref_type=heads

(draft):

config BR2_PACKAGE_VIRGLRENDERER_SUPPORTS_VIRGL
	bool
	default y if (BR2_PACKAGE_HAS_LIBEGL && BR2_PACKAGE_HAS_LIBGBM) \
		|| BR2_PACKAGE_HAS_LIBGL

config BR2_PACKAGE_VIRGLRENDERER
	bool "virglrenderer"
	depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_9
	depends on BR2_TOOLCHAIN_HAS_THREADS
	depends on BR2_USE_MMU # fork()
	select BR2_PACKAGE_LIBEPOXY
	help

We can actually get ride of BR2_PACKAGE_VIRGLRENDERER_VIRGL option:

ifeq ($(BR2_PACKAGE_VIRGLRENDERER_SUPPORTS_VIRGL),y)
ifeq ($(BR2_PACKAGE_HAS_LIBEGL)$(BR2_PACKAGE_HAS_LIBGBM),yy)
VIRGLRENDERER_PLATFORMS += egl
VIRGLRENDERER_DEPENDENCIES += libegl \
			      libgbm
endif

ifeq ($(BR2_PACKAGE_HAS_LIBGL),y)
VIRGLRENDERER_PLATFORMS += glx
VIRGLRENDERER_DEPENDENCIES += libgl
endif
endif # BR2_PACKAGE_VIRGLRENDERER_SUPPORTS_VIRGL

Or do you want let the user the hability to disable virglrenderer virgl support
evenf if EGL or GL is available?

> 
>>>
>>> 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.
> 
> That's a reasonable next step.
> 
>> Then, BR2_PACKAGE_QEMU_VIRGLRENDERER should not only select
>> BR2_PACKAGE_VIRGLRENDERER without enabling any suboption.
>>
> 
> This is a bit tricky. Earlier versions in this series attempted to
> implicitly enable virglrenderer DRM backends based on the presence of
> a Mesa UMD, the consumer of the DRM API. So if we had
> BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_RADEONSI or
> BR2_PACKAGE_MESA3D_VULKAN_DRIVER_AMD, we would enable the amdgpu DRM
> backend in virglrenderer.
> 
> The initial assumption was that having these UMDs enabled implies we
> also have the corresponding KMD. However, I realized that another very
> valid config is to have no UMD enabled on the host, in which case we
> need an explicit config to enable the DRM backend for virglrenderer.
> This works in coordination with a mesa config to enable virtio as a
> backend for various UMDs, which is part of a separate series [1] (This
> mesa build is intended to run in a guest environment).

Please, try to add a comment (in help or .mk direclty) about such "valid corner
use case".

> 
> I'm open to thoughts and ideas on the best way to handle this.

I'm not sure about virglrenderer DRM backends being enabled based on the
presence of a Mesa UMD. If only the user can know if a specific virglrenderer
DRM backend can be enabled or not, we can't do much.

At least we could add a comment in Config.in when no suboption is selected

For example, if busybox package is disabled a comment is printed in menuconfig:

comment "You may need to enable other packages to get a working system"
comment "You better know what you're doing!"

https://gitlab.com/buildroot.org/buildroot/-/blob/master/package/busybox/Config.in?ref_type=heads#L101

comment "You may need to enable virgl or venus or a DRM backend to get a working
graphics compute for guests"
	depends on !BR2_PACKAGE_VIRGLRENDERER_VIRGL \
		&& !BR2_PACKAGE_VIRGLRENDERER_VENUS \
		&& !BR2_PACKAGE_VIRGLRENDERER_DRM_BACKEND_AMDGPU \
		etc..

(sorry for the very long comment line)

Best regards,
Romain

> 
> Best,
> Joseph
> 
> [0] https://docs.mesa3d.org/drivers/zink.html
> [1] https://lore.kernel.org/buildroot/20260512-mesa3d-amdgpu-virtio-v2-0-30678b797df9@anodize.com/T/#t

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Joseph Kogut]

Hello Romain,

On Thu, May 14, 2026 at 5:10 AM Romain Naour <romain.naour@smile.fr> wrote:
>
> Le 14/05/2026 à 00:09, Joseph Kogut a écrit :
> >
> > To answer your question succinctly, selecting virglrenderer without
> > virgl still leaves Venus and DRM drivers, and any combination of these
> > can provide the guest with graphics and compute capabilities. Building
> > virglrenderer without virgl, venus, or DRM probably (?) results in a
> > qemu build that works as expected, but lacks graphics/compute for
> > guests.
>
> Indeed, virglrenderer build (at least) without any virgl, venus, or DRM (this
> case may be non-functional though):
>
> virglrenderer 1.3.0
>
>   Directories
>     prefix                 : /usr
>     libdir                 : lib
>
>   Configuration
>     c_args                 : -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> -D_FILE_OFFSET_BITS=64 -O2 -g0 -D_FORTIFY_SOURCE=1
>     egl                    : false
>     glx                    : false
>     gbm                    : false
>     venus                  : false
>     drm-amdgpu             : false
>     drm-asahi              : false
>     drm-i915               : false
>     drm-panfrost           : false
>     drm-msm                : false
>     render server worker   : none
>     video                  : false
>     tests                  : false
>     fuzzer                 : false
>     tracing                : none
>     unstable-apis          : false
>
> Even if it will prevent any use of graphics/compute for Qemu guests.
>
> >
> > We turn on VirGL by default when the host has libGL, and likewise turn
> > on Venus by default when a mesa Vulkan driver is enabled. We also turn
> > on DRM backends by default when their corresponding UMDs are selected,
> > more on that below.
>
> I'm agree with that but using "default y if" still allows the user to disable
> the option (because it's an user visible kconfig option):
>
> config BR2_PACKAGE_VIRGLRENDERER_VIRGL
>         bool "virgl"
>         default y
>
> I'm tkinking about this case for the sake of our autobuilder testing that can
> select or disable randomly any kconfig option when it generate the defconfig to
> build.
>

Having the ability to disable VirGL and Venus is likely quite
desirable, when a DRM backend is available. VirGL/Venus and host
native context both provide paths to accelerated OpenGL/Vulkan, but
host native context has lower overhead, better security, more complete
API support, and additional support for OpenCL and VAAPI for hardware
accelerated video encode/decode. There's even a merge request open in
the virglrenderer repository to support ROCm in guests [0].

> I guess you could try using hidden options like for waffle package:
>
> https://gitlab.com/buildroot.org/buildroot/-/blob/master/package/waffle/Config.in?ref_type=heads
>
> (draft):
>
> config BR2_PACKAGE_VIRGLRENDERER_SUPPORTS_VIRGL
>         bool
>         default y if (BR2_PACKAGE_HAS_LIBEGL && BR2_PACKAGE_HAS_LIBGBM) \
>                 || BR2_PACKAGE_HAS_LIBGL
>
> config BR2_PACKAGE_VIRGLRENDERER
>         bool "virglrenderer"
>         depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_9
>         depends on BR2_TOOLCHAIN_HAS_THREADS
>         depends on BR2_USE_MMU # fork()
>         select BR2_PACKAGE_LIBEPOXY
>         help
>
> We can actually get ride of BR2_PACKAGE_VIRGLRENDERER_VIRGL option:
>
> ifeq ($(BR2_PACKAGE_VIRGLRENDERER_SUPPORTS_VIRGL),y)
> ifeq ($(BR2_PACKAGE_HAS_LIBEGL)$(BR2_PACKAGE_HAS_LIBGBM),yy)
> VIRGLRENDERER_PLATFORMS += egl
> VIRGLRENDERER_DEPENDENCIES += libegl \
>                               libgbm
> endif
>
> ifeq ($(BR2_PACKAGE_HAS_LIBGL),y)
> VIRGLRENDERER_PLATFORMS += glx
> VIRGLRENDERER_DEPENDENCIES += libgl
> endif
> endif # BR2_PACKAGE_VIRGLRENDERER_SUPPORTS_VIRGL
>
> Or do you want let the user the hability to disable virglrenderer virgl support
> evenf if EGL or GL is available?

If a user knows their KMD is a supported host native context path,
they may wish to disable API forwarding (VirGL/Venus) to reduce code
size and/or prevent less secure paths from being available.

For example, if a guest has a mesa build that lacks host native
context virtio backends, but includes the virgl/venus UMDs, that guest
gets access to running untrusted code in the host UMD, which opens up
numerous potential exploits and VM escapes.

Disabling API forwarding in virglrenderer means guests must run their
own host native context UMD inside the guest address space, which
talks to the host kernel's DRM API through virglrenderer over
virtio-gpu. Without this, they get no graphics or compute capability,
no fallback to API forwarding. This removes the host's Mesa build from
the attack surface, in addition to being faster and more featured.

> >
> >>>
> >>> 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.
> >
> > That's a reasonable next step.
> >
> >> Then, BR2_PACKAGE_QEMU_VIRGLRENDERER should not only select
> >> BR2_PACKAGE_VIRGLRENDERER without enabling any suboption.
> >>
> >
> > This is a bit tricky. Earlier versions in this series attempted to
> > implicitly enable virglrenderer DRM backends based on the presence of
> > a Mesa UMD, the consumer of the DRM API. So if we had
> > BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_RADEONSI or
> > BR2_PACKAGE_MESA3D_VULKAN_DRIVER_AMD, we would enable the amdgpu DRM
> > backend in virglrenderer.
> >
> > The initial assumption was that having these UMDs enabled implies we
> > also have the corresponding KMD. However, I realized that another very
> > valid config is to have no UMD enabled on the host, in which case we
> > need an explicit config to enable the DRM backend for virglrenderer.
> > This works in coordination with a mesa config to enable virtio as a
> > backend for various UMDs, which is part of a separate series [1] (This
> > mesa build is intended to run in a guest environment).
>
> Please, try to add a comment (in help or .mk direclty) about such "valid corner
> use case".
>

I'll add this to the next submission.

> >
> > I'm open to thoughts and ideas on the best way to handle this.
>
> I'm not sure about virglrenderer DRM backends being enabled based on the
> presence of a Mesa UMD. If only the user can know if a specific virglrenderer
> DRM backend can be enabled or not, we can't do much.
>
> At least we could add a comment in Config.in when no suboption is selected
>
> For example, if busybox package is disabled a comment is printed in menuconfig:
>
> comment "You may need to enable other packages to get a working system"
> comment "You better know what you're doing!"
>
> https://gitlab.com/buildroot.org/buildroot/-/blob/master/package/busybox/Config.in?ref_type=heads#L101
>
> comment "You may need to enable virgl or venus or a DRM backend to get a working
> graphics compute for guests"
>         depends on !BR2_PACKAGE_VIRGLRENDERER_VIRGL \
>                 && !BR2_PACKAGE_VIRGLRENDERER_VENUS \
>                 && !BR2_PACKAGE_VIRGLRENDERER_DRM_BACKEND_AMDGPU \
>                 etc..
>
> (sorry for the very long comment line)
>

I think additional messaging in the Config.in help line would benefit
users. Maybe even a defconfig or test case demonstrating setup?

[0] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1568

Best,
Joseph
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Romain Naour via buildroot]

Hello Joseph,

Le 14/05/2026 à 20:05, Joseph Kogut a écrit :
> Hello Romain,
> 
> On Thu, May 14, 2026 at 5:10 AM Romain Naour <romain.naour@smile.fr> wrote:
>>
>> Le 14/05/2026 à 00:09, Joseph Kogut a écrit :
>>>
>>> To answer your question succinctly, selecting virglrenderer without
>>> virgl still leaves Venus and DRM drivers, and any combination of these
>>> can provide the guest with graphics and compute capabilities. Building
>>> virglrenderer without virgl, venus, or DRM probably (?) results in a
>>> qemu build that works as expected, but lacks graphics/compute for
>>> guests.
>>
>> Indeed, virglrenderer build (at least) without any virgl, venus, or DRM (this
>> case may be non-functional though):
>>
>> virglrenderer 1.3.0
>>
>>   Directories
>>     prefix                 : /usr
>>     libdir                 : lib
>>
>>   Configuration
>>     c_args                 : -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
>> -D_FILE_OFFSET_BITS=64 -O2 -g0 -D_FORTIFY_SOURCE=1
>>     egl                    : false
>>     glx                    : false
>>     gbm                    : false
>>     venus                  : false
>>     drm-amdgpu             : false
>>     drm-asahi              : false
>>     drm-i915               : false
>>     drm-panfrost           : false
>>     drm-msm                : false
>>     render server worker   : none
>>     video                  : false
>>     tests                  : false
>>     fuzzer                 : false
>>     tracing                : none
>>     unstable-apis          : false
>>
>> Even if it will prevent any use of graphics/compute for Qemu guests.
>>
>>>
>>> We turn on VirGL by default when the host has libGL, and likewise turn
>>> on Venus by default when a mesa Vulkan driver is enabled. We also turn
>>> on DRM backends by default when their corresponding UMDs are selected,
>>> more on that below.
>>
>> I'm agree with that but using "default y if" still allows the user to disable
>> the option (because it's an user visible kconfig option):
>>
>> config BR2_PACKAGE_VIRGLRENDERER_VIRGL
>>         bool "virgl"
>>         default y
>>
>> I'm tkinking about this case for the sake of our autobuilder testing that can
>> select or disable randomly any kconfig option when it generate the defconfig to
>> build.
>>
> 
> Having the ability to disable VirGL and Venus is likely quite
> desirable, when a DRM backend is available. VirGL/Venus and host
> native context both provide paths to accelerated OpenGL/Vulkan, but
> host native context has lower overhead, better security, more complete
> API support, and additional support for OpenCL and VAAPI for hardware
> accelerated video encode/decode. There's even a merge request open in
> the virglrenderer repository to support ROCm in guests [0].

Ok.

> 
>> I guess you could try using hidden options like for waffle package:
>>
>> https://gitlab.com/buildroot.org/buildroot/-/blob/master/package/waffle/Config.in?ref_type=heads
>>
>> (draft):
>>
>> config BR2_PACKAGE_VIRGLRENDERER_SUPPORTS_VIRGL
>>         bool
>>         default y if (BR2_PACKAGE_HAS_LIBEGL && BR2_PACKAGE_HAS_LIBGBM) \
>>                 || BR2_PACKAGE_HAS_LIBGL
>>
>> config BR2_PACKAGE_VIRGLRENDERER
>>         bool "virglrenderer"
>>         depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_9
>>         depends on BR2_TOOLCHAIN_HAS_THREADS
>>         depends on BR2_USE_MMU # fork()
>>         select BR2_PACKAGE_LIBEPOXY
>>         help
>>
>> We can actually get ride of BR2_PACKAGE_VIRGLRENDERER_VIRGL option:
>>
>> ifeq ($(BR2_PACKAGE_VIRGLRENDERER_SUPPORTS_VIRGL),y)
>> ifeq ($(BR2_PACKAGE_HAS_LIBEGL)$(BR2_PACKAGE_HAS_LIBGBM),yy)
>> VIRGLRENDERER_PLATFORMS += egl
>> VIRGLRENDERER_DEPENDENCIES += libegl \
>>                               libgbm
>> endif
>>
>> ifeq ($(BR2_PACKAGE_HAS_LIBGL),y)
>> VIRGLRENDERER_PLATFORMS += glx
>> VIRGLRENDERER_DEPENDENCIES += libgl
>> endif
>> endif # BR2_PACKAGE_VIRGLRENDERER_SUPPORTS_VIRGL
>>
>> Or do you want let the user the hability to disable virglrenderer virgl support
>> evenf if EGL or GL is available?
> 
> If a user knows their KMD is a supported host native context path,
> they may wish to disable API forwarding (VirGL/Venus) to reduce code
> size and/or prevent less secure paths from being available.
> 
> For example, if a guest has a mesa build that lacks host native
> context virtio backends, but includes the virgl/venus UMDs, that guest
> gets access to running untrusted code in the host UMD, which opens up
> numerous potential exploits and VM escapes.
> 
> Disabling API forwarding in virglrenderer means guests must run their
> own host native context UMD inside the guest address space, which
> talks to the host kernel's DRM API through virglrenderer over
> virtio-gpu. Without this, they get no graphics or compute capability,
> no fallback to API forwarding. This removes the host's Mesa build from
> the attack surface, in addition to being faster and more featured.

Ok.

> 
>>>
>>>>>
>>>>> 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.
>>>
>>> That's a reasonable next step.
>>>
>>>> Then, BR2_PACKAGE_QEMU_VIRGLRENDERER should not only select
>>>> BR2_PACKAGE_VIRGLRENDERER without enabling any suboption.
>>>>
>>>
>>> This is a bit tricky. Earlier versions in this series attempted to
>>> implicitly enable virglrenderer DRM backends based on the presence of
>>> a Mesa UMD, the consumer of the DRM API. So if we had
>>> BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_RADEONSI or
>>> BR2_PACKAGE_MESA3D_VULKAN_DRIVER_AMD, we would enable the amdgpu DRM
>>> backend in virglrenderer.
>>>
>>> The initial assumption was that having these UMDs enabled implies we
>>> also have the corresponding KMD. However, I realized that another very
>>> valid config is to have no UMD enabled on the host, in which case we
>>> need an explicit config to enable the DRM backend for virglrenderer.
>>> This works in coordination with a mesa config to enable virtio as a
>>> backend for various UMDs, which is part of a separate series [1] (This
>>> mesa build is intended to run in a guest environment).
>>
>> Please, try to add a comment (in help or .mk direclty) about such "valid corner
>> use case".
>>
> 
> I'll add this to the next submission.
> 
>>>
>>> I'm open to thoughts and ideas on the best way to handle this.
>>
>> I'm not sure about virglrenderer DRM backends being enabled based on the
>> presence of a Mesa UMD. If only the user can know if a specific virglrenderer
>> DRM backend can be enabled or not, we can't do much.
>>
>> At least we could add a comment in Config.in when no suboption is selected
>>
>> For example, if busybox package is disabled a comment is printed in menuconfig:
>>
>> comment "You may need to enable other packages to get a working system"
>> comment "You better know what you're doing!"
>>
>> https://gitlab.com/buildroot.org/buildroot/-/blob/master/package/busybox/Config.in?ref_type=heads#L101
>>
>> comment "You may need to enable virgl or venus or a DRM backend to get a working
>> graphics compute for guests"
>>         depends on !BR2_PACKAGE_VIRGLRENDERER_VIRGL \
>>                 && !BR2_PACKAGE_VIRGLRENDERER_VENUS \
>>                 && !BR2_PACKAGE_VIRGLRENDERER_DRM_BACKEND_AMDGPU \
>>                 etc..
>>
>> (sorry for the very long comment line)
>>
> 
> I think additional messaging in the Config.in help line would benefit
> users. Maybe even a defconfig or test case demonstrating setup?

Having a test case running in gitlab-ci environment demonstrating this setup is
definitively welcome (If running in gitlab-ci environment is possible).

Buildroot defconfigs are used as initial/minimal configuration to boot a board,
they should not contain any additional packages.

Thanks for your detailled explanations!

Best regards,
Romain

> 
> [0] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1568
> 
> Best,
> Joseph

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Joseph Kogut]

Hello Romain,

On Thu, May 14, 2026 at 11:38 AM Romain Naour <romain.naour@smile.fr> wrote:
>
> Le 14/05/2026 à 20:05, Joseph Kogut a écrit :
> >
> > I think additional messaging in the Config.in help line would benefit
> > users. Maybe even a defconfig or test case demonstrating setup?
>
> Buildroot defconfigs are used as initial/minimal configuration to boot a board,
> they should not contain any additional packages.
>

Yes, that makes sense.

> Having a test case running in gitlab-ci environment demonstrating this setup is
> definitively welcome (If running in gitlab-ci environment is possible).
>

I don't think we can create a test case for host native context
without a supported GPU in the gitlab-ci runners, but I believe we
could at least create a VirGL/Venus test case using llvmpipe/lavapipe
for software rendering on the host. The guest would just use mesa
built with the virgl/venus UMDs, and we could verify that we see the
host UMD presented with the virtio-gpu wrapper, as shown in my cover
letter.

Best,
Joseph
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot