On Tue, Dec 23, 2025 at 10:23 PM Akihiko Odaki <[email protected]> wrote: > > On 2025/12/20 1:11, Joelle van Dyne wrote: > > On Wed, Dec 3, 2025 at 10:31 PM Akihiko Odaki > > <[email protected]> wrote: > >> > >> On 2025/12/03 13:07, Joelle van Dyne wrote: > >>> Make way for other platforms by making the variable more general. Also we > >>> will be using the device in the future so let's save the pointer in the > >>> global instead of just a boolean flag. > >>> > >>> Signed-off-by: Joelle van Dyne <[email protected]> > >>> --- > >>> include/ui/egl-helpers.h | 2 +- > >>> hw/display/virtio-gpu-virgl.c | 2 +- > >>> ui/egl-helpers.c | 4 ++-- > >>> 3 files changed, 4 insertions(+), 4 deletions(-) > >>> > >>> diff --git a/include/ui/egl-helpers.h b/include/ui/egl-helpers.h > >>> index acf993fcf5..c239d32317 100644 > >>> --- a/include/ui/egl-helpers.h > >>> +++ b/include/ui/egl-helpers.h > >>> @@ -12,7 +12,7 @@ > >>> extern EGLDisplay *qemu_egl_display; > >>> extern EGLConfig qemu_egl_config; > >>> extern DisplayGLMode qemu_egl_mode; > >>> -extern bool qemu_egl_angle_d3d; > >>> +extern void *qemu_egl_angle_native_device; > >> > >> I guess ANGLE will not be relevant for Metal and leaving it will be > >> misleading. > > What is your suggestion? This is just to remove "D3D" from the > > variable name. If you want to remove "ANGLE" from the variable name as > > well, it may be misleading because this variable is only used with an > > ANGLE EGL backend. > Looking the usage of the variable in your tree, I realized this variable > may not be necessary for this at all. > > There are two use cases: > > 1. To determine if VIRGL_RENDERER_NATIVE_SHARE_TEXTURE needs to be set. > 2. To pass the device used by ANGLE to Cocoa. > > Regarding 1, virglrenderer can simply pass MTLTexture whenever the EGL > context is backed with Metal and Venus is in use. > > Although your code is modeled after the code dealing with Direct3D > handles, the functionality of your code is quite a different from it. > > Direct3D handles are used to "share" texture with other processes in a > zero-copy manner. It is an optional hint; dbus can fall back to use > OpenGL textures if they are missing, and the other displays just don't care. > > On the other hand, MTLTexture plays an essential role in your scenario. > There are no corresponding OpenGL texture so no fallback happens. That's a good point, but there's two uses of MTLTexture: one as a direct parallel to D3D handles (vrend allocate a texture backed by MTLTexture; returns it in info_ext along with a tex_id) and one returned as part of the new API (virgl_renderer_create_handle_for_scanout) which does not have an associated tex_id.
> > The difference shows that the VIRGL_RENDERER_NATIVE_SHARE_TEXTURE flag > is useful when dealing with Direct3D handles but not with MTLTexture. > The absence of flag tells virglrenderer that we do not need Direct3D > handle (because the dbus display is not used), and allows it to skip > some code to convert OpenGL textures to Direct3D handles). > > On the other hand, not passing MTLTexture in your scenario does not make > sense because it prevents the scanout at all. virglrenderer does not > have any code that can be skipped when the flag is absent. virglrenderer > can simply pass MTLTexture in your scenario. > > 2 implicitly lets ANGLE choose a device, but this can be suboptimal. > Ideally, Cocoa should instead choose a device because it knows what > device displays the window. Cocoa should pass the device it chose to ANGLE. > > To demonstrate the point, I updated my tree to use ANGLE's Metal > renderer for OpenGL and to pass the device from Cocoa to ANGLE: > https://github.com/akihikodaki/v/commit/8f191a7d2c225fa601c22a783c24c81a3fda47fa > > By the way, I had to make a few modifications to ANGLE, Epoxy, and > virglrenderer to fix glitches when hosting glmark2 and Firefox on GNOME. > You can also find them with the above URL if you are interested. Thank you, we picked up a couple of your changes in the UTM branch already. Do you have plans to upstream those changes? And also, what are your plans for upstreaming the Cocoa GL backend changes for QEMU? > > Regards, > Akihiko Odaki
