Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenGL 3.3 with GPU acceleration? #4285

Open
grav opened this issue Aug 10, 2022 · 16 comments
Open

OpenGL 3.3 with GPU acceleration? #4285

grav opened this issue Aug 10, 2022 · 16 comments

Comments

@grav
Copy link

grav commented Aug 10, 2022

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
Copy link

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

@Andy312432
Copy link

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

@NDevDrone
Copy link

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"

@williamzborja
Copy link

I have the same here with fedora Workstation 37

@taojing10
Copy link

Same issue, hope we could support openGL

@DragonSWDev
Copy link

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
Copy link
Contributor

osy commented Mar 18, 2023

Yes, macOS does not support higher versions of OpenGL.

@DragonSWDev
Copy link

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

@osy
Copy link
Contributor

osy commented Mar 18, 2023

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

@DragonSWDev
Copy link

DragonSWDev commented Mar 18, 2023

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

@osy
Copy link
Contributor

osy commented Mar 18, 2023

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
Copy link

DragonSWDev commented Mar 18, 2023

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
Copy link

vancluever commented Sep 5, 2023

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
Copy link
Contributor

osy commented Sep 5, 2023

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

@vancluever
Copy link

vancluever commented Sep 5, 2023

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.

@sandangel
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants