When VSync is enabled, framerate is set to 60Hz erroneously

[giantclambake]

See #1295 for some background

To recreate...

Launch amiberry, GUI -> Miscellaneous -> enable Status Line native --> Start

Emulation starts and proceeds to KS-1.3 insert disk screen -- Note: (problematic) Status Line indicates 50FPS

F12 -> Display panel -> enable VSync --> Resume

Status Line now indicates 60FPS -- Note: Status Line is now behaving as it should (wrt CPU load)

Check F12 -> Chipset panel --> NTSC is NOT set

Two birds with 1 bug? ;)

TIA

[midwan]

What's your monitor's current refresh rate when you run Amiberry? The screenmode is not changed (well, unless you use Fullscreen mode, and even then, we don't control the refresh rate), and Amiberry uses V-Sync internally always anyway. The checkbox enables it internally in emulation as well, the same way that WinUAE does it.

If you are doing 60Hz on your monitor, try changing the screen mode to a 50Hz one instead. You should see the framerate stay there as well.

[giantclambake]

Ooops... seems this display cannot do 50Hz.....

Current refresh rate is 60Hz .... this is the default applied by the nvidia driver (I believe it looks at EDID to determine optimum display resolution). As such, any refresh rates <60Hz are not to offered to the user (or the xfce4 Display settings). The 'important' specs of the monitor (Philips 273V5LHAB/75) are;

Panel Size 27 inch / 68.6 cm Aspect ratio 16:9 Optimum resolution 1920 x 1080 @ 60 Hz Scanning Frequency 30 -83 kHz (H) / 56 -75 Hz (V)

This is reflected in amiberry.log at display initialization time;

Compiled against SDL2 v2.26.5, Linked against SDL2 v2.26.5
Enumerating display devices..
Sorting devices and modes...
0: 640x480, 24-bit (60,75)
1: 800x600, 24-bit (75)
2: 1024x768, 24-bit (75)
3: 1280x960, 24-bit (60)
4: 1280x1024, 24-bit (75)
5: 1440x900, 24-bit (75)
6: 1920x1080, 24-bit (60)

What you see there, are the screenmodes offered to user (using nvidia driver), although I do have a choice of 60Hz or 75Hz for most all of them (not just a single refresh rate). Even if we were changing to Fullscreen, 800x600 is going to be at 60Hz (confirmed, nvidia driver enforces this)...even though amiberry detects 800x600, 24-bit (75)...hmmm..

This makes me wonder what happens if VSync=true on displays that do even higher refresh rates...ie; 120Hz or 144Hz...?

I do understand your explanation here, appreciate that, but the puristic view is that a PAL Amiga machine type/software title, should not end up being emulated at NTSC refresh rate of 60Hz...(especially not with a PAL display mode, largely due to the way the original Amiga hardware was designed with timing clocks derived from v_refresh frequency)... as it causes many problems, like here ;)

Assuming the role of the average user here, I am apparently unprepared to change anything ('coz it looks like something the root user needs to check into), and if it's a nvidia driver thing then that's too bad, because the user needs those drivers, in linux, to play all their Steam games on using WINE ... and using nouveau x11 driver is not an option =)

Sigh... allow me some time to check into this further on another host with the x11 i915 driver....

[midwan]

If the monitor cannot do 50Hz, then perhaps it's best not to enable the Vsync option there.

As I mentioned above, Amiberry uses VSync for the SDL Presenter always, and it caps the frames drawn internally depending on the emulated system (PAL/NTSC/RTG). The Vsync option comes from WinUAE, which has a few different ones actually:

We use the Standard VSync option from those seen in the screenshot above. If you follow the same steps on WinUAE, on a monitor that does not support 50Hz, you'll get exactly the same results (emulating a PAL machine will still give you 60 FPS).

Therefore, you should only enable the Vsync option if your monitor is actually capable of doing the refresh rate requested by the emulation.

[giantclambake]

Thanks, that clarifies the situation somewhat...to answer your query tho'...

try changing the screen mode to a 50Hz one instead

....I'm going to miss x11 if it ever goes by the wayside, having gotten used to it since X11R4/5 days...

I did check this, it's reasonably 'non trivial' for your average end user....and of course only applicable if a 50Hz capable display is being used...in debian 12, one has to ;

-disable (or fake) the EDID detection -throw the Xserver some non-standard flags to stop it from using internal tables -provide a Monitor section in your xorg.conf file to accurately represent the display hardware -calculate a Modeline for your Screens section, that's within the specs of your display hardware defined in the Monitor section ...this can be fickle, as you may not hit 50Hz precisely for all resolutions (an actual of 50.65Hz was best I could get working on 1280x1024)...one could leverage this further, by providing a Modeline for use when amiberry is configured to use fullscreen...

Once you get over that configurata, amiberry does indeed behave as you describe with VSync enabled ;) I did say in the discussion about this, that if this all worked on what I personally consider to be 'appropriate' display hardware, I'd declare nothing to be wrong, here, and I find no reason to change that position.

What is wrong however, looking at that screenshot of WinUAE, is at best... the statement "_The VSync option in amiberry is only partially implemented at this stage, and for PAL titles in particular, will only work if you have a display setup capable of a 50Hz vrefresh rate" applies ... and we barely touch upon this fact in the Display panel helptext ...perhaps some mention of this should be made on wiki/GUI:-Display as well?

...I just lost 90% of the viewing audience using widescreen monitors... and it probably ups the ante for the above WinUAE option of 'Standard VS, 50/60' to be part of amiberry some day?

The elephant in the room, was seeing the Status Line (native) working correctly when VSync is set (60Hz), there must be some clue there as to why it's not working otherwise (emulating PAL and the display is running at 60Hz)

[midwan]

If your monitor supports 50Hz, in most distros it's just a matter of selecting that in the Display settings of Linux (where you also choose resolution). On RPIs, you also have a config file you can modify under /boot, which is useful if you're booting in console mode only and the X settings do not apply.

The Vsync feature is 100% implemented as it's found on WinUAE as well. The Beam-racing modes are excluded, since they don't make sense on the hardware we're targeting (they require high-end GPUs to be useful). The Standard Vsync vs the VSync 50/60Hz options are just a different number in the config (1 or 2 respectively), so they could both be added as a dropdown, instead of a checkbox. You can modify the value manually in the config, and it will be used accordingly.

If you find that the second option is more useful, I can make the changes in the GUI. But in my tests, both seemed to behave identically, so I've left it as a Checkbox control to simplify things.

[giantclambake]

If your monitor supports 50Hz, in most distros it's just a matter of selecting that in the Display settings of Linux (where you also choose resolution).

Not entirely correct, as proven in my testing ~ the correct line should read "If your monitor ONLY supports 50Hz" ... (and sets EDID optimal resolution to a 50Hz modeline).

In my testing, I used a HP LA1956x display ~ it's specifications are;

Horizontal frequency = 24 - 83 kHz Vertical refresh rate = 50 - 76 Hz Max dot_clock value = 170Mhz

However, it's EDID will always proffer Optimum graphic resolution = 1280 x 1024 (60 Hz) analog/digital input, to the Xserver auto-configuration ....this is exactly why I had to set things to ignore EDID (and/or fake EDID), else the monitor never advertises 50Hz capabilities to the graphics adapter. I didn't check, but there are 10 user programmable Custom modes one can enter into the EDID eeprom, but it's just as easy to adjust things at the Xserver side, and the monitor will sync to any valid Modeline thrown at it (if the Modeline isn't valid, the monitor goes black and kicks out an 'Out of Range' message box....don't ask how I know ;)

The Beam-racing modes are excluded, since they don't make sense on the hardware we're targeting (they require high-end GPUs to be useful).

M'kay... so when we target x86-64, we don't cater for high-end GPUs (even though that may very well be the case ;)..noted.

The Standard Vsync vs the VSync 50/60Hz options are just a different number in the config (1 or 2 respectively)

I couldn't find this param in the config ('config' is ambiguous, but it's not in amiberry.conf nor config.uae files =)

What I do see is;

gfx_vsync=true
gfx_vsyncmode=normal
gfx_vsync_picasso=false
gfx_vsyncmode_picasso=normal

I'm supposing you're referring to the keyword normal ? Obviously not an integer...what antonym should I use there... 'abnormal' or 'insane' ? (joke ;) I think I see it in main.cpp ...

 prefs->gfx_apmode[1].gfx_vsyncmode = 1;
if (ap->gfx_vsyncmode) {
ap->gfx_vsyncmode = 0;

..alas, I don't see what you're referring to.... perhaps you can clarify.

I should stress, it does work when display/monitor is running at v_refresh=50Hz ... but if it's not going to work, with amiberry in windowed mode, emulating a PAL Amiga title, on a desktop display running at 1920x1080_60Hz, then the VSync option is of no use to me (and I'll guarantee I am in no way alone here ;)....

...not that it matters (to me)...everyone should be using 4:3/5:4 aspect monitors capable of 50Hz when emulating Amiga titles...unfortunately, a good many Amiga titles are PAL, and the majority of monitors available today have their optimal resolution hardcoded into EDID using a 60Hz res. ...(and like the display units here, not capable of 50Hz anyhow)...

...this, is a corollary of 'technical progression', would be the best way to put it ;)

Edit: Ahhh... did a bit more reading ...so the Beam-racing modes in WinUAE, are using DirectX calls in Windows to function ~ so I guess in linux, this would need to be implemented using OpenGL (if possible), so the accelerated OpenGL libraries in the nvidia/radeon proprietary drivers, can be utilized to achieve the same ends...is that right?

[midwan]

I've added the list of options that WinUAE has on the GUI, as dropdowns. This now matches the functionality (minus the lagless/beamraced modes) to that of WinUAE, with the exception that Amiberry uses VSync for the SDL_Presenter always anyway.

These options should only be enabled if your monitor is set to the matching refresh rate of the emulated system.

[giantclambake]

Closing this ~ turns out there was a very good reason I chose to buy some 50Hz monitors ;) After testing in WinUAE (using WINE), caveat the beam-racing mode not being available yet, the behavior in amiberry is pretty much the same.

So with the available VSync options -- PAL titles work correctly on a 50Hz display, and NTSC titles work correctly on 60Hz displays (which is what most folks will have). Not sure if a 100Hz v_refresh can be used for PAL titles to display/run correctly, but then we're talking an equally limited amount of folks with that hardware, as is so for 50Hz displays ;)