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 <j@getutm.app>
---
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;
typedef struct egl_fb {
int width;
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 07f6355ad6..20c856c04e 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -1152,7 +1152,7 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
}
#endif
#ifdef VIRGL_RENDERER_D3D11_SHARE_TEXTURE
- if (qemu_egl_angle_d3d) {
+ if (qemu_egl_angle_native_device) {
flags |= VIRGL_RENDERER_D3D11_SHARE_TEXTURE;
}
#endif
diff --git a/ui/egl-helpers.c b/ui/egl-helpers.c
index e3f2872cc1..57bcf99498 100644
--- a/ui/egl-helpers.c
+++ b/ui/egl-helpers.c
@@ -28,7 +28,7 @@
EGLDisplay *qemu_egl_display;
EGLConfig qemu_egl_config;
DisplayGLMode qemu_egl_mode;
-bool qemu_egl_angle_d3d;
+void *qemu_egl_angle_native_device;
/* ------------------------------------------------------------------ */
@@ -651,7 +651,7 @@ int qemu_egl_init_dpy_win32(EGLNativeDisplayType dpy, DisplayGLMode mode)
}
trace_egl_init_d3d11_device(device);
- qemu_egl_angle_d3d = device != NULL;
+ qemu_egl_angle_native_device = d3d11_device;
}
#endif
--
2.41.0On 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 <j@getutm.app>
> ---
> 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.
Regards,
Akihiko Odaki
>
> typedef struct egl_fb {
> int width;
> diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> index 07f6355ad6..20c856c04e 100644
> --- a/hw/display/virtio-gpu-virgl.c
> +++ b/hw/display/virtio-gpu-virgl.c
> @@ -1152,7 +1152,7 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
> }
> #endif
> #ifdef VIRGL_RENDERER_D3D11_SHARE_TEXTURE
> - if (qemu_egl_angle_d3d) {
> + if (qemu_egl_angle_native_device) {
> flags |= VIRGL_RENDERER_D3D11_SHARE_TEXTURE;
> }
> #endif
> diff --git a/ui/egl-helpers.c b/ui/egl-helpers.c
> index e3f2872cc1..57bcf99498 100644
> --- a/ui/egl-helpers.c
> +++ b/ui/egl-helpers.c
> @@ -28,7 +28,7 @@
> EGLDisplay *qemu_egl_display;
> EGLConfig qemu_egl_config;
> DisplayGLMode qemu_egl_mode;
> -bool qemu_egl_angle_d3d;
> +void *qemu_egl_angle_native_device;
>
> /* ------------------------------------------------------------------ */
>
> @@ -651,7 +651,7 @@ int qemu_egl_init_dpy_win32(EGLNativeDisplayType dpy, DisplayGLMode mode)
> }
>
> trace_egl_init_d3d11_device(device);
> - qemu_egl_angle_d3d = device != NULL;
> + qemu_egl_angle_native_device = d3d11_device;
> }
> #endif
>
On Wed, Dec 3, 2025 at 10:31 PM Akihiko Odaki
<odaki@rsg.ci.i.u-tokyo.ac.jp> 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 <j@getutm.app>
> > ---
> > 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.
>
> Regards,
> Akihiko Odaki
>
> >
> > typedef struct egl_fb {
> > int width;
> > diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> > index 07f6355ad6..20c856c04e 100644
> > --- a/hw/display/virtio-gpu-virgl.c
> > +++ b/hw/display/virtio-gpu-virgl.c
> > @@ -1152,7 +1152,7 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
> > }
> > #endif
> > #ifdef VIRGL_RENDERER_D3D11_SHARE_TEXTURE
> > - if (qemu_egl_angle_d3d) {
> > + if (qemu_egl_angle_native_device) {
> > flags |= VIRGL_RENDERER_D3D11_SHARE_TEXTURE;
> > }
> > #endif
> > diff --git a/ui/egl-helpers.c b/ui/egl-helpers.c
> > index e3f2872cc1..57bcf99498 100644
> > --- a/ui/egl-helpers.c
> > +++ b/ui/egl-helpers.c
> > @@ -28,7 +28,7 @@
> > EGLDisplay *qemu_egl_display;
> > EGLConfig qemu_egl_config;
> > DisplayGLMode qemu_egl_mode;
> > -bool qemu_egl_angle_d3d;
> > +void *qemu_egl_angle_native_device;
> >
> > /* ------------------------------------------------------------------ */
> >
> > @@ -651,7 +651,7 @@ int qemu_egl_init_dpy_win32(EGLNativeDisplayType dpy, DisplayGLMode mode)
> > }
> >
> > trace_egl_init_d3d11_device(device);
> > - qemu_egl_angle_d3d = device != NULL;
> > + qemu_egl_angle_native_device = d3d11_device;
> > }
> > #endif
> >
>
On 2025/12/20 1:11, Joelle van Dyne wrote: > On Wed, Dec 3, 2025 at 10:31 PM Akihiko Odaki > <odaki@rsg.ci.i.u-tokyo.ac.jp> 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 <j@getutm.app> >>> --- >>> 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. 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. Regards, Akihiko Odaki
On Tue, Dec 23, 2025 at 10:23 PM Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote: > > On 2025/12/20 1:11, Joelle van Dyne wrote: > > On Wed, Dec 3, 2025 at 10:31 PM Akihiko Odaki > > <odaki@rsg.ci.i.u-tokyo.ac.jp> 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 <j@getutm.app> > >>> --- > >>> 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
On 2025/12/24 16:54, Joelle van Dyne wrote: > On Tue, Dec 23, 2025 at 10:23 PM Akihiko Odaki > <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote: >> >> On 2025/12/20 1:11, Joelle van Dyne wrote: >>> On Wed, Dec 3, 2025 at 10:31 PM Akihiko Odaki >>> <odaki@rsg.ci.i.u-tokyo.ac.jp> 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 <j@getutm.app> >>>>> --- >>>>> 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. > >> >> 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
On Wed, Dec 24, 2025 at 12:22 AM Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote: > > On 2025/12/24 16:54, Joelle van Dyne wrote: > > On Tue, Dec 23, 2025 at 10:23 PM Akihiko Odaki > > <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote: > >> > >> On 2025/12/20 1:11, Joelle van Dyne wrote: > >>> On Wed, Dec 3, 2025 at 10:31 PM Akihiko Odaki > >>> <odaki@rsg.ci.i.u-tokyo.ac.jp> 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 <j@getutm.app> > >>>>> --- > >>>>> 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
On 2026/01/04 7:24, Joelle van Dyne wrote: > On Wed, Dec 24, 2025 at 12:22 AM Akihiko Odaki > <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote: >> >> On 2025/12/24 16:54, Joelle van Dyne wrote: >>> On Tue, Dec 23, 2025 at 10:23 PM Akihiko Odaki >>> <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote: >>>> >>>> On 2025/12/20 1:11, Joelle van Dyne wrote: >>>>> On Wed, Dec 3, 2025 at 10:31 PM Akihiko Odaki >>>>> <odaki@rsg.ci.i.u-tokyo.ac.jp> 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 <j@getutm.app> >>>>>>> --- >>>>>>> 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*. MTLTexture is always allocated; If virglrenderer doesn't, ANGLE does that internally. There should be no practical difference whether MTLTexture is exposed to QEMU or not. So I think the only thing matters here is code complexity. MTLTexture should be exposed to QEMU if it makes the code simpler. If it complicates the code, it shouldn't be done. No flag is needed either way. Regards, Akihiko Odaki
On Sat, Jan 3, 2026 at 7:35 PM Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote: > > On 2026/01/04 7:24, Joelle van Dyne wrote: > > On Wed, Dec 24, 2025 at 12:22 AM Akihiko Odaki > > <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote: > >> > >> On 2025/12/24 16:54, Joelle van Dyne wrote: > >>> On Tue, Dec 23, 2025 at 10:23 PM Akihiko Odaki > >>> <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote: > >>>> > >>>> On 2025/12/20 1:11, Joelle van Dyne wrote: > >>>>> On Wed, Dec 3, 2025 at 10:31 PM Akihiko Odaki > >>>>> <odaki@rsg.ci.i.u-tokyo.ac.jp> 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 <j@getutm.app> > >>>>>>> --- > >>>>>>> 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*. > > MTLTexture is always allocated; If virglrenderer doesn't, ANGLE does > that internally. There should be no practical difference whether > MTLTexture is exposed to QEMU or not. The difference is that if virglrenderer creates it and exposes it to QEMU, then the UI can use a faster blit path. When the flag is set, virglrenderer creates the MTLTexture, passes it to ANGLE, and holds a reference for QEMU to retrieve. When the flag is not set, there is no way of getting the MTLTexture from ANGLE. > > So I think the only thing matters here is code complexity. MTLTexture > should be exposed to QEMU if it makes the code simpler. If it > complicates the code, it shouldn't be done. No flag is needed either way. > > Regards, > Akihiko Odaki
On 2026/01/04 13:27, Joelle van Dyne wrote: > On Sat, Jan 3, 2026 at 7:35 PM Akihiko Odaki > <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote: >> >> On 2026/01/04 7:24, Joelle van Dyne wrote: >>> On Wed, Dec 24, 2025 at 12:22 AM Akihiko Odaki >>> <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote: >>>> >>>> On 2025/12/24 16:54, Joelle van Dyne wrote: >>>>> On Tue, Dec 23, 2025 at 10:23 PM Akihiko Odaki >>>>> <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote: >>>>>> >>>>>> On 2025/12/20 1:11, Joelle van Dyne wrote: >>>>>>> On Wed, Dec 3, 2025 at 10:31 PM Akihiko Odaki >>>>>>> <odaki@rsg.ci.i.u-tokyo.ac.jp> 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 <j@getutm.app> >>>>>>>>> --- >>>>>>>>> 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*. >> >> MTLTexture is always allocated; If virglrenderer doesn't, ANGLE does >> that internally. There should be no practical difference whether >> MTLTexture is exposed to QEMU or not. > The difference is that if virglrenderer creates it and exposes it to > QEMU, then the UI can use a faster blit path. When the flag is set, > virglrenderer creates the MTLTexture, passes it to ANGLE, and holds a > reference for QEMU to retrieve. When the flag is not set, there is no > way of getting the MTLTexture from ANGLE. I suspect it is a premature optimization. There is only one blit per frame and it is a simple blit, so I don't think it can create a perceivable performance uplift. Besides, if the optimization turns out useful, you can still unconditionally let virglrenderer create the MTLTexture, so the flag is unnecessary. Regards, Akihiko Odaki
> On 4. Jan 2026, at 12:01, Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote: > > On 2026/01/04 13:27, Joelle van Dyne wrote: >> On Sat, Jan 3, 2026 at 7:35 PM Akihiko Odaki >> <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote: >>> >>> On 2026/01/04 7:24, Joelle van Dyne wrote: >>>> On Wed, Dec 24, 2025 at 12:22 AM Akihiko Odaki >>>> <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote: >>>>> >>>>> On 2025/12/24 16:54, Joelle van Dyne wrote: >>>>>> On Tue, Dec 23, 2025 at 10:23 PM Akihiko Odaki >>>>>> <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote: >>>>>>> >>>>>>> On 2025/12/20 1:11, Joelle van Dyne wrote: >>>>>>>> On Wed, Dec 3, 2025 at 10:31 PM Akihiko Odaki >>>>>>>> <odaki@rsg.ci.i.u-tokyo.ac.jp> 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 <j@getutm.app> >>>>>>>>>> --- >>>>>>>>>> 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*. >>> >>> MTLTexture is always allocated; If virglrenderer doesn't, ANGLE does >>> that internally. There should be no practical difference whether >>> MTLTexture is exposed to QEMU or not. >> The difference is that if virglrenderer creates it and exposes it to >> QEMU, then the UI can use a faster blit path. When the flag is set, >> virglrenderer creates the MTLTexture, passes it to ANGLE, and holds a >> reference for QEMU to retrieve. When the flag is not set, there is no >> way of getting the MTLTexture from ANGLE. > > I suspect it is a premature optimization. There is only one blit per frame and it is a simple blit, so I don't think it can create a perceivable performance uplift. > > Besides, if the optimization turns out useful, you can still unconditionally let virglrenderer create the MTLTexture, so the flag is unnecessary. > > Regards, > Akihiko Odaki > Hello, It might be worthwhile having a way to do partial damage from the get-go - which entails not doing full blits each frame. It has its importance for battery life. Although there are more aspects around that still look in flux within virglrenderer… and ANGLE (at least on Vulkan) has a stub implementation of EGL_KHR_partial_update that doesn’t actually implement partial damage...
On 2026/01/05 1:15, Mohamed Mediouni wrote: > > >> On 4. Jan 2026, at 12:01, Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote: >> >> On 2026/01/04 13:27, Joelle van Dyne wrote: >>> On Sat, Jan 3, 2026 at 7:35 PM Akihiko Odaki >>> <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote: >>>> >>>> On 2026/01/04 7:24, Joelle van Dyne wrote: >>>>> On Wed, Dec 24, 2025 at 12:22 AM Akihiko Odaki >>>>> <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote: >>>>>> >>>>>> On 2025/12/24 16:54, Joelle van Dyne wrote: >>>>>>> On Tue, Dec 23, 2025 at 10:23 PM Akihiko Odaki >>>>>>> <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote: >>>>>>>> >>>>>>>> On 2025/12/20 1:11, Joelle van Dyne wrote: >>>>>>>>> On Wed, Dec 3, 2025 at 10:31 PM Akihiko Odaki >>>>>>>>> <odaki@rsg.ci.i.u-tokyo.ac.jp> 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 <j@getutm.app> >>>>>>>>>>> --- >>>>>>>>>>> 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*. >>>> >>>> MTLTexture is always allocated; If virglrenderer doesn't, ANGLE does >>>> that internally. There should be no practical difference whether >>>> MTLTexture is exposed to QEMU or not. >>> The difference is that if virglrenderer creates it and exposes it to >>> QEMU, then the UI can use a faster blit path. When the flag is set, >>> virglrenderer creates the MTLTexture, passes it to ANGLE, and holds a >>> reference for QEMU to retrieve. When the flag is not set, there is no >>> way of getting the MTLTexture from ANGLE. >> >> I suspect it is a premature optimization. There is only one blit per frame and it is a simple blit, so I don't think it can create a perceivable performance uplift. >> >> Besides, if the optimization turns out useful, you can still unconditionally let virglrenderer create the MTLTexture, so the flag is unnecessary. >> >> Regards, >> Akihiko Odaki >> > > Hello, > > It might be worthwhile having a way to do partial damage from the get-go - which entails not doing full blits each frame. It has its importance for battery life. > > Although there are more aspects around that still look in flux within virglrenderer… and ANGLE (at least on Vulkan) has a stub implementation of EGL_KHR_partial_update that doesn’t actually implement partial damage... > It is better to look at the Metal API instead; after all, we use ANGLE's Metal renderer so ANGLE can only provide features Metal allows. If necessary, we can use the underlying MTLTexture as this series and the corresponding virglrenderer change does. Searching the Web, I found partial damage is feasible with Metal, but there is a complication, CAMetalLayer implements double or triple buffering, which complicates damage calculation. Flutter's issue for partial damage and its corresponding pull request details the problem and their solution: https://github.com/flutter/flutter/issues/124526 The issue also shows the CPU usage is dramatically reduced and the optimization is worthwhile (though I wonder why; it is mostly GPU work and the CPU shouldn't be affected. Perhaps the memory bandwidth shared between CPU and GPU may affect the accounting). In conclusion, partial damage is worthwhile to explore, but it should be done with a follow-up patch as it is not so simple that we can implement it by just passing the damaged area to Cocoa and Metal but it requires an additional logic. Keeping the initial patch small is essential for upstreaming. And any optimization patch should come with some benchmark. Something simple is sufficient; e.g., the Flutter issue tells the CPU usage is dropped from 40% to 16% for "the blinking cursor in flutter gallery". Regards, Akihiko Odaki
© 2016 - 2026 Red Hat, Inc.