Documentation update: VRR not enabled when vsync_adjust is not 0

[loki666]

I had the feeling gut that my VRR settings wasn't being applied, and rightly so...

https://github.com/MiSTer-devel/Main_MiSTer/blob/master/video.cpp#L2099C25-L2099C41

Nowhere in the doc, nor Mister.ini sample file is this condition documented,
it's very confusing, because when you have vsync_adjust != 0 in your config, you still see the lines

https://github.com/MiSTer-devel/Main_MiSTer/blob/master/video.cpp#L1737
https://github.com/MiSTer-devel/Main_MiSTer/blob/master/video.cpp#L2003

in the console logs

on a side note, shouldn't this test be in the first lines of function set_vrr_mode(), I mean, what's the point if querying EDID and stuffs, if it's to disable it in the end ?

[sorgelig]

You either use vsync_adjust or VRR not both. VRR is already a way to sync the framerate.
EDID reading is primarily for default video resolution.
No definitive way to detect vrr support found, so it's mostly informative than definitive. Generally speaking vrr support is experimental.

[loki666]

ok, I understand that both method are exclusives, it should just be more clear in the doc / .ini

[wickerwaka]

There are two different ways the VRR works on MiSTer.

When VRR is enabled then VRR metadata is sent to the display, this puts the display into VRR mode which can have a benefit on some displays.

When VRR is enabled and vsync_adjust=0 then MiSTer will also be VRR processing, this means that the pixel clock remains constant and the size of the blanks are adjusted. Some displays will handle this better than the pixel clock adjustments that vsync_adjust=2 does. So you might find that the PSX core can switch resolutions without losing sync.

[loki666]

ah ok clearer, thanks

vrr enabled, and vsync_adjust=0 barely works (no Menu, most of games are completly garbage display)
vrr enabled and vsync_adjust=2 works, but just as well as vrr disable with vsync_adjust=2 (except for some arcade core which I need to setlle back to vsync_adjust=1 or 0)

So my last question is, if vsync_adjust=2 works fine, are there any benefits to enable vrr ?

thanks for the details

[sorgelig]

Both vrr and vsync_adjust do the same job - sync HDMI framerate with original core's framerate. If vsync_adjust=2 works fine, then better use it.
VRR is more precise (it sticks to core's framerate), but not all displays support it.

[loki666]

Ok if I'd like to test or improve the VRR situation in Mister, where should I start?

My display is supposed to support VRR (Freesync / GSync compatible), where / how did you find the current values that Mister is sending to the ADV7513 ?

Is this protocol documented somewhere?

Also while looking at the console logs, I noticed sometimes a core isn't able to open the i2c (ie: getting "adv7513 not found on i2c bus! HDMI won't be available" errors), should I be worried about that ?

It doesn't seem to be persisting as usually launching another core doesn't expose this error...

[sorgelig]

Not sure what improvements you may provide. MiSTer simply extends vblank till next frame from the core. There is no clear documentation about VRR. There are also some caveat: because original video doesn't case about HDMI output, so each frame on HDMI may have +-1 blank line - many monitors don't like it and either produce shaking video or other artifacts.

Also while looking at the console logs, I noticed sometimes a core isn't able to open the i2c (ie: getting "adv7513 not found on i2c bus! HDMI won't be available" errors), should I be worried about that ?
It doesn't seem to be persisting as usually launching another core doesn't expose this error...

it's not an error, actually. Just disregard this "error" message.

[loki666]

There are two different ways the VRR works on MiSTer.

When VRR is enabled then VRR metadata is sent to the display, this puts the display into VRR mode which can have a benefit on some displays.

When VRR is enabled and vsync_adjust=0 then MiSTer will also be VRR processing, this means that the pixel clock remains constant and the size of the blanks are adjusted. Some displays will handle this better than the pixel clock adjustments that vsync_adjust=2 does. So you might find that the PSX core can switch resolutions without losing sync.

https://github.com/MiSTer-devel/Main_MiSTer/blob/master/video.cpp#L2134

it' seems VRR is still playing with the Fpix, not the vertical front porch

[zakk4223]

There are two different ways the VRR works on MiSTer.
When VRR is enabled then VRR metadata is sent to the display, this puts the display into VRR mode which can have a benefit on some displays.
When VRR is enabled and vsync_adjust=0 then MiSTer will also be VRR processing, this means that the pixel clock remains constant and the size of the blanks are adjusted. Some displays will handle this better than the pixel clock adjustments that vsync_adjust=2 does. So you might find that the PSX core can switch resolutions without losing sync.

https://github.com/MiSTer-devel/Main_MiSTer/blob/master/video.cpp#L2134

it' seems VRR is still playing with the Fpix, not the vertical front porch

It only does it once, after that the scaler/core itself varies the blanking interval. It has to, because you need to scan out at the 'fastest' frame rate in order to properly vary the blanking interval. (If your max VRR is 75hz, you have to scan out at 75hz and then insert longer vblanks to 'reduce' your framerate).

Honestly I think it isn't 'some displays don't like it', I think it is causing the ADV7513 to sometimes output incorrect TDMS packets. A few people have displays with extensive hidden debug menus, and vsync_adjust=0+vrr shows constantly increasing TDMS error count. I don't have access to an HDMI protocol analyzer to say for certain what is going on, though.

The 'adv7513 not found on i2c bus' means the core has a framework so old it doesn't have the changes requires for main to program the chip directly. Those changes were committed to the template core in Feb 2021, so if you find one of those cores you might want to drop a note in github issues or to the author. Probably needs some updating at this point. Without those changes the HPS can't set the VRR flags (and a few other features too).

[loki666]

so let me try to recap this with a table

	vsync_asjust = 0	vsync_asjust = 1	vsync_asjust = 2
vrr = 0	most compatible setup should set HDMI vsync to video_mode highest latency	set HDMI vsync to core vsync can output short black screens when changing resolution can put screen out of sync	lowest latency update pixel clock can output short black screens when changing resolution can put screen out of sync
vrr != 0	set HDMI to max vrr refreshrate (can result in very high pixel clock) core vary blanking interval to match its vsync can put screen out of sync lowest latency (i guess ?)	???	???

[sorgelig]

There is no mix of vsync_adjust and vrr if you are looking for something special. They are mutually exclusive.
those ??? are the same as row above. VRR is turned off if vsync_asjust != 0

[zakk4223]

In the case where vsync_adjust is !=0 and vrr is != 0 mister will send the 'enable VRR' HDMI SPD frames to the display, but the video won't actually be real VRR.

It seems for a lot of modern displays, sending those infoframes causes them to act less weird when non-standard refresh rates are used, and in some cases it even provides a reduction in display latency. All the stuff in the chart still applies to adjust=1/2 (pixel clock updating, blank screens/resync on resolution change etc). Vblank duration is constant.