Bug with AMOS 3D in WinUAE 2.3.2+

[Mequa]

I have noticed a bug in WinUAE when running AMOS 3D programs using Fastest Possible CPU + JIT (with Vsync disabled), which involves some graphical corruption.

From my testing, this bug was introduced in WinUAE 2.3.2 (2011.06.02).
WinUAE 2.3.1 (2011.02.26) and earlier do not have this bug.

I enclose a zipped ADF test which reproduces this bug, as well as WinUAE logs from version 2.3.3 and the configuration used, as well as a screenshot.

I can confirm that this bug is still current in the latest WinUAE 2.4.0 beta 20 (2012.03.04).
I am hoping it can be fixed in final 2.4.0 release. (I want to create an updated AMOS for Windows emulation pack.)

Mequa


P.S. Enabling the new Vsync fixes this problem, however performance decreases drastically with this example and other AMOS 3D programs. Perhaps performance with the new Vsync can also be investigated.

[Toni Wilen]

JIT and fastest possible timing can and will change between versions. Not a bug, sorry. (Does immediate blitter fix it?)

To test 2.4 vsync:

Use sysinfo (yes, it is quite useless normally but works fine in this test) or some other speed test program and compare speed results using 2 following setups:
- fullscreen + low latency vsync vs no vsync, fastest possible (no JIT)
- fullscreen + low latency vsync vs no vsync, and JIT.

First make working copy of your configuration and before each test, restart winuae, load same configuration and change vsync/buffer option only. Do not touch anything else.

Use standard 60Hz refresh rate (It is guaranteed to work, other refresh rates may do something unexpected..) Try all buffering options. Save logs (winuaelog.txt only) from all vsync tests.

Thanks.

In my tests I get about 10-15% speed loss in JIT modes when using vsync. It is not possible to have full speed in vsync modes.

[Mequa]

Immediate/original blitter doesn't seem to make much difference. The above uses A4000/040 quickstart options with immediate blitter enabled.

The above glitches also occur with fastest possible CPU without JIT, but to a much lesser extent. Downgrading to WinUAE 2.3.2 or earlier completely removes the above glitches.

Correction to above: New Vsync reduces this glitch, but it still occurs.

P.S. Speed loss in the above program (and other AMOS 3D ones) is MUCH more than 15% with new Vsync. It seems to run around 30% of the non-vsync speed.

[Toni Wilen]

In my opinion drastically is much much more than 30%. Hard facts and numbers only accepted

You can test which 2.3.3 beta introduced the JIT issue if you are interested.. But I am quite sure it is simply working as designed.

[Mequa]

I think the glitch was introduced in one of the 2.3.2 betas. Where can I download them to test, since I narrowed it to that?

[Toni Wilen]

Check old beta threads. All betas since 2.1 are still available.

[Mequa]

Never mind, I found all 8 of them here: http://eab.abime.net/showthread.php?t=58121

The glitch was introduced in 2.3.2 beta 4. All betas after that have the glitch, 2.3.2 beta 3 and earlier work fine.

I'm wondering if it's this modification in beta 4 which caused the issue:
"Stop the cpu and wait until blitter has finished if any blitter register is accessed while blitter is busy and cpu mode is fastest possible".
As stated, setting immediate blitter does not fix the glitch, so this appears to also affect immediate blitter.
(I know AMOS 3D makes heavy use of both the CPU and blitter, it requires fastest possible CPU + JIT + immediate blitter + disabled Vsync for best performance.)

If it is this which causes issues, could it possibly be moved to config options?
(Perhaps a "CPU wait for blitter" checkbox, on by default?)

[Toni Wilen]

Create minimal archive that includes required AMOS stuff (no WB files) and I'll take a closer look.

[Mequa]

What is required in the archive? I included an ADF which boots into a CPU-heavy AMOS 3D demo which demonstrates the glitch (in AMOS3Dbugtest.zip), would you like its files in an archive?

I added an archive below containing the same demo (recompiled to include amos.library), this one should work from the folder when extracted. Its AMOS source is also included.

Other than the 3DOBJECTS directory and compiled demo binary itself, the only required file included is c3d.lib (for compiled AMOS 3D programs).

[Toni Wilen]

I missed the included adf, I wasn't expected it to be included already

btw, does older versions work with immediate blitter? (It would be really bad if it requires disabled immediate blitter..)

[Mequa]

Yes, immediate blitter has always worked well with AMOS including 3D extension.

[Toni Wilen]

It was a bug in that 2.3.2 fastest possible CPU blitter update and quite stupid bug as usual..

This bug was triggered by amos bug, it calls graphics.library OwnBlitter() and then writes to some blitter registers, without waiting for blitter. OwnBlitter() does not wait, it is very clearly said in documentation.

btw, amos blitter line draw code is horribly ineffective and other code isn't much better.. (Unfortunately I had to disassemble it to find this problem...)

[Mequa]

Is this bug and inefficient line drawing in AMOS itself or AMOS 3D extension (c3d.lib)?
I knew the 3D engine was pretty crap.

Thanks for investigating!

[Toni Wilen]

Originally Posted by Mequa

Is this bug and inefficient line drawing in AMOS itself or AMOS 3D extension (c3d.lib)?
I knew the 3D engine was pretty crap.

Thanks for investigating!

I don't know, I only looked at disassembly, I have no idea where the code came from

btw, do the vsync test, please. I need to know if some simple test (like sysinfo, make sure to run each test at least 3 times and ignore possible strange results that only appear once) shows the same slowdown or if it only happens when something more complex is happening.

[Toni Wilen]

Does http://www.winuae.net/files/b/winuae.zip run any faster in fastest possible + low latency vsync modes?

[Mequa]

I couldn't see much of a speed increase - it's still quite a bit slower than half the speed without the new vsync (my game Operation Gigabyte has its own FPS counter, the game's reported difference is 50FPS without vsync to 17FPS with vsync, still running at 50FPS internally according to WinUAE) - but the graphical glitches are gone!

[Toni Wilen]

Originally Posted by Mequa

I couldn't see much of a speed increase - it's still quite a bit slower than half the speed without the new vsync (my game Operation Gigabyte has its own FPS counter, the game's reported difference is 50FPS without vsync to 17FPS with vsync, still running at 50FPS internally according to WinUAE) - but the graphical glitches are gone!

Ok, attach some program that includes FPS counter (much easier to compare than watching animation speed), thanks.

It appears this requires some specific condition because I can't see any major JIT + vsync slowdowns and I have tested it on 3 different PCs, which includes one crappy laptop that can't even run cycle-exact A500 full speed..

[Mequa]

I attach a file archive of the same demo with an FPS counter added.
I get around 17 FPS without new Vsync and 7 FPS with new Vsync (both fastest possible CPU + JIT + immediate blitter).
New Vsync is even slower when using included AROS ROM (around 6 FPS).

Source included (in both .AMOS and Ascii format, for anyone interested).

Zipped ADF version also included (autobooting, also works with AROS ROM).

[Toni Wilen]

Thanks, I can finally confirm it.

JIT gets slow, fastest possible without JIT works normally.

I am not sure what happens but it seems there is some strange JIT trick in custom emulation code which does not make sense. JIT slows down even in non-vsync mode (exact same slow speed!) if this weird code is disabled...

EDIT: It finally makes sense, I think this slowdown can be fixed!

[Toni Wilen]

http://www.winuae.net/files/b/winuae.zip should finally fix low latency vsync + fastest possible (with or without JIT) slowdown.

Beta coming tomorrow if no new issues found. This update changed code that I haven't really touched (or even fully understood until now), it may cause surprises..

One nice side-effect is non-JIT fastest possible CPU being now faster (possibly much faster) than previously.

EDIT: funnily enough both JIT and non-JIT fastest possible modes + immediate blitter are faster than previous JIT mode in older versions, even in non-vsync mode!