On Wed, Dec 24, 2025 at 12:22 AM Akihiko Odaki <[email protected]> wrote: > > On 2025/12/24 16:54, Joelle van Dyne wrote: > > 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. > > Thanks for clarification. I think the point I mentioned below still > holds; virglrenderer does not have any code that can be skipped for > MTLTexture with the absence of VIRGL_RENDERER_NATIVE_SHARE_TEXTURE. We support the same "hint" use case in vrend for MTLTexture. So, without that flag set, there will be no attempt to allocate a MTLTexture. This works regardless if Venus is used or not. However, in the Venus use case, the hint does not matter at all because as long as the new API virgl_renderer_create_handle_for_scanout is used, a MTLTexture is returned. In this sense, I think it makes sense to rename *D3D* to *NATIVE*.
I agree with point 2 though, it is better to pass the native device handle from the Cocoa backend. I will wait for those changes to be upstreamed. > > > > >> > >> 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? > > It depends on changes. > > I intend to upstream the Cocoa change and the following virlgrenderer > changes once the libepoxy change to enable ANGLE is merged, which is > blocking forever... They are useless without the libepoxy change: > https://github.com/akihikodaki/virglrenderer/commit/6dfbc7e61a72347485c09a171c8c6c0908e12a2a > https://github.com/akihikodaki/virglrenderer/commit/b12bda2fd272b0ffd0a9b95a021e4a13e947749b > > I intend to upstream all two changes for ANGLE: > https://github.com/akihikodaki/angle/commits/v/ > > The other changes are already submitted to the upstream if I don't miss > anything. > > Regards, > Akihiko Odaki
