LCD Tearing with Variable Refresh

[DJO_Maverick]

So I recently migrated to an LCD after shorting out the tube in my cab, and am working out the kinks...

I got one of the new Unico Phoenix 26 monitors, and while it's not recognized as Freesync capable by the driver, it will properly sync to any frequency I've thrown at it so far.  I've got Groovymame set up with lcd_range 54-61 and allow hw refresh on, and it certainly appears to be working as intended; monitor is reporting expected frequency for every odd game I've thrown at it.  And yet...

Groovy is consistently giving an intermittent tear line, in any game I've tried, about 20% down from the top of the screen.  I know there are some old threads beating this to death, but it's been a while, and some of the advice seemed a bit cryptic.

Fiddling with frame_delay does not appear to affect it.  Likewise, if I fiddle with the Vsync_Offset slider, it appears to have no visible effect on the line.  Mainline doesn't tear, but, that has other tradeoffs, of course.

I know it's a common issue; is there a consensus on the best way to troubleshoot it these days?

Thanks,

[DJO_Maverick]

Adding current ini and a couple of token logs as well.  INI was originally set up to use the dummy resolution/refresh rate before I switched to the LCD range method, so there's some legacy stuff in there...  and I've got HLSL disabled until I can at least sort the tearing without it.

And PS: is there any advantage/disadvantage to using the new lcd_range and hw_refresh method versus the legacy 'dummy resolution' method with a CRT range for the LCD monitor?  If not, wondering if maybe I should go back to the old ways just to avoid the notification sounds.

[Calamity]

Hi DJO_Maverick,

Your configuration and logs look correct. Both methods, allow_hw_refresh and dummy resolution are equivalent.

I'm trying it here right now, and I get like 1.5 cm of tearing on top of a 32" lcd, which can be removed with fd + vsync_offset. But I'm using an R9 270 here. So it could be your R7 isn't fast enough for tearfree rendering at 1600x1200. Just an idea.

[DJO_Maverick]

Thanks for the response.  I've actually kept at it with troubleshooting and I'm sure you're right on the resolution-

Dropped overall resolution to 1280x960, which had a similar tear factor to what you describe.  Then with bumping from Framedelay 0 to 1 and a VSync Offset of 85, managed to eliminate tearing without HLSL.  Now proceeding to tweak further to get it working without tearing.  Led to a couple of additional questions that I'm fuzzy on:

- Is having some degree of Framedelay a prerequisite to VSync Offset having any effect?  Seems to not do anything with it off-
- It seems like with some games (taking RType for example), which is properly running at 55hz...  going from Framedelay 0 to 1 ratchets it up to turbo mode.  I have to push Framedelay up to 3 or 4 to push it back down to normal running speed.  Is that expected behavior?

Sounding like maybe I should just bump up the card a bit, but limited by a low profile slot.

[Calamity]

- Is having some degree of Framedelay a prerequisite to VSync Offset having any effect?  Seems to not do anything with it off-

Correct. Frame delay is required for vsync offset to be considered. This isn't obvious and I had to check the code now to answer, because it's been a long time since I touched that.

- It seems like with some games (taking RType for example), which is properly running at 55hz...  going from Framedelay 0 to 1 ratchets it up to turbo mode.  I have to push Framedelay up to 3 or 4 to push it back down to normal running speed.  Is that expected behavior?

This is an issue I thought that was already fixed, but maybe it's gpu speed dependent, so I only fixed it here. It's just a matter of increasing fd as you say, but not desired behaviour.

I didn't mean that you lowered the resolution, because on an LCD you should always use the native panel's resolution. But the fact that it helped solving the issue points to the gpu speed as the culprit here.

[schmerzkaufen]

I'll be damned; another flat panel Groovy user posting here. Thought it would never happen. 

And so yes, confirming when using allow_hw_refresh you need frame_delay to be ON even if just at level 1, for vsync to work...
Which means depending on your system and X or Y game you're often gonna need to use a bit of vsync_offset too to get rid of tearing.

Lately I've had no speed nor sync issues with the 50~75Hz non-VRR monitor I typically use all the Groovy features with, using the latest 0.256 testing 'down' to Xexex or R-Type.
Also tested my compatible display extensively for Groovy using several AMD cards over the years so now I can tell rather quickly if something's actually not working right with a release.
But I can double-check again tomorrow to be sure.

It's indeed rather bad to lower the resolution, to improve performance I rather use simpler HLSL settings without fancy extra features like Bloom which is quite demanding.
Pushing high scanline brightness offset instead and building around, it looks less realistic and makes finding working values without uneven lines artifacts trickier, but I got used to it.

That said I've got a powerful system with modern components for playing current PC games to begin, wich is fitting because Groovy for flat panels (non-VRR but compatible like we're using) requires MUCH more CPU+GPU muscle than for CRTs.
I'm a sucker for efficiency so I don't max-out all the things I could, but if you are in a situation at the other end of the PC performance spectrum forcing you to sacrifice too much on quality and lag reduction to keep the framerates, it'd be a good idea to upgrade your dedicated PC components, indeed.
You don't need a 13900K nor a 7900XTX, no worries, but the kind of ancient PC hardware some ppl use in CRT mamecabs like HD 5000 cards and and Athlon or something just won't do here in this situation.
And yeah both the CPU and GPU count for our particular use case, so if you can; upgrade the former too.


Just going to bed now. G'night. * yawn *

PS: btw what is the current most powerful LP AMD ? Sapphire Radeon RX 6400 ?

[DJO_Maverick]

I'll be damned; another flat panel Groovy user posting here. Thought it would never happen. 

Yep; I studied quite a few old threads between you and Calamity about it before I poked my head out.  Have to be honest, it wasn't a first choice; tried all I could to get the 'ole 27" CRT working again, but when it was clear it was dead and gone, it was just cost-prohibitive to gamble with getting a similar size TV/monitor brought cross-country...  and this Phoenix monitor was coming out later the same week.

So re: the resolution...  I agree conceptually/philosophically about not changing from the native resolution.  The interesting glitch with that idea right now is that nobody knows what the native panel resolution on these ULM26 monitors actually is!  While it seems to be a 'good' display for the niche, the manufacturer doesn't list it, and their community guy hasn't been able to dig it up yet.  The control board they picked seems to be some Chinese off-the-shelf part that doesn't actually match the panel, per se, though it performs well.  With best efforts, I haven't been able to determine what the panel resolution is with any confidence either.  So...  in the meantime...  I don't feel very guilty about playing with the resolution!

At 1280x960, I've since dialed it in to work with all my glorious bloom, I believe with a V Offset of 215 (not looking at it) and a default frame delay of 3.  While that gets rid of the consistent tear line, there's still a periodic, momentary tear/glitch here or there...  MOSTLY ignorable (except to me).  I'm guessing and assuming that's just going to be GPU-related and not much I can do about it until I swap the card.

As far as I can tell, yeah, the RX 6400 looks like the best option available.  It's not THAT pricey, and appears to be a very significant upgrade.  I may try to pick one up sometime soon.

And if you have any other good sources/recommendations about ideal (bloom-and-all) HLSL CRT sim settings for Groovy, would love to see them.  I'm currently using a lightly modified version of this guy's settings: https://hyperspin-fe.com/forums/topic/25154-my-mame-0172-hlsl-settings/

[DJO_Maverick]

PS, one more GM-LCD Noob question...  do higher resolutions alter the way unevenstretch works?  Taking CPS games for example, at oddball 384x224 (and yeah, understanding the PAR isn't 3:4, but well accepted they're supposed to be displayed at 3:4)...

On this new 4:3 monitor, if I curtail the resolution down to 1024x768, unevenstretch works as anticipated and fills out the 4:3 screen.  If I launch the same games with a higher 4:3 resolution (like 1280x960, or 1600x1200), it will NOT fill the screen...  in both of those cases, it appears to be doing the closest integer scaling only.  Same INI as already posted.

Am I missing something...?  I was under the impression unevenstretch is supposed to fractionally scale it up to fit the available screen real-estate, as limited only by aspect ratio.  Shouldn't a 4:3 source stretch up to fit any 4:3 resolution?

[Calamity]

Check -autostretch option, it's specific to GM. It will handle stretching automatically, choosing integer scaling when possible. That's why higher resolutions increase the chances that a suitable integer scale factor is found. You want it disabled if you prefer to have unevenstretch always on.

[DJO_Maverick]

Check -autostretch option, it's specific to GM. It will handle stretching automatically, choosing integer scaling when possible. That's why higher resolutions increase the chances that a suitable integer scale factor is found. You want it disabled if you prefer to have unevenstretch always on.

Tried following your guidance here, but disabling it seems to have no effect.  With unevenstretch 1 and autostretch 0, it still is performing identically at higher res for CPS.