MAMEWorld Forums - News - Re: MAME 0.191

> Can the following drivers be made to run faster? Konami GX

Yes, with a whole ton of effort. Ideally, it might be possible to offload the functionality of the various Konami graphics ICs onto compute shaders to leverage the GPU. But again, that would be a whole ton of effort.

Also, these days it's unlikely that the video emulation on Konami GX is the bottleneck, I seem to recall it has to do with the audio DSP needing incredibly tight sync. I don't even know how you could get around that to make it faster.

In general, I'd say that's starting our list off at a difficulty level of 10/10. This gives a good metric by which to rate the difficulty of your subsequent questions.

> Aleck 64,

That one's N64-based. At the moment, the DRC system is turned off for N64-related drivers because of some extremely rare and tough-to-debug game lockups that can happen literally minutes into the emulated game's time (so, upwards of half an hour or more in real life), but only with the DRC. It's difficult to debug in particular because the DRC doesn't have exactly the same timing as the interpreter core: whereas the interpreter core checks for interrupts after every instruction, the DRC checks for interrupts in between blocks of recompiled instructions.

Having said that, I should try to find the time to just quickly hack the interrupt-check UML into the start of mips3_dedvice::generate_opcode and see if any of these issues go away. If the DRC is fixed, that will gain a decent amount of speed back. Probably not enough to make the games run full speed on a machine that can't run some of the other drivers you mention full speed, but still a good speed increase.

On top of this, profiling with Intel VTune indicates that the main bottleneck of the N64 is not the emulation of the CPU, but the emulation of the GPU, called RDP. The amount of time spent in function calls related to the RDP dwarfs the amount of time spent elsewhere in MAME's codebase when emulating N64 games, so that would be a great place to optimize. However, the simple fact of the matter is the current implementation is slow, and no amount of optimizing what's there is going to make it that much faster.

There are, however, plenty of ways to skin this proverbial cat.

First, I'm tempted to simply ditch my current RDP code in MAME and port angrylion's C implementation back over. The two implementations have diverged wildly over the past few years, and I don't trust a number of the optimizations I've added to be bug-free, so I'd rather go back to a clean slate. I know he's spent some time doing optimization as well, so who knows, it might end up being faster. But there's a good chance it would be slower since it would involve ditching the current implementation's use of polynew.h, which lets MAME use multiple threads to speed up the emulation of GPUs like the RDP.

Another thing I'm considering is potentially doing my own reverse-engineering and seeing if I can make it any faster by making it a bit closer to how the silicon itself works. The cons include that it would effectively have worst-case performance at all times, since all "modules" would need to be advanced, whether in-use or not. It would also be a gargantuan pain in the ass. The pros include that it would give a fixed performance target, be cycle-accurate, (ideally) pass Nintendo's hardware tests, and potentially not be that much slower: 2-cycle mode would actually take two cycles, for instance, not forced through the emulation at once. This would probably be a difficulty level of about 7.5/10.

Then there's the whole subject of accelerating it on the GPU using compute shaders - and some graphics plugins for other N64 emulators have done this - but then we get into the realm of requiring a Herculean amount of effort, and knowledge that simply doesn't exist on the MAME team, myself included. Difficulty, 10/10, as with Konami GX.

> F-32, DGPIX,
> Eolith, Vegaeo?

These all use the E132XS "Hyperstone" derived CPU core. It's a pretty advanced CPU, but it's been years since the core was written, and it could use some love. Someone should throw a performance profiler at it and see what shakes loose, there could be some low-hanging fruit. If that were to be the case, the difficulty would probably me maybe 3.5/10.

A more difficult, but still doable, option would be to write a DRC frontend for it. It's fast enough to be worth it, though it of course would be a bit tough, as writing a DRC frontend tends to be. This one would probably be a 6/10.

> Ghosteo

This has a fairly fast ARM9 CPU, and profiling indicates that there isn't much to be done to make the ARM core faster in MAME. This one will require writing a DRC frontend for ARM architecture. On the bright side, I've had that exact project on my backburner for a while, and I've slowly been chipping away at it. Maybe 5/10 in difficulty, given what's left to do.

So yes, all of them can potentially be made faster. Will they be made faster? Who knows. But they can be.