OpenGL 3.3 with GPU acceleration?

[grav]

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

[theMaddis]

This would be amazing to get working. Would love to be able to run Aether SX on the iPad Pro M1

[Andy312432]

#4433 This issue seems related to this.
Any updates...?

[NDevDrone]

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"

I have the same here with fedora Workstation 37

[taojing10]

Same issue, hope we could support openGL

[DragonSWDev]

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?

[osy]

Yes, macOS does not support higher versions of OpenGL.

[DragonSWDev]

@osy Can't UTM atleast provide OpenGL 3.3 core profile somehow?

[osy]

We use ANGLE to provide the highest version that supports all the features requested by virgl

[DragonSWDev]

Ok but ANGLE is providing OpenGL ES implementation. How does it relate to desktop OpenGL?

[osy]

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.

[DragonSWDev]

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.

[vancluever]

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

[osy]

Yeah that’s CPU rendering. You can get the same result in QEMU by choosing a display hardware that doesn’t have -gl