Does it support OpenGL 3.3?

[seraphlive]

Hi @knazarov ,

Thanks for the work! I'd like to ask if the solution currently supports OpenGL 3.3 in the guest system? I was trying to run Alacritty terminal emulator, which requires OpenGL 3.3+, and it told me that the system doesn't support OpenGL 3.3 and above. (It's a Fedora 34) So is this just current situation or did I misconfigure anything?

BTW the installation through homebrew seems failing now because it can't find the latest binary package from GitHub release. 😃

[seraphlive]

Oops, sorry I mean GLSL 3.30 when saying OpenGL 3.3. Not sure if they are kind of same thing though..😅

[knazarov]

Hi @seraphlive !

To the best of my knowledge, alacritty doesn’t work under GLES. There’s some upstream work to get it work on top of it with a few extensions, but it’s far from complete.

It’s really a pity, because this terminal gets recommended a lot.

Regarding the binary release — thanks for letting me know! I’ll upload it today.

[knazarov]

It may still be possible to play around with a pull request that’s open for this repo. If you’re brave enough, you can try to apply it and see if it will change anything.

[seraphlive]

After upgrading to the latest release (without that pull request, just the binary you recently uploaded), Alacritty does work fine now. The glxinfo command reports OpenGL version string: 3.1 Mesa 21.1.5. I don't know, maybe some update from you or Akihik Odaki actually fixed it and that's enough for Alacritty to work (at least on Intel)?

Anyway I do find another issue. Not sure if it's known and related to the upstream work you mentioned. If I use below options:

-device virtio-vga \
-display cocoa,gl=es \

to start the machine and log into the gnome 40 on Fedora 34 using Wayland, severe memory leak will happen. Just open Firefox and load a YouTube video page, the I can watch the vm eating up all 8GB of the 5500M GPU and over 50GB memory before I force to shut it down. Then I tried same options on X11, no such issue (the performance is a little bit worse though). For other video devices like Virtio-gpu-* I don't have Wayland option on the login page. Finally I tried Wayland with Virtio-vga again but this time with gl=off, and there is no memory leak and performance is good.

So from my testing only Virtio-vga, gl=es plus Wayland will trigger this memory leak issue. For now I'm OK to stick with gl=off. The performance is good enough for my use cases. But if you'd like to dig into the issue, feel free to let me know what can I do to help.

[knazarov]

The reason why you see OpenGL 3.1 is likely due the the fact that you're not using virgl, but instead use llvmpipe (this can be verified in the Gnome "About" dialog in Settings.

The latest patchset seems to have pulled changes by kraxel which split the graphic devices into virtio-vga and virtio-vga-gl. I suggest you to check if virtio-vga-gl will work for you. I've added the -gl suffix to the device used for arm, because I have access to arm hardware at the moment, and not to x86.

If adding -gl to the device will work, I'll change the README.md to reflect that.

[knazarov]

BTW, I managed to start alacritty like this:

LIBGL_ALWAYS_SOFTWARE=1 alacritty

So if you manage to get the virgl device working properly, you may use the same approach.

[seraphlive]

Yes, you are right. gnome settings indicates that I'm using llvmpipe. If I use virtio-vga-gl or virtio-gpu-gl with gl=on or gl=es, I will get below result: As you can see, dmesg shows that virgl feature is enabled, while gnome setting still shows llvmpipe. Also Wayland is not an option when using these drivers.

[seraphlive]

Currently for me, the best working combination is virtio-vga with gl=off. Wayland works, alacrity works out of box, firefox and YouTube performance is good and there is no memory leak. Except for that it seems not actually using virgl :)