WinUAE 4.10.0 — P96Speed issues in PAL Hires mode

[Brett Eden]

When running P96Speed in PAL Hires mode (AGA), it runs fine until it reaches the MoveWindow() test. Instead of running the test for the default 13s as it does with other tests, it continues infinitely.

If 32bit Chip is enabled, the same thing happens only it makes it one test further to SizeWindow(), which it runs infinitely.

These behaviours are not exhibited when running P96Speed in RTG modes.

[Toni Wilen]

Sounds like Amiga software side problem (memory leak?)

[Brett Eden]

Originally Posted by Toni Wilen

Sounds like Amiga software side problem (memory leak?)

WinFellow was able to complete all tests in PAL Hires/68030/16 colours. I downgraded WinUAE to ECS and it was still getting stuck at MoveWindow(). I disabled JIT and WinUAE was able to complete all tests in PAL Hires/68030/16 colours.

HOWEVER…MoveWindow() and SizeWindow() took longer than their allotted time. All subsequent tests ran for as long as they were supposed to.

[rutra80]

SysSpeed doesn't have that problem, but it doesn't disable multitasking. P96Speed doesn't run infinitely, just much longer, I guess that with disabled multitasking it has problems with counting time - it does it either only when intuition is redrawing, or only when it doesn't...

[Toni Wilen]

JIT probably confuses its timing calculations. JIT can make some operations to look like they executed in zero cycles.

[rutra80]

It's not right even in A1200 cycle exact mode with Chip RAM only (that 2 intuition tests always take longer than the set time).

[Toni Wilen]

Works for me (both JIT and 68020 CE + standard KS3.1).

Probable reason is different KS version, system patches etc.

[rutra80]

Brett what KS were you testing on? I was testing on heavily modified 3.X and vanilla 3.2.

[rutra80]

Toni I've just checked CE vanilla A1200 booted from floppy WB 3.1 and SizeWindow() takes 2-4 seconds when set to run for 1 second (with tendency to take longer with 256 colours than with 4).

[Toni Wilen]

I also get unstable results when using real A1200 (without expansions). For example 4s time but 7s total real world time. Other tests work correctly as expected.

I think reason is simple: these tests are disabling interrupts temporarily (intuition/layers operations possibly when window is created/resized?) and because program uses vblank timer to count test length which will become unreliable if interrupts are disabled long enough.

It should have used CIA timers.

[rutra80]

Great so this case is explained now. Thank you.

[hexaae]

@Toni
A decent benchmark suitable for WinUAE? AmigaMARK?

[Toni Wilen]

Originally Posted by rutra80

Great so this case is explained now. Thank you.

Yet another thing that no one noticed before, probably because it was mainly used as RTG benchmark and most users just run all benchmarks without timing how long it exactly took.

JIT messing up timing enough to cause it to work even worse is normal

Originally Posted by hexaae

@Toni
A decent benchmark suitable for WinUAE? AmigaMARK?

I don't know. P96Speed is fine, except those 2 tests because it made bad timer choice. At least it does not have the biggest problem: test run taking almost no time with JIT active.

Main requirements are: timing should use CIA timers, test length should adjust to CPU speed. It is "bad" test if it takes less than few seconds with JIT.

[hexaae]

AmigaMARK
Violet: 4.10
Red: old 4.3.0