QEMU's master repository doesn't support Virtio GPU blob resources and Virgl 3D acceleration at the same time. Has anyone tried a branch that does with AmigaOS?
QEMU's Virtio support looks like it's still rather rough, and under development. I know that there are branches with experimental Vulkan support (codenamed Venus), but they seem to be based on old QEMU versions. Plus, there's no indication that the code will make it back to the master project. To complicate things further, the Vulkan capable branches seem to support other extensions like shared-mem. Again with no indication these will become official parts of QEMU.
It's all rather messy, and makes figuring out what to use rather difficult.
@Hans QEMU (like the Linux kernel) is under constant development and depends on contributors to make progress so some things being off-tree or have forks with different goals is normal. What's "official" i.e. included by distros and widely available so what you should build on is in QEMU master. I don't know virtio-gpu but I think what's currently in master supports virgl and maybe shared buffers were already merged but I haven't seen patches yet to add Vulkan support so at the moment it's probably uses OpenGL. This is a bit old status report but maybe still mostly the case: https://www.kraxel.org/blog/2021/05/vi ... gpu-qemu-graphics-update/ The author of that blog entry is the QEMU graphics maintainer so you can write to him to ask about current status and plans but he seems to be busy with other projects so unless somebody will submit patches to merge it probably won't happen very soon. So if you need something that's currently off-tree but has s signed-off-by already you can ask the author if plans to upstream it or take it yourself and do the upstreaming (see https://www.qemu.org/docs/master/devel/submitting-a-patch.html). The sam460ex emulation was done that way. Somebody started working on it but amabdoned it half finished when I took over and updated and finished it and upstreamed in QEMU. So either use what's in master or help moving it to the direction you want it to go then you can use that.
I don't know virtio-gpu but I think what's currently in master supports virgl and maybe shared buffers were already merged but I haven't seen patches yet to add Vulkan support so at the moment it's probably uses OpenGL. This is a bit old status report but maybe still mostly the case: https://www.kraxel.org/blog/2021/05/vi ... gpu-qemu-graphics-update/
The master branch supports blobs and Virgl, but NOT at the same time. It's either one or the other. I see no shared memory support for Virtio GPU.
What's concerning about the Vulkan forks, is that some of them haven't been touched in three years. This includes code in other repositories, such as mesa3d, and virglrenderer. I don't want to be using the remnants of someone else's abandoned experiments.
No thanks. I've got way too much on my plate already without adding that on top. There are multiple branches, multiple projects, and I have no idea what state any of them are in. It looks like none of them forked/merged QEMU recently enough for AmigaOS 4 to run.
Based on your response, I think I'd better stick with what's in the master branch.
The master branch supports blobs and Virgl, but NOT at the same time. It's either one or the other. I see no shared memory support for Virtio GPU.
What's concerning about the Vulkan forks, is that some of them haven't been touched in three years. This includes code in other repositories, such as mesa3d, and virglrenderer. I don't want to be using the remnants of someone else's abandoned experiments.
These quetions are best asked on the qemu-devel list cc-ing Gerd Hoffmann to get an authorative answer as people on the list and the subsystem maintainer should be the best source of current status so I encourage you to ask there rather than here. If you need something that's easy to fix maybe somebody will be inspired on the list to do that or can at least give you advice how could that be achieved.
Quote:
Based on your response, I think I'd better stick with what's in the master branch.
If you have no time to add missing stuff you need then you should use what's in master and hope somebody else will eventually add what you can use but that may be a long time or never so without taking actions it's best to stick with master. But may still worth asking the maintainer what may come in the future although I don't think any big change is planned for this year because freeze is a few weeks away and I did not see any gfx patches yet on the list so probalby nobody is working on it at the moment.
@Hans Well, I was wrong (not following virtio-gpu development). There seems to be some activity. This was just posted and will be merged soon: https://patchew.org/QEMU/2023101613540 ... candre.lureau@redhat.com/ According to this the direction now is gfxstream whatever is that and no idea if that's relevant or useful for you. When writing to the qemu list to ask you can find the people to cc to increase the chance of getting an answer by using the scripts/get_maintainer.pl script you can use -f path/to/file to get people relevant to that file. It's better to ask and find out nobody knows the answer than redoing something that maybe somebody can answer on the list.
The last patch in the above pull request adds some documentation of the different virtio-gpu variants which may also provide info on what works currently and how to use them.
Thanks. I took a look at the documentation you mentioned. So, Venus is out, and gfxstream + Rutabaga are in (whatever those are). I don't see an updated Virtio GPU specification covering those, so they're probably still under development. It's a pity that each graphics API seems to need its own pass-through protocol.
I've sent an email to the mailing list. Will see what they say...
@Hans The virtio-gpu series I've liked above is now applied in master. Not sure what this series added helps you. It says blob resources are enabled with virtio-gpu but I don't know what those are and if it helps with sharing memory between guest and host as you need. The commit messages have some info on what these are and the docs in the last patch has links to more info too. Apparently these come from Android Emulator and gfxstream was previously called Vulkan Cereal (link in qemu/docs/system/devices/virtio-gpu.rst) and should allow streaming both Vulkan and GLES commands from guest to host. It provides both host and guest side libs but maybe you'd need to implement the guest side in your driver to use this. But this seems a bit experimental still but some things like Wayland can already use it. Don't know where to get more detailed info on this but there are some links in the commit messages and the docs. Or you can stick to virgl which seems to be an independent way of doing almost the same but less general and mainly for Mesa/OpenGL. I can't really help with this as I don't know this graphics stuff.
I saw your message on the list but it may take a while to get an answer. If nothing happens for about a week you can try adding more people on cc (or I can do this for you replying to your message) but lets wait a bit, Gerd does not seem to be active on QEMU too often for a while.
Good to see it actually get merged. I've looked at the code. Still no blob support with VirGL. Only with Rutabaga (gfxstream). Rutabags/gfxstream appears to only be available in Android emulators for now, so no Linux backend. It's developed by Google, so no surprise. I'm sure Linux support will come later, but it's not there right now.
Thinking about it a bit more, even blob resources won't help me, because Virtio GPU only supports 32-bit pixel formats. Blobs can't be used for direct VRAM access to 8 and 16-bit bitmaps. So, I still need to work around P96 expecting direct access to VRAM and Virtio GPU not being able to provide it.
It looks like I best proceed with VirGL minus blobs for now...
VirGL i can say for sure was working on Linux PPC plus i was able to build it but not tested on Linux Arm (raspberry). This mean if KVMpr and Virgl together will work on PPC Linux host machine we will have a good base for new devs and extra users for AmigaOS. On Linux Arm i was able to build and use Vulkan (3y ago). where i had success to have Linux X86 inside a blob with full Vulkan 3d acceleration support. This mean we can have a good start in future for have a SDK Amigaos vms machines an arm or on other hw architectures if some one take the right decisions.
@Hans I never used any of these so I'm just exploring it but it seems gfxstream is meant to be a generic low level facility to send anything from guest to host so it can support multiple usages not and GFX APIs. Virgl is quite tied to Mesa/Gallium and may have some limitations so unless you can easily fit in those it may not be the best way now that things seem to move towards the more generic gfxstream way that may not be well supported yet but likely will replace virgl at some point. So this may be considered when deciding which way to go now.
If you search for posts from Gurchetan Singh who seems to be a main person behind these on the qemu list you may find more info on how these fit together or what are the plans. E.g.: https://lists.nongnu.org/archive/html/ ... vel/2023-03/msg04271.html These may be patches that were submitted as RFC and not in QEMU yet or may take a different form later but that's the way it's moving towards.
I think you can ignore rutabaga which seems to be a higher level thing for crosswm and wayland that may not be needed to just get 3D gfx throgh from guest to host for which gfxstream it probably enough and it could carry not just what virgl can but also Vulcan or GLES (but if you already have something matching virgl in guest that may not matter only if it's easier to serialise GLES for example with gfxstream). I still dont's see what's needed on the host and how would it work for all hosts but maybe the gfxstream core or docs if exist is where one should start to find out.
Gfxstream sounds nice, but it's just been added to QEMU. I can't rebuild QEMU to use it because I can't find the external dependencies. I also haven't found any documentation on the protocol, either. It sounds like the protocol hasn't been fully nailed down, and may still change (although they're close). There's no guarantee that gfxstream will replace VirGL, or supplant the still experimental Venus protocol.
At the moment, gfxstream isn't any more generic than VirGL. It's supported only by Android, and works by piping high-level graphics API calls directly to the host driver (e.g., GLES & Vulkan, Wayland). Yes, the VirGL protocol is based on how Gallium3D works.** However, Gallium3D is based on how modern GPUs work, and there's no reason why VirGL's command stream couldn't be used on other platforms. The basic commands sent to the GPU are the same regardless of which API you use: you give the GPU a render state, a vertex array, a shader program, and tell it to go.
Most if not all of Gurchetan Singh's critique of VirGL look like implementation issues. Performance, memory use, and render errors are a product of how VirGL has been implemented rather than a flaw in the protocol itself.
VirGL is ready to use on my machine, and is stable. I have documentation on the protocol. It's ready to go.
Hans
** Ironically, this makes the protocol lower level than piping OpenGL ES calls directly.
@Hans I get what you say. What I meant was just in case it's more difficult to implement this with virgl then maybe gfxstream might be a better match. But since that's new and experimental in QEMU it may be less well documented and not so easy to use at the moment.
Using virgl should also work and probably also future proof as it should srill be supported for quite a while and even if gfxstream gets a bit more mature in the future it should be generic enough to be able to send through the same stream as virgl uses so the driver should still work with that. Therefore using virgl is not a bad choice just wanted to bring up gfxstream as a possible alternative as this is a good time to evaluate both before committing to any of them.
I don't understand much about it, but which dependencies under Qemu have to be fulfilled for the VirtIO GPU driver to be used under AmigaOs4.1. ?
You don't need much for basic framebuffer support (with no hardware acceleration). Assuming you do want hardware graphics acceleration, then the following should be enough to enable VirGL:
Not all of those are for VirGL (e.g., libbluetooth-dev certainly isn't). Some of them are needed for QEMU, and others are for optional modules that you're likely to want.
@balaton Quote:
I get what you say. What I meant was just in case it's more difficult to implement this with virgl then maybe gfxstream might be a better match. But since that's new and experimental in QEMU it may be less well documented and not so easy to use at the moment.
That does not seem short at all. Probably much less is enough. One way to find out is to add --enable-virglrenderer to your QEMU configure command and install the libraries it tells you. Probably just libvirglrenderer=dev which should pull in its dependencies. Most of the others are probably optional or not needed.
True. Some of those dependencies are needed simply to build QEMU at all. Others are needed for modules that you're likely to want (e.g., slirp networking). Others I added because I wanted certain modules enabled (e.g., SDL2 & GTK backends).
If someone wants the minimum dependencies only for VirGL, then they're welcome to do the work needed to trim down the list, and figure out which dependencies go with what.
Ok, thanks for the information...Hans ok, it looks like you prefer to use Linux as a test system.
For MacOs I found this, which should be pretty easy to install using the homebrew package manager. I haven't tested it yet. When this driver is released, 3D acceleration will be added with later versions, so it's not that important for now.
Ok, thanks for the information...Hans ok, it looks like you prefer to use Linux as a test system.
Not really. I'd stick to Windows if I could. Unfortunately, VirGL doesn't work on Windows yet. This made Linux a must. So, I installed Linux on an external hard drive for my existing laptop. Not ideal, but much cheaper than buying a new machine.
VirtioGPU.chip will work on systems without VirGL. The screenshots that Trevor showed at Amiga38 & AmiWest were captured on Windows. Of course, you won't get hardware acceleration or 3D drivers without VirGL.
Quote:
For MacOs I found this, which should be pretty easy to install using the homebrew package manager. I haven't tested it yet. When this driver is released, 3D acceleration will be added with later versions, so it's not that important for now.
By the way did you test the emaculation.com windows builds vs. the welnetz.de builds and is there a differentce between those? Also if you have real hardware and also used AmigaOS on QEMU so you can compare the experience what are the points you think is still behind on QEMU (apart from slower FPU that I already know aobut and gfx which is being worked on).
Virgl should also work on windows but maybe you need to build it yourself. (Probably because nobody bothered to upstream the needed patch.) There are some tickets: https://gitlab.com/qemu-project/qemu/-/issues/564 https://gitlab.com/qemu-project/qemu/-/issues/1461 and a blog post about it: https://guanzhang.medium.com/running-a ... indows-10-11-4eea9be9a06b If this works and want others to be able to use it without having to build a patched version consider upstreaming the patch by submitting it to the qemu-devel list following the patch submission guidelines.
Good to know. I'll leave experimenting with it and submitting patches to someone else. I have drivers to write...
Quote:
By the way did you test the emaculation.com windows builds vs. the welnetz.de builds and is there a differentce between those?
No. I wasn't aware of the different builds. I downloaded the Windows version from qemu.org (so the welnetz.de builds). I had to build my own version on Linux, because Ubuntu's official packages are far too old.
Quote:
Also if you have real hardware and also used AmigaOS on QEMU so you can compare the experience what are the points you think is still behind on QEMU (apart from slower FPU that I already know aobut and gfx which is being worked on).
I have an X5000 and A1222. The X5000 is so much faster than QEMU, which feels sluggish on my laptop. My hardware systems also have 3D and hardware video decoding support. I also have reliable networking on real hardware IIRC, you already know about the problems with the emulated RTL network card; the network regularly fails.
The emulated machine will randomly lock up when playing videos, with the last sound being repeated a tight loop. On real hardware (with a RadeonRX card) I can watch UHD videos smoothly, without problems
QEMU is also rather difficult to set up compared to actual hardware.** You need to create a custom ISO, and fiddle with custom parameters. Then there's setting up BBoot, which also has the added difficulty of updating kernel modules (on real hardware AmiUpdate & A-EON's Updater can update modules directly).
There are probably other differences, but I only use QEMU for testing the Virtio GPU drivers.
Hans
** Installation on real hardware is bad enough. The OS installer should be able to partition & install the system with little to no input required. In particular, the installer should be able to partition the system automatically (or with a little guidance), with the full-blown partition editor being an option for "power users."
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
