Question about new beam racing VSync

[hexaae]

Correct. To force a custom desktop resolution you have to define a new screen mode with CRU (or Nvidia CP) and set it as "native" from NVidia CP.

[Toni Wilen]

My g-sync monitor (Acer X34) supported 50Hz automatically. Almost all resolutions support 50 to 100hz except 1024x768 and smaller.

Originally Posted by hexaae

Same for WinUAE in Fullscreen at 50 or 60Hz/fps... even though since 3.4.0 the new chipset/cpu logic works much worse on my PC than before (up to 3.4.0 I couldn't hear crackles and small random fps drops as I can see now with WinUAE 4.0.0+)

Stop complaining about this in every thread! It is getting annoying. One thread is enough. (or buy a better PC)

[Toni Wilen]

http://www.winuae.net/files/b/winuae.7z has (still experimental) 2x+ variable sync refresh rate mode.

Enable: tick "VRR" tick box in top of display panel (This "detaches" selected refresh rate from chipset refresh rate), select at least 100Hz (or 120Hz if NTSC) refresh rate or higher. Make sure lagless vsync number of slices is 2 or more.

Not very useful because it will tear strangely but at least it should work with >=100Hz modes. (Note that if monitor max is exactly 2x50=100 or 2x60=120, you should reduce chipset panel refresh rate value by 1 to keep refresh rate under monitor max)

[DamienD]

Originally Posted by Toni Wilen

Stop complaining about this in every thread! It is getting annoying. One thread is enough. (or buy a better PC)

You should really just ignore his bug reports as he never tries anything you suggest; painful to read let alone try to support...

[Toni Wilen]

Not going to do that (at least not yet) because this is the most difficult thing to debug and it can get really random and difficult to find out if changed config did change something or if it was just bad luck.. But I want to keep it in that other thread only.

And this is the end of this topic in this thread.

[DamienD]

Of course you're not. You love a challenge, have the tools to investigate / analyse and are a helpful person

[hexaae]

Sorry for complaints.

Originally Posted by DamienD

You should really just ignore his bug reports as he never tries anything you suggest; painful to read let alone try to support...

That's not true. I always follow Toni's steps… the problem is that these kind of bugs are not always mathematically reproducible. It's not always do A+B+C bingo!
In particular this one might involve: G-Sync weird issues (see NVidia forums, there are a lot of complaints since Windows 10 1709...), Realtek Audio Drivers + Maxx Audio that (as explained by Toni) could steal some D3D11 objects randomly, Windows 10 task scheduler and power saving strange bugs with some drivers…
When you test half day something and it seems to work, then in the evening you try again and you reproduce it again doing nothing different (!) it's hard for betatesters too…
Win 10 has become a very complex OS with advanced power saving tricks, new bugs at every build , GameMode etc. and other automated hacks you have very little control of, and around MS also Nvidia (+ GeForce + Ansel + VR…) added recently lots of bugs in its drivers (e.g. g-sync in window mode is broken since jan 2018 if I remember well, random FPS drops with some games).... All these can interfere with a clean betatesting of such a complex emulation.

I'll do more testing isolating all variables (DX9, DX11, drivers, etc.)

[Torkio]

Originally Posted by Toni Wilen

http://www.winuae.net/files/b/winuae.7z has (still experimental) 2x+ variable sync refresh rate mode.

Enable: tick "VRR" tick box in top of display panel (This "detaches" selected refresh rate from chipset refresh rate), select at least 100Hz (or 120Hz if NTSC) refresh rate or higher. Make sure lagless vsync number of slices is 2 or more.

Not very useful because it will tear strangely but at least it should work with >=100Hz modes. (Note that if monitor max is exactly 2x50=100 or 2x60=120, you should reduce chipset panel refresh rate value by 1 to keep refresh rate under monitor max)

Thanks, much appreciated. I’ll test as soon as possible (tomorrow)
Hope to give you back some feedback in proper thread and, hopefully, in the proper way!
Btw you said to try ticking also the BFI in miscellaneous? Or is it to early to test that too?
Thanks again

[DamienD]

Originally Posted by hexaae

Sorry for complaints.

That's not true. I always follow Toni's steps… the problem is that these kind of bugs are not always mathematically reproducible. It's not always do A+B+C bingo!
In particular this one might involve: G-Sync weird issues (see NVidia forums, there are a lot of complaints since Windows 10 1709...), Realtek Audio Drivers + Maxx Audio that (as explained by Toni) could steal some D3D11 objects randomly, Windows 10 task scheduler and power saving strange bugs with some drivers…
When you test half day something and it seems to work, then in the evening you try again and you reproduce it again doing nothing different (!) it's hard for betatesters too…
Win 10 has become a very complex OS with advanced power saving tricks, new bugs at every build , GameMode etc. and other automated hacks you have very little control of, and around MS also Nvidia (+ GeForce + Ansel + VR…) added recently lots of bugs in its drivers (e.g. g-sync in window mode is broken since jan 2018 if I remember well, random FPS drops with some games).... All these can interfere with a clean betatesting of such a complex emulation.

I'll do more testing isolating all variables (DX9, DX11, drivers, etc.)

You don't think I know about intermittent / random IT issues; look at my job title...

You may know more about NG Amiga OSs' than me but I guarantee you I know more about computers, systems, infrastructure etc. on a corporate level...

Anyway, the point here is that there are at least 100 other people using similar setups as yourself but don't report the number of / same issues you have and then say "but WinUAE 2 years ago was perfect". That's your "goto" phrase when you can't work something out...

...and the fact the the emulator author is getting annoyed when trying to help you; giving steps to simplify / eliminate options which unfortunately then fall on deaf ears...

Yeah, you're right... not your system, you're just pushing boundaries and finding bugs no one else can or could possibly ever experience

There's a lot smarter people than you on EAB, Amiga and IT wise

[Torkio]

Originally Posted by Toni Wilen

My g-sync monitor (Acer X34) supported 50Hz automatically. Almost all resolutions support 50 to 100hz except 1024x768 and smaller.

Excuse me, are you using hdmi or display port?
thanks

[Toni Wilen]

Originally Posted by Torkio

Excuse me, are you using hdmi or display port?
thanks

DP (I don't think HDMI 2.0 has enough bandwidth, it is ultra-wide monitor)

[Torkio]

Thanks, well, my monitor is not that wide though! it just a 1920*1080 but it has just DP input

[Torkio]

Originally Posted by Toni Wilen

http://www.winuae.net/files/b/winuae.7z has (still experimental) 2x+ variable sync refresh rate mode.

Enable: tick "VRR" tick box in top of display panel (This "detaches" selected refresh rate from chipset refresh rate), select at least 100Hz (or 120Hz if NTSC) refresh rate or higher. Make sure lagless vsync number of slices is 2 or more.

Not very useful because it will tear strangely but at least it should work with >=100Hz modes. (Note that if monitor max is exactly 2x50=100 or 2x60=120, you should reduce chipset panel refresh rate value by 1 to keep refresh rate under monitor max)

It's working fair with VRR ticked at 100Hz (I'm testing with Kick Off 2 (PAL)
4 slices and I didn't need to reduce the chipset panel to have the right speed of the game.
As you said I had tears.
I also tried null filter to reduce the screen size (I'm used to reproduce the exact size of a 1084S Commodor on my LCD to have no impact when I come back on real amiga) and it worked too, tear still visible
In the end I also tried the black frame insertion but it didn't work, both graphic API 9 and 11.
thanks.

[Toni Wilen]

winuae.7z now includes some simple fixes for future 4.0.1 update:

- black frame insertion now works in all 100/120Hz vsync modes (lagless and standard)
- 100Hz/120Hz supported in lagless mode

Some of above previously worked strangely or differently in d3d9/d3d11 or didn't work at all.

[Torkio]

Originally Posted by Toni Wilen

winuae.7z now includes some simple fixes for future 4.0.1 update:

- black frame insertion now works in all 100/120Hz vsync modes (lagless and standard)
- 100Hz/120Hz supported in lagless mode

Some of above previously worked strangely or differently in d3d9/d3d11 or didn't work at all.

That’s a great news! I’ll try it right tomorrow evening!
Just a question: must I switch off g-sync?
Thanks

[Toni Wilen]

I didn't notice any obvious difference with or without g-sync. But as usual, it may depend on Windows version, GPU model, driver version and more..

[WildW]

Hopefully continuing this thread rather than starting a new one is the right thing to do.... I've been trying to get this lagless vsync to work since it first appeared, and now that I have my CRT running at 50Hz I thought that was going to be the last piece of the puzzle, but no.

Standard vsync works fine and is super smooth. If I select lagless vsync the emulation runs at maybe double speed, with audio pitch-shifted up to match. From some of the other comments in this thread I thought it might be related to my 60Hz refresh rate, but now that I'm running at 50Hz and still have the problem I'm stumped.

Running on Windows XP with a CRT at 800x600 @ 50Hz. Configuration attached - just a basic A1200 setup with Cycle Exact enabled. Any ideas what I'm doing wrong?

[Toni Wilen]

XP is not really supported in this mode (I am not going to use different hardware just for something like XP and virtual machines are useless for testing these kinds of features) but latest 4.0.1 beta may work better because of included wine compatibility patches. Also make sure Direct3D mode is enabled. DirectDraw most likely isn't going to work either.

Try beta and if it does not work: attach logs. (tick misc panel logging, winuaelog.txt and winuaebootlog.txt)

[WildW]

Thanks for the rapid response

I've tried the 4.0.1 beta and the result is the same - still running fast. I am indeed running in DirectDraw mode - changing to DirectX causes a crash-to-desktop when I click OK. From the log files I suspect that may have something to do with my custom 50Hz resolution, although switching back to a standard refresh rate did not help either.

If XP is not supported then don't worry too much about it. Standard v-sync performance is pretty good anyway. At some point I may install a Windows 7 dual-boot on this machine to experiment with, but the computer is intended for older PC games, hence Windows XP.

Logs are attached in case it ends up helping anyone else in future.

[Torkio]

Hi, I've got another question about the new beamracing v-sync.
As far as I understood , the beamracing v-sync works only with full screen and full size picture so if you use fullscreen but you want to reduce the picture ( I do so to practice Kick Off 2 in the original 1084S size to not lose the habit, the moment you play on real hardware) you are going to see tearing.
Perhaps is there e plan to have beamracing working also in scaled size?
Thanks