Cave cv1k driver performance

[donluca]

Is it normal that even with a Pentium G3258 running at 4.8Ghz CAVE games don't run smoothly?

I've tried Ibara Kuro BL which is almost unplayable due to slowdowns when a lot of bullets are around, and Mushihimesama has some slowdowns at certain points when lots of enemies and bullets are on screen.

I've tried running those in SDLMame on my Mac with i7 3.4Ghz and they run smoothly.

EDIT - to make the point clear: it's not the in-game slowdown intended to help the player navigate among thousands of bullet. The audio changes pitch and the % shown by pressing F11 goes down.

EDIT 2 - Also, I'll try these games with regular MAME on my G3258 to see if they exhibit the same problems.

[Calamity]

GM always runs with v-sync enabled. This requires that every frame is emulated at least at the same speed or faster than the real hardware runs. Regular MAME has v-sync disabled by default, so frames that take longer to emulate may be compensated by frames that are emulated faster, keeping the average emulation speed constant and giving the appearence of better performance.

[donluca]

I see, I was wondering because here: http://forum.arcadecontrols.com/index.php?topic=145172.0 the guy is running the same CPU as me at 3.9Ghz (mine is at 4.8 Ghz) and he's saying he has everything running smoothly, including CAVE SH3 games.

So that had me wondering if I was missing something.

I'm using crt_emudriver (catalyst 6.5 version) with windows xp 32 bit and an ATI X300SE, while he's using Win7 64 bit.

I'm wondering if he actually played those games or just run through the attract modes.

[haynor666]

With G3258 at 4,2 Ghz there are still occiasional speed/sound slowdowns. Performance will vary on XP/XP x64/7 x64 and/or with mt disabled or enabled. From my tests the slowest is Muchi Muchi Pork.

[donluca]

Thanks for reporting!

I'll try doing some tests today. First one is a performance test with Passmark to make sure I didn't screw up something while overclocking, then I'll test with older versions of GroovyMame and/or regular MAME to see what works best for CAVE games.

I'm a great fan of bullet hell shooters (although I'm absolutely terrible at them, lol)

[donluca]

Ok, here's an update.

My G3258 is ok-ish about performance: a Passmark single thread test revealed a score of 2548 for my 4.8 Ghz vs 2503 of a 4.2 Ghz. I expected a more substantial boost, but there's that.

As predicted, running "vanilla" MAME without V-sync gave me an almost constant 100% speed and when I activated vsync it dropped down at the same levels of Groovymame (actually, much worse).

Tried also with older versions of MAME and didn't notice any improvements.

This means that even with a superclocked processor, the CAVE games are almost unplayable due to unstable frame rates, which is a bummer.

Hopefully they'll work more on the driver and optimize it in the future.

[haynor666]

Driver is already optimized but emulation lacks proper slowdowns that were on real hardware. Probably in the future driver will be even slower. Maybe Haze could shed some light on this driver and plans.

[donluca]

IIRC the problem on inaccurate slowdowns was solved by using the Blitter Delay and setting it for each game to emulate the correct amount of slowdown.

My problem here is the game not running 100% on a modern 4.8Ghz processor, while I have 3D games running smooth

If Haze reads this, it would be awesome to know if there are any further plans on this driver!

[Calamity]

As predicted, running "vanilla" MAME without V-sync gave me an almost constant 100% speed and when I activated vsync it dropped down at the same levels of Groovymame (actually, much worse).

If this is actually the issue, you can probably improve the result by running GM with -mt -tripplebuffer. This will run the v-sync code in a separate thread, so the emulation can run in parallel. You'll gain performance at the cost of choppy scrolling.

[donluca]

You'll gain performance at the cost of choppy scrolling.

Thanks, but I'd rather live without CAVE cv1k games and keep only 1 frame of input lag, v-sync and smooth scrolling

[Calamity]

Thanks, but I'd rather live without CAVE cv1k games and keep only 1 frame of input lag, v-sync and smooth scrolling

Obviously, I meant using those options only for the cv1k driver. Anyway, GM's triplebuffer doesn't add lag as other implementations do.

[donluca]

Obviously, I meant using those options only for the cv1k driver. Anyway, GM's triplebuffer doesn't add lag as other implementations do.

I knew there was a way to create per-game configurations, is there a way to create a per-driver configuration too? That would indeed be awesome!

EDIT: OMFG I figured it out myself, I just have to create a .ini file and name it with the driver's name, in this case cv1k.ini
It works!
Game plays smoothly, only thing is that the speed% shown is quite erratic, going from 97% to 102% but I think this is due to inaccuracy in MAME as the game plays really smoothly and, most important, no choppy scrolling so far!!

Thank you so much, I'm a happy gamer!

[Calamity]

Good! I think I'll split these posts about Cave to a separate thread, I'll be easier to find.

[donluca]

Good! I think I'll split these posts about Cave to a separate thread, I'll be easier to find.

Good idea.

I also suggest putting the -mt and -triplebuffer option on by default for cv1k games from the next GM release and putting a dual core processor as a requirement for running them smoothly.

One thing I've been wondering: why isn't frame delay set to 1 as default?

[Calamity]

I also suggest putting the -mt and -triplebuffer option on by default for cv1k games from the next GM release and putting a dual core processor as a requirement for running them smoothly.

This driver will eventually run ok when hardware improves. I don't think it's a good idea to force the -triplebuffer option from the source base.

One thing I've been wondering: why isn't frame delay set to 1 as default?

Because frame delay is not meant for the casual user. People with older hardware would report performance issues, etc.

[donluca]

After further testing I discovered that on my machine there's no need for triplebuffer on Muchi Muchi Pork!

Just the multithread option did it and it runs great!

EDIT: wait, there's something strange: just for fun, I've tried setting frame delay to 9 and it didn't hit the performance. Is frame delay disabled when using the multithread option? Or does the triplebuffer enable automatically when you set multithread to 1 ?

[haynor666]

I think frame_delay is no depending on mt option. From my test setting frame_delay from 0 to 3 slowdowns game a lot so You probably messed some settings.

I've made some test and I discovered strange thing - there is not frame_delay option in log file even is set through mame.ini or cv1k.ini. But from performance it's look like is set up.

Triplebuffer seems to be disabling frame_delay probably because does not make sense to use it with triplebuffer.

[donluca]

Triplebuffer seems to be disabling frame_delay probably because does not make sense to use it with triplebuffer.

Frame delay doesn't work with triplebuffer, only with syncrefresh. Frame delay is very cpu expensive, that's why you can't use a general setting for it and you need to apply a custom value per game.

The problem here is that I'm using only -mt without triplebuffer and it looks like frame delay is doing nothing since I'm running muchi muchi pork with ddraw, multithreading and frame delay 9, without triplebuffer, at 100%. It should run super slow, instead it runs at max speed, as if frame delay has been set to 0.

[Calamity]

The problem here is that I'm using only -mt without triplebuffer and it looks like frame delay is doing nothing since I'm running muchi muchi pork with ddraw, multithreading and frame delay 9, without triplebuffer, at 100%. It should run super slow, instead it runs at max speed, as if frame delay has been set to 0.

I highly doubt that. Get a log and look inside it to check whether triplebuffer is being enabled. You probably have it enabled in some left over ini file.

[donluca]

I highly doubt that. Get a log and look inside it to check whether triplebuffer is being enabled. You probably have it enabled in some left over ini file.

You're right, I've just spent some time reading some tutorials about how MAME manages .ini files and, long story short, I messed up. 

Ignore everything I wrote before, this statement stays true:

To run Muchi Muchi Pork you MUST enable multithreading and triplebuffer if you want to play it at 100%.

At least with current gen hardware. This may vary in the future with faster and more powerful processors and/or updates to the cv1k drivers.

[Haze]

If Haze reads this, it would be awesome to know if there are any further plans on this driver!

As already mentioned, the driver is already VERY heavily optimized, I'm amazed it runs as fast as it does considering there's no recompiler for the SH3 (and I have no plans to do one of those)

[donluca]

Thanks for the reply!

I understand your point, I was wondering if there's any plan to improve the accuracy, in particular the problem related to the slowdowns in the CAVE games.

Right now we have the Blitter Delay option which kind of works but we have to figure out the correct value by trial and error and, even with a certain value, there are still inaccuracies in some games.

Are we going to see any updates on the cv1k or is it considered "good enough" and be left as is, until someone else picks it up and works on it?

[Haze]

Thanks for the reply!

I understand your point, I was wondering if there's any plan to improve the accuracy, in particular the problem related to the slowdowns in the CAVE games.

Right now we have the Blitter Delay option which kind of works but we have to figure out the correct value by trial and error and, even with a certain value, there are still inaccuracies in some games.

Are we going to see any updates on the cv1k or is it considered "good enough" and be left as is, until someone else picks it up and works on it?

I don't have the information required to do that, there are even disagreements over if it's really a blitter speed problem or an SH3 speed problem or both.

It would require extensive tests to get the blitter right, including working out why the blitter microcode is changed between games (we don't use the microcode for emulation) but I can only assume it was optimized / tweaked depending on the needs of different games, so even if we do timing measurements it might not end up being a 'one size fits all' solution, and there are a lot of variables to test.

The other issue is the SH3, for any modern CPU you have things like cache, and often significant waitstates if slower parts are used.  Emulating the caching algorithms of a modern CPU is tricky, MAME assumes RAM has 0 access time (so everything is the speed it would be if read from cache) but in reality code running from RAM/ROM could be slower, or even affected by blitter operations to further complicate things.

It's taken years to finally get 99.99% perfect emulation of the blitter speeds on Robotron (only happened in the last 2-3 years) and Robotron is a FAR less complex system.

In other words, the best you're likely to see for a long time is an approximation, even the ports use approximations.

[haynor666]

I expected that games using sh3 processor won't be fast. I'm glad that I can play those games on my arcade PC connected to TV even I have many Xbox360 ports. I hope in some time Akai Katana will be added (I really don't like XBox360 ports).