Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
20 user(s) are online (10 user(s) are browsing Forums)

Members: 1
Guests: 19

beworld, more...

Support us!

Headlines

 
  Register To Post  

« 1 ... 52 53 54 (55) 56 57 58 ... 75 »
Re: What the fastest possible x64 emulation way of OS4 today ?
Not too shy to talk
Not too shy to talk


See User information
@Maijestro

I think this is not a qemu problem.

You need to check the load monitor to see if something is eating up your resources. Usually an mds process related to Spotlight or other system related processes.
Maybe qemu is pointing to a core that is currently busy/used.

Check on a freshly booted system: reboot, start the monitor - see what happens or wait a while for all startup processes and startup programs to finish.
start Qemu.

Check a couple of times on a cleanly booted system - I know this may be silly advice for you.

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


See User information
@geennaam
That's not enough info to see whu it fails. At least the BBoot output would also be needed. Other than that the error tells you where in QEMU source it failed: qemu/hw/pci/pcie.c line 92 so you could try to find out what does that do why it might not work. Likely getting unexpected values from where it's called and from where it's called can be found from a back trace that you can get with gdb either running QEMU under gdb or enabling coredumps with ulimit then analyse it with gdb after the crash. I can't tell any more from that error alone.

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


See User information
Also apparently this problem of using graphics cards connected with a bridge was already solved in MoprhOS according to this thread:

https://morph.zone/modules/newbb_plus/ ... d=1215&forum=11&start=175

so that could help checking if the problem is with pass through, the bridge or AmigaOS. When you think you have a working setup with a card that MorphOS should support, preferably one that was tested in above thread (These are probably only some HD cards) then try with the MorphOS demo iso to see if that works which then mean it's probably something missing from AmigaOS that we might be able to patch up in BBoot or if it does not work then maybe it's somehting with the bridge or QEMU or your host setup that needs to be solved.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


See User information
@balatonQuote:
balaton wrote:@Maijestro
info irq and info jit are QEMU monitor commands that print statistics about how many interrupts or events during jit happened that could impact performance. You should do about the same thing once when it's fast and once when it's slow and after the same code has been run in the guest check the stats to see if there's a difference that could show where the slowness could come from.


Could you please give me an example how to include info irq and info jit under Qemu ? I would then test it with a good and bad session, I do not know how to use info irq and info jit together with Qemu.

In the meantime I did another benchmark with SDLBench under AmigaOs4.1, it shows the result of a good and bad session. Since I couldn't save the output as history because Qemu fails completely after the benchmark, I made a screenshot and packed both results side by side.

On the left the good Qemu session, on the right the bad Qemu session.

Resized Image

@smarkusg

Quote:
You need to check the load monitor to see if something is eating up your resources. Usually an mds process related to Spotlight or other system related processes.
Maybe qemu is pointing to a core that is currently busy/used.


I took this into account in my tests and the CPU host was always occupied with 5% CPU last when the tests took place.System-heavy processes like mdworker or spotlight were not active during the test. You can also see it in my video above.


Edited by Maijestro on 2023/7/25 9:59:25
Edited by Maijestro on 2023/7/25 10:07:58
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne A1222plus AmigaOs4.1 FE
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
@Maijestro
If in doubt read documentation: https://www.qemu.org/docs/master/system/monitor.html

Just type info jit or info irq in QEMU monitor. You can redirect the monitor to stdout with -monitor stdio in which case leave out -serial stdio or you can use -serial mon:stdio to multiplex both on the same window.

Your scren shot is not readable at all, it's two low resolution and your color scheme does not help either so can't somment on that.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


See User information
@balatonQuote:
balaton wrote:@Maijestro
Just type info jit or info irq in QEMU monitor. You can redirect the monitor to stdout with -monitor stdio in which case leave out -serial stdio or you can use -serial mon:stdio to multiplex both on the same window.


You need to switch the recording to HD playback then you can see and read it better

Thanks for the help, I'll run some tests later to see if I'm right with my theory.

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne A1222plus AmigaOs4.1 FE
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
@batalon

There was no bboot output. Just those two lines.

But I've upgraded ubuntu to 23.04. Installed the dependancies and rebuild qemu 8.1.2 rc0 again.

And guess what? Error gone at first and QEMU boots with bboot 0.4.

RX 560 shows an image on my monitor. Everything runs stable. With and without interrupt. With and without compositing.
Only spoiler is that the GUI is dead slow. But it works and that's a start

I've attached the RX 560 to AGP bus. So bus=pci.0
Interrupt line is 0x0B Pin A. Interrupt number is 27.

Unfortunately the "Assertion `next <= PCIE_CONFIG_SPACE_SIZE - 8' failed" error returns randomly after a restart of QEMU. So it looks related to missing reset of the RX 560 GPU.

Edit1: GPU doesn't work on pci.1. So that must be the shared interrupt bug in the RX driver.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Not too shy to talk
Not too shy to talk


See User information
@geennaam

The previous error you showed is what happens on a card that doesn't release everything properly on QEmu shutdown. I've found that the RX cards do that, especially if the emulator doesn't shut down properly using the power off option in AOS4. You have to reboot the host.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Not too shy to talk
Not too shy to talk


See User information
@balaton

I installed a Debian VM, installed the packages and the linker doesn't like the version of the library. I've tried Ubuntu, Arch, Debian - I can only guess (and it is a guess) that the version of GCC is too new?

I also had a quick go under AOS4 but that just throws makefile errors which I've got when I've tried to compile anything so far (something about invalid separator). I need to look at that independently to this.

skipping incompatible /usr/lib/gcc-cross/powerpc64-linux-gnu/12/libgcc.a when searching for -lgcc


Amiga x5040 ı 16GB ı RX580
GB-A1000 060@100,
A1200 PiStorm32-Lite CM4
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
@MartinW

The performance is slow on your RX cards as well?

I didn't apply the interrupt patch. So just a clean build of the QEMU master sources

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Not too shy to talk
Not too shy to talk


See User information
@geennaam

Yes, unusably slow but AFAIK Hans is potentially looking into the shared interrupt support so I'm guessing if that happens then it would help, if not fix it.

You also have the problem of having to reboot the host which if you think about it isn't unreasonable behaviour as a reset of the card either via reboot or shutdown would always happen on real hardware.

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


See User information
@MartinW

Quote:

Yes, unusably slow but AFAIK Hans is potentially looking into the shared interrupt support so I'm guessing if that happens then it would help, if not fix it.


I have my RX on the AGP bus. As far as I can tell it has its own interrupt.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Not too shy to talk
Not too shy to talk


See User information
That's not the entire issue though - there's a message lost in the wilds of this thread somewhere. The RX driver doesn't correctly ACK with a 1 or a 0 as it should do once it has serviced the interrupt. That may not be exactly correct, but something like that.

But yes, I saw the same behaviour with the RX cards.


Amiga x5040 ı 16GB ı RX580
GB-A1000 060@100,
A1200 PiStorm32-Lite CM4
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
@geennaam
Good to hear it works. Having BBoot output from where it works would still be good to at least know what settings work and what don't.
The problem with resetting the card is independent of AmigaOS or BBoot or any of my code so can't help with that but I guess this may have something to do with the VGA part of the card being used by something. You should make sure your BIOS does not try to use the card and no driver is loaded for it in Linux. There were some mentions of vga arbitration and some patches needed for ATI cards somewhere but I may be completely wrong about this so try to search for and check info on this. The same problem happens when someone passes through GPU for Windows guest so I think there's some info on that somewhere.

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


See User information
@MartinW
You'd need GNU make, maybe try gmake if make is a BSD make, I may be using some GNU extensions. For the library that's probably 64 bit but BBoot is 32 bit so needs corresponding libgcc. In makefile I have: powerpc64-linux-gnu-gcc -print-file-name=32 because in /usr/lib/gcc I have a libgcc.a for 64bit but there's a subdir called 32 with 32 bit versions of the same. If your distro packages it differently you may need to adjust it or it may have a different package for powerpc-linux-gnu-gcc instead of powerpc64 that contains the 32 bit version.

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


See User information
@geennaam
On pegasos2 ultimately everything uses the ISA IRQ 9 and PCI INT pins are handled within PCI bus emulation so they are also shared. The pci.1 and pci.0 are separate buses so they have different PCI bus emulation but I think they PCI interrupts are connected to vt8231 PINT inpits which is then uses the PCI interrupt handler of the PCI bus the VT8231 is connected to that is pci.1 even for devices on pci.0 which may or may not be a problem. I also don't fully understand how this works in QEMU and this may have problems. I had may patch originally track each interrupt source separately but testing by Martin found it made no difference regarding freeze so that maybe caused by something else.

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


See User information
@balaton

One thing to note is that I do not experience any freeze. And I don't have that patch applied. Maybe because I'm running on an Intel platform.

It's just slow.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


See User information
@balatonQuote:
balaton wrote:@Maijestro
If in doubt read documentation: https://www.qemu.org/docs/master/system/monitor.html

Just type info jit or info irq in QEMU monitor. You can redirect the monitor to stdout with -monitor stdio in which case leave out -serial stdio or you can use -serial mon:stdio to multiplex both on the same window.


I did the test with info jit and info irq at a good and bad session.

Info Jit bad session:

(gemuinfo jit
Accelerator settings
:
one-insn-per-tboff
Translation buffer state
:
gen code size
121540068
/1073724416
TB count
186886
IE aug target size
23 max
=2048 butes
Th aug host size
313 butes 
(expansion ratio13.2)
cross page TB count 0 (0%)
directjump count
104199 
(55%) (2 jumps=87643 46%)
TH hash buckets
99012
/131072 (75.54head buckets used)
TB hash occupancy
34.17
avg chain occHistogram: (o,10Irdà rte rûärturdar
turtulE90
,1001%
TB hash avg chain
1.019 buckets
Histogram11rdêrûurâu13

Statistics
:
TB flush count
0
TB invalidate count 2775
TLB full flushes 0
TLB partial flushes 505722
TLB elided flushes 5143430
[TCG profiler not compiled]
(
qemu)


info irq bad session

(gemuinfo irq
IRQ statistics 
for 7447_01.1-powerpc-cpu:
24844
4
5081
7
37
8
3044952
10
70489
73
27
IRO statistics 
for isa-18259:
012
1
78
2
5556
9
2196
12
2096
14
2048
15
279 
(qemu)


good session info jit:

(gemuinfo jit
Accelerator settings
:
one-insn-per-tboff
Translation buffer state
:
gen code size
122601716
/1073724416
TB count
188792
TB avg target size
23 max
=2048 butes
TB avg host size
311 bytes 
(expansion ratio13.1)
cross page TB count 0 (0%)
directjump count
105220 
(55%) (2 jumps=88483 467)
TB hash buckets
99418
/131072 (75.85 head buckets used)
TB hash occupancy
34.45
avg chain occHistogram: (o,10Irdà rte rûärturdar
turtulE90
,1001%
TB hash aug chain
1.019 buckets
Histogram11 dêrûurâul3

Statistics
:
TB Flush count    0
TB invalidate count 3074
TLB full flushes
.  0
TLB partial flushes 491380
TLB elided flushes 5042828
[TCG profiler not compiled]
(
qemu)


good session info irq:

(gemuinfo ira
IRQ statistics 
for 7447_01.1-powerpc-cpu:
24850
4
4515
7
41
8
2184883
10
29055
73
30
IRO statistics 
for isa-18259:
011
1
70
2
5270
9
1503
12
3216
14
2032
15
144 
(qemu)


The value of irq 8 and 10 looks suspicious, because there are big differences here. But I don't know, that's just a guess. At least the numbers show that it is different, shouldn't it always be the same?


Edited by Maijestro on 2023/7/25 18:35:03
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne A1222plus AmigaOs4.1 FE
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
@Maijestro
Quote:
At least the numbers show that it is different, shouldn't it always be the same?

It should be about the same if the same thing has been run in the guest when you collect these statistics so if you always do the same and get the stats at the same point then difference shows something if they are from runs where different things happened since starting QEMU then they don't show anything.

PPC interrupt 8 is syscall when guest executes sc instruction which is done when something is calling AmigaOS services so maybe something is running in guest that does more stuff sometimes? Is there some task manager where you can check what task is using CPU time and compare that?

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


See User information
@balaton
Quote:
PPC interrupt 8 is syscall when guest executes sc instruction which is done when something is calling AmigaOS services so maybe something is running in guest that does more stuff sometimes?
AmigaOS doesn't use sc, nearly the whole OS is running in user mode.
(Of course not 100% of it, a few things need supervisor mode in AmigaOS as well, like changing MMU tables or anything else requiring supervisor mode, or even hypervisor mode on 64 bit/POWER CPUs, for some special PowerPC instructions, but that are very rare cases).

Go to top

  Register To Post
« 1 ... 52 53 54 (55) 56 57 58 ... 75 »

 




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




Powered by XOOPS 2.0 © 2001-2024 The XOOPS Project