-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Comments
This would be amazing to get working. Would love to be able to run Aether SX on the iPad Pro M1 |
#4433 This issue seems related to this. |
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 |
Same issue, hope we could support openGL |
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? |
Yes, macOS does not support higher versions of OpenGL. |
@osy Can't UTM atleast provide OpenGL 3.3 core profile somehow? |
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 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
|
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 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 |
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):Configuration
The text was updated successfully, but these errors were encountered: