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