GM ASIO ALPHA 0.171

[Dr.Venom]

You could also use a RAM disk to get the disk I/O issues pretty much out of the metric.

I've used this one successfully: http://reboot.pro/topic/2148-news/page-4#entry192685

That reminds me of the Amiga RAM disk

I've recreated the graph using this, but for my setup it doesn't seem to make a material difference.

In regards to variable emulation time. Deathsmiles for instance seems to vary quite a bit, and might make a nice (if difficult) test case.

It seems a difficult case indeed. The graph would suggest lowest speed is (safely) about 300%, allowing for framedelay of 6. Running deathsml with this value keeps it overrunning though. It only becomes somewhat stable when I use fd 2.

[intealls]

It seems a difficult case indeed. The graph would suggest lowest speed is (safely) about 300%, allowing for framedelay of 6. Running deathsml with this value keeps it overrunning though. It only becomes somewhat stable when I use fd 2.

Hmm. The speed percentage is updated four times per second. Maybe this isn't accurate enough. Perhaps we need to time each frame.

[Calamity]

Could you lift the veil a little bit of what possible solution with the scanline number you're thinking of?

The idea is, instead of measuring the speed when running full speed, which requires to run the game unthrottled at least once, simply start running the game with fd 0, at normal speed. But because fd is 0, the throttle function won't wait at all and will go directly to the render code. At this point, we read the current scanline. This value will indirectly give us the emulation speed, in scanlines, because we know the value it had when we left from there the last time. Ideally, on a relatively fast machine this value, with fd 0, will correspond to a scanline by the top of the screen. Say we left v-sync at the first scanline, which is #22 (remind first is not zero), and then we're back at scanline #26, this means the frame took 4 full scanlines to emulate. This means, if our vertical total is 262 lines, we could wait until scanline 262-4 = 258 and still don't miss the retrace. Thus we'd use this value as a feedback to go increasing fd internally, until we reach that position. Think the value of fd and the first scanline number when we arrive at the render code are the same concept. Obviously the problem in practice is dealing with the variable emulation speed. If the algorithm tries to squeeze the scanlines to the maximum then as soon as a frame takes an extra scanline to emulate we'll be late. So we'll need to add some sort of security buffer, of a given number of lines (this is what I meant), so we have some tolerance. This won't work anyway for games like deathsmiles with such variations in speed, and this is the situation I don't know how to deal with. A dirty but maybe effective solution would be to allow the current automatic fd value to be shown when pressing f11, and allow adjusting it manually through the ui for the cases where it's required (I'm hating the idea of adding anything to the ui but just suggesting it).
 

[intealls]

This won't work anyway for games like deathsmiles with such variations in speed

If the control loop can be made quick enough, a feasible solution might be to reset it at a missed deadline, to limit the drop to a single frame. Also, I think there's a lot more speed variation in the drivers than one would think. Did a few -nothrottle runs with neodrift/sfa3 and Mega Turrican and they vary quite a bit, as can be seen in the plots below. Of course they all eat a lot less CPU than Deathsmiles do, limiting the actual impact.

[filimpan]

lol uh, I just tried -nothrottle along with the same settings as before and got ~102000% speed o.O.

[Calamity]

If the control loop can be made quick enough, a feasible solution might be to reset it at a missed deadline, to limit the drop to a single frame. Also, I think there's a lot more speed variation in the drivers than one would think. Did a few -nothrottle runs with neodrift/sfa3 and Mega Turrican and they vary quite a bit, as can be seen in the plots below. Of course they all eat a lot less CPU than Deathsmiles do, limiting the actual impact.

The problem is how to know for sure when a deadline has been missed. Unfortunately we can't access the internal frame counter through d3d9. I believe it can be done with newer versions of DirectX though. So some heuristics are required.

[Dr.Venom]

The idea is, instead of measuring the speed when running full speed, which requires to run the game unthrottled at least once, simply start running the game with fd 0, at normal speed. But because fd is 0, the throttle function won't wait at all and will go directly to the render code. At this point, we read the current scanline. This value will indirectly give us the emulation speed, in scanlines, because we know the value it had when we left from there the last time. Ideally, on a relatively fast machine this value, with fd 0, will correspond to a scanline by the top of the screen. Say we left v-sync at the first scanline, which is #22 (remind first is not zero), and then we're back at scanline #26, this means the frame took 4 full scanlines to emulate. This means, if our vertical total is 262 lines, we could wait until scanline 262-4 = 258 and still don't miss the retrace. Thus we'd use this value as a feedback to go increasing fd internally, until we reach that position. Think the value of fd and the first scanline number when we arrive at the render code are the same concept. Obviously the problem in practice is dealing with the variable emulation speed. If the algorithm tries to squeeze the scanlines to the maximum then as soon as a frame takes an extra scanline to emulate we'll be late. So we'll need to add some sort of security buffer, of a given number of lines (this is what I meant), so we have some tolerance. This won't work anyway for games like deathsmiles with such variations in speed, and this is the situation I don't know how to deal with. A dirty but maybe effective solution would be to allow the current automatic fd value to be shown when pressing f11, and allow adjusting it manually through the ui for the cases where it's required (I'm hating the idea of adding anything to the ui but just suggesting it).

It would be interesting to see how well such an approach could work. Of course having things automatic does has its advantage, but as has been mentioned you're always a bit behind the fact, which brings its disadvantages. Personally I'm a bit skeptical as you either have to keep a very safe distance, or you run the risk of skipping frames, which is a no go in my book.

So in some sense it may be giving away some latency reduction (versus a manually optimized setting) for the benefit of ease of use. I guess I'm more of a perfectionist, wanting it to run to the absolute lowest latency. But I understand that there are users, who would gladly trade that in for some more ease of use.

I'm really liking your idea of measuring frame emulation time trough the scanline method. Could a first step possibly be to create some statistics with this, such as single longest frame time, average of 1% longest frame times, average frame time, and given this the amount of framedelay "overruns" and report these on exit? That would be really useful for having an easy way to get better understanding of how this all works out in the various drivers we're testing.

Edit: deleted some possibly incorrect reasoning re the automatic framedelay

[Dr.Venom]

The problem is how to know for sure when a deadline has been missed.

If a too high framedelay causes the frame emulation to flow over into the next frame, how is that currently handled?

WinUAE used to still flip the frame when missing vblank, as long it was less than one third into the new frame. This may lead to occasional screentearing, but Toni regarded this as being preferable to dismissing the entire frame. (Don't know if it's still working that way in WinUAE).  Maybe that could be a useful part of the approach when handling overflows with an automated framedelay algorithm?

[Dr.Venom]

If the control loop can be made quick enough, a feasible solution might be to reset it at a missed deadline, to limit the drop to a single frame. Also, I think there's a lot more speed variation in the drivers than one would think. Did a few -nothrottle runs with neodrift/sfa3 and Mega Turrican and they vary quite a bit, as can be seen in the plots below. Of course they all eat a lot less CPU than Deathsmiles do, limiting the actual impact.

This is quite enlightening, the speed variations in the drivers are certainly larger than one would think. I also ran mega turrican unthrottled, and besides there being large speed differences, it's great to see how performance sometimes dips slightly below 750%. Displays it very well why I need to run it with a max fd of 7.

Maybe a silly thought, but since this provides such a great insight, would it be an idea to add a little math and an extra colum to the asio log, that displays the maximum frame delay (preferably rounded to real framedelay units) in an additional graph?   

[intealls]

If the control loop can be made quick enough, a feasible solution might be to reset it at a missed deadline, to limit the drop to a single frame. Also, I think there's a lot more speed variation in the drivers than one would think. Did a few -nothrottle runs with neodrift/sfa3 and Mega Turrican and they vary quite a bit, as can be seen in the plots below. Of course they all eat a lot less CPU than Deathsmiles do, limiting the actual impact.

This is quite enlightening, the speed variations in the drivers are certainly larger than one would think. I also ran mega turrican unthrottled, and besides there being large speed differences, it's great to see how performance sometimes dips slightly below 750%. Displays it very well why I need to run it with a max fd of 7.

Maybe a silly thought, but since this provides such a great insight, would it be an idea to add a little math and an extra colum to the asio log, that displays the maximum frame delay (preferably rounded to real framedelay units) in an additional graph?   

Sure, I can add that to the script. When run with -nothrottle, I've changed so that the speed percentage reflects the actual frame render speed (not an average). So when specifying -nothrottle and a value for -seconds_to_run one should get a pretty good idea of what fd value could be considered stable when examining the log.

Edit:

Ok, added. -mt should be disabled. Run the game with -nosyncrefresh -nowaitvsync -nothrottle -seconds_to_run -notriplebuffer. Then simply do s('path to log', 60.0) for genesis for instance. It's saved in RAM now so the log can't be viewed until after emulator exit. I think I got the formula right, but double check it to be sure. You can also use -video none. Note that ASIO output is disabled with -nothrottle.

https://mega.nz/#!a0ZGVASI!AhPJugKmGkRqImH-chiynBGAHJGaQFyh585aPaSnXAs

Edit again:

Updated the script to output the occurrence of each fd value, minor modification

[Dr.Venom]

Ok, added. -mt should be disabled. Run the game with -nosyncrefresh -nowaitvsync -nothrottle -seconds_to_run -notriplebuffer. Then simply do s('path to log', 60.0) for genesis for instance. It's saved in RAM now so the log can't be viewed until after emulator exit. I think I got the formula right, but double check it to be sure. You can also use -video none. Note that ASIO output is disabled with -nothrottle.

https://mega.nz/#!a0ZGVASI!AhPJugKmGkRqImH-chiynBGAHJGaQFyh585aPaSnXAs

Edit again:

Updated the script to output the occurrence of each fd value

Awesome, many thanks for creating this! The addition to see the occurence of each fd value in a table is great.

With regards to the formula, I think it needs a small adjustment. Framedelay in gm is set in units of 1/10th of frametime, and is being "off" by 1 unit as Calamity noted. So although the current formula is a good approximation and works for the edge cases (such as  frame emulation time getting very small), it will generally give a (too) positive skew to the maximum framedelay values.

I changed the following line is s.m:
   

Code: [Select]

fdvals = round((frame_time - (frame_time ./ data(:,1))) / (frame_time / 9) - 0.5);to
   

Code: [Select]

fdvals = round((frame_time - (frame_time ./ data(:,1))) / (frame_time / 10) - 1 - 0.5);
The attached graphs shows how this affects the results for a run of deathsml.

I've created a simple script that asks for a driver name and time to benchmark (see attached mame64bench.bat). Just to save a bit of typing everytime. This made me think that it should be possible to extend the script with a call to Octave (CLI?) and have it all fully automated? But for that we would also need to have the driver refresh rate available to the script.

I did notice one particular thing when benching the genesis driver. There is a peculiar speeddrop to about 113% for two frames in the middle of the test when i run a bench for 240 seconds, see attached image. This occurs every time when I run the test, any idea what may be causing this?

I also wondered if there's a specific reason that the benchtest needs to be run with -mt disabled?

@Calamity
Rethinking your approach for automation of fd, that would probably nicely work for the (big) lot of drivers that are able to run at high speed, with the variations only occuring above a certain level. The problem as you noted will be with the deathsml like drivers. What would you think of an approach where if the automated fd value detects to many overruns or "resets", that it logs this with a message to the user to run a benchmark of the driver, possibly like the one that intealls created? It would need a little bit of polishing for end-user usage and robustness, but with this approach we would have the best of both worlds.

Over the years, when hardware get's more and more powerful, the need for applying the manual benchmark will ofcourse fade, and automated fd will gradually take over. I'm getting more enthusiastic about your automation idea

[Dr.Venom]

Edit: r2.1 fixes a patch apply issue

When I apply the asio_163_r2.1.diff I get this error

Code: [Select]

patching file src/osd/windows/switchres.c
Hunk #1 FAILED at 26.
1 out of 1 hunk FAILED -- saving rejects to file src/osd/windows/switchres.c#

Apparently the patch doesn't expect two empty lines at lines 28+29 in src/osd/windows/switchres.c. Removing one of those lines before applying the patch fixes it.

[intealls]

Edit: r2.1 fixes a patch apply issue

When I apply the asio_163_r2.1.diff I get this error

Code: [Select]

patching file src/osd/windows/switchres.c
Hunk #1 FAILED at 26.
1 out of 1 hunk FAILED -- saving rejects to file src/osd/windows/switchres.c#

Apparently the patch doesn't expect two empty lines at lines 28+29 in src/osd/windows/switchres.c. Removing one of those lines before applying the patch fixes it.

Sigh. I use the --ignore-all-space option when creating the diff, to make it compatible with Visual Studio. I hope this is the option causing problems. I tried applying r2.1 before posting it which worked without issues, but since you're seeing the exact same problem the patch tried to fix, it's probably not fixed.

[Dr.Venom]

There's something critical I've found out: the frame_delay value is off by 1 unit of what's supposed to be. So if you use -frame_delay 8, it's effect is -frame_delay 9. If you use -frame_delay 9, it actually "wraps" to the next frame, so -fd 9 must not be used!

Calamity, are you sure about the frame_delay being off by 1 framedelay unit (1/10th of frametime) of what it's supposed to be, or could it also be that it's off by some other (non framedelay related) constant value?

I'm starting to think it may be the latter, but could use some input from you on this.

[Dr.Venom]

Hi guys,

Some more tests results.

To summarize the findings: framedelay is not off by 1 framedelay unit, and it is possible to run fast drivers with framedelay 9 without issues.

I found out after testing some more with the benchmark tool, it showed wrong values for maximum framedelay when compared with real runs of gm, and suggested the framedelay "off by 1" notion isn't exactly right.

I managed to overclock my 4790 to 4.7Ghz stable, which made it possible to run genesis at fd8. See attached runs for the genesis driver fd8 with audio latency 1 to 3. They all run without issues. But also see the first two benchmark graphs (intealls div9 and the div10minus1 method), they incorrectly suggest a maximum framedelay of 7. Only after removing the "off by 1" correction in the benchmark formula, it shows the correct max framedelay of 8 for genesis (see benchmark-genesis-div10.png).

This made me think there's something smurfy about the framedelay "off by 1" notion. To confirm this I tested the odyssey2 driver that runs almost 3000% unthrottled and indeed, this runs completely without issues at framedelay 9, see attached graph odyssey2_fd9_48_2.png.

Based upon this the correct benchmark formula (as it stands now) is:

Code: [Select]

fdvals = round((frame_time - (frame_time ./ data(:,1))) / (frame_time / 10) - 0.5);
See the attached benchmark graph for the odyssey driver, correctly suggesting fd9. (Adding the "off by 1" would wrongly suggest max fd of 8 ).

But given Calamity's finding that there's probably some sort of offset (which now appears to be smaller than a whole framedelay unit), the question becomes how large this offset actually is and what's causing it?
 
It would suggest that the framedelay waiting loop isn't exactly started at the beginning of a new frame, but a bit (although less than a whole fd unit) later.

Hopefully we can nail this more precisely!

[Calamity]

Sorry, I'm quite busy these days...

To summarize the findings: framedelay is not off by 1 framedelay unit, and it is possible to run fast drivers with framedelay 9 without issues.

You need to log the first scanline number when you arrive at the d3d render code. That number should approximate v_total * fd /10.

[Dr.Venom]

Hi intealls,

I've been using the ASIO patch with great pleasure and find it to be pretty solid.

Since this thread is called "pre-alpha", I was wondering if you're looking for further specific improvements, before getting to beta or final stage?

[intealls]

Hi intealls,

I've been using the ASIO patch with great pleasure and find it to be pretty solid.

Since this thread is called "pre-alpha", I was wondering if you're looking for further specific improvements, before getting to beta or final stage?

Thanks!

When GM 0.165 gets released, it's going to be bumped to alpha. There's an automatic frequency calibration routine in place now, which will hopefully work well for most ASIO drivers, which eats virtually no CPU. However, it's still possible to input the manually calibrated frequency, which will disable the automatic frequency calibration.

Regarding driver stability (and performance), the more stable the driver is, the easier it gets to find the correct calibration frequency. ASIO4ALL+Realtek seems to (weirdly enough) be the most stable of the ones I've tested, it's slow though (frame_delay needs to be turned down a notch or two). kX is very unstable, but quick (doesn't seem to affect performance with high frame_delay settings). The Xonar driver is placed somewhere in between ASIO4ALL and kX. Everything can be visualized with -asio_log and Octave, so we can find the best card/driver to use.

Other than that, a lot of testing has been done for GM with LCDs. With the 0.165 release, I'm going to do a writeup of the correct settings to use (with CRTEmudriver or LCDs).

[Dr.Venom]

When GM 0.165 gets released, it's going to be bumped to alpha. There's an automatic frequency calibration routine in place now, which will hopefully work well for most ASIO drivers, which eats virtually no CPU. However, it's still possible to input the manually calibrated frequency, which will disable the automatic frequency calibration.

Sounds great, I think that especially novice users will be happy with that.

Regarding driver stability (and performance), the more stable the driver is, the easier it gets to find the correct calibration frequency. ASIO4ALL+Realtek seems to (weirdly enough) be the most stable of the ones I've tested, it's slow though (frame_delay needs to be turned down a notch or two). kX is very unstable, but quick (doesn't seem to affect performance with high frame_delay settings). The Xonar driver is placed somewhere in between ASIO4ALL and kX. Everything can be visualized with -asio_log and Octave, so we can find the best card/driver to use.

Yes the difference between the various drivers is interesting. It may be that the ASIO4ALL+Realtek seems most stable because your other two options are on PCI-Express. In my experience using the HPET timer causes unstable results for audio-cards on PCI-Express. On-board soundchips seem much less affected in the same situation (thus making them look relatively stable).

The only solution to that is using the PMTimer (~3.579545 MHz), which can be accessed in W7 by the combination of:
- HPET OFF in bios
- bcdedit /set useplatformclock true

I know your systems don't have the ability to switch off the HPET in BIOS, but if you would ever get the chance to test the Kx and xonar cards/drivers on a system with above settings, it would be interesting to see if you get different (i.e. more stable) results for the PCI-Express cards. But only testing it would confirm it, so I'm interested in the results also

Other than that, a lot of testing has been done for GM with LCDs. With the 0.165 release, I'm going to do a writeup of the correct settings to use (with CRTEmudriver or LCDs).

Great, looking forward to that!

[intealls]

Bump to 0.165! Check the first post for info.

[big10p]

Will be grabbing this as soon as I get spare time aware from restoring another cab. The auto calibration sounds great! Thanks intealls!! 

[vicosku]

Thanks for the latest update!  Seems great so far.  Does your bench show that you can use frame_delay 8 reliably with any games? Everything I've checked so far gives me a figure above 95%.  For example, I can run Terra Cresta at 2925%, but the bench indicates I should use frame_delay 7.  I'm just wondering what other people are seeing. 

[intealls]

Thanks for the latest update!  Seems great so far.  Does your bench show that you can use frame_delay 8 reliably with any games? Everything I've checked so far gives me a figure above 95%.  For example, I can run Terra Cresta at 2925%, but the bench indicates I should use frame_delay 7.  I'm just wondering what other people are seeing.

The benchmark simply measures frame times and reports the occurrence of observed frame times as percentages of frame delay values. The benchmark is also likely to be driver dependent, of the ones I've tested, the kX driver seems to be the fastest. Try doing a bench with -sound none, even though I can't really recommend this. One should also run the bench at least twice, to rule out issues with the PC.

When testing, I've found that the frame delay value the benchmark reports will enable you to run the benchmarked game with a minimal amount/no frameskips (which in turn will not make the buffer over/underrun), however, you should be able to get pacman to report 8 (it runs at several thousand percent). Have you successfully been able to run terracre at fd 8 for a longer period of time (say 20-30 minutes) without over/underrun issues?

[vicosku]

Thanks for verifying.  This is what I get with Pacman.

SwitchRes: [pacman] (1) vertical (224x288@60.61)->(2560x288@51.14)
Frame delay/percentage: 0/0.06% 8/99.94%
Average speed: 16474.14% (180 seconds)

At frame_delay 8 with no ini files present, I got "ASIO: Overrun/underrun: 683/130" over 42 minutes.

So I assume the bench is accurate.  This is with the kx driver with the default sync and 96 samples.  I tried different values up to 384 but the bench result was the same. 

This machine is heavily overclocked so I probably have some issues running fd8 reliably.  Very nice to have some additional information to verify this rather than unknowingly running with unstable settings.  I'll work on it sometime.  Thanks again!

[intealls]

At frame_delay 8 with no ini files present, I got "ASIO: Overrun/underrun: 683/130" over 42 minutes.

This was with terracre, right? On my G3258 clocked at 4 GHz with kX (96 sample size, default sync) I get ASIO: Overrun/underrun: 2/1 after a 1500 second pacman run. It might be possible to get rid of the over/underruns completely by setting -nosleep and -priority 1.

Also as a reminder, for proper ASIO operation multithreading must be enabled.

[vicosku]

Thanks.  This was with Pacman.  setting sleep to 0 and priority 1 is my normal config, but these options didn't change anything.  I still get a 99.99% fd8 value from -bench along with overruns/underruns.  I tried a variety of things this morning and nothing really changed the situation. 

-Tried each HPET/bcdedit configuration for timers.
-Reset BIOS to default settings to eliminate overclock.
-Tried high audio latencies and various Kx settings (Default, KRNL/SMP, etc...)
-Tried both regular and super resolution configs in VMMWAKER
-Removed secondary monitor
-Tried both d3d and ddraw
-adjusted a variety of overclocking settings and disabled some CPU features like speedstep and others.

That's about it, I think.  I assume this is just the limit of what my current hardware configuration can do with stability at frame_delay 8.  However, I can run most games at frame_delay 7 with very low audio latency, so I'm quite happy regardless.  When I get a chance to rebuild my secondary machine that uses older hardware, I'll see if it behaves the same.

[intealls]

Thanks for the detailed tests!

Very strange. What kX driver version and card are you using?

Would you mind giving ASIO4ALL a go (preferrably with official Realtek drivers) and see if it behaves the same?

[Calamity]

Hi vicosku,

Thanks for verifying.  This is what I get with Pacman.

SwitchRes: [pacman] (1) vertical (224x288@60.61)->(2560x288@51.14)
Frame delay/percentage: 0/0.06% 8/99.94%
Average speed: 16474.14% (180 seconds)

At frame_delay 8 with no ini files present, I got "ASIO: Overrun/underrun: 683/130" over 42 minutes.

You can't use that game for testing purposes as it's probably activating triplebuffer (check your log). With triplebuffer enabled no proper timing based on vsync is possible. Actually syncrefresh is indispensable for frame_delay to work at all. GM can only use either triplebuffer or syncrefresh, not both, that's the problem. You don't need to force syncrefresh manually, however, it'll be enabled automatically by GM, except in cases like this where the target refresh can't be achieved (60.61 vs 51.14). So what you have to do is to run this game at its native orientation.

[intealls]

Actually syncrefresh is indispensable for frame_delay to work at all.

Thanks for pointing this out, I was under the false impression frame_delay was active also when triple buffer was active. I should also add to the first post that it's very much recommended to let SwitchRes handle all the settings (which is why multithreading needs to be enabled (triple buffer)). Pretty much all of my recent testing is done with SwitchRes handling all settings.

Another game that runs as fast as pacman is rallyx, which might be better to use as a 'does the rig work properly' test, since it's horizontally oriented.

[filimpan]

The automatic frequency calibration seems to work just as well as manually inputting a value, so that's cool .

The dialogue box for the benchmark disappears immediately just like the batool64 cal freq one used to. "Press any key to exit" would be nice on this one too.

I managed to print screen the benchmark dialog box before it disappeared, and I basically got a similar result to the one in the first post, but using SFIII: 3rd Strike, so something like:

Frame delay/percentage: 0/0.31% 7/3.51% 8/96.18%

I was using fd_8 before, but tried 7 in light of this result. Thing is, there wasn't much difference in buffer overruns and underruns. For a 1 minute run of SFIII:3rd Strike I got 2/4 with 96 samples and fd_8, and 0/3 with fd_7. At 196 samples, both values of fd resulted in 0/2. At 288 samples, both values got 0/1. To me, that's a negligible difference, especially because I intend to use 288 samples at which there was literally no difference in my brief testing. Should I carry on using fd_8 in this case, or are the bench results indicating something important (other than the best value for audio), like video framerate stability?

[intealls]

The automatic frequency calibration seems to work just as well as manually inputting a value, so that's cool .

The dialogue box for the benchmark disappears immediately just like the batool64 cal freq one used to. "Press any key to exit" would be nice on this one too.

I managed to print screen the benchmark dialog box before it disappeared, and I basically got a similar result to the one in the first post, but using SFIII: 3rd Strike, so something like:

Frame delay/percentage: 0/0.31% 7/3.51% 8/96.18%

I was using fd_8 before, but tried 7 in light of this result. Thing is, there wasn't much difference in buffer overruns and underruns. For a 1 minute run of SFIII:3rd Strike I got 2/4 with 96 samples and fd_8, and 0/3 with fd_7. At 196 samples, both values of fd resulted in 0/2. At 288 samples, both values got 0/1. To me, that's a negligible difference, especially because I intend to use 288 samples at which there was literally no difference in my brief testing. Should I carry on using fd_8 in this case, or are the bench results indicating something important (other than the best value for audio), like video framerate stability?

What monitor configuration are you using now? As Calamity pointed out a few posts up, if you're not using syncrefresh (check the log), frame_delay isn't active.

Sfiii3 exhibits varying speeds at in-game transitions (fight->ranking screen etc), and you should probably get worse performance than you're getting.

On my i7-6700k (4.3GHz) I get

Code: [Select]

Frame delay/percentage: 0/0.13% 2/0.01% 4/0.07% 5/0.07% 6/0.34% 7/12.75% 8/86.65%

With sfiii3. I get similar performance with my G3258 at 4GHz. Also, you should start using cmd to start GM. That way the results won't disappear.

[filimpan]

Log says:

SwitchRes: Setting option -syncrefresh

In mame.ini:

syncrefresh               1

[intealls]

Log says:

SwitchRes: Setting option -syncrefresh

In mame.ini:

syncrefresh               1

Ok, I can't explain this. Would you mind doing a 10 minute run with -asio_log set and upload the log somewhere? All of my testing with sfiii3 has shown that the speed will drop at in-game transitions, leading to underruns. I've attached what a run on my G3258 looks like.

Edit: What CPU are you using btw?

[filimpan]

Ok, I just played arcade mode for 10 minutes (lots of transitions) with fd_8 and 288 samples and got 0/25. I've attached the asio log and the -v log.

I have an i5-3570k@4.2GHz.

[intealls]

Ok, I just played arcade mode for 10 minutes (lots of transitions) with fd_8 and 288 samples and got 0/25. I've attached the asio log and the -v log.

I have an i5-3570k@4.2GHz.

Thanks alot for this. Your log shows the same behavior, if I were to try and explain the minor performance difference between fd8 and fd7, I'd say that the majority of underruns are caused by the transitions, the speeds in between transitions are probably fd8+.

[filimpan]

Ah ok. So do you think it would be fine for me to use fd_8 then?

[intealls]

Ah ok. So do you think it would be fine for me to use fd_8 then?

For this particular game, if you can live with a few underruns at in-game transitions, sure.

sfiii3 is tricky, to get rid of the underruns at in-game transitions, you'd pretty much have to run the game at fd1.

[filimpan]

Ya, that's totally acceptable. Thanks

[Dr.Venom]

Hi intealls,

Thanks for the update. I've been doing a little testing and overall it works great.

Three minor issues:

There seems to be an issue with the -bench time. The seconds to run is not set in seconds but in 1/10ths of seconds?  So if I use -bench 60, it will only run for 6 seconds. Doing a -bench 600 will run for about 60 seconds.

For games that have writeconfig set to "1" in the ini, using the -bench option will overwrite certain settings, which makes it a hassle to start the game next time. Could you possibly add "-nowriteconfig" when the -bench option is used? That way it will not overwrite settings.

With regards to the framedelay benchmark, it's very nice to have it in there. Coming back to an old issue, for my setup most benchmark results seem to be a bit on the conservative side though. I guess this is because you're using 9 bins, while groovymame framedelay is set in 1/10ths of frametime. Theoretically you should be using 10bins for the calculation.

I guess you're still using 9 bins, because of Calamity's findings of not using framedelay 9? Calamity's findings may be machine and/or video card specific though. (I've also shown in an earlier post that fd9 is possible without issues.)

IMO, I'd rather have the benchmark results show accurate information, based on the correct math, instead of an artifical curtailing of the results. That way the user can decide what value he'd like to use based on the true bin results. I'd love to hear your take on this.

On my i7-6700k (4.3GHz) I get

That's a pretty decent specced cpu Out of interest, what mainboard are you using with it?

Thanks again for your continued work on gmasio, great stuff.

[intealls]

There seems to be an issue with the -bench time. The seconds to run is not set in seconds but in 1/10ths of seconds?  So if I use -bench 60, it will only run for 6 seconds. Doing a -bench 600 will run for about 60 seconds.

Very strange, it works properly on my main rig and GM rig. Does it exhibit the same behavior with -seconds_to_run?

For games that have writeconfig set to "1" in the ini, using the -bench option will overwrite certain settings, which makes it a hassle to start the game next time. Could you possibly add "-nowriteconfig" when the -bench option is used? That way it will not overwrite settings.

Sure, will add it to the next update.

With regards to the framedelay benchmark, it's very nice to have it in there. Coming back to an old issue, for my setup most benchmark results seem to be a bit on the conservative side though. I guess this is because you're using 9 bins, while groovymame framedelay is set in 1/10ths of frametime. Theoretically you should be using 10bins for the calculation.

I guess you're still using 9 bins, because of Calamity's findings of not using framedelay 9? Calamity's findings may be machine and/or video card specific though. (I've also shown in an earlier post that fd9 is possible without issues.)

IMO, I'd rather have the benchmark results show accurate information, based on the correct math, instead of an artifical curtailing of the results. That way the user can decide what value he'd like to use based on the true bin results. I'd love to hear your take on this.

Yes, it's based on Calamity's findings. I've noticed that my GM rig (G3258 @ 4GHz) can run neogeo games at fd8 without issues, even though the benchmark tells me the maximum setting should be 7. I also seem to be able to run nrallyx at fd9 without issues. But I really need to understand every aspect of frame delay before altering it.

The formula used is a simplified version of this one (from a previous post of yours)

Code: [Select]

(frame_time - (frame_time ./ data(:,1))) / (frame_time / 10) - 1 - 0.5)


That's a pretty decent specced cpu Out of interest, what mainboard are you using with it?

ASUS Z170-A. It sure is nice to have a fast rig again. Compilation time is really reduced compared to my i5-2500k.