Windows 10 FCU issues with WinUAE

[hexaae]

After further testing (almost all day long)...

To me it looks like some WinUAE issue with Nvidia driver + Win 10 FCU when Picasso 96 emu is running for Workbench screen: random instability and that annoying random audio slowdown after some time.
I've experienced also WinUAE.exe crashes like these, clearly pointing to Nvidia drivers:

Firma del problema
Nome evento problema: APPCRASH
Nome applicazione: winuae360b16.exe
Versione applicazione: 3.6.0.0
Timestamp applicazione: 5a4a6c5b
Nome modulo con errori: nvwgf2um.dll
Versione modulo con errori: 23.21.13.8871
Timestamp modulo con errori: 5a344b55
Codice eccezione: c0000005
Offset eccezione: 001aa29c
Versione SO: 10.0.16299.2.0.0.768.101
ID impostazioni locali: 1040
Informazioni aggiuntive 1: 2beb
Ulteriori informazioni 2: 2beba6fb4680d73a8c78ca7c24ccdb46
Ulteriori informazioni 3: 3ad0
Ulteriori informazioni 4: 3ad0e9f4486e91d86927e4a71227ee49

Ulteriori informazioni sul problema
ID bucket: bcb74d3b06a9013945bb8d1e7b168475 (1566000457494987893)


Rock stable only when I use WineD3D DX9->OGL wrapper, even though it's not a perfect workaround since network access (bsdsocket.library emu) causes audio stuttering with IBrowse, but at least games etc. run well and Workbench in Picasso mode is perfectly stable in this case.
I have no special issues with PC games from Steam/Origin/UPlay or other emulators so I can exclude a generic system instability due to bad video drivers for example...

Unfortunately as far as I can understand there are (?) very few Amiga users running a full Workbench env in Picasso emu with WinUAE, and playing also WHDLoad games, so I'm the only one reporting these kind of issues...

My WinUAE cfg: https://drive.google.com/file/d/16kM...ew?usp=sharing

[Toni Wilen]

There are lots of users that use Picasso96. (All emulator WB replacements use it, Amiga Forever uses it and most of them include games that use native modes or whdload). There would have been dozens of these kinds of reports if it is global problem.

I can't see how it can be winuae problem if it affects directdraw. It is very basic, dd surface is filled with display data, then it is told to blit it to display. (D3D9 on the other hand is much more complex)

At least I have never seen this and I have used Windows 10 preview builds for long time, I should have seen it long time before official release.

Does CPU% on screen display change when it slows down? Describe exactly what you need to do to duplicate it? Does it happen if you try unmodified WB 3.1 or 3.9 config? Does it happen if you don't use JIT? If you don't change JIT mode when running whdload game? (If you do it know). What if windowed mode display size is exact same as RTG mode size? (Less display changes when mode changes)

There has to be some detail that makes some difference.

[hexaae]

My system:
1080p 75Hz with G-Sync display

Emu settings:
WB screen = full-window borderless (60Hz says Workbench...)
Native = full-screen (thanks to g-sync games look silky smooth in 50/60Hz)

Can it be a specific refresh problem for those with non standard 60/120Hz displays? Because I've noticed that setting WB screen = full-window borderless + low latency vsync (becomes 75Hz I guess), it alleviates the "zombie" symptom (= Delitracker music doesn't sound trashed anymore even though WB is still a bit slow)...

[Toni Wilen]

I also have g-sync display (but it is ultrawide 100hz) and 1080Ti so different nvidia generation too.

Does same happen with g-sync disabled in nvidia control panel? It probably makes no difference but the only way is to reduce variables until something useful is found. Remove everything unneeded from your config, use as basic config as possible, make sure CPU idle is off and so on.

I can't duplicate your frontier issue either so it unfortunately seems to be caused by something unique in your system. Perhaps some weird antivirus/security software conflict?

[hexaae]

Originally Posted by Toni Wilen

I can't duplicate your frontier issue either so it unfortunately seems to be caused by something unique in your system. Perhaps some weird antivirus/security software conflict?

No, it's a clean Win 10 FCU system with just Defender... It is something with JIT on this machine... Also the crash you reported with my Startup-Sequence (without DH1 and no MODS: assigned), I've been able to reproduce it only with JIT on and dismissing assign requesters quickly... If I wait a few secs after before clicking Cancel to skip missing MODS: drive it worked fine even with JIT on.
Looks like JIT is too fast/trashes some memory...

[Toni Wilen]

Originally Posted by hexaae

No, it's a clean Win 10 FCU system with just Defender... It is something with JIT on this machine... Also the crash you reported with my Startup-Sequence (without DH1 and no MODS: assigned), I've been able to reproduce it only with JIT on and dismissing assign requesters quickly... If I wait a few secs after before clicking Cancel to skip missing MODS: drive it worked fine even with JIT on.
Looks like JIT is too fast/trashes some memory...

That does not guarantee anything. I have seen system patches that crash or corrupt memory if CPU is too fast (don't have proper locks and assumes something that should can happen, even in real world but is normally very rare).

You need to reduce your config/WB and remove programs from startup-sequence one by one and only when you have minimal possible setup that still crashes: it can be debugged without wasting huge amounts of time.

[hexaae]

Ok, will try that too...
G-Sync off = nothing changes

In the meanwhile another clue in the weird video refresh direction: when the system is slowed down and so is audio (I usually play something with Delitracker to notice this, since visually it's harder to spot) and run the old Amiga command "C:p96refresh 60" from shell, audio gets suddenly fixed and plays back again at correct speed...

EDIT:
I've also noticed WinUAE UI shows strange (ghosted) fps after I use "p96refresh 60" jumping from 59.280407 to 98.280407...

EDIT2:
Emu speed seem to go crazy while I hear "trashed audio":

After boot the on-screen display say "- 100 59 ..." and everything is OK.
When I start to hear corrupt audio and see sluggish WB it is something like the sshot above "-19 169 59 ..."

[Toni Wilen]

Another random guess: what if you force winuae.exe to only use single core of CPU? (task manager, details, right click winuae.exe, set affinity, untick all except one checkbox)

[hexaae]

Still audio/video slowdown after a while when I'm on the WB screen in Picasso mode 60Hz, after I switch WB RTG screen <-> native (games) for 5-10 mins.
When it starts doing so and I switch to Host>Display>RTG: low latency vsync (remember my Windows res is 75Hz), at least music goes back to correct speed, even though whole emu speed is a bit degraded...

I've already tried a standard WB3.9 clean install (+ Picasso monitor in Amiga DEVS: ) and I was still able to reproduce the slowdown syndrome after playing some games...

Can you send me the Amiga p96 libs + monitor you use in your WB environment? ( https://dropfile.to/ or https://sendspace.com ), these are mine:

[8.HDUAE:Libs] ver Picasso96API.library
Picasso96API.library 2.300 (19-Settembre-99)
©1996-1999 A.Kneer & T.Abt
[8.HDUAE:Libs] ver Picasso96/uaegfx.card
UAE Graphics Card 0.9 (24-Febbraio-98)
[8.HDUAE:Libs] ver HDUAE:Devs/Monitors/uaegfx
Picasso96 40.42 (27-Maggio-99)
©1996-98 Tobias Abt & Alexander Kneer

[hexaae]

It's definitely something related to Windows 10 FCU + Nvidia drivers:
since I started using "on-screen display" option I've noticed whenever the apparent slowdown starts, the counters (normally saying "- 100 60 ...." right after WB boot) start reporting something like "- 175 35 ...", or "- 200 29 ..." etc. Notice in particular that ~35 is approximately 75Hz/2...



In short something weird happens randomly after a while when I switch between native 50Hz WHDLoad games (using fullscreen exclusive), and WB 60Hz (full borderless, p96 emu). The emulator FPS and internal timing (or the video driver makes it) go crazy desyncing everything.
I can make a short YT video if needed, since I can reproduce it everytime...

P.S.
Notice in my WHDLoad games I use to change WinUAE settings on a per-game basis (e.g. uae-configuration cachesize 0 cpu_multiplier 8), and when quitting back to WB, my S:WHDLoad_cleanup script run this command: "C:uae-configuration cachesize 8192 cycle_exact false immediate_blits true cpu_cycle_exact false cpu_speed max" to restore max speed in the Workbench...

P.P.S.
Tested and reproduced also with non-WHDLoad games, just to be sure wasn't something messed up by WHDLoad or my S:WHDLoad_cleanup and S:WHDLoad_start scripts

[hexaae]

I'll try with minimal WB3.1 and 3.9 standard install, with just p96 as extra... Let's see if this weird timing/video refresh issue is really always reproducible on my system with 75Hz display.

[Toni Wilen]

uaegfx does not contain anything card specific and uaegfx.card is emulation internal, it is not used anymore.

Have you tried checking or setting custom settings for winuae.exe using nvidia control panel? (Like forcing max power, disable vsync etc) If it makes any difference.

[hexaae]

Originally Posted by Toni Wilen

uaegfx does not contain anything card specific and uaegfx.card is emulation internal, it is not used anymore.

So how am I supposed to configure WB to correctly use RTG emu (WinUAE: RTGBoard>UAE Zorro III)?

I usually copied the following files in place, and enabled UAE Zorro III RTG emu:
[8.HDUAE:Libs] ver Picasso96API.library
Picasso96API.library 2.300 (19-Settembre-99)
©1996-1999 A.Kneer & T.Abt

[8.HDUAE:Libs] ver Picasso96/uaegfx.card
UAE Graphics Card 0.9 (24-Febbraio-98)

[8.HDUAE:Libs] ver HDUAE:Devs/Monitors/uaegfx
Picasso96 40.42 (27-Maggio-99)
©1996-98 Tobias Abt & Alexander Kneer

If I remove from my Amiga DEVS:Monitors/uaegfx or LIBS:Picasso96/uaegfx.card I see no available UAE screenmodes available from WB... Is this config correct?

Have you tried checking or setting custom settings for winuae.exe using nvidia control panel? (Like forcing max power, disable vsync etc) If it makes any difference.

Yep, I'm constantly experimenting with NVidiaProfileInspector trying to customize also settings not usually available with official Nvidia control panel... Tried to disable g-sync, forced max Frame rate limiter to 60, disabled Battery Boost (to lower fps to 30 in case battery is in use), etc. but nothing changes: after 10 min I switch from 50Hz games <-> my UAE Zorro III Picasso emulated WB, WinUAE timings seem go crazy...

[hexaae]

Originally Posted by hexaae

I'll try with minimal WB3.1 and 3.9 standard install, with just p96 as extra... Let's see if this weird timing/video refresh issue is really always reproducible on my system with 75Hz display.

In the meanwhile...
Standard WB3.1 fresh installation on a FFS hdfile. NOTHING else modified.
Just added:

[8.HDUAE:Libs] ver LIBS:Picasso96API.library
Picasso96API.library 2.300 (19-Settembre-99)
©1996-1999 A.Kneer & T.Abt

[8.HDUAE:Libs] ver LIBS:Picasso96/uaegfx.card
UAE Graphics Card 0.9 (24-Febbraio-98)

[8.HDUAE:Libs] ver SYS:Devs/Monitors/uaegfx
Picasso96 40.42 (27-Maggio-99)
©1996-98 Tobias Abt & Alexander Kneer

and set WinUAE RTG Board: UAE Zorro III, vram size 128MB, Match host and RTG color depth, Scale if smaller..., Hardware vertical blank interrupt, Refresh rate: chipset, Buffer mode: double, Aspect ratio: disabled.
Tried also to change them (triple buffer, refresh default, no hardware vertical blank interrupt etc.) but nothing helped.

Host>Display:



WinUAE internal timings/fps go crazy after I switch 50Hz Pal screen/WB screen for 5-10 mins...

[hexaae]

Unfortunately for me since Windows 10 x64 FCU (now 16299.192), Nvidia driver 38x.xxx WHQL, it's become impossible to enjoy a decent WB + gfx card emulation without fluctuating FPS issues impacting on emulation sync and timing (with consequent random visible slowdowns and disturbed audio).

Playing with RTG Board>Refresh rate: Chipset, Default, 60, 75 when timings go crazy seems to work for a while at least, until it restarts fluctuating...

The issue is reproducible for me after I switch RTG WB screen/games 50Hz back and forth for a while.

[hexaae]

I see FPS and audio chip usage from on-screen display suddenly changes for a moment in-between when switching screens Amiga WB/Native 50Hz... It's not a direct and steady switch from 60 (WB) to 50. I think this limbo when there's the screen switch, randomly, is the root cause of problems desyncing DX video drivers <-> WinUAE timings that go crazy and become unstable and fluctuating.

As said above, playing with RTG Board>Refresh rate sometimes help to recover a stable 60 or 50 resolution, depending whether you're on WB or native screen mode, so it's clearly a problem between video drivers and WinUAE (any version since 2.4.1, the oldest I've tested, up to 3.6.0 beta...). This is also confirmed by the fact that using WineD3D for Windows as a DX <-> OpenGL wrapper solves these fluctuations, timings are always kept correctly and screen res are stable at 60 or 50 even after long tests. Hard to report this WinUAE issue to Nvidia, and harder they'll ever fix it as they do for mainstream games

Windows 10 x64 FCU 16299.192, Nvidia driver 390.65 WHQL (WDDM 2.3), GeForce Experience 3.11.0.73

P.S.
It happens always in DX9/DX11/DirectDraw, not in OGL mode (using WineD3D for Windows OGL wrapper, which is not a perfect workaround though since WinUEA's bsdsocket.library emulation network access causes strange audio lags for example loading web pages with IBrowse/AWeb, not present in native DX mode without wrapper)

[Toni Wilen]

Originally Posted by hexaae

I see FPS and audio chip usage from on-screen display suddenly changes for a moment when switching screens between Amiga WB/Native 50Hz... It's not a direct and steady switch from 60 (WB) to 50. I think this, randomly, causes problems desyncing DX video drivers <-> WinUAE timings that go crazy.

That is normal. Switch usually is not fast enough and can cause temporary glitch. (few seconds max)

[hexaae]

Originally Posted by Toni Wilen

That is normal. Switch usually is not fast enough and can cause temporary glitch. (few seconds max)

Is there some secret launch parameter I can experiment with? I'm almost sure that if there was no fluctuation there, video drivers and WinUAE timings wouldn't go crazy.
This bug indeed is unreproducible keeping AGA WB and launching native screen games. It happens only using RTG Zorro III + p96emu WB, when switching to native screen modes and returning back to WB (and is random, you have to try for 5-10 mins).

Why isn't reproducible with WineD3D for Windows putting d3d9.dll, wined3d.dll and libwine.dll in the same dir of WinUAE.exe? It should be even slower theoretically...

If switch can't be fast enough, maybe a chipset emulation pause up to new screen full opening could solve this issue?

[Toni Wilen]

Does it also happen with standard WB 3.1 + RTG if you only use screen switching shortcut (amiga+m/n) to continuously switch between some native mode application (like sysinfo, not game) and RTG WB?

(This is what is required, find as simple as possible test case)

[hexaae]

Yes Toni.
Just tried again as you say, just switching screens (AMIGA+M/N) between WB3.1 + RTG Zorro III with p96emu and OctamedSoundStudio (own screen PAL 50HZ 640 256).
When I switch between screens I see the on-screen display counters bouncing from stable "- 100 60 ...." (WB) to weird fluctuating numbers like "-10 168 37 ..." that finally get stable around these values "- 208 29 ..." (but may vary):



At this point audio is distorted and emulation sluggish.
Rebooting WB won't change this state: it proves it's something in WinUAE/Nvidia drivers. I have to fully quit WinUAE.
Already tried with G-Sync off.
Not reproducible when using WineD3D for Windows OGL wrapper (= even though I can still see fps etc. fluctuating when switching screens, the final restored values are always correct: "- 100 60 ..." for WB and "- 100 50 ..." for native modes).

All these tests suggest the bug has really nothing to do with custom WB setups. It looks like a video driver VS WinUAE desync issue. Tried also "Disable fullscreen optimization" to disable new Windows 10 FCU screen handling but doesn't change a thing. Tried also to set Windows battery save mode to full power state (not "Balanced" as default for laptops) with 100% CPU usage always.

Attached my cfg (before you ask because it's from 2.5.2... I already tried a brand new 3.6.0 config from scratch with the same settings and nothing changed).
And here are the only P96 files I've added to standard WB3.1 fresh new installation: https://dropfile.to/AWDC8XS
Tested with WinUAE 2.4.1 up to 3.6.0b17

P.S.
I have no issues with games like Batman Arkham Knight, The Witcher 3, etc. All games I have (DX9, 10, 11, 12) run really fine without FPS drops.

My full HW config is:
NVidia 390.65 WHQL (with GeForce Experience installed) + Windows 10 x64 FCU 16299.192
Gaming laptop ASUS G751JY [Intel HM87 Lynx Point, i7-4860HQ, 24GB DDR3L 2133MHz, GTX 980M (GM204M, 10DE-1617/1043-22DA Rev A1, vBIOS v84.04.48.00.39), 4GB GDDR5 (Micron)], Windows 10 x64, display: G-Sync LG Philips LP173WF4-SPD1 (LGD046C) 17", desktop res: 1080p 75Hz, Audio: Realtek, Competition Pro USB arcade joystick SpeedLink SL-6603-SPORTS-EU, XBox One Bluetooth controller, Microsoft PN7-00004 Bluetooth mouse