Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
61 user(s) are online (42 user(s) are browsing Forums)

Members: 0
Guests: 61

more...

Support us!

Headlines

 
  Register To Post  

« 1 2 (3) 4 »
Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
Quite a regular
Quite a regular


See User information
Today I tried a normal compilation
so a simple one
./configure

and it gave me the error
meson flex and it came out
I updated:
"meson flex"

then again
./configure
ok everything went well.

but if I use for example a compilation only for PPC AmigaOS:
./configure --target-list=ppc-softmmu --disable-dbus-display --enable-slirp --enable-lto --enable-sdl --enable-gtk -Doptimization=3

Here again the connection is lost every now and then again as in previous versions to version 9 of qemu.

so it seems strange to me that I can't complete:
./configure

without having to update "meson flex"

@joerg

This is a separate question,
Excuse me in which file do I find the string:

CFLAGS="-march=native -mtune=native" CXXFLAGS="-march=native -mtune=native"

@Maijestro

I've switched everything to SSD now so I have an SSD just for Linux and another just for AmigOS the old Crucial 250gb I used before.
This makes my job easier.
And I can put a lot of stuff in there

Go to top
Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
Just can't stay away
Just can't stay away


See User information
@white
Quote:
A video card like this one for example with the exact specifications:
EBAY
https://tinyurl.com/2c699sf6
Similar, but that's a gfx card from Gigabyte.
The one geennaam used is a MSI one: https://www.techpowerup.com/vgabios/191488/191488
(probably https://www.techpowerup.com/gpu-specs/msi-r9-270x-gaming-oc.b2537 but this page doesn't include the PCI IDs to be 100% sure).
Even if the hardware may be the same just a different BIOS could cause problems.

Quote:
Apart from the Drivers.

Is the card recognized even without drivers?
I mean on real AmigaOS hardware it is recognized regardless of the drivers.
No, AmigaOS doesn't include a fallback VGA/VESA framebuffer driver.
On systems supporting PCIe (X1000, X5000, Sam460, A1222) a Lite version (max. resolution 800x600, no GPU HW acceleration) of the RadeonHD driver should be included in AmigaOS 4.1 and you can use that to install the full version from Enhancer Software (RadeonHD v3), or the separately available RadeonHD v5 driver for gfx cards requiring the newer version.
Of course it's in the PCI tree you can check for example with Ranger if you have a 2nd, supported gfx card installed, but without a gfx driver for it you can't use it for gfx output.

U-Boot should theoretically work with any VGA compatible gfx card, but it's old x86 emulator doesn't work with the BIOS of some newer gfx cards and may crash.


Edited by joerg on 2024/5/4 17:42:58
Go to top
Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
Quite a regular
Quite a regular


See User information
@joerg

Thanks for the valuable information,
For optimization I'm just seeing if I find something.

https://wiki.gentoo.org/wiki/Distcc#CFLAGS_and_CXXFLAGS

I compiled this but I don't understand how to use it

https://github.com/hartwork/resolve-march-native

But the speed is fine now.

Some time ago, if I remember correctly, on Morphos there was a graphics card on which you had to directly flash the FIRMWARE to make it recognise.

Who knows if someone in qemu could do something like this on ATI cards.
especially for the qemu emulator.

Go to top
Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
Not too shy to talk
Not too shy to talk


See User information
@white

Maybe I wrote something wrong - English is not my strong point.

Maybe here this description will help you
https://en.wikipedia.org/wiki/CFLAGS


You can add it depending on your Linux distro in /etc/profile/xx so that each of your programs is compiled with your preferences as you wish.
In your current shell/console (bash .zsh .. ) use the word ‘export’ to output them by adding the word ‘$’ the previous values will not be overwritten
export CFLAGS="$CFLAGS -march=native -mtune=native"
export CXXFLAGS="$CXXFLAGS -march=native -mtune=native"


If you do not want to do this, use their values when calling the configre command:
"CFLAGS=’-march=native -mtune=native" CXXFLAGS="-march=native -mtune=native" ./configure <here the rest of the options>.

You can add to the optymalization flag etc ....
I hope I have written it now a little clearer



Cards that were supplied with APPLE MAC required firmware changes to make them work on other systems.
Inversely, this could also be done so that a card that was not supported by APPLE MAC would work.
* without going into details

Go to top
Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
Quite a regular
Quite a regular


See User information
@smarkusg

Thanks to you too for the explanation

I tried to compile with this:
-march=znver3 instead of native the results look identical to "native"

it compiled without any errors

https://wiki.gentoo.org/wiki/Safe_CFLAGS#Ryzen_.28Zen_family.29


* without going into details

Who knows if such an idea in emulation would be feasible
It would be interesting to know the ideas of those who are familiar with these things.
Sure, maybe not all the advanced instructions but at least something that keeps you entertained.
And you support a good portion of the instructions that serve "minigl etc."

This memory came to mind:

And to think that with an AMD which was even inferior to the INTEL and a Voodoo I was playing the first UNREAL at the highest possible resolution.

Go to top
Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
Quite a regular
Quite a regular


See User information
@white
Instead of setting CFLAGS env variable you could pass it with --extra-cflags="-march=native -mtune=native" option to configure. This is preferred over setting it globally as then it won't affect anything else only QEMU. QEMU does not use C++ (and the little that may still be there likely isn't used by qemu-system-ppc) so you can skip CXXFLAGS. You won't see difference between native and your specific CPU option as native will select the right option for the CPU it's compiling on so it will be the same. The advantage of native is that it works on all CPUs without needing to find what the right options for it.

On PPC Mac hardware where MorphOS runs on only graphics cards with an OpenFirmware ROM work, cards with a PC BIOS will not be initialised even if the hardware is the same. This is the reason to change ROM on cards for MorphOS on Mac hardware. Pegasos2 and other AmigaNG machines have BIOS emulator in their firmware so would work with at least the graphics cards that are contemporary to these machines. Theoretically it's possible to change BIOS on a card but only BIOS that is for that card will work so you should not try that unless you know exactly what BIOS works with what card or don't mind bricking your graphics card. There is usually no need to change BIOS on a graphics card for AmigaOS or QEMU. Even if you would run MorphOS on QEMU's Mac emulation a Mac card won't work because the OpenBIOS QEMU uses for Mac can't run Mac nor BIOS ROMs. For AmigaNG machines the board's firmware (U-Boot or SmartFirmware) should be able to handle usual PC cards.

But as I've said earlier old ATI cards won't work with QEMU PCI pass through until somebody fixes the part that only supports HD cards now in QEMU and newer cards may not be supported by the BIOS emulator in the old firmwares so currently it's likely only RadeonHD cards that could work.

Go to top
Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
Quite a regular
Quite a regular


See User information
@balaton
@smarkusg

Thanks for the explanation,

Well I have to say that it has really improved a lot.
I also tried the "m3u8" live broadcasts in HD
And they are fine, obviously it depends on the Live but in general it works well.
The whole system is very responsive compared to some time ago.

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.

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"

sudo make install -j16

qemu-system-ppc -M pegasos2 -kernel /home/white0/Downloads/bboot-0.7/bboot -initrd /home/white0/Downloads/Kickstart.zip -m 2048 -serial stdio -device sm501 -device rtl8139,netdev=mynet0 -netdev user,id=mynet0 -vga none -display gtk,zoom-to-fit=on -full-screen -drive media=disk,format=raw,file=/dev/sde1 <--- Real SSD

-drive file=fat:rw:/tmp/qemu-amiga,id=ufat,format=raw,if=none -device usb-storage,drive=ufat



separate note for those who use firefox with linux:
disable recommended extensions
about:config
extensions.htmlaboutaddons.recommendations.enabled
put on false

every time I restore the backup I have to put it back and look for the string

If anyone wants to suggest anything else to help me I'm happy

Thank you.

@balaton
next developments in later versions of qemu ?


@joerg
with qemu emulation
with an SSD how many block size do you recommend 512 ?
is Buffer 600 ?
with sfs/02

Thank you.

Go to top
Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
Just can't stay away
Just can't stay away


See User information
@white

Quote:

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"

sudo make install -j16

qemu-system-ppc -M pegasos2 -kernel /home/white0/Downloads/bboot-0.7/bboot -initrd /home/white0/Downloads/Kickstart.zip -m 2048 -serial stdio -device sm501 -device rtl8139,netdev=mynet0 -netdev user,id=mynet0 -vga none -display gtk,zoom-to-fit=on -full-screen -drive media=disk,format=raw,file=/dev/sde1 <--- Real SSD

-drive file=fat:rw:/tmp/qemu-amiga,id=ufat,format=raw,if=none -device usb-storage,drive=ufat


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.

Resized Image

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne A1222plus AmigaOs4.1 FE
Go to top
Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
Quite a regular
Quite a regular


See User information
@Maijestro

With a second graphics card I could use
vSphere (vmware)
and other similar platforms.
Other things like Streamlink and a lot of things like that.
But an ATI with 2GB wouldn't be ideal so I have to think about it a bit.

a geforce 1060 6gb would already be good to do this as a second card.

Go to top
Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
Just can't stay away
Just can't stay away


See User information
@Maijestro
Quote:
I'll leave you my configuration with SFS/02. I'm not sure about Buffers 500
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).

Go to top
Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
Quite a regular
Quite a regular


See User information
@joerg

I selected 5000 buffers for all partitions

I currently have for SWAP
1024 blocks
600 buffers

What do you recommend for swap instead ?
block buffers etc. ?


Resized Image

Go to top
Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
Just can't stay away
Just can't stay away


See User information
@joerg


Quote:
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.

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne A1222plus AmigaOs4.1 FE
Go to top
Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
Just can't stay away
Just can't stay away


See User information
@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).

Go to top
Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
Just can't stay away
Just can't stay away


See User information
@joerg

Quote:
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.

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne A1222plus AmigaOs4.1 FE
Go to top
Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
Quite a regular
Quite a regular


See User information
@joerg
Is this Buffers usage the same for all file systems or just SFS? Or does it mean something else for FFS for example? Also then for swap it may not make sense to have buffers or does that use it for something else?

Go to top
Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
Just can't stay away
Just can't stay away


See User information
@balaton
It's the same for all file systems, but since the "buffers" only cache meta data blocks of the file system, not data blocks of files, a disk cache like diskchache.library.kmod used by SFS and JXFS, fs_plugin_cache for FFS, or internal ones like in NGFS and in NTFS/FAT/etc. (probably all FUSE/Filesysbox based ports) which cache all blocks makes it even faster.

For FFS there is a special exception: On DOSType DOS\0, DOS\2, DOS\4 and DOS\6 partitions, which probably nobody uses, file data blocks have a header with a checksum, leaving only 488 bytes for the actual file data on 512 byte blocks, and are cached by the "buffers" as well.
All other AmigaOS file systems I know, as well as the other FFS DOSTypes like DOS\7 (probably the only one used by 99.9% of the users), use the complete block for file data blocks and don't cache it with "buffers".

There is no swap file system, creating a partition with DOSType SWAP just reserves space for it on the HD, the pager uses direct 4KB (page size) device read/writes within it's bounds without any caching.
(I added support for SWAP partitions in diskcache.library and the required changes in the kernel about 20 years ago, but AFAIK it was never used.)

Go to top
Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
Quite a regular
Quite a regular


See User information
@joerg

OK so basically buffers is a metadata cache, not related to caching file data but only directory entries so its size probably should be related to how many files are stored on the partition and how many of them are expected to be open at the same time. So it can be lower for archive volumes or volumes with large files but should be higher for sys or partition with many small files that are accessed frequently. For swap will it be ignored whatever is set there or it's allocated but unused? If it's not allocated then it does not matter and can be left to default. If I got this correctly.

Quote:
(I added support for SWAP partitions in diskcache.library and the required changes in the kernel about 20 years ago, but AFAIK it was never used.)


It seems a bit pointless to cache swap because its purpose is to remove pages from memory so copying a page over to some other part of memory does not seem to be what it should do. Either the page should be kept or swapped out so not much point to put it in cache which would just take space from file system data that the cache is meant to hold. Maybe that's why it wasn't used.

Go to top
Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
Quite a regular
Quite a regular


See User information
@smarkusg
Quote:
But it is also interesting to compare QEMU versions.
For me in this test, QEMU8 is about 1-2 seconds faster than the new Qemu9

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.

Go to top
Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
Just can't stay away
Just can't stay away


See User information
@balaton
Quote:
OK so basically buffers is a metadata cache, not related to caching file data but only directory entries so its size probably should be related to how many files are stored on the partition and how many of them are expected to be open at the same time. So it can be lower for archive volumes or volumes with large files but should be higher for sys or partition with many small files that are accessed frequently.
For a partition with only few very large files used most of the time read-only you can use only a few buffers, but when writing it it will get slow as well since it's not only directories but several other file system block types like the bitmap of used/free blocks on the partition, pointers to the data blocks used by a file, etc.

Quote:
For swap will it be ignored whatever is set there or it's allocated but unused? If it's not allocated then it does not matter and can be left to default. If I got this correctly.
All file system parameters are ignored, for example the block size as well since the swap partition has to use the CPU page size for it.

Go to top
Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
Quite a regular
Quite a regular


See User information
@joerg

In practical terms
what would you recommend for qemu "Pegasos2"
do not create the SWAP partition I created it with 4GB double the RAM that you can have with qemu.

In this case, the Command to add in the startup-sequence:
Is C:BootLoader COMMANDLINE "NoDiskPager" also valid for Pegasos2 if I remove the SWAP ?
Could the system be more efficient ?


Is it valid only for the classic ?

I have currently changed to:

BlockSize 512
Buffers 10000
MaxTransfer FFFFFFF (maximum)
Mask 7FFFFFFC (32bit aligned)

I have not currently removed the SWAP
If I remove it, will it lead to invalidation of the disk ?


Edited by white on 2024/5/8 17:03:12
Go to top

  Register To Post
« 1 2 (3) 4 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project