It's not VRAM related at all, neither on real hardware nor with vfio pass through on QEmu, but faster CPU (emulation) speed should help anyway.
x64 CPUs aren't relay suitable for PPC emulation anyway, way too few registers, emulation is only fast if the host CPU has more registers than the emulated guest CPU, for example as it's the case with the m68k emulators of AmigaOS 4.x: m68k: 16 integer registers, of which 8 can only be used for data, and 8 only for pointers, and 8 FPU registers - but those were 80 bits, not the usual 64 bits of current FPUs. The 80 bit 68882 results from real m68k FPUs were used for example for the newlib math library code tests, and of course nearly all of them failed, with more or less errors. PPC: At least 32 32 bit integer (GPR) and 32 64 bit FPU registers (some CPUs have more, CPUs with AltiVec additionally 32 128 bit registers, or may have less but larger ones like the 64 bit instead of 32 bit GPR/SPE registers on the A1222). m68k emulators on PPC can use a 1:1 register mapping of host and guest registers, and still have 16 integer and 24 FPU resisters left which can be used by the emulator code.
For example ARM based CPUs, like the Apple M4, and MIPS based ones should be much better at PPC emulation than x64 CPUs are.
@joerg But results so far did not prove that faster CPUs should be better for using real cards with passthrough. At least I got the impression that the Gfx2DBench results were more dependent on something else than host CPU speed. But the thread where I've asked people to collect results went nowhere so I don't have data to compare.
I'm also not sure that number of registers plays the bigest role in emulation performance. We know that FPU, MMU emulation, exceptions and dcbz are all factors that if something hits any of these a lot it will get slow. If something hits multiple of them it may be even worse. Compared to that having to move data to/from registers is probably less of an issue given that modern CPUs are much faster and this should still work from cache so this may have less of an effect than the other issues. Trying to optimise those may help more. I've tried cleaning up exceptions before but it did not help that much. MMU is not easy to improve. For FPU there was a design that could be implemented but nobody tried it and I've also tried dcbz but again nobody cared about it enough so these aren't solved still. I guess dcbz would not be too difficult as it's just one small part that somebody could learn in a few weeks and make a patch but there weren't many people wanting to try that so far.
If you doesn't mind, can you enable in options of spencer "fps show" , set everything to maximum as well (shadows, light, resolution, etc), and check what FPS you have when in the menu walk a bit (the middle value), and what FPS you have in the first level, when staying at beginning and do nothing ?
If you doesn't mind, can you enable in options of spencer "fps show" , set everything to maximum as well (shadows, light, resolution, etc), and check what FPS you have when in the menu walk a bit (the middle value), and what FPS you have in the first level, when staying at beginning and do nothing ?
Looks like smarkusg is using the demo version of Spencer where no options are available.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
about 28-29 frames The game runs at my monitor's native resolution of 1680x1050. Tested on Raden HD R9
@Maijestro This can be set in the demo version
Yes, I didn't find the button for selecting the options menu It's Space.....
On real hardware the FPS numbers fluctuate a bit, but on yours they seem to be fixed at 28. How are the numbers in the first level, surely they will go down a bit here ?
And thanks for this test.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
@kas1e It is behaving strangely. In the first level I have 28 to 35 frames. The average of 32 frames comes out At the beginning of the first level when I don't move I have 28 - here should be these 35 frames.
Are you using unreleased version of kernel and driver under Radeon on Pegasos2 ?
Are you using unreleased version of kernel and driver under Radeon on Pegasos2 ?
On x5000 all public ones, on pegasos2 just updated kernel to fix those peg2 related bugs. Frames wary that ok in game (i have it too). But by all means it looks like qemu with passed GPU even didn't hit those limits we have on real hardware, and about 3-4 times slower in 3D for now.
Quote:
That's interesting...thanks! Here it's 120 FPS in the menu and about 140-150 FPS in level 1 with RXRadeon.
The maximum i had with RadeonRX and beta stuff on x5k/020 it's 160 in menu and ~130-140 in game.
..didn't hit those limits we have on real hardware, and about 3-4 times slower in 3D for now...
Must someone try QEMU with 3D on better hardware than mine. Maybe then it will reach that limit.
@Maijestro Quote:
Here it's 120 FPS in the menu and about 140-150 FPS in level 1 with RXRadeon.
There is nothing to compare my 2012 PC/X86_64 with your powerful PPC machine. You can compare it to the result of a football match between the Spanish national team and the national team of San Marino. The guys from San Marino are not even professional football - you know what the result will be. But they play and very well. 10 FPS would be enough for me and I would be happy.
Here it's 120 FPS in the menu and about 140-150 FPS in level 1 with RXRadeon.
There is nothing to compare my 2012 PC/X86_64 with your powerful PPC machine. You can compare it to the result of a football match between the Spanish national team and the national team of San Marino. The guys from San Marino are not even professional football - you know what the result will be. But they play and very well. 10 FPS would be enough for me and I would be happy.
I wasn't referring to your test with Spencer, but rather to what @kas1e wrote and the figures he achieved on his X5000.
Regarding Qemu, I still find it impressive and we are still at the very beginning of what will eventually be possible. We don't have data from powerful machines like i9 or amd ryzen. I think everything will be better than with sm501/2 and only 16 bit resolutions.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Problem with env variable or default nvram.bin is that user will need to remember to include it at every start which they will forget and complain. It must be either default or done once then be persistent. I can't easily add text file to set default nvram as there's no QEMU option for that and no other example in other machines which should still work alike so I can't add random hacks. But it's possible to include a text file in Kickstart, the pegasos2 nvram.resource does that and works so other modules could do the same. I think that's the simplest solution but the problem is theoretical at the moment as we don't even know such config is needed or we can just fix it elsewhere.
I'm okay with adding a way to force enable GART and disable the cache hint instructions.
Generally, I hate having lots of env-vars, and prefer that default options are optimal. However, in this case there's no reliably way to test if GART is supported on an emulated machine (testing it will likely freeze the machine). The same goes for the dcbz instruction which you cannot safely disable (e.g., memory clear operations might use it).
@all
However, I need a simple and reliable way to read the configuration file that works regardless of the (emulated) machine. Is there a standard way for OS modules to read firmware ENV vars? Or is there a standard way to read a text file that's embedded in the kicklayout?
By "standard," I mean works regardless of the motherboard. I do NOT want to add per-motherboard workarounds.
Whatever it is, it's neither U-Boot, the kernel nor the motherboard hardware. @geennaam managed to get nearly 2 Gb/s with his nvme.device on the X5000.
Careful with mixing Giga-bits per second and Giga-Bytes per second.
EDIT: Looked up @geennaam's test results, and it's 2 GB/s. Nice to know that the PCIe controller itself can deliver.
I still haven't got a clue why it's slow with the GPU. I can't remember how I tested it 9or what the actual results were), but I do know that some of the GPU's DMA engines are slower than others. I got mixed messages from AMD's guys whether the CPDMA engine was actually slow or not. Being 5-6x slower would be pretty bad...
@Hans The way that the pegasos2 version of nvram.resource uses also works on amigaone and sam460ex as I've tried that before to set env vars using the nvram.resource module from pegasos2 before NVRAM emulation was added to amigaone. So your drivers could do the same to check a config text file added to Kicklayout. This may not be standard but at least already exists in some versions so you can promote it to a standard hack status.
But for dcbz you can't just add a conditional around it as that may make it slower so you may need to patch it on load to something else based on the CPU or config. For most CPUs used in latest AmigaNG machines dcba might be better or according to the Apple sources Joerg found maybe even nop so if you can test that having dcbz there helps at all maybe it's simpler to just remove it completely.
I don't know how much GART matters but if we also have an interrupt issue fixing that first may be needed.
Problem is with any modifications you make is that we'll never get them. I can't even get an answer for the simple question about releasing virtio.library interface. So I'm still interested in improving dcbz in QEMU which is beneficial of existing old code, also those that you cannot change because they are in some other closed source stuff like MacOS or third party apps. And if dcbz is still used for clearing memory because it helps on real machine QEMU has to handle that anyway. Adding config options for these in the driver may help to test these ways also on real machines so for that it's still useful.
The way that the pegasos2 version of nvram.resource uses also works on amigaone and sam460ex as I've tried that before to set env vars using the nvram.resource module from pegasos2 before NVRAM emulation was added to amigaone. So your drivers could do the same to check a config text file added to Kicklayout. This may not be standard but at least already exists in some versions so you can promote it to a standard hack status.
So is the nvram.resource workable for QEmu? Or do I need to go the config text file route? If so, I need to know the API to detect and read the text file in the kicklayout.
Quote:
But for dcbz you can't just add a conditional around it as that may make it slower...
Of course I wouldn't do that. The driver can already use different copy routines for different systems (FPU, altivec, spe). I'd just add one more set of copy routines.
Quote:
For most CPUs used in latest AmigaNG machines dcba might be better or according to the Apple sources...
I can't remember the details, but there's a reason why we don't use dcba.
Quote:
I don't know how much GART matters but if we also have an interrupt issue fixing that first may be needed.
GART makes a difference.
Quote:
Problem is with any modifications you make is that we'll never get them...
Such a pessimist...
I understand your frustration with the lack of response regarding the virtio.library (which annoys me too). However, updates do eventually make it out into the wild. One downside of working under contract, is that I don't get to decide the release schedule.
So is the nvram.resource workable for QEmu? Or do I need to go the config text file route?
I think it would not be workable in practice. Problem with nvram.resource is that users would need access to pegasos2 version too to get it which they probably don't have if they have another version and also using it means the newly added NVRAM support in amigaone would not work with that so it's better to have a separate config file for gfx drivers.
Quote:
If so, I need to know the API to detect and read the text file in the kicklayout.
In case you have access to the source of nvram.resource used on pegasos2 I guess you can find it in there. The API did not change for other modules on pegasos2 as it is just emulating an NVRAM which gets data from a text file instead of the firmware but the way to get a text file from the kicklist should be there.
Quote:
GART makes a difference.
On real hardware sure but I meant for QEMU with vfio-pci. I don't even know if it would work currently so maybe it's not top priority over other possible improvements. But adding a config for it helps testing it in any case.
Quote:
Such a pessimist...
I understand your frustration with the lack of response regarding the virtio.library (which annoys me too). However, updates do eventually make it out into the wild. One downside of working under contract, is that I don't get to decide the release schedule.
They say optimists are oblivious pessimists But it does look like from my perspective that your work is just going into a black hole. You had working 2D virtio-gpu driver a year ago and we still have nothing of that (maybe you even have 3D now which we still can't try). Neither the fixed pegasos2 kernel was released which I could at least work around but vfio-pci passthrough would be easier with a fixed kernel. So that does not make me too optimistic about it unless you can release a test driver yourself.
However, I need a simple and reliable way to read the configuration file that works regardless of the (emulated) machine. Is there a standard way for OS modules to read firmware ENV vars? Or is there a standard way to read a text file that's embedded in the kicklayout?
Firmware ENV variables: Works on all systems, not only U-Boot ones even if the functions have UBoot in their names, and even on classic Amigas and Pegasos2 without NVRAM support (they use a special version of it and a kickstart module text file instead, but of course unlike the other implementations that's read-only): nonvolatile.library, documentation of the new functions seems to be missing in the AutoDoc, but check interfaces/novonlatile.h: GetUBootVar()
Using a kickstart module text file for config: If you have access to the AmigaOS 4.x sources check for example my diskboot.kmod sources (Hyperion has no permission to use it anymore, but you can use the part of my sources parsing the config for your drivers). IIRC it's something like
EDIT: Looked up @geennaam's test results, and it's 2 GB/s. Nice to know that the PCIe controller itself can deliver.
I still haven't got a clue why it's slow with the GPU. I can't remember how I tested it 9or what the actual results were), but I do know that some of the GPU's DMA engines are slower than others. I got mixed messages from AMD's guys whether the CPDMA engine was actually slow or not. Being 5-6x slower would be pretty bad...
@geennams's nearly 2 GB/s nvme.device benchmark result on the X5000 with PCIe x4 v2.0 is only a theoretical result, transferring 128 MB of data in a single DMA transfer is next to never done with real world DOS/filesystem operations. Using 16 KB it's only 222 MB/s, and with the max. transfer size NGFS uses (128 KB) it's 450 MB/s. I don't know anything about 3D GPUs, but I guess most GPU texture, etc. DMA transfers are quite small as well and not several MB at once either.
News feed
OS4 Feedback forum
OS4Depot Feedback 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
It's Space.....
But it does look like from my perspective that your work is just going into a black hole. You had working 2D virtio-gpu driver a year ago and we still have nothing of that (maybe you even have 3D now which we still can't try). Neither the fixed pegasos2 kernel was released which I could at least work around but vfio-pci passthrough would be easier with a fixed kernel. So that does not make me too optimistic about it unless you can release a test driver yourself.