utmapp
OpenGL 3.3 with GPU acceleration?
Describe the issue
Is it possible to get OpenGL 3.3 support with GPU acceleration? Until now I've only gotten OpenGL 2.1.
I've tried both Arch (using these instructions), Debian (using the image from the gallary) and Ubuntu (using the instructions from the gallary).
All of them can boot with Emulated Display Card set to virtio-ramfb-gl (GPU Supported) (the other GPU Supported do not seem to work), but they only give me OpenGL 2.1.
I looked to see if the virgl driver supports OpenGL 3.3, and it does seem so, from this issue.
This is example output from glxinfo on Ubuntu (similar on Arch and Debian):
$ glxinfo -B
name of display: :0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Mesa/X.org (0x1af4)
Device: virgl (ANGLE (Apple, Apple M1 Pro, OpenGL 4.1 Metal - 76.3)) (0x1010)
Version: 22.0.5
Accelerated: yes
Video memory: 0MB
Unified memory: no
Preferred profile: compat (0x2)
Max core profile version: 0.0
Max compat profile version: 2.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.0
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: virgl (ANGLE (Apple, Apple M1 Pro, OpenGL 4.1 Metal - 76.3))
OpenGL version string: 2.1 Mesa 22.0.5
OpenGL shading language version string: 1.20
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 22.0.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
Configuration
- UTM Version: 3.2.4 (58)
- macOS Version: 12.3 (21E230)
- Mac Chip (Intel, M1, ...): M1 Pro
This would be amazing to get working. Would love to be able to run Aether SX on the iPad Pro M1
Same problem here, can't run ignition gazebo with virtio-ramfb-gl enabled. Gazebo GUI spits out error stating "does not support Ogre 3.3"
What is missing for this? virgl Mesa driver supports OpenGL 4.3 and macOS itself supports OpenGL 4.1. Is it related to the lack of compatibility profile support in macOS OpenGL implementation?
We use ANGLE to provide the highest version that supports all the features requested by virgl
Ok but ANGLE is providing OpenGL ES implementation. How does it relate to desktop OpenGL?
Okay we have the following:
Guest Mesa <-1-> virglrenderer <-2-> ANGLE <-3-> macOS Host
<-1-> Can be any version of OpenGL/GLES that is supported which can be up to OGL 4.3 for example <-2-> Must be GLES <-3-> Uses the macOS OGL framework
The maximum supported version is determined at runtime through a feature querying system. ANGLE queries macOS for all the features it supports and determines a maximum version of GLES that it is able to support. That version is what is fed to virglrenderer which goes to Mesa.
We do not have a direct OGL<->OGL interface and it must go through GLES.
Of course, it is possible to develop a custom virglrenderer that could pass through OGL directly and maybe that could work. However, we are working on a different graphics backend based off of Google's gfxstream which should support Vulkan and higher versions of OGL. This will take quite some time to develop though.
Thank you for explanation, I understand it now. That gfxstream sounds like good idea, I hope you can make it happen. Thank you for your work. It's pretty important for me as I used Linux on PC but switched to macOS on Apple Silicon and I still want to have Linux for some things. Asahi Linux is not there yet so UTM is my best pick for now. I guess current support will do fine for accelerated desktop.
Just thought I'd mention (as mentioned in the linked issue) that you can seem to get full support using Apple virtualization, FWIW.
Here's the output snippet of glxinfo -B for comparison to the OP:
$ glxinfo -B
name of display: :0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Mesa (0xffffffff)
Device: llvmpipe (LLVM 15.0.7, 128 bits) (0xffffffff)
Version: 23.1.5
Accelerated: no
Video memory: 7925MB
Unified memory: yes
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 4.5
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
Yeah that’s CPU rendering. You can get the same result in QEMU by choosing a display hardware that doesn’t have -gl
Oh interesting. Yeah I notice that the results are the same and kitty launches just fine on virtio-gpu-pci (non-GL).
I swear that sway was having issues with this card, but now I'm not 100% sure (might have just been my config). Sway does run on the Apple virt graphics, but with graphic artifacts and massive lag.
Hi, I hit this issue as well. I wonder is it because of the QEMU version? My OpenGL also fixed to 2.1 The VMWare fusion shows OpenGL 4.3. So it means the Apple side already supported OpenGL 4.3.
Okay we have the following:
Guest Mesa <-1-> virglrenderer <-2-> ANGLE <-3-> macOS Host
<-1-> Can be any version of OpenGL/GLES that is supported which can be up to OGL 4.3 for example <-2-> Must be GLES <-3-> Uses the macOS OGL framework
The maximum supported version is determined at runtime through a feature querying system. ANGLE queries macOS for all the features it supports and determines a maximum version of GLES that it is able to support. That version is what is fed to virglrenderer which goes to Mesa.
We do not have a direct OGL<->OGL interface and it must go through GLES.
Of course, it is possible to develop a custom virglrenderer that could pass through OGL directly and maybe that could work. However, we are working on a different graphics backend based off of Google's gfxstream which should support Vulkan and higher versions of OGL. This will take quite some time to develop though.
It is possible, but somehow I can't get it to work. I don't know what am I missing: https://github.com/libsdl-org/SDL/issues/4986
build % ./qemu-system-aarch64 \
-machine virt,accel=hvf,highmem=off \
-cpu cortex-a72 -smp 2 -m 3G \
-display sdl,gl=core -device virtio-gpu-gl-pci \
-device intel-hda -device hda-output \
-device qemu-xhci \
-device usb-kbd \
-device virtio-mouse-pci \
-drive "if=pflash,format=raw,file=pc-bios/edk2-aarch64-code.fd,readonly=on" \
-drive "if=pflash,format=raw,file=pc-bios/edk2-arm-vars.fd,discard=on" \
-drive "if=virtio,format=raw,file=./virtio.raw,discard=on" \
-device usb-storage,drive=fdrw -drive id=fdrw,if=none,media=cdrom,file=Fedora-Silverblue-ostree-aarch64-41-1.4.iso
qemu_gl_create_compile_shader: compile vertex error
ERROR: 0:1: '' : version '300' is not supported
ERROR: 0:1: '' : syntax error: #version
qemu_gl_create_compile_shader: compile fragment error
ERROR: 0:1: '' : version '300' is not supported
ERROR: 0:1: '' : syntax error: #version
ERROR: 0:4: 'vec2' : syntax error: syntax error
qemu_gl_create_compile_shader: compile vertex error
ERROR: 0:1: '' : version '300' is not supported
ERROR: 0:1: '' : syntax error: #version
qemu_gl_create_compile_shader: compile fragment error
ERROR: 0:1: '' : version '300' is not supported
ERROR: 0:1: '' : syntax error: #version
ERROR: 0:4: 'vec2' : syntax error: syntax error
Qemu Configure
qemu 8.2.1
Build environment
Build directory : /Users/macbookpro/source/qemu/build
Source path : /Users/macbookpro/source/qemu
Download dependencies : YES
Directories
Build directory : /Users/macbookpro/source/qemu/build
Source path : /Users/macbookpro/source/qemu
Download dependencies : YES
Install prefix : /usr/local
BIOS directory : share/qemu
firmware path : share/qemu-firmware
binary directory : /usr/local/bin
library directory : /usr/local/lib
module directory : lib/qemu
libexec directory : /usr/local/libexec
include directory : /usr/local/include
config directory : /usr/local/etc
local state directory : /var/local
Manual directory : /usr/local/share/man
Doc directory : /usr/local/share/doc
Host binaries
python : /Users/macbookpro/source/qemu/build/pyvenv/bin/python3.13 (version: 3.13)
sphinx-build : NO
gdb :
iasl : NO
genisoimage :
smbd : /usr/sbin/smbd
Configurable features
Documentation : NO
system-mode emulation : YES
user-mode emulation : NO
block layer : YES
Install blobs : YES
module support : NO
fuzzing support : NO
Audio drivers : coreaudio sdl
Trace backends : log
D-Bus display : YES
QOM debugging : YES
Relocatable install : YES
vhost-kernel support : NO
vhost-net support : NO
vhost-user support : NO
vhost-user-crypto support : NO
vhost-user-blk server support : NO
vhost-vdpa support : NO
build guest agent : NO
Compilation
host CPU : aarch64
host endianness : little
C compiler : cc
Host C compiler : cc
C++ compiler : NO
Objective-C compiler : clang
CFLAGS : -F/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks -I/opt/homebrew/opt/qemu-virgl-deps/include/qemu-virgl/epoxy -I/opt/homebrew/opt/qemu-virgl-deps/include/qemu-virgl/virgl -I/opt/homebrew/opt/qemu-virgl-deps/include/qemu-virgl/angle -g -O2
OBJCFLAGS : -F/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks -g -O2
LDFLAGS : -F/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks -I/opt/homebrew/opt/qemu-virgl-deps/include/qemu-virgl/epoxy -I/opt/homebrew/opt/qemu-virgl-deps/include/qemu-virgl/virgl -I/opt/homebrew/opt/qemu-virgl-deps/include/qemu-virgl/angle -F/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks -L/opt/homebrew/opt/qemu-virgl-deps/lib/qemu-virgl -L/opt/homebrew/opt/qemu-virgl-deps/lib
QEMU_CFLAGS : -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -fno-pie -fstack-protector-strong
QEMU_OBJCFLAGS : -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -fno-pie
QEMU_LDFLAGS : -fstack-protector-strong
link-time optimization (LTO) : NO
PIE : NO
static build : NO
malloc trim support : NO
membarrier : NO
debug graph lock : NO
debug stack usage : NO
mutex debugging : NO
memory allocator : system
avx2 optimization : NO
avx512bw optimization : NO
avx512f optimization : NO
gcov : NO
thread sanitizer : NO
CFI support : NO
strip binaries : NO
sparse : NO
mingw32 support : NO
Targets and accelerators
KVM support : NO
HVF support : YES
WHPX support : NO
NVMM support : NO
Xen support : NO
Xen emulation : NO
TCG support : YES
TCG backend : native (aarch64)
TCG plugins : YES
TCG debug enabled : NO
target list : aarch64-softmmu alpha-softmmu arm-softmmu avr-softmmu cris-softmmu hppa-softmmu i386-softmmu loongarch64-softmmu m68k-softmmu microblaze-softmmu microblazeel-softmmu mips-softmmu mips64-softmmu mips64el-softmmu mipsel-softmmu nios2-softmmu or1k-softmmu ppc-softmmu ppc64-softmmu riscv32-softmmu riscv64-softmmu rx-softmmu s390x-softmmu sh4-softmmu sh4eb-softmmu sparc-softmmu sparc64-softmmu tricore-softmmu x86_64-softmmu xtensa-softmmu xtensaeb-softmmu
default devices : YES
out of process emulation : NO
vfio-user server : NO
Block layer support
coroutine backend : sigaltstack
coroutine pool : YES
Block whitelist (rw) :
Block whitelist (ro) :
Use block whitelist in tools : NO
VirtFS (9P) support : YES
VirtFS (9P) Proxy Helper support (deprecated): NO
Live block migration : YES
replication support : YES
bochs support : YES
cloop support : YES
dmg support : YES
qcow v1 support : YES
vdi support : YES
vhdx support : YES
vmdk support : YES
vpc support : YES
vvfat support : YES
qed support : YES
parallels support : YES
FUSE exports : NO
VDUSE block exports : NO
Crypto
TLS priority : NORMAL
GNUTLS support : YES 3.8.4
GNUTLS crypto : YES
libgcrypt : NO
nettle : NO
AF_ALG support : NO
rng-none : NO
Linux keyring : NO
Linux keyutils : NO
User interface
Cocoa support : YES
SDL support : YES 2.32.2
SDL image support : YES 2.8.8
GTK support : NO
pixman : YES 0.44.2
VTE support : NO
PNG support : YES 1.6.47
VNC support : YES
VNC SASL support : YES
VNC JPEG support : YES 3.1.0
spice protocol support : YES 0.14.4
spice server support : NO
curses support : YES
brlapi support : NO
Audio backends
CoreAudio support : YES
PipeWire support : NO
JACK support : NO
Network backends
vmnet.framework support : YES
AF_XDP support : NO
slirp support : YES 4.9.0
vde support : NO
netmap support : NO
l2tpv3 support : NO
Dependencies
libtasn1 : YES 4.20.0
PAM : YES
iconv support : YES
virgl support : YES 1.1.0
rutabaga support : NO
blkio support : NO
curl support : YES 8.7.1
Multipath support : NO
Linux AIO support : NO
Linux io_uring support : NO
ATTR/XATTR support : NO
RDMA support : NO
PVRDMA support : NO
fdt support : internal
libcap-ng support : NO
bpf support : NO
rbd support : NO
smartcard support : NO
U2F support : NO
libusb : YES 1.0.27
usb net redir : YES 0.15.0
OpenGL support (epoxy) : YES 1.5.10
EGL : YES 1.5.10
GBM : NO
libiscsi support : NO
libnfs support : NO
seccomp support : NO
GlusterFS support : NO
hv-balloon support : YES
TPM support : YES
libssh support : YES 0.11.1
lzo support : NO
snappy support : NO
bzip2 support : YES
lzfse support : NO
zstd support : YES 1.5.7
NUMA host support : NO
capstone : YES 5.0.5
libpmem support : NO
libdaxctl support : NO
libudev : NO
FUSE lseek : NO
selinux : NO
libdw : NO
Subprojects
berkeley-softfloat-3 : YES
berkeley-testfloat-3 : YES
dtc : YES
keycodemapdb : YES
User defined options
Native files : config-meson.cross
b_pie : false
docs : disabled
opengl : enabled
plugins : true
sdl : enabled
virglrenderer : enabled
Found ninja-1.12.1 at /opt/homebrew/bin/ninja
Running postconf script '/Users/macbookpro/source/qemu/build/pyvenv/bin/python3.13 /Users/macbookpro/source/qemu/scripts/symlink-install-tree.py'
Configuration successful! To build QEMU, run:
cd source/qemu && make -j14
@ddalton15: You can run Gazebo with OGL 2.1 too, it just won't look as good:
QT_QPA_PLATFORM=xcb gz sim --render-engine=ogre
Having OpenGL >= 3.3 with UTM would be amazing.
Parallels has a 3d through virgl:
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Mesa/X.org (0x1af4)
Device: virgl (Apple M4 Pro (Compat)) (0x1010)
Version: 22.3.6
Accelerated: yes
Video memory: 0MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.0
Max compat profile version: 4.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.0
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: virgl (Apple M4 Pro (Compat))
OpenGL core profile version string: 4.0 (Core Profile) Mesa 22.3.6
OpenGL core profile shading language version string: 4.00
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
Okay we have the following: Guest Mesa <-1-> virglrenderer <-2-> ANGLE <-3-> macOS Host <-1-> Can be any version of OpenGL/GLES that is supported which can be up to OGL 4.3 for example <-2-> Must be GLES <-3-> Uses the macOS OGL framework The maximum supported version is determined at runtime through a feature querying system. ANGLE queries macOS for all the features it supports and determines a maximum version of GLES that it is able to support. That version is what is fed to virglrenderer which goes to Mesa. We do not have a direct OGL<->OGL interface and it must go through GLES. Of course, it is possible to develop a custom virglrenderer that could pass through OGL directly and maybe that could work. However, we are working on a different graphics backend based off of Google's gfxstream which should support Vulkan and higher versions of OGL. This will take quite some time to develop though.
It is possible, but somehow I can't get it to work. I don't know what am I missing: libsdl-org/SDL#4986
build % ./qemu-system-aarch64 \ -machine virt,accel=hvf,highmem=off \ -cpu cortex-a72 -smp 2 -m 3G \ -display sdl,gl=core -device virtio-gpu-gl-pci \ -device intel-hda -device hda-output \ -device qemu-xhci \ -device usb-kbd \ -device virtio-mouse-pci \ -drive "if=pflash,format=raw,file=pc-bios/edk2-aarch64-code.fd,readonly=on" \ -drive "if=pflash,format=raw,file=pc-bios/edk2-arm-vars.fd,discard=on" \ -drive "if=virtio,format=raw,file=./virtio.raw,discard=on" \ -device usb-storage,drive=fdrw -drive id=fdrw,if=none,media=cdrom,file=Fedora-Silverblue-ostree-aarch64-41-1.4.iso qemu_gl_create_compile_shader: compile vertex error ERROR: 0:1: '' : version '300' is not supported ERROR: 0:1: '' : syntax error: #version qemu_gl_create_compile_shader: compile fragment error ERROR: 0:1: '' : version '300' is not supported ERROR: 0:1: '' : syntax error: #version ERROR: 0:4: 'vec2' : syntax error: syntax error qemu_gl_create_compile_shader: compile vertex error ERROR: 0:1: '' : version '300' is not supported ERROR: 0:1: '' : syntax error: #version qemu_gl_create_compile_shader: compile fragment error ERROR: 0:1: '' : version '300' is not supported ERROR: 0:1: '' : syntax error: #version ERROR: 0:4: 'vec2' : syntax error: syntax errorQemu Configure
did you get this fixed, facing same issue?
UTM only provides OpenGL1.1:
Parallels provides Metal :
The Linux Mesa drivers in UTM provide the same acceleration as Parallels for Windows:
root@myhostname ~ # glxgears -info
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
GL_RENDERER = virgl (ANGLE (Apple, Apple M4 Pro, OpenGL 4.1 Metal - 89.4))
GL_VERSION = 2.1 Mesa 25.1.4-arch1.1
GL_VENDOR = Mesa
GL_EXTENSIONS = GL_ARB_multisample GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_copy_texture GL_EXT_subtexture GL_EXT_texture_object GL_EXT_vertex_array GL_EXT_compiled_vertex_array GL_EXT_texture GL_EXT_texture3D GL_IBM_rasterpos_clip GL_ARB_point_parameters GL_EXT_draw_range_elements GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_separate_specular_color GL_EXT_texture_edge_clamp GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_ARB_framebuffer_sRGB GL_ARB_multitexture GL_EXT_framebuffer_sRGB GL_IBM_multimode_draw_arrays GL_IBM_texture_mirrored_repeat GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_transpose_matrix GL_EXT_blend_func_separate GL_EXT_fog_coord GL_EXT_multi_draw_arrays GL_EXT_secondary_color GL_EXT_texture_env_add GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_INGR_blend_func_separate GL_NV_blend_square GL_NV_light_max_exponent GL_NV_texgen_reflection GL_NV_texture_env_combine4 GL_S3_s3tc GL_SUN_multi_draw_arrays GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_EXT_framebuffer_object GL_EXT_texture_compression_s3tc GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_MESA_window_pos GL_NV_packed_depth_stencil GL_NV_texture_rectangle GL_ARB_depth_texture GL_ARB_occlusion_query GL_ARB_shadow GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_window_pos GL_ATI_fragment_shader GL_EXT_stencil_two_side GL_EXT_texture_cube_map GL_NV_depth_clamp GL_NV_fog_distance GL_NV_half_float GL_APPLE_packed_pixels GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_shader GL_ARB_shader_objects GL_ARB_vertex_program GL_ARB_vertex_shader GL_ATI_draw_buffers GL_ATI_texture_env_combine3 GL_ATI_texture_float GL_EXT_shadow_funcs GL_EXT_stencil_wrap GL_MESA_pack_invert GL_NV_primitive_restart GL_ARB_depth_clamp GL_ARB_fragment_program_shadow GL_ARB_half_float_pixel GL_ARB_occlusion_query2 GL_ARB_point_sprite GL_ARB_shading_language_100 GL_ARB_sync GL_ARB_texture_non_power_of_two GL_ARB_vertex_buffer_object GL_ATI_blend_equation_separate GL_EXT_blend_equation_separate GL_OES_read_format GL_ARB_color_buffer_float GL_ARB_pixel_buffer_object GL_ARB_texture_compression_rgtc GL_ARB_texture_float GL_ARB_texture_rectangle GL_EXT_packed_float GL_EXT_pixel_buffer_object GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc GL_EXT_texture_rectangle GL_EXT_texture_sRGB GL_EXT_texture_shared_exponent GL_ARB_framebuffer_object GL_EXT_framebuffer_blit GL_EXT_packed_depth_stencil GL_ARB_vertex_array_object GL_ATI_separate_stencil GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_gpu_program_parameters GL_EXT_texture_array GL_EXT_texture_integer GL_EXT_texture_sRGB_decode GL_EXT_timer_query GL_OES_EGL_image GL_ARB_copy_buffer GL_ARB_depth_buffer_float GL_ARB_draw_instanced GL_ARB_half_float_vertex GL_ARB_instanced_arrays GL_ARB_map_buffer_range GL_ARB_texture_rg GL_ARB_texture_swizzle GL_ARB_vertex_array_bgra GL_EXT_texture_swizzle GL_EXT_vertex_array_bgra GL_AMD_conservative_depth GL_AMD_draw_buffers_blend GL_ARB_ES2_compatibility GL_ARB_blend_func_extended GL_ARB_debug_output GL_ARB_draw_buffers_blend GL_ARB_draw_elements_base_vertex GL_ARB_explicit_attrib_location GL_ARB_fragment_coord_conventions GL_ARB_provoking_vertex GL_ARB_sampler_objects GL_ARB_seamless_cube_map GL_ARB_shader_texture_lod GL_ARB_texture_cube_map_array GL_ARB_texture_rgb10_a2ui GL_ARB_uniform_buffer_object GL_ARB_vertex_type_2_10_10_10_rev GL_EXT_provoking_vertex GL_EXT_texture_snorm GL_EXT_texture_storage GL_MESA_texture_signed_rgba GL_NV_copy_image GL_ARB_get_program_binary GL_ARB_robustness GL_ARB_separate_shader_objects GL_ARB_shader_bit_encoding GL_ARB_texture_compression_bptc GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_EXT_direct_state_access GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ARB_base_instance GL_ARB_compressed_texture_pixel_storage GL_ARB_conservative_depth GL_ARB_internalformat_query GL_ARB_map_buffer_alignment GL_ARB_shading_language_420pack GL_ARB_shading_language_packing GL_ARB_texture_storage GL_ARB_transform_feedback_instanced GL_EXT_transform_feedback GL_AMD_shader_trinary_minmax GL_ARB_ES3_compatibility GL_ARB_arrays_of_arrays GL_ARB_clear_buffer_object GL_ARB_explicit_uniform_location GL_ARB_invalidate_subdata GL_ARB_program_interface_query GL_ARB_texture_query_levels GL_ARB_vertex_attrib_binding GL_KHR_debug GL_KHR_texture_compression_astc_ldr GL_ARB_clear_texture GL_ARB_internalformat_query2 GL_ARB_multi_bind GL_ARB_shading_language_include GL_EXT_debug_label GL_EXT_shader_integer_mix GL_ARB_get_texture_sub_image GL_KHR_context_flush_control GL_ARB_parallel_shader_compile GL_KHR_no_error GL_KHR_texture_compression_astc_sliced_3d GL_ARB_gl_spirv GL_ARB_spirv_extensions GL_MESA_shader_integer_functions GL_ARB_texture_filter_anisotropic GL_KHR_parallel_shader_compile GL_EXT_EGL_image_storage GL_EXT_EGL_sync GL_EXT_EGL_image_storage_compression GL_NV_ES1_1_compatibility
@startergo As far I know UTM provides no GPU acceleration for Windows at all. That software reports OpenGL 1.1 because Windows has builtin OpenGL 1.1 implementation.
Parallels provide OpenGL support through Virgl. But look at the score:
glmark2 --annotate
=======================================================
glmark2 2023.01
=======================================================
OpenGL Information
GL_VENDOR: Mesa/X.org
GL_RENDERER: virgl (Apple M4 Pro (Compat))
GL_VERSION: 4.0 (Compatibility Profile) Mesa 22.3.6
Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=32 stencil=0 samples=0
Surface Size: 800x600 windowed
=======================================================
[build] use-vbo=false: FPS: 10650 FrameTime: 0.094 ms
=======================================================
glmark2 Score: 10649
And the GL_Version is 4.0
@startergo I'm not sure what your point is. Parallels has over $300M in funding and over $100M in annual profits. They have hundreds of employees working on Parallels Desktop and a large number of them probably work on GPU acceleration. We use open source libraries that obviously lack in comparison. I don't see what comparing the two does than point out the obvious fact that Parallels is the better product.
@startergo I'm not sure what your point is. Parallels has over $300M in funding and over $100M in annual profits. They have hundreds of employees working on Parallels Desktop and a large number of them probably work on GPU acceleration. We use open source libraries that obviously lack in comparison. I don't see what comparing the two does than point out the obvious fact that Parallels is the better product.
This is the ugly truth unfortunately. But I am trying to point out something different. They are not using Angle at all. They use Virglrenderer purely to get OpenGL4.0 . I have a variation of Qemu using SDL with openGL and Virglrenderer without Angle, similar to Parallels approach, but unfortunately GL_Version is still 2.1 even though the GLmark score is much higher than UTM's (around 2400)
It's not just virglrenderer. You also need the QEMU device to handle it. It requires work all across the stack which is difficult and time consuming work. I'm looking at alternatives like Google's gfxstream and Rutabaga which is based on passing through Vulkan. However, macOS support is basically non-existant at this point.
I got some progress in the SDL2 with openGL Qemu, but still OpenGL score is not 11000:
export MESA_GL_VERSION_OVERRIDE=4.6
export MESA_GLSL_VERSION_OVERRIDE=460
arch@myhostname ~ % glxinfo | grep -E "(OpenGL ES|GLES)"
glxinfo | grep "OpenGL ES profile version"
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.0
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 25.1.6-arch1.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 25.1.6-arch1.1
arch@myhostname ~ % glmark2 --annotate
=======================================================
glmark2 2023.01
=======================================================
OpenGL Information
GL_VENDOR: Mesa
GL_RENDERER: virgl (Apple M4 Pro)
GL_VERSION: 4.6 (Compatibility Profile) Mesa 25.1.6-arch1.1
Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=24 stencil=0 samples=0
Surface Size: 800x600 windowed
=======================================================
[build] use-vbo=false: FPS: 1694 FrameTime: 0.590 ms
=======================================================
glmark2 Score: 1693
=======================================================
I Added these libraries: https://github.com/startergo/Mesa-VirGL/actions/runs/16789622776
And chromium still stumbles on aquarium:
Unfortunately macOS only provides OpenGL 2.1 through Apple's legacy OpenGL-over-Metal. VirtGL can only forward what the host provides (OpenGL 2.1 max) Mesa Override is Ineffective: MESA_GL_VERSION_OVERRIDE doesn't create capabilities that don't exist. Parallels uses Metal.framework alongside OpenGL. This explains their superior performance. Likely translates guest graphics calls to Metal rather than just forwarding OpenGL
Parallels is using:
AGXMetalG16X.bundle - Apple's Metal driver for M4 Pro GPU AppleMetalOpenGLRenderer.bundle - Metal-to-OpenGL translation layer Metal libraries (.metallib files) Uses IOAccelerator for GPU access This allows bypassing the OpenGL 2.1 limitation by translating Metal commands to OpenGL:
find /System/Library/Extension
s -name "*MetalOpenGL*" -type f
/System/Library/Extensions/AppleMetalOpenGLRenderer.bundle/Contents/MacOS/AppleMetalOpenGLRenderer
macbookpro@Mac macos-dri-result % otool -L "/System/Library/Exte
nsions/AppleMetalOpenGLRenderer.bundle/Contents/MacOS/AppleMetal
OpenGLRenderer" | head -10
/System/Library/Extensions/AppleMetalOpenGLRenderer.bundle/Contents/MacOS/AppleMetalOpenGLRenderer:
/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1889.5.3)
/System/Library/PrivateFrameworks/IOAccelerator.framework/Versions/A/IOAccelerator (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 3502.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Metal.framework/Versions/A/Metal (compatibility version 1.0.0, current version 368.12.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)