Getting better performance out of GM than mainstream?

[Trnzaddict]

Since MAME dev added Calamity's low latency patch I started moving away from GM as there didn't seem to be anymore reason to use it as a Gsync LCD user and to Arcade64. Alas I think I'm back tho...

So while performing some cab maintenance I noticed the San Francisco Rush games speed was jumping all over the place from 80% to 108%, then steady at 100% for a bit then drop, spike, etc. Started tesing other games from the Seattle driver, same thing. These are my favorite racing games to play So I overclocked my i7 8700k to 5.1 GHZ. No difference whatsoever. Frustrated now as I remember these games running perfect for me previously I took to ask the devs in the forums and basically was told that my processor was just not cutting it and this driver needs as much raw cpu power as it can handle. However running the games un throttled speed is up to 280% and never drops below 130%. So this seemed like a syncing issue. I asked them how my CPU can be the issue if it runs these games well over 100% unthrottled but can't throttled and got no response. So I tried baseline MAME, fiddled with every performance setting but nothing made a difference except using portaudio but the performance drops were still occurring but the sound skips were not as noticeable so I settled on that. So this issue was present even in straight baseline.

So for giggles I downloaded GM218. Games are fine. Imported all my settings being used for Arcade 64 (HLSL, etc.) and used them with GM, buttery smooth performance on Seattle.cpp. Finally I removed my overclock as I don't like OC'ing if I don't have to and this was the first situation I felt it was necessary, games run fine. Granted unthrottled they don't run as high but I don't care. I knew it was not my processor.

So my question is if someone feels like answering is why is this happening?

[Calamity]

I gather you're using the -lowlatency option.

Baseline uses a clock named std::high_resolution_clock. GM uses std::steady_clock instead. My understanding is hrc is buggy and the cause of the issue you're seeing. Usually the buggy implementation is masked by the normal throttling mechanism but when the more demanding -lowlatency throttling is used you need an accurate clock, otherwise you get these timing issues. GM uses the steady clock since long for this reason.

When I have some time I'll try to get the proper evidence for this and report it to MAMEdev.

[Trnzaddict]

I gather you're using the -lowlatency option.

Baseline uses a clock named std::high_resolution_clock. GM uses std::steady_clock instead. My understanding is hrc is buggy and the cause of the issue you're seeing. Usually the buggy implementation is masked by the normal throttling mechanism but when the more demanding -lowlatency throttling is used you need an accurate clock, otherwise you get these timing issues. GM uses the steady clock since long for this reason.

When I have some time I'll try to get the proper evidence for this and report it to MAMEdev.

Hi Calamity - Yes I was using low latency but I forgot to mention that this issue occurs on baseline even with low latency disabled. So looks like the clock you speak of in general GM uses is better than baseline. Well for me anyway. So I guess it’s back to GM.