Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
63 user(s) are online (31 user(s) are browsing Forums)

Members: 1
Guests: 62

daveyw, more...

Headlines

Forum Index


Board index » All Posts (balaton)




Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


@defcon9
Quote:
Maybe getting the SM502 driver to support modern screen resolutions would be a good starting project.

I think you can't do that. It's not something missing from sm501 emulation, it works fine with Linux and MorphOS with in screen modes (apart from MorphOS currently not booting on sam460ex emulation in latest QEMU for different reasons but used to work with older QEMU versions) but AmigaOS has some limitation in its graphics.library that does not support the format that the sm501/sm502 use for 24/32 bit modes so the AmigaOS driver only works up to 16 bit. Also the siliconmotion502.chip driver is closed source as is AmigaOS so you can't do much about that.

Quote:
After that, I’d love to look into OS support for a paravirtualization driver.

I think potential projects you could consider are these with increasing difficulty:
- Easy: virtio sound or network driver, these are all documented both on the virtio and AmigaOS side AHI and network driver APIs should have docs and example code.
- Medium: virtio disk (blk or scsi) driver or cirrus-vga/stdvga bochs DISPI interface driver, there may be some reverse engineering needed and less example code available for these but if you want a challenge these could be good candidates
- Hard: 3D support either with virtio-gpu or ati-vga (there's some closed source work going on for virtio-gpu driver but as it's unclear if this will be available and likely won't be free so I still consider these to be potential projects in the future but maybe not something you want to start at first).

Quote:
Quick question about the 460ex ecosystem: I'm trying to install the "Extras" from the install CD. However, when I mount the virtual CD drive again in QEMU (in addition to my HD file), it forcefully boots into the Install CD everytime, even though I've manually override U-Boot to boot from the SATA HDD. I see U-Boot indicating to boot from HD0, but I end up in the CD installer everytime. Is there some Amiga magic I'm missing?

Maybe boot priorities of partitions? Either you need to set the HD higher as the CD or you could boot without the CD and insert the disk after booted. With gtk and cocoa display backends there might be a menu entry for it, with -display sdl you can use the change command in QEMU monitor to attach a CD, see also info block QEMU monitor command. You may need to add -device ide-cd,id=something without a -drive or -cdrom option to attach an empty CD drive. Or you can access the early startup menu by holding or quickly keep pushing both mouse buttons while AmigaOS boots around where the logo appears where you can select the boot device.

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


@defcon9
Hello and welcome. You can chose between amigaone, pegasos2 and sam460ex. Each has some advantages and disadvantages so nothing is perfect. Sam460ex is easiest to install but currently has some issues and is slower than the other two so if you don't already have this version then better chose from amigaone or pegasos2. These will need some tweaking as they don't include sm502 driver but with BBoot this should not be too difficult. The pegasos2 version of AmigaOS has some kernel bugs (which may have already been fixed but no update was released), some of these could be worked around and others may happen (like SDL1 graphics issues with some statically linked programs) but is well tested and should run well. Amigaone uses the same emulation as the two machines have the same or very similar components so it should also run well but the AmigaOS version is a bit different. It does not have issue with SDL1 but may need some tweaks but it's not more difficult to get work than pegasos2. If you're getting it new maybe you can only still buy amigaone version anyway as the pegasos2 is sold out. I recommend this guide: https://qmiga.codeberg.page/aos_bboot.html

If you're interested in contributing to QEMU emulation a start page is on the Developer section of my home page (for short qmiga.codeberg.page that redirects there) the development page is in the top menu: https://codeberg.org/qmiga/pages/wiki

If you're interested in graphics I've written an article about the possibilities here: https://codeberg.org/qmiga/pages/wiki/AmigaOSGfx
AmigaOS already has Voodoo driver but QEMU has no Voodoo emulation. There are several projects (mame, PCem, WinUAE) that have Voodoo emulation which could be adapted for QEMU but one issue is that it may need a non-free ROM which would likely make it not accepted in QEMU and also it's a limited hardware so the emulated one would have the same limitations therefore it's not the best option.

It you're more interested in developing drivers for AmigaOS instead of improving device emulation in QEMU then there are other options such as virtio disk, network or sound driver or a driver for the PCI Cirrus VGA or stdvga in QEMU which may be smaller projects and mostly AmigaOS specific that could help running AmigaOS on QEMU without having to learn about QEMU itself.

Go to top


Re: Tracing
Quite a regular
Quite a regular


@Hypex
You only need struct Task *taskID in the message, processID can be get from that so it's redundant.

@kas1e
Quote:
Yep, that better, but still not very readable as it still mix of different debug output. If use messages with all those processIDs is it possible to deal with ?

You could either add locking around the whole stack collecting part where you print things not just around a single printf but that would lock all other tasks until one stack trace is done. You could instead of printing it open a file for each task or each call (append taskId+timestamp to make unique file name) and print the trace there so you'd get a separate file for each call with just the stack trace for that call.

Go to top


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


@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)
Quite a regular
Quite a regular


@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: Tracing
Quite a regular
Quite a regular


@kas1e
Your hook function runs in the caller task while your main runs in your own task. You have to stop the caller after messaging the main task until the main task finishes collecting the stack trace otherwise the caller continues and may exit or will not be at the place you want to trace. There are several ways to do that:
1. Reply with a message, the caller needs a message port for that in addition to the main's message port where you call it.
2. Wait for a signal, then the main task needs to raise the signal (don't know what's the corect term for that in AmigaOS) once finished to make the caller continue.
3. or maybe in the hooked function call suspend self after sending the message and from the main task call restart for the process ID that was passed in the message, then you won't need either a reply message port nor a signal.

Go to top


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


@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: Tracing
Quite a regular
Quite a regular


@kas1e
Quote:
Yeah, busylooping take 100% cpu loading, which i kind of fix by adding IDOS->Delay(1) in , but that of course ugly crap :)

Through i still don't understand one moment : why when i simply run my CallHookPkt() test case, i have about 150 calls of CallHookPkt() from patched function, but only 12 StackTraces.. I was expected to have the same amount : for each call of patched CallHookPkt - one StackTrace.


First call to hook sets process_to_inspect. Then another process calls CallHookPkt and your hook function overwrites process_to_inspect. This happens a few times until your main process gets a chance to run or finishes the delay and notices process_to_inspect is != NULL and suspends the last process that overwrote the global variable. Then goes on to collect the stack trace, if unlucky, there was already another call from another process so process_to_inspect now points to some other process not which was suspended. Then collects trace of that process and restarts some random process at the end, depending if there was more calls that replaced process_to_inspect while the stack trace was running. This won't work this way. You need to make the trace collection function not depend on any globals and pass the process id to trace via a message or some other way that's not overwritten by another call to your hook function. Since the hook function can also be invoked by several tasks simultaneously (it can be preempted while running and another process could call it again) it also cannot use globals. You could add locking to avoid these problems and only allow one instance of the hook and stack collection to run at a time but that would stall every other caller until stack collection is finished and create a bottleneck in your tracer. It's better to make the trace collection reentrant so it can be called multiple time on different processes without breaking and connect it to a message port so it can be invoked thorugh a message. Then hook function only needs to send the message and wait for reply which is again something that's independent of all other calls, it can constuct the message in a local stack variable so then multiple tasks can invoke this simultaneously and the separate calls can commence without blocking each other.

Go to top


Re: MPlayer 1.5 released!
Quite a regular
Quite a regular


@Maijestro
Quote:
Example: FFPlay -loglevel quit -x 640 -y 480 path/to/stream

That would be -loglevel quiet I guess.

Go to top


Re: Tracing
Quite a regular
Quite a regular


@kas1e
Constantly polling process_to_inspect global variable in an infinite loop is not only very inefficient as you've found but also not safe in a multitasking environment, because another process could call your hooked function while it's still collecting a stack trace and that would overwrite process_to_inspect during the stack trace function is running. You really should send the process id via a message or some other IPC mechanism and make the stack tracing function reentrant (i.e. not using any globals) so it won't break if invoked by different processes at the same time. Invoking this with a message would both avoid 100% CPU usage from busy waiting and avoid needing Suspend/Restart as the traced process would wait for the message.

I don't know how to get more detailed info but you probably would need to at least run debug kernel to get info on kernel functions and may need debug versions of libraries too which may not be available.

Go to top


Re: Tracing
Quite a regular
Quite a regular


@kas1e
Maybe I don't understand the problem in the first place but I think if you're in the hooked function then you're running within the task that called the function you've replaced so whatever you do will affect the caller. If you suspend the task then it will not be run any more so the next line that would resume it won't be reached and there's nothing else to resume it. If you can't walk the stack to find the callers from the hooked function then I think what you might need to do is implement getting a stack trace in your main program and create a message port to invoke this stack trace collecting function on the task passed in the message. Then from the hooked function send the process id to the main program and wait until it replies. This will suspend the task waiting for the reply until the main program can collect the stack trace then it can resume the caller by replying to the message. This is what @Hypex proposed above if I got that correctly.

Go to top


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


@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


@white
You don't get error with modifying meson.build and that works too until you want to update from git. Then you'd need to undo the change and redo it again afterwards so it's better to pass it to configure and not change meson.build. Maybe you can try to add one more configure option: --disable-qom-cast-debug but don't know if it makes any difference in performance. It may be a little faster in some cases but probably not a big deal, but if you want to optimise everything than this can be added.

With gfx card passed through to guest the AmigaOS driver gets full control of the card so a card is needed that QEMU can pass through correctly and AmigaOS can drive. This seems to be ATI HD7000 or similar card currently. Older cards aren't properly passed through by QEMU (it needs some changes in the places I've pointed to before) and newer cards may have problems with PCIe passed through as PCI or newer BIOS that crashes the emulated BIOS in these older firmwares or something. It also needs separate purchase of Enhancer software or whatever the RadeonHD driver comes with as the one included in AmigaOS 4.1FE is just enough to get picture to install the real driver that fully supports the card. One important point is that GPU pass through with pegasos2 needs BOTH -bios pegasos2.rom (but not -kernel bboot) and then boot with boot hd:0 bboot.fth with at least bboot 0.7. The firmware is needed to run the card bios and then BBoot is needed to fix IRQ routing and 64bit BARs. If you boot with -kernel bboot as usual then the card BIOS will not be run and may not work so need to boot with firmware and use bboot from firmware not on its own. It may be easier with amigaone where only the -bios u-boot-amigaone is needed without bboot or sam460ex but that may have other problems so currently only the pegasos2.rom+bboot way was tested.

I won't try to explain what's needed for AmiCygnix again as I did that for a few times so you'd need to understand the network setup under QEMU and either configure tap networking or with -netdev user add the appropriate hostfwd option to allow connecting to the X server in the guest. I'll let others have a go trying to explain that as I could not describe it in a way that you could understand so I would just confuse you further trying to explain.

Go to top


Re: Pegasos2 with RadeonHD/RX via bridge
Quite a regular
Quite a regular


@joerg
Yes I know, maybe my wording was not clear. What GPL prevents is one party turning GPL software into closed source software which is what I really meant by "commercial code", so maybe that's what causes misunderstanding. BSD license has no such restriction so somebody can take it and use it in part or change it and make it closed source, they only cannot claim they wrote it and have to keep copyright messages to acknowledge original developers. GPL also requires to keep the sources free and available for everybody and not use it in code that does not allow the same. So when you substitute commercial code with closed source code that's what I meant but failed to describe properly.

By the way it's not the GPL code that's sold commercially because the code itself is freely available (and cannot be charged more than the fair amount needed to transfer it) but additional services using that code like making distros or providing services based on that code and so on. But GPL software can be developed commercially for sure.

Go to top


Re: Pegasos2 with RadeonHD/RX via bridge
Quite a regular
Quite a regular


@joerg
Quote:
OTOH with the GPL you have no choice/control over your own code any more, even just linking with a GPL library will force you to release any sources linked with it, no matter if you want to do that or not. Even worse: Any output/data generated by GPL software is GPL as well.

And there's a reason for that which is to ensure that GPL code is not used in commercial code only in free software so it cannot be exploited without the developer's consent (who still has the right to sell their work under a different license as they own the copyright so commercial vendors could buy a license from the author for code otherwise available as GPL but cannot just copy and use parts of GPL code unless they also publish the result as GPL). If less strict MPL like license is needed there's LGPL for that which only applies it to the code itself and allows it to be combined with non free software (but still does not allow copying part of LGPL code into non LGPL or GPL code and make it non-free).

Go to top


Re: Pegasos2 with RadeonHD/RX via bridge
Quite a regular
Quite a regular


@kas1e
I think Linux also uses RTAS on pegasos2 if I remember correctly but I could be wrong. It can be checked in Linux source or you could boot Linux on QEMU pegasos2 and add debug log to RTAS calls to see if they are called. Even if config-l@ can access card regs you can only use that from firmware before OS boots but the BAR addresses are also in the device tree so you could get it from there without reading the register. Otherwise if you need to write or access other regs and can't get it using RTAS then it needs to access PCI directly.

Go to top


Re: Pegasos2 with RadeonHD/RX via bridge
Quite a regular
Quite a regular


@kas1e
I remember that we've concluded that you can't use my donate button and I can't accept what you can use so we've left it at that. It's OK, it's not about money as I've made it clear before, donations aren't required, it's just there to allow people who want to thank me that way can do so if they wanted. I prefer to work on what I'm interested in and I can't use this bridge support much as I have no real pegasos2 (also no real gfx card or driver for it) and on QEMU even with PCI pass through there's no bridge visible for the guest so there the problem is already solved by current BBoot.

This looks like primarily a problem in AmigaOS kernel. If it can't even see the card then maybe it also does not look behind the bridge like BBoot (so does not even read the device tree below the bridge) and when it did, it might get problems with 64bit BARs and RTAS not supporting bridges. Patching all this from BBoot is too much work (almost like reimplementing a large part of the firmware) which I'm not interested to do just to fix a closed source OS that's not even free and others would want to benefit from it. This is something that should be fixed in the AmigaOS kernel and I'm not the right person for that job.

I remember you've posted info about this before but it's in that long thread somewhere and was a long time ago so I don't remember the details any more. From the firmware listings it seems the firmware did find the card and could access BARs and config registers but the ROM is missing so not sure it could run it and init the card fully. If AmigaOS only needs the data from the device tree then maybe it does not need RTAS just to parse the tree but if it needs access to config regs and ROM then it might need to access PCI directly and not via RTAS if that cannot handle the card behind the bridge.

I think Hans already understands the problem, it just takes time to do all this by him alone.

Go to top


Re: Pegasos2 with RadeonHD/RX via bridge
Quite a regular
Quite a regular


@kas1e
Technical knowledge isn't something god given or special talent. All it needs is ability to think logically and be able to read documentation ant then it only takes time. No need to say sorry, just spend the time needed to acquire technical knowledge.

I don't quite know what you get as I only see what you post here so I don't know what beta kernels do or how it appears in firmware. If there's a device node then that means the firmware does look behind the bridge but I'm not sure it inits the card correctly or AmigaOS can handle it without further tweaking like what BBoot does for cards not on the bridge. It does not show in BBoot output because BBoot does not handle bridges. I could enhance that but as I said it's probably a limited use case better handled in AmigaOS so even if BBoot fixed 64bit BARs behind the bridge maybe that would not be enough for it to work and still would need AmigaOS changes so then all of it could be handled there.

(Also realised where did you get 16 for BAR address. Forth is hex by default do dec# 16 is wriiten as 10 in Forth.)


Edited by balaton on 2024/4/28 13:55:31
Go to top


Re: Pegasos2 with RadeonHD/RX via bridge
Quite a regular
Quite a regular


@kas1e
BBoot on pegasos2 just lists the devices that the firmware detected so if the firmware does not look behind the bridge then BBoot won't do that by itself. This shows two things however. The correct format for config-addr which is more difficult to get from SmartFirmware so BBoot can help here, that's why I've added this output when we needed it for the 64bit BAR script (16 is not even a BAR, those are at 10,14 etc.). And that the firmware may not correctly init the bridge so to access devices behind it you'd need a driver for PCI bridge in AmigaOS first (or teach BBoot to handle bridges but then it would also need to modify the device tree which would get complex as AmigaOS gets the device tree from RTAS so then BBoot would also need to replace RTAS and that's the point where I said it would be too much work for a use case better fixed in AmigaOS in the first place and doing something else is better use of my time).

Go to top


Re: A1222 support in the SDK and problems
Quite a regular
Quite a regular


With QEMU amigaone I get good results (slower than real G4 but we know QEMU FPU is slow and this combines that with memory access that also gets slower for bigger blocks):
-------------------------------------------------------------
STREAM version $Revision5.10 $
-------------------------------------------------------------
This system uses 8 bytes per array element.
-------------------------------------------------------------
Array 
size 10000000 (elements), Offset (elements)
Memory per array = 76.3 MiB (= 0.1 GiB).
Total memory required 228.9 MiB (= 0.2 GiB).
Each kernel will be executed 10 times.
 
The *besttime for each kernel (excluding the first iteration)
 
will be used to compute the reported bandwidth.
-------------------------------------------------------------
Your clock granularity/precision appears to be 2 microseconds.
Each test below will take on the order of 170922 microseconds.
   (= 
85461 clock ticks)
Increase the size of the arrays if this shows that
you are not getting at least 20 clock ticks per test
.
-------------------------------------------------------------
WARNING -- The above is only a rough guideline.
For 
best resultsplease be sure you know the
precision of your system timer
.
-------------------------------------------------------------
Function    
Best Rate MB/s  Avg time     Min time     Max time
Copy
:            2540.6     0.068012     0.062977     0.077582
Scale
:           1009.5     0.163934     0.158498     0.172685
Add
:             1217.1     0.208123     0.197197     0.223799
Triad
:            965.6     0.261186     0.248550     0.281111
-------------------------------------------------------------
Solution Validatesavg error less than 1.000000e-13 on all three arrays
-------------------------------------------------------------

But with QEMU sam460ex something seems to be wrong:
-------------------------------------------------------------
STREAM version $Revision5.10 $
-------------------------------------------------------------
This system uses 8 bytes per array element.
-------------------------------------------------------------
Array 
size 10000000 (elements), Offset (elements)
Memory per array = 76.3 MiB (= 0.1 GiB).
Total memory required 228.9 MiB (= 0.2 GiB).
Each kernel will be executed 10 times.
 
The *besttime for each kernel (excluding the first iteration)
 
will be used to compute the reported bandwidth.
-------------------------------------------------------------
Your clock granularity/precision appears to be 3 microseconds.
Each test below will take on the order of 192721 microseconds.
   (= 
64240 clock ticks)
Increase the size of the arrays if this shows that
you are not getting at least 20 clock ticks per test
.
-------------------------------------------------------------
WARNING -- The above is only a rough guideline.
For 
best resultsplease be sure you know the
precision of your system timer
.
-------------------------------------------------------------
Function    
Best Rate MB/s  Avg time     Min time     Max time
Copy
:            1672.3     0.098496     0.095678     0.109226
Scale
:            771.9     0.212180     0.207291     0.219799
Add
:              968.0     0.253143     0.247930     0.264263
Triad
:            760.0     0.326087     0.315804     0.345664
-------------------------------------------------------------
Failed Validation on array a[], AvgRelAbsErr epsilon (1.000000e-13)
     
Expected Value1.153301e+12AvgAbsErr1.141173e+12AvgRelAbsErr9.894843e-01
     
For array a[], 9895936 errors were found.
Failed Validation on array b[], AvgRelAbsErr epsilon (1.000000e-13)
     
Expected Value2.306602e+11AvgAbsErr2.282429e+11AvgRelAbsErr9.895204e-01
     AvgRelAbsErr 
Epsilon (1.000000e-13)
     For array 
b[], 9895936 errors were found.
Failed Validation on array c[], AvgRelAbsErr epsilon (1.000000e-13)
     
Expected Value3.075469e+11AvgAbsErr3.043100e+11AvgRelAbsErr9.894753e-01
     AvgRelAbsErr 
Epsilon (1.000000e-13)
     For array 
c[], 9895936 errors were found.
-------------------------------------------------------------

which is odd as the FPU emulation is the same so maybe there's some memory access issues still left. (This is with my current development version but same result with QEMU 8.0.0 so at least not something I broke recently but don't know yet what causes it.)

Compiling stream.c with gcc 10.2.1 for Linux (with -mcpu=powerpc -O3 -DVERBOSE) and running it on QEMU sam460ex with Linux guest instead of AmigaOS I get:
-------------------------------------------------------------
STREAM version $Revision5.10 $
-------------------------------------------------------------
This system uses 8 bytes per array element.
-------------------------------------------------------------
Array 
size 10000000 (elements), Offset (elements)
Memory per array = 76.3 MiB (= 0.1 GiB).
Total memory required 228.9 MiB (= 0.2 GiB).
Each kernel will be executed 10 times.
 
The *besttime for each kernel (excluding the first iteration)
 
will be used to compute the reported bandwidth.
-------------------------------------------------------------
Your clock granularity/precision appears to be 2 microseconds.
Each test below will take on the order of 208608 microseconds.
   (= 
104304 clock ticks)
Increase the size of the arrays if this shows that
you are not getting at least 20 clock ticks per test
.
-------------------------------------------------------------
WARNING -- The above is only a rough guideline.
For 
best resultsplease be sure you know the
precision of your system timer
.
-------------------------------------------------------------
Function    
Best Rate MB/s  Avg time     Min time     Max time
Copy
:            2126.6     0.076052     0.075236     0.077315
Scale
:            775.6     0.208164     0.206299     0.212734
Add
:              950.8     0.256040     0.252422     0.261350
Triad
:            825.2     0.294674     0.290838     0.302348
-------------------------------------------------------------
Solution Validatesavg error less than 1.000000e-13 on all three arrays
Results Validation Verbose Results

    
Expected a(1), b(1), c(1): 1153300781250.000000 230660156250.000000 307546875000.000000 
    Observed a
(1), b(1), c(1): 1153300781250.000000 230660156250.000000 307546875000.000000 
    Rel Errors on a
bc:     0.000000e+00 0.000000e+00 0.000000e+00 
-------------------------------------------------------------

So the validation error only happens on AmigaOS with the binary from @sailor. Could it be some problem with gcc 6 and -O3? I don't have AmigaOS compiler set up now so can't try it but if somebody can compile it with gcc 10 or without -O3 and verify if that runs correctly on QEMU sam460ex that may help further to locate why this fails. But the same binary runs on real Sam460EX as confirmed above so the problem must be in QEMU but I have no idea how to debug it.


Edited by balaton on 2024/4/28 13:56:30
Edited by balaton on 2024/4/28 15:50:34
Edited by balaton on 2024/4/28 15:51:35
Edited by balaton on 2024/4/28 19:10:58
Go to top



TopTop
(1) 2 3 4 ... 28 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project