VSync question: has anyone tried amiberry with a G-Sync display?

[giantclambake]

My more pointed question, is what happens if one does that? Every time I see reference to VSync 50/60Hz area, I go for a little look-see ~ going by the nvidia docs, it seems if I had a G-Sync compliant display, I can dial in a 50Hz profile based upon the application being run --- it occurs to me, amiberry initializes against the current display params, but this is unlikely how the g-sync hardware displays things...ie; it's a hardware bridge in effect. Anyone poked around with this?

Or....I'm tempted to buy one, and find out for myself =) The spec numbers are 96.4-186.7 KHz(H) : 48-165 Hz(V) ...looks hinky, because they don't say VRR ...full variable refresh rate. If I get the gist of it right, amiberry should run the emulation at the selected internal sync, and have a don't care respect for v_refresh (of the host display)...or such and similar.

Any insights appreciated -- if nobody's tried it out, I'll need address that... ;)

[midwan]

There is currently no support for variable refresh rates, so it won't make any difference.

[giantclambake]

Thanks, that's what I figured ~ I don't think VRR is of any use, here, because the emulation is always going to be 50Hz or 60hz....

... what I was trying to work out, was the case when you wanted to render at a fixed FPS, irrespective of what host display setup was being used...ie; you always want a 60Hz v_refresh, regardless of the fact the monitor itself was in the 75-165Hz range. I had a search around SDL tomes (for sure this has been asked before)...and I came across this thread...

https://discourse.libsdl.org/t/question-about-sdl-renderer-presentvsync/34687

...that's more or less what I was thinking about... being able to render frames with constant time step, instead of fixed frame rate. No doubt, that's not applicable for amiberry. Closing as wishful thinking (but I might buy one anyway ;)

[giantclambake]

...typing in discussion of my own closed question ; the one thing I hadn't quite divined, was how the window-manager would deal with all this....and the answer is it doesn't ~ it's the compositor's job ... in XFCE4 this is 'Compton'. So one has to enable the compositor, and then adjust it's config like so;

unredir-if-possible = true;
vsync = "opengl-swc";
refresh-rate = 0;

...then you need to make sure the actual window-manager (xfwm4) is deriving it's vsync from the same source;

xfconf-query -c xfwm4 -p /general/vblank_mode -t string -s "glx" [--create]

...I believe from there, amiberry would have to use an opengl renderer....ie; ./amiberry --vsync opengl (which hooks back to opengl-swc) ...but we're a ways off that being possible... ;)

[giantclambake]

There is currently no support for variable refresh rates, so it won't make any difference.

Turns out it does make a difference ~ this is likely the space between variable refresh rates & multiple refresh rates versus current desktop display settings?

Display unit arrived today (Philips Evnia 27M1N3200Z) ~ this was a 'hot swap'...turn off/unplug old display, plugin (change from DVI to HDMI) and turn on new unit...in the process, dbus & friends prompted the XFCE4 display settings window to pop, to announce the new hardware, and if I would like to proceed with the current settings...1920x1080@60Hz ...glxgears seems to agree...

....launch amiberry using classicwb-p96.uae .... emulation starts, but in a 720x568 window (with 4 colours I think ;) ...obviously something has gone wrong ; checking amiberry.log I can see what's transpired...

Enumerating display devices..
Sorting devices and modes...
0: 640x480, 24-bit (60,73,75,100,120)
1: 720x480, 24-bit (60)
2: 720x576, 24-bit (50)
3: 800x600, 24-bit (56,60,72,75,100,120)
4: 1024x768, 24-bit (60,70,75,100,120)
5: 1280x720, 24-bit (50,60)
6: 1280x1024, 24-bit (60,75)
7: 1920x1080, 24-bit (25,30,50,60,120,144,165)
8 display modes.
Desktop: W=1920 H=1080 B=24 HZ=165. CXVS=1920 CYVS=1080

The last line is in error, if "Desktop" refers to the active WM desktop -- it is not running at 165Hz. It follows that error is responsible for the nonsense I see onscreen. Why on earth is it wrongly selecting 165Hz?

Got any idea how to make things work correctly? This has nothing to do with g-sync etc, this is just the monitor proffering multiple different modes, and it should be selecting "Desktop: W=1920 H=1080 B=24 HZ=60. CXVS=1920 CYVS=1080" ...which is the currently configured/used values for $display ?

Edit: Providing an appropriate /etc/X11/xorg.conf does not work either unfortunately...

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "nvidiaXineramaInfoOrder" "HDMI-0"
    Option         "metamodes" "1920x1080_60 +0+0"
    Option         "SLI" "Off"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "off"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Interestingly, further on in the log...

Getting Current Video Driver...
Current Display mode: bpp 24    SDL_PIXELFORMAT_RGB888  1920 x 1080     60Hz

amiberry.log.gz

...//later//.... turns out that 'for some mysterious reason', the screenmode prefs in both of my classicwb installs had reverted to basic PAL, 8 colours ; I have no idea why, I do know it wasn't me. Otherwise amiberry is working as before...very strange..

[giantclambake]

...babbling to myself again.... did some more reading ...sdl_getdisplay list all available screenmodes, lowest to highest, but by default proffers the highest resolution...

...g-sync is another layer (and I note nvidia & mediatek just announced collaboration, to bring g-sync to more devices ... as opposed to display devices, so looks like g-sync is not quite as dead as I thought) ; for this to work OOTB then you'd need open an SDL window, using a GL driver...

...compositors are different again (especially if wayland), but I note most of them even hook the NV_GL contexts ..but it doesn't look like SDL has fully embraced wayland protocols...looks like future stuffs =)