Has anyone tried enabling OpenGL in Qemu? Everything works great without it. Once OpenGL is enabled, the GTK display mode becomes unusable. On my machine, the screen is squished into the window's lower left quadrant, and the rest of the window flickers like crazy.
The SDL display type works, but screen updates are very slow, which in turn slows down the emulated machine (at least, with the Virtio GPU device).
My display option is currently: -display sdl,gl=on,show-cursor=on, and I'm using a self-compiled Qemu 8.1.0 on Linux.
Has anyone else experimented with this? I'd prefer to use the GTK mode because performance is much better, but it's unusable in its current state (when OpenGL is enabled).
@Hans Since nobody else has your virtio-gpu driver nobody can experiment with it. Generally OpenGL in QEMU should work with Linux guests, have you tested it that way to confirm you get the same results? (To test if the problem is with your QEMU version, host setup or within the guest.) Without access to your driver I'm afraid nobody can really help you.
Is your version of qemu from the Linux distro or did you compile it? During the build for enable the openGL it need of other package.
I had to compile it, which included guessing what dependencies I had to install for the features I needed.
Quote:
Are you using Wayland or a regular X server? With Wayland there is many problems with GTK
I think it's X11. At least, that's what the about window says. I'm using Ubuntu 22.04.4 LTS.
Quote:
I am not sure, bat the acceleration opengl I think it want a client spice
What's a "client spice?" I've seen spice mentioned, but have no idea what it is, or how it fits into the larger ecosystem.
Either way, I can confirm that OpenGL is working. Otherwise I wouldn't be able to work on the VirtioGPU's hardware acceleration. My problem is that the GTK display is messed up, and SDL is annoyingly slow.
@Hans Linux - SLD works without any problem, there is no slowdown. Just don't know why you have "show-cursor=on" because then there are two indicators.
SPICE (the Simple Protocol for Independent Computing Environments) is the best remote display for VM. Because it is very fast and is separated from VMs. It has many fractures: * USB redirection * 3d acceleration * Audio * and more https://www.spice-space.org/
Edited by vagappc on 2024/2/21 14:32:07 Edited by vagappc on 2024/2/21 14:32:44
Never have issues on Sdl or GTK with Gl=on under Qemu X86 guest on X86 host. with PPC guest on X86 host you will find issue with strange colors with gl=on i think because bit swapping endianess.
The same endianess is present if you run an X86 guest on PPC host with gl=on.
I dont know other issue, i suggest to compile and run NOT the last one version.
I could observe the same behavior as you only this was with the display manager Cocoa under MacOs. It squeezed the output to the bottom left of the full screen. Even changing the resolution under AmigaOs4.1 did not help. Guest and host used the same resolution.
With the output "-display sdl,gl=on" I have no problems and it does not slow down as you described. The build was provided to me by @smakusg because you currently need external patches for the GL output under Qemu.
As far as I can remember the build is based on Qemu 8.1 which is not up to date anymore, meanwhile there is version 8.2.1. Maybe the problem has already been solved with newer builds.
Edit:Here you can see the "-display Cocoa,gl=on" zoom-to-fit in full screen. As already mentioned, there are no problems with the SDL output.
Edited by Maijestro on 2024/2/21 15:13:42 Edited by Maijestro on 2024/2/21 15:15:09 Edited by Maijestro on 2024/2/21 15:17:58 Edited by Maijestro on 2024/2/21 20:56:09
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Edit:Here you can see the "-display Cocoa,gl=on" zoom-to-fit in full screen.
Yes there was a problem on QEMU macOS and Cocoa. MacOS SDL works fine on all machines and those running AmigaOS4.1. SDL I also checked macOS with Fedoera Linux "./qemu-system-aarch64 -machine virt,accel=hvf -cpu host -smp 4 -m 4G -device virtio-gpu-gl-pci -device virtio-keyboard -device virtio-rng -display sdl,gl=core" no problems.
I guess the problem on macOS and Cocoa was fixed already in the git version because I saw on the mailing list that you helped the developer to fix it. Thanks!!!
Linux - SLD works without any problem, there is no slowdown. Just don't know why you have "show-cursor=on" because then there are two indicators.
I have it enabled, because Virtio uses the host OS' actual mouse pointer, and otherwise you can't see it.
@vagappc
Quote:
SPICE (the Simple Protocol for Independent Computing Environments) is the best remote display for VM.
Ah, okay. The SPICE software that I know, is the circuit emulator (link).
@all I think the SDL slowness is Virtio GPU specific. With SDL, flushing the screen bitmap to the monitor is incredibly slow. That's crazy, given that the screen bitmap is in an OpenGL texture, so blitting to the display window on the host OS should be incredibly fast. Either way, drawing graphics ends up being painfully slow unless reduce how often the display is flushed (which lowers the frame-rate).
With GTK, the flush operation is way faster.
@Maijestro Nice to see the problem confirmed, albeit with Cocoa instead of GTK. I was hoping someone would tell me that the GTK issue had been fixed, and I just needed to upgrade. I'm currently using v8.1.0 (self-compiled).
@smarkusg Quote:
I guess the problem on macOS and Cocoa was fixed already in the git version because I saw on the mailing list that you helped the developer to fix it. Thanks!!!
Has it also been fixed for GTK? Or for Cocoa alone?
I suspect that my problem may be SDL2_GL_SwapWindow() waiting for a vsync, or the nVidia driver forcing a vsync. To make matters worse, my monitor runs at 30Hz in 4K.** If QEMU's Virtio GPU code is running in the same thread as the CPU emulation (and I suspect that it is), then emulation gets blocked by up to 33ms at a time.
Hans
** Despite this, the VirtioGPU driver is told that it's got a 60Hz screen. So, it's trying to update the screen at that rate. I wish that the EDID that QEMU sends to Virtio GPU was based on the actual monitor's capabilities.
Adding SDL_GL_SetSwapInterval(0) did nothing, nor did my attempts to disable vsyncing in the drivers. My laptop has both an Intel and nVidia GPU, and I've got no idea which one it's using, or what the settings are (the nVidia control panel doesn't even have OpenGL settings).
Switching the desktop to 1920x1080 @60Hz did help, but flushing the image to screen is still hurting performance (reducing screen bitmap flushing to once every 6 frames gives approx. 3x speed up). It's still slower than the GTK backend.
I don't see anything wrong with QEMU's SLD2 GL code. Time for me to move on. I'll just have to live with it for now.
I have no idea what kind of errors these are. For a test, I quickly converted qemu with gtk,sdl,ppc options to x86_84 Test results - except for one case everything works
I do not know - maybe I do something wrong or it depends on the host ?
You wrote earlier , that you are not able to share your driver even if you wanted to for the test publicly because the owner of the rights is A-EON. If there is no driver then there is nothing to check so generally speaking. You can only guess.
---
QEMU 8.2.1 na Linux x86_64 X11 "Ubuntu 20.04.6 LTS x86_64"
CPU: Intel i5-3360M (4) @ 3.500GHz
GPU: Intel 3rd Gen Core processor Graphics Controller
As I said earlier, the GTK backend is completely broken on my system when OpenGL is enabled, regardless of which emulated graphics card you use. It's the same when I use the emulated SM501. No idea why it works for you but not me (and some other people who reported the same issue).
Linux has a large number of distros with different setups. QEMU's GTK code itself has two OpenGL backends (one being EGL based).
The mouse pointer issue (in one of the bug reports I linked to) is specific to the Virtio GPU device. Emulated cards like the SM501 use a mouse pointer that's drawn directly to the window. Virtio uses the host system's actual mouse pointer.
The SDL2 slowdown with a Virtio GPU display may also be specific to my system. I've seen varying reports about Virtio GPU performance (with Linux guest OSes) from "near native" to "horribly slow." It seems to vary a lot depending on which distro, hardware, libs and drivers people have.
I can try upgrade to the latest release (8.2.1) and see if GTK works any better. I didn't see anything relevant in QEMU's commit history, though.
I'm pleased to say that updating to QEMU 8.2.1 fixed the GTK display.
Unfortunately, the GTK display backend is now almost as slow as SDL2 when using the Virtio GPU device. Also, the Virtio mouse pointer is indeed completely unusable, as per this bug report.
Looks like I have to put up with the slowness for now...
I'm pleased to say that updating to QEMU 8.2.1 fixed the GTK display.
Unfortunately, the GTK display backend is now almost as slow as SDL2 when using the Virtio GPU device. Also, the Virtio mouse pointer is indeed completely unusable, as per this bug report.
Looks like I have to put up with the slowness for now...
It's good that some problems with the Display Manager GTK have already been fixed. The GTK output was also completely unusable for me under Qemu 8.1.
As for Virtio GPU and its use on your machine, of course we can't check if it's fast or slow as we don't have those drivers. Nobody currently knows how far along these drivers are and if and when A-EON will release them....I guess when they are ready
I am also not sure what exactly you are testing with your Virtio GPU drivers is it still the 2d part or 3d part of your driver?
Other than that there are a lot of Virtio patches waiting to be added to Qemu Master. Also for the Qemu PPC emulation there is currently a very large patch series that is in pull status, I have never seen such a large series.
Balaton Zoltan told me that we still have about 2 months to fix things before the freez and release of Qemu 9.0. Maybe you should report your problems under Qemu Devel or contact Qemu developers directly and describe the problem.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
49 patches is not too much for a pull request that merges several series each can be 10+ patches so that's only a bit over average size for pulls. I've seen 100+ patch series sometimes but up to 10-20 patches is more usual. This pull is now being reworked and maybe will include even more patches in next version. What's interesting for us in it is the ppc440 tlbwe fixes that should make the sam460ex emulation quite a bit faster as it removes the biggest issue that currently makes it slower than pegasos2 and amigaone. It may still run slower but hopefully not so much. This is now on the PPC maintainer's court so it depends when he gets around finishing testing it to send the pull again. We should be still in time for QEMU 9.0 for that.
Quote:
Balaton Zoltan told me that we still have about 2 months to fix things before the freez and release of Qemu 9.0. Maybe you should report your problems under Qemu Devel or contact Qemu developers directly and describe the problem.
You can see the schedule here: https://wiki.qemu.org/Planning/9.0 Bugfixes are still possible until rc2 at least but no other changes after March 12, those will have to wait for QEMU 9.1. Reporting issues to qemu-devel list would certainly help. Even if patches are the best way just bringing up a problem and provide your insight on it could help some people interested in it to eventually come up with a fix. Telling people about the problem here or even bug requests are not that effective because the relevant people may not see it so the best way is to discuss on qemu-devel which is for discussing QEMU development related techincal issues. So if you can describe the problem it may worth asking on the list to see if anybody knows about a solution.
I'm pleased to say that updating to QEMU 8.2.1 fixed the GTK display.
Unfortunately, the GTK display backend is now almost as slow as SDL2 when using the Virtio GPU device.
In that case it may be possible to bisect it to the patch that fixed it which should provide more insight in the problem. Then you can also ask about that patch specifically on the list.
Quote:
Also, the Virtio mouse pointer is indeed completely unusable, as per this bug report.
Problem with pointer tracking usually stem from different mouse acceleration settings in guest and host. As QEMU does not know about your guest settings it cannot take it into account so this is not easily fixable. Either try to match guest settings to host settings for mouse acceleration or try using an absolute pointing device such as -device usb-tablet which may avoid the problem. QEMU has two ways for mouse pointer drawing, In ati-vga I've implemented both after trying the host side way which is preferred but the guest side one has less problems with jumping cursor. The sm501 I think only has guest side and don't know what the virtio-gpu has but could be it's host side only. One could take a look at ati-vga and take inspiration to implement it in virtio-gpu or just try the above with tablet may be the simplest and what most people use.
Quote:
Looks like I have to put up with the slowness for now...
Unfortunately if everybody takes this route then it will never be fixed. Just letting people know about the problem by reporting and discussing it on the qemu list would raise the chance of it being improved eventually.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
