On 2026/01/05 1:15, Mohamed Mediouni wrote:
On 4. Jan 2026, at 12:01, Akihiko Odaki <[email protected]> wrote:
On 2026/01/04 13:27, Joelle van Dyne wrote:
On Sat, Jan 3, 2026 at 7:35 PM Akihiko Odaki
<[email protected]> wrote:
On 2026/01/04 7:24, Joelle van Dyne wrote:
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*.
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
