Software Support > GroovyMAME

GroovyArcade live-CD 2022 (collaborative effort)

<< < (112/112)

Calamity:
Hi intealls,


--- Quote from: intealls on February 12, 2024, 06:18:53 pm ---I'm also seeing weird issues when trying out different mesa versions, with mesa > 23.2.x, the lower part of the screen (with the R7 260) will occasionally jitter around while the top part won't? For some strange reason toggling the UI off and on seems to fix it. With mesa > 23.2.x I couldn't get reliable next-frame response with the R7 260. For whatever reason, 23.1.4 works great with the R7 260 for me. I haven't tested the HD 5770 with 23.1.4.

--- End quote ---

Yes, unfortunately they seem to be focused on breaking v-sync each release. I've tuned the algorithm at least twice already after they changed something, but they'll likely break things again.

I left several algorithm built-in permamently so we can test different methods when things go bad (option -sync_mode):


--- Code: ---sync   algorithm        amdgpu          radeon          radeon/kms      amdgpu/kms
mode
   0  -Swap(1)          perfect(1)      perfect         smooth          smooth
      -glFinish                                         lag 1 frame     lag 1 frame

   1  -Swap(0)          tearing         tearing         perfect         tearing/
      -drmWaitVBlank    perfect w/fd                                    stuttering
      -glFinish

   2  -Swap(1)          perfect(1)      perfect         perfect         perfect(1)
      -drmWaitVBlank
      -glFinish

   3  -drmWaitVBlank    tearing         perfect(2)      tearing         tearing
      -Swap(0)
      -glFinish
               
   4  -drmWaitVBlank    half speed      half speed      smooth          smooth
      -Swap(1)                                          lag 1 frame     lag 1 frame
      -glFinish

- Swap(x), x = Opegl swap interval (0 = immediate, 1 = v-sync)
(1) Low frame delay performance
(2) GM's pre-0.232 implementation
perfect = smooth + subframe latency
--- End code ---

I'd say the long term solution is to handle the frame buffer directly on kms, and maybe v-sync at lower level.

In any case, GM's syncrefresh needs a "lifting", based on what we've learned while implementing GroovyMiSTer.

intealls:
Hi Calamity,


--- Quote from: Calamity on February 13, 2024, 04:24:16 pm ---I'd say the long term solution is to handle the frame buffer directly on kms, and maybe v-sync at lower level.

--- End quote ---

That sounds really cool!


--- Quote from: Calamity on February 13, 2024, 04:24:16 pm ---In any case, GM's syncrefresh needs a "lifting", based on what we've learned while implementing GroovyMiSTer.

--- End quote ---

Maybe in some way the rate_filter stuff that I've done for the audio patch could be of help, or something similar to it.

I've attached the first revision of the sound patch. It's to be considered experimental, testing is needed on Windows and more machines etc etc.

It's only been tested on Linux (GroovyArcade) with PortAudio + ALSA. Only PortAudio is supported.

For high frame_delay levels I would say the stuff below is almost a necessity:

* -nosleep

* Allow low nice levels for user:
  https://wiki.archlinux.org/title/Limits.conf
  and launch mame using "nice -n -20 ./mame ..."

* The patch requires a low callback latency to work properly. 8 ms or lower is probably required. So use -pa_latency 0.016 or lower. If the system supports -pa_latency 0.004/0.006, use that. When over-/underrunning the buffer the actual callback count is displayed, so use that as a guide (48 = 1 ms).

* For games that switch resolution (Genesis etc), use super resolutions, -dotclock_min 32 -resolution0 3072x0. This way the playback rate will not need to be re-estimated at every resolution switch.

The latency has been slashed, each step > 1 adds 1 ms of additional buffering. So -audio_latency 5 will allow 1.5 + 4 ms additional buffering. This will probably not work for the general case, but for the purposes of this it aligns well.

To aid debugging, an option -pa_rnsnd has been added. When under-/overrunning the buffer, a square wave is added to the mix.

It's also possible to create a detailed run-time log as well using -pa_log. use "nice -n -20 ./mame ... -pa_log | grep 123456.123456 > pa.log" and the buf.py Python script which is also in the patch. Python 3.x, numpy and matplotlib need to be installed to run it.

I've attached some plots for 20 minute runs of sfiii3n, neodrift and contra (genesis) at frame_delay 7. For neodrift and contra (genesis) it's possible to see that we're perilously close to underrunning, but we don't. The main takeaway from sfiii3n is that we don't do large pitch shifts, the pitch shifts should be inaudible (I've used 441/440 as a guide = ~0.228%) and we try to set the rate when the deviation is about a third of that (0.08%). Since sfiii3n has properly crunchy aliasing all over the place anyway the underruns are barely noticeable, so in practice it runs very well.

More work is needed for a generic/general solution, but it runs well for me with GA + PortAudio.

Calamity:
Hi intealls,

Thanks for sharing this!

BTW, did you miss the patch? At least I can't see it attached here.


--- Quote ---Maybe in some way the rate_filter stuff that I've done for the audio patch could be of help, or something similar to it.
--- End quote ---

Probably something similar, yes.

The way sound synchronization in GM is done now is super sensitive to emulation speed fluctuations (real or bogus). This wasn't meant to happen in the past.

To improve things speed should be more based on the actual precalculated refresh (modeline), and just use the real-time measurements to fine tune the period in order to compensate the dotclock shift.

This could help to already count with a "good enough" value right after a mode switch.

Current implementation is badly penalized by random frame drops caused by frame delay. This could be solved by separating vblank polling to a different thread just focused on registering accurate vblank timestamps. Similar to what we've done for GroovyMiSTer, where even high frame delay values can only cause tearing glitches but no speed fluctuations.

intealls:
Hi Calamity!


--- Quote from: Calamity on March 07, 2024, 03:21:38 am ---BTW, did you miss the patch? At least I can't see it attached here.

--- End quote ---

It's named rate_v01.txt and should be above the first image, it's easy to miss, the images turned out to be much bigger than I thought they would be :)


--- Quote from: Calamity on March 07, 2024, 03:21:38 am ---The way sound synchronization in GM is done now is super sensitive to emulation speed fluctuations (real or bogus). This wasn't meant to happen in the past.

--- End quote ---

I think the recommendation do disable soundsync and lower syncrefresh_tolerance has been good though, humans are apparently really sensitive to changes in pitch. The patch is really restrictive with pitch changes, but there are a couple of cases where it will be difficult to get rid of the problem completely, such as when changing resolutions. syncrefresh_tolerance will help here as well though.


--- Quote from: Calamity on March 07, 2024, 03:21:38 am ---To improve things speed should be more based on the actual precalculated refresh (modeline), and just use the real-time measurements to fine tune the period in order to compensate the dotclock shift.

This could help to already count with a "good enough" value right after a mode switch.

--- End quote ---

Yes this would be really nice. I was about to ask you if it was possible to know exactly what frequency we would end up with if we knew more about the GPU itself - then it would be adequate to just estimate the audio frequency (just estimating the audio frequency seems much more difficult though, for whatever reason). But for sure the emulation speed is far more important than the audio playback frequency itself. The audio frequency will linger about 48 kHz and if we start with a good video estimate the rest will fall into place rather quickly. If you enable -pa_rnsnd you can hear a couple of underruns at the start of every game, and occasionally when switching resolutions as well.


--- Quote from: Calamity on March 07, 2024, 03:21:38 am ---Current implementation is badly penalized by random frame drops caused by frame delay. This could be solved by separating vblank polling to a different thread just focused on registering accurate vblank timestamps. Similar to what we've done for GroovyMiSTer, where even high frame delay values can only cause tearing glitches but no speed fluctuations.

--- End quote ---

This could also really help, I tried reading up on DRM but it seems to be a real jungle.

I think this could really turn out real good. :) It's a *JOY* to run with GM+DRMKMS, -pa_rnsnd enabled and hear no square waves whatsoever. Honestly, the emulation is just so damn good, I'm certain I couldn't tell any difference from real hardware. *Maybe* some difference, since the RGB output from a GPU is so good, I don't think most real systems will output such a nice picture. But this obviously not a negative. :)

Edit: Also, I'm still using the linux-rt patches, but since things have stabilized I'll compile a kernel without them and see whether or not there's any difference. I have a test suite of games that run ~20 min with various -pa_latency settings (0.004/0.006/0.008/0.016).

intealls:
Right, I compiled 6.5.9 without the -rt patches and did a comparison with 6.5.9 with -rt patches, and the difference is quite staggering.

For this use case (minimize audio latency, maximize frame_delay) the -rt patched kernel seems to completely blow the non-rt kernel away.

Attached are plots of a 15 minute neodrift run with frame_delay 7, -pa_latency 0.004 with and without -rt. It's possible to see multiple frame drops and audio hiccups with the non-rt kernel.

I ran the test twice just to make sure.

In the plots, the most telling performance indicator is a straight line in "Incoming vs outgoing samples". With non-rt, it's easy to see multiple dropped frames (upward steps) and audio hiccups (downward steps). With the -rt patch, it's basically perfect.

Navigation

[0] Message Index

[*] Previous page

Go to full version