Tearing with super resolutions

[bjt42]

I tried super resolutions on my GroovyMame linux setup but am seeing a lot of tearing in the upper third of the screen.
The only change I made to mame.ini was to set resolution 2560x0.
I confirmed that a 2560 wide resolution was being used via Machine Information in Mame.

This setup works without tearing when using resolution auto.

Core i5 3470T, HD5450, arcade_15 monitor, linux 4.10 with 15khz and interlaced vblank patches.

[Doozer]

If you are using the latest GM build. Tearing can only come from your X version, you have to perform the update X to the last version.

[bjt42]

If you are using the latest GM build. Tearing can only come from your X version, you have to perform the update X to the last version.

I'm using the 2018 GroovyArcade, so

Mame 0.195
xorg-server 1.19.6
xf86-video-ati 1:7.10.0

You think I need to update X beyond the versions included with the 2018 CD?

[bjt42]

I should also mention that the tear line is not always horizontal, sometimes it is diagonal, which I though was interesting.

[Doozer]

I should also mention that the tear line is not always horizontal, sometimes it is diagonal, which I though was interesting.

Diagonal tearing is indeed interesting. This would mean that the previous issue can be signal related like an HSync issue (horizontal rolling sync).

Nevertheless, I recommend you to proceed to the update of your X server, the version you are running have some issue withe the frame shadowing. You can fix it without updating but it will cost you 1 frame delay. Here is the fix:

Insert in the xorg.conf under the decive section:

Code: [Select]

Option "GLXVBlank" "true"

In case of HSync issue, it will not help at all.

 

[bjt42]

Insert in the xorg.conf under the decive section:

Code: [Select]

Option "GLXVBlank" "true"


I tried this with my existing X version and it does help slightly. The tear line is still present but has moved further towards the top of the frame.
I'll upgrade the X server and try again.

[bjt42]

Upgraded my install to arch latest, GroovyMame 0.204 and AttractMode 2.5.1. The tear line is still present in super resolutions, but now it disappears if I add the Option "GLXVBlank" "true".
Didn't really want to add another frame lag on top of the 2-3 caused by SDL 

On the plus side, AttractMode seems more stable during video playback, even using the latest 4.14 kernel. Maybe the issues with the radeon driver have been fixed.
I haven't tried fullscreen video yet, but previously I was seeing freezing when playing video snaps and even in the AttractMode menus.

EDIT: Realised I was actually using the latest 4.19 kernel when I wrote this! Will build 15khz 4.19 and 4.14 kernels and retest.

[donluca]

Didn't really want to add another frame lag on top of the 2-3 caused by SDL 

Is it still the case? I thought they figured it out in one of the latest versions.

[Doozer]

Just some corrections not to confuse people.

SDL is only 1 frame lag like in Windows.
Video playback issue is still present in 4.14 up to 4.19.9.

Otherwise, I am happy that your issue is fixed. Normally, you shouldn't experience a noticeable input lag with the option in comparison to the previous configuration, do you confirm?

[donluca]

Just out of curiosity, what's the cause for the additional frame of lag in SDL?

[Doozer]

Just out of curiosity, what's the cause for the additional frame of lag in SDL?

Very good question. Best answer would come from an SDL dev person. I have only an assumption which is related to the internal SDL processing code. With upcoming releases, lag could completely disappear.

[Calamity]

Just out of curiosity, what's the cause for the additional frame of lag in SDL?

Additional compared to what?

[donluca]

Additional compared to what?

Compared to the d3d9x with Vsync off implementation which I always use as a reference.

[bjt42]

Well, I did a load more testing on this and unfortunately have decided to give up on GroovyArcade/Linux for now.

Even with the fixes to xorg.conf described above, I am still seeing artifacts in super resolutions. The artifact is a triangular-shaped area in the upper right of the screen that lags one frame behind. It looks like an incomplete blit vs page flip or something similar rather than a signal related problem. Uncommenting the "ShadowPrimary" option in xorg.conf seems to fix this but causes the framerate to be halved.

There is also an issue that causes periodic stalls of 3-4 seconds when super resolutions are enabled for vertical modes on a horizontal monitor.

We are already aware of the unresolved video playback problems with kernels >= 4.14, and the problem with interlaced vblank which requires a kernel patch.

Getting the latest version of the X server requires a full system update, as Arch doesn't support partial updates. Unfortunately I have found that when running an older (4.10) kernel with Arch latest, the system is unable to load libQt5. The older kernels also don't compile under Arch latest. The latest MAME binaries require latest GLIBC and libQt5 and won't run under an old Arch system. The latest MAME source doesn't compile cleanly under an old Arch system either.

So right now the choice seems to be to run an older Arch system and kernel, have working video playback but be limited to an older X server and MAME version, or run a later Arch system with latest MAME but have no video playback. That's on top of the unresolved issues with super resolutions.

I also tested a Win7/CRT Emudriver/GroovyMame setup and did not observe any issues with super resolution artifacts, super resolutions in vertical modes, interlaced vblank or video playback. Win7 also doesn't suffer from the library/kernel/compiler versioning nightmare of Arch.