Groovymame emulation speed

[Doozer]

Hi,

Just to share some stats on the current real-time emulation versus mame. I own the original neogeo WindJammers cartridge and I can confirm that emulation is a bit faster than original. There is a minimal deviation through time between the elapsed time counter and the emulation counter. Despite mame internal counter correction, the system is constantly delayed due to emulation offset incrementally propagating through time. This effect is depicted on the attached graphic. Looking at switchres frequency, the deviation is located at 10^-3.

Code: [Select]

SwitchRes: v0.015l, Monitor: custom, Orientation: horizontal, Modeline generation: enabled
SwitchRes: Monitor range 15625.00-16500.00,49.50-65.00,2.000,4.700,8.000,0.064,0.192,1.024,0,0,192,288,448,576
SwitchRes: Found output connector 'VGA-0'

SwitchRes: Entering switchres_modeline_setup
SwitchRes: v0.015l:[wjammers] Calculating best video mode for 320x224@59.185608 orientation: normal

SwitchRes: (   1)x(   1)_(60=60.0000Hz)
   rng(0):  320 x 224_59.186p 15.625 [integ] scale(1, 1, 1) diff(0.00, 0.00, 0.0000) ratio(1.000, 1.000)

SwitchRes: [wjammers] (1) horizontal (320x224@59.19)->(320x224@59.19)
   rng(0):  320 x 224_59.186p 15.625 [integ] scale(1, 1, 1) diff(0.00, 0.00, 0.0000) ratio(1.000, 1.000)
SwitchRes: Modeline "320x224_60 15.63KHz 59.19Hz" 6.62 320 336 368 424 224 235 238 264   -hsync -vsync


 

[Doozer]

Now, if I explicitly disable syncrefresh and waitvsync from the command line. The overall emulation is more accurate.

@Calamity, why is groovymame forcing syncrefresh hand waitvsync?

Default options

Code: [Select]

SwitchRes: Setting option -rotate
SwitchRes: Setting option -noror
SwitchRes: Setting option -autoror
SwitchRes: Setting option -norol
SwitchRes: Setting option -noautorol
SwitchRes: Setting option -noblack_frame_insertion
SwitchRes: Setting option -multithreading
SwitchRes: Setting option -syncrefresh
SwitchRes: Setting option -waitvsync
SwitchRes: Setting option -keepaspect
SwitchRes: Setting option -nounevenstretch
SwitchRes: Setting option -nofilter
SwitchRes: Setting option -prescale 1


[Doozer]

This is the same test with default settings and secondly introducing nosyncrefresh and nowaitvsync. But this time with Moonwalker rom.

Now switchres matches perfectly the game original refresh rate.

Code: [Select]

SwitchRes: Resolution change from 320x224@57.230000 normal to 256x224@57.230000 normal
SwitchRes: Resolution change to 256x224@57.230000

SwitchRes: Entering switchres_modeline_setup
SwitchRes: v0.015l:[mwalk] Calculating best video mode for 256x224@57.230000 orientation: normal

SwitchRes: (   1)x(   1)_(60=60.0000Hz)
   rng(0):  256 x 224_57.230p 15.681 [integ] scale(1, 1, 1) diff(0.00, 0.00, 0.0000) ratio(1.000, 1.000)

SwitchRes: (   1)x(   1)_(60=57.2300Hz) - locked

SwitchRes: [mwalk] (1) horizontal (256x224@57.23)->(256x224@57.23)


[intealls]

Dotclock granularity. Without syncrefresh you get the 'correct' speed but sacrifice smooth scrolling. Also, since Calamity's modeline generator is so awesome, the speed difference is so slight you really do need a plot to tell the difference.

I own the original neogeo WindJammers cartridge and I can confirm that emulation is a bit faster than original.

How did you confirm this?

[Doozer]

How did you confirm this?

A side by side comparison is quickly showing the difference. It is true that 1s delta every 16 minutes does not matter a lot. But when moving from real hardware to mame or reverse you can feel it. I am just trying to get switchres even more accurate ;-) No doubt about the wonderful job done by Calamity.

Nevertheless, I do not understand your point about syncrefresh. I have no tearing or bad scrolling when I disable it. My initial idea was that the new frame rendering delay have already some internal sync refresh mechanism.

@Calamity, is switches impacted by any kind of quartet alignment constraint that make 3 to 4 decimal digit calculation for the modeling useless?

[Doozer]

Based on the comment from Intealls, I have increase switchres calculalation decimal precision to see how far the system calculates the timings. Here is the output linked to wjammer.

Code: [Select]

SwitchRes: Entering switchres_modeline_setup
SwitchRes: v0.015l:[wjammers] Calculating best video mode for 320x224@59.185608 orientation: normal

SwitchRes: [ 640]x[ 480]_(60=60.000000Hz)
   rng(0):  640 x 480_59.185608p 29.415247 [integ] scale(2, 2, 1) diff(0.00, 6.64, 0.0000) ratio(2.000, 2.143)

SwitchRes: [wjammers] (1) horizontal (320x224@59.185608)->(640x480@59.185608)
   rng(0):  640 x 480_59.185608p 29.415247 [integ] scale(2, 2, 1) diff(0.00, 6.64, 0.0000) ratio(2.000, 2.143)

As you can see, by removing the rounding the calculation matches perfectly the refresh frequency. It means that the introduction of any vertical synchronisation mechanism shall not introduce any delay. If no delta exists between the emulation time and the real time, the offset should be a constant as seen in the second situations. The visible increasing offset in the timeline is not expected when the frequency matches perfectly. Something is happening here.

[intealls]

Something is happening here.

Yes, and that something is dotclock granularity. Even though the OS reports a perfect refresh, there's no guarantee the GPU can actually display it. You need to measure the frequency to know the truth.

[Calamity]

Something is happening here.

Indeed, dotclock granularity.

Basically, the dotclock that the drivers finally apply is just a good approximation of our requested dotclock.

Besides, our requested dotclock is anyway generally rounded to 10 kHz steps when managed internally by driver. But even if this wasn't the case, producing an exact match is mathematically impossible.

The problem the driver has to solve is to obtain your random requested frequency starting from the reference clock frequency and applying a series of discrete dividers to it, in a creative way. ATI drivers do a good job in my opinion, specially when you compare it to other implementations such as Powerstrip's.

Regarding syncrefresh, it's absolutely critical for GroovyMAME and any emulator that aspires not to suck. I wrote a long text about it, it's here.


EDIT: intealls was faster

[Doozer]

Something is happening here.

Yes, and that something is dotclock granularity. Even though the OS reports a perfect refresh, there's no guarantee the GPU can actually display it. You need to measure the frequency to know the truth.

Ok, I will check with my DSO the resulting signals.

[intealls]

Something is happening here.

Yes, and that something is dotclock granularity. Even though the OS reports a perfect refresh, there's no guarantee the GPU can actually display it. You need to measure the frequency to know the truth.

Ok, I will check with my DSO the resulting signals.

The DSO is probably overkill. A simpler way is to take the Average speed (if no framedrops occur) times the refresh MAME thinks the game should be using. This is also accurate. You might want to add a few digits to the rounding, I think it's in emu/video.c somewhere.

[Doozer]

The DSO is probably overkill. A simpler way is to take the Average speed (if no framedrops occur) times the refresh MAME thinks the game should be using. This is also accurate. You might want to add a few digits to the rounding, I think it's in emu/video.c somewhere.

I am curious to see how precise is the dotclock frequency generated by the ATI driver and how this can be correlated to the xrandr reported clock.

[Doozer]

Regarding syncrefresh, it's absolutely critical for GroovyMAME and any emulator that aspires not to suck. I wrote a long text about it, it's here.

I agree with the explanations and how it should be. Nevertheless, it does not explain why throttling + nosyncrefresh gives the right speed. Based on the article it should run at fastest speed. Do you agree?

[Calamity]

Nevertheless, it does not explain why throttling + nosyncrefresh gives the right speed. Based on the article it should run at fastest speed. Do you agree?

No, I can't see how one could reach to that conclusion based on that article. Throttling + nosyncrefresh will obviously give you the right speed at the cost of crappy scrolling (even if this is not easily detected).

[Doozer]

You might ask yourself why I am focussing on speed emulation. I do not aim to debate or challenge the current implementation nor implement a new synchronisation method. I am investigating another odd synchronisation behaviour and before pointing at subcomponents, I would prefer to understand from where the weirdness is coming from. Sorry to bother you all with this investigation but I want to trace the issue.

Based on the mentioned throttling/syncrefresh recommendation I am able to reproduce a case where emulation is not targeting 100%. With the provided mane.ini and wjammers.txt I am not able to achieve the 100% expected speed emulation in both crt and lcd timing range.
If I disable syncrefresh, the system behaves normally. As mentioned by Intealls and Calamity, the syncrefresh option is beneficial. Why is it not the case here?

[Calamity]

Hi Doozer,

You don't bother me in any way. The refresh accuracy is a recurrent topic, brought here every few months by the 1% of users that really care about this. I myself was obsessed with refresh accuracy back in 2009. Now I'm inclined to believe  you could find similar offsets between different units of the same original hardware, although I might be wrong about this.

Regarding your logs, the crazy speed points to the sync signal not being available for GroovyMAME, for whatever reason. As you know we're using drm to implement waitvsync since this feature got broken during the SDL2 migration. The bit that seems missing in your logs is the drm initialization ("/dev/dri/card0 successfully opened").

[Calamity]

Hi Doozer,

Could you confirm if this issue is caused by absent drm support?

[Doozer]

Hi Doozer,

Could you confirm if this issue is caused by absent drm support?

Yes I can confirm this. In case the call to open the DRI is failing, the deactivation of the syncrefresh option could be a good compromise. What's your opinion?

[Calamity]

Yes I can confirm this. In case the call to open the DRI is failing, the deactivation of the syncrefresh option could be a good compromise. What's your opinion?

I'm adding a fix for this, it should be quite straightforward.

Actually GM should refuse to run at all on a system without video sync but that's another matter
(we still need to use virtual machines sometimes)

[Doozer]

(we still need to use virtual machines sometimes)

Yes, I am guilty.

I tried the qxl (spice) driver and even if it exposes a drm (and associated dri interface). The results are chaotic, sync event happens every 10s more or less. Unless vt-d or IOMMU is used to access real hardware, a VM will definitely not support correct frame rendering (vmware plus guest driver is a different case). But to compile and do quick tests, VMs are contributing a lot to reduce the HW/SF setup complexity.

Thank you for taking care of non synced video systems as well.