Is that consistently so or you just happened to get different measurements or something else is changed on your system between these versions? If this reproduces consistently now with two QEMU versions and you want to find the cause then you could try to bisect which commit made it slower. As the test is automated you may even be able to script that and let the bisect run without intervention so you don't have to compile and test a lot of versions by hand. But 1-2 second may be within the variation that you get by running the test multiple times on the same QEMU version. Testing this on macOS with M1 where you sometimes get faster and slower runs may not be the best so maybe should be tested on something more stable where that issue does not happen.
I have also observed this behavior compared to Qemu 8.1 to Qemu 9 it has become slightly slower, you know that I like to test it with Quake as a benchmark and here I get 29.2 FPS (Qemu 9) with 8.1 it was 31-32 FPS always tested with the fastest session which always leads to the same result in speed.
Which commit has slowed down Qemu 9 will be hard to check there have been too many changes and I don't want to find out because it's still very fast and I'm not arguing about 1-3 FPS I think what is really missing is a better FPU emulation.
joerg wrote:@Maijestro The only differences between SFS\0 and SFS\2 are - SFS\2 supports partitions larger than 128 GB, SFS\0 doesn't (with 512 bytes/block). - SFS\2 supports files larger than 4 GB, required for example for DVD image files, on SFS\0 (and FFS) the max. file size is 4 GB - 2 bytes (with 512 bytes/block). - For SFS\0 data recovery tools (SFSSalv, PartitionWizard, etc.) are available, for SFS\2 there are none.
The "Buffers" are used to cache meta-data blocks of the file system, in case of SFS for example the directories, extents of the files (which data blocks on the partition are used for the file), BitMaps (records which blocks of the partition are in use and which ones are unused), etc., and in general all of the B-Tree blocks used for file system meta data. If you use only a few buffers (like 500) such blocks have to be re-read much more often from the HD/SSD, with "enough" buffers (for example 5000 or 10000) the file system can use the data in the "Buffers" in RAM and doesn't have to read them from the HD/SSD (again).
Thank you for this valuable information. It gives me personally a better understanding of why Buffers and what support and limitations SFS has.
For the updated Mediathek version of os4Welt.de (evil) maybe try asking if it can be put on OSdepot. So maybe a more updated version can be used.
I've already asked him about it, but he wants to make it available on his website/server so he doesn't have to do too many updates on different sources.
Maybe tomorrow I can give you a source with the current version to try out.
Use at least 5000 buffers, and since there are no data recovery tools for it SFS\2 instead of SFS\0 only for the partitions on which SFS\0 can't be used (partition size > 128 GB, files > 4 GB).
Thanks for the hint about the buffer size.
Did I understand you correctly that all partitions above 128 GB should use SFS/02, partitions below should use SFS/0?
This would currently only affect my Games partition, which is 182GB in size.
If you don't mind, could you briefly explain to me what the buffer size setting does and why it is important. I would like to understand it a little better.
I have to get another card anyway because without a second card I can't do other things.
However, I see that no one on the forum seems interested in experimenting with this.
I would have loved to try it out and it would be fantastic to be able to use 3D acceleration under Qemu with AmigaOs4.1 and also 32bit screens. Unfortunately I don't have the necessary PC hardware at the moment.
Quote:
For my Mac M1 Max there is already Asahi Linux "Fedora" it's all there, but the Thunderbold support is still missing and so I can't pass an external GPU to Linux/Qemu at the moment. well I'll leave my ./configure also as a reminder for a future time. git clone https://gitlab.com/qemu-project/qemu.git cd qemu git submodule init git submodule update --recursive ./configure --target-list=ppc-softmmu --disable-dbus-display --enable-slirp --enable-lto --enable-sdl --enable-gtk -Doptimization=3 --disable-qom-cast -debug --disable-debug-info --extra-cflags="-march=native -mtune=native"
Thanks for testing it again, I added some things to my configuration when I compiled it.
Quote:
with qemu emulation with an SSD how many block size do you recommend 512 ? is Buffer 600 ? with sfs/02
Since I also gave a real SSD to Qemu, I'll leave you my configuration with SFS/02. I'm not sure about Buffers 500, but everything runs smoothly and I have very fast read/write speeds.
I have all the Italian channel lists and would like to use them and adapt them if possible. or I don't know if there is any other program to do this.
I watched their video it runs fantastic on their system. Thanks for the video
Mediathek is developed by a German user (evil) on os4Welt.de and at the moment only registered members on os4Welt get access to the program.
The original source of the author is http://evil.bplaced.net/index.php?name=Mediathek&page=About but the version that is offered there is unfortunately a bit older and does not provide TV streaming. I have already asked evil to give me a current source so that I can link to it.
If you are interested I would do the English and Italian (Italian was your language, wasn't it?) translation. TV streams and thumpnails would then only have to be added, which can be done directly via Mediathek without any problems.
The streams can be played with FFPlayer/Emotion/MPlayer.
For now, you should pass "-loglevel quiet" to FFPlay to ensure that the streams are loaded very quickly and there is no unnecessary shell output.
Try this out.
FFPlay -loglevel quit path/to/stream
Resolutions can be forced in the window with "-x" "-y"
Thank you for your feedback but I personally tested this new version on native machines (SAM440, software and opengl rendering actually goes through SDL1 but I don't see the connection).
The Qemu/Pegasos2 machine currently has problems with old SDL1 libraries and it leads to unsightly artifacts and distortions.
The AmigaOneXe/Sam460 machine does not have these problems and we do not yet know exactly what the problem is, as the Pegasos2/AmigaOneXe machine is based on the same code. At the moment it is suspected that it could be something in the AmigaOs4.1 kernel that only occurs with the Pegasos2 version of AmigaOs4.1 in combination with the SiliconMotion 502 graphics card.
As far as we know it is due to the 16-bit bitmaps of SDL1
SDL2 from version 2.26.5 uses 32-bit bitmaps in all applications and this also works very well under Qemu/Pegasos2.
The card is much too old and can only be used via a PCIe to PCI bridge. You would probably have Warp3d (MiniGL) available under amigaOs4.1. Warp3d Nova (GLes2) does not work with these old cards.
As I understand it, an AMD Radeon R9 270/x is the best card to use for full 3d acceleration including Warp3D Nova under Qemu/Pegasos2. This card has 2 GB memory.
However, AmigaOs4.1 does not provide a driver for this card and you would have to use additional software (Enhancer Software) which provides current graphics card drivers among others. And you probably need a board with 2 PCIe slots.
So we have no proof that it actually works as it has only been tested by one user and there is no real useful information about it.
Edited by Maijestro on 2024/5/2 16:53:07 Edited by Maijestro on 2024/5/2 17:15:34
Regarding GPU passthrough, yes, I got it "working", but it was not properly working. And I might be wrong but I don't think we ever truely fixed it (IRQ issues from memory maybe?). In small part because I just went and bought an X5000 system instead which obviously works much better - or as best as any OS4 system can :D
The passing of real graphics cards has already been tested by @gennaam and was successful @Balaton had to solve a few IRQ problems in BBoot.
So technically it is feasible and gennaam described that the Qemu/Pegasos2 system with R9 270 behaved like a real system, based on the CPU display.
I don't test it but use it like someone with real hardware
Since the Pegasos2 machine was the first one available under Qemu, I stayed with it and set up a nice AmigaOs4.1 system that I use every day. In addition, AmigaOs4.1 is on a real SSD that I have given to Qemu. Everything that is worthwhile for me I have installed (os4depot) or bought software myself.
I also did some tests with the AmigaOneXe and Sam460 machine. Mainly because of SDL1 problems that do not exist on these machines.
I really liked the Polish report which is neutral about the problems of hardware/emulation/software AmigaOs4.1. The translation of the video worked well and I could understand it well.
Thank you smarkusg (Marek) for the interview and the past projects you were mainly involved in.
Thanks Huno for the new version I have already tried it but it seems that the software renderer mode is broken, did you use SDL1 libraries for it?
Otherwise great that they disabled the fade in out function so the SnesGui starts much faster. Seems the OpenGL mode works best for me although it runs over Wazp3d. Composit also works but then there are problems with the sound output although it does not come to 100% CPU load.
A small video which shows the problems.
The video is currently being edited for better playback in higher resolutions.
Attention! This video is only intended to show the problems and I will remove it from the forum later so as not to slow it down.
Yes, I recorded Quake FPS 20.1 here 1280x800 and Desktop 2048x1152 because there is recording software.
It doesn't matter which resolution you use for your guest system AmigaOs4.1 under the WB the result is always the same if you run e.g. Quake Timedemo in a slightly lower resolution which is then also used.
I have tested it briefly with optimization=2 and optimization=3 "-mtune=native -mcpu=nativethe" increased optimization level led mostly to problems with the graphics output it was so far everything ok, but behaved somewhat differently than with level 2.
I changed it directly in "meson.build"
With optimization=3 there was also no relevant speed increase.
For me is always a good test with Quake1 Timedemo under AmigaOs4.1 and here I reached 29.2 FPS 1280x720 in both cases. So I'm not sure if optimization=3 does anything at all except maybe more problems.
The biggest problem is the lack of 3D acceleration everything else is already really fast on my hardware.
Edited by Maijestro on 2024/4/29 18:37:08 Edited by Maijestro on 2024/4/30 19:04:06
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
I think what is really missing is a better FPU emulation.
