Dolphin + GCEmu = ???

[tehdarkknight]

This may be treading on thin ice, but I was wondering if any code from
GCEmu will be incorporated into Dolphin? (If it hasn't already...)
I noticed that Fires, one of Dolphins coders, worked on GCEmu as well,
and I got to thinking. Sorry if this bugs anyone, I'm just a little excited
at the possibility of an advancement in GameCube emulation.

 

[Dysprosium]

I haven't tried GEemu myself (Haven't had a chance.), but from what I've seen, the difference from Dolphin in FPS isn't substancial. I can't see why it would be added.

Dolphin is mostly about compatibility, while GCemu seems to be proving that optimization can increase the FPS slightly; aren't these like two identical poles on a magnet?

 

[ector]

If GCemu was made as compatible as Dolphin, the speed difference would be smaller, although GCemu does have a better dynarec so the difference would not be zero.

 

[GCFreak]

I find SSBM's speed to be faster on Dolphin than GCEmu.

 

[Knuckles]

yeah but the graphics are messed and it's realllly unstable

 

[timmyhawky]

good thing from dolphin+good things from gcemu= a good emu
if these should use the tricks a lot things should be better
p.s. is gcemu faster than whinecube

 

[Guru64]

I tried GCemu, and the speed isn't that fast at all. I guess only a few games would benefit in speed.

 

[Opfer]

Hmm, one quick question: When the code would be all optimized, let's say a perfect recompiler, would the emulation run with 60FPS on a machine that can do 5 GFLOPS? Or would we still need to wait until the PCs get faster?

 

[DeathRain99]

I think it would be awesome if two groups of programmers teamed up and created something greater. The compatibility of Dolphin with the slightly faster speed of GCEmu would be very cool.

"Come together, right now..."

 

[kickukicku]

I tried GCemu, and the speed isn't that fast at all. I guess only a few games would benefit in speed.

Yeah Some 3D games nearly full speed.:w00t:
http://forums.ngemu.com/gcemu-forum/68235-gcemu-first-release-shots.html

 

[ChaosCode]

I was wondering when this one was gonna happen. The differnces between GCEmu and dolphin are the goals. I meen they both want full compat and speed but dolphin is going for combat first and GCEmu is going for speed. Good luck to both!

 

[timmyhawky]

I think it would be awesome if two groups of programmers teamed up and created something greater. The compatibility of Dolphin with the slightly faster speed of GCEmu would be very cool.

"Come together, right now..."

and the good dolphin grafX

 

[tehdarkknight]

Unfortunately, like ector said, the only thing GCEmu has going for it is a better dynarec. You would probably only get + 1 to 2 fps if it had the same compatibility as Dolphin. I guess we'll just have to wait until the authors code in more CPU optimizations like dual core, HT and whatnot. From what I understand about C++, load balancing can be a pain when dealing with multiple threads. But I trust our awesome coders!

 

[or9]

The good thing which can somewhat speed up emulation is HLE. For example matrix library calls, or THP movie playback which is actually use JPEG decompressor, HLE of OS context switcher and simple memcpy or memset C calls. Complex HLE can gain additional ~5-10 FPS.

BTW, talking about Gekko performance. Recently I made some profiling of different CPUs on matrix concatenation demo. Here is the result:

> Gekko : 2660
> P3 800 : 1800-2200
> duron 1200: 1100-1300
> 1800+XP : 900-1000
> P4 2500 : 600
> 2600 XP : 700
> 3000+ : 500
> 3200 XP : 600

This is the time, needed to concatenate a lot of matrcies, in microseconds. On Gekko I used paired singles, and on IA-32 I used SSE extension. I remind, that Gekko is at 486 Mhz.

I think the advantage of GCEmu is that its using a lot of SSE optimizations in paired single operations, which beat usual FPU implementation.

 

[GCFreak]

For once or9, you are wrong. The Gekko operates at 485MHz.

 

[BlueFalcon7]

The good thing which can somewhat speed up emulation is HLE. For example matrix library calls, or THP movie playback which is actually use JPEG decompressor, HLE of OS context switcher and simple memcpy or memset C calls. Complex HLE can gain additional ~5-10 FPS.

BTW, talking about Gekko performance. Recently I made some profiling of different CPUs on matrix concatenation demo. Here is the result:

> Gekko : 2660
> P3 800 : 1800-2200
> duron 1200: 1100-1300
> 1800+XP : 900-1000
> P4 2500 : 600
> 2600 XP : 700
> 3000+ : 500
> 3200 XP : 600

This is the time, needed to concatenate a lot of matrcies, in microseconds. On Gekko I used paired singles, and on IA-32 I used SSE extension. I remind, that Gekko is at 486 Mhz.

I think the advantage of GCEmu is that its using a lot of SSE optimizations in paired single operations, which beat usual FPU implementation.

if the Dolphin had HLE for THP playback you would get a little more gain than just 5-10 fps and when i say a little, i mean alot

 

[Tratax]

I think the advantage of GCEmu is that its using a lot of SSE optimizations in paired single operations, which beat usual FPU implementation.

Actually the funny thing is, that the SSE2 optimizations didnt make any noticable difference because of the need to load/store SSE2 registers around every basic block. It could make more of a difference if the GPU plugin would be on its own thread so it wouldnt be stepping over the SSE2 registers at random. By default (even if the CPU support SSE2!) SSE2 is DISABLED.

As your statistics already show, a 3000+ CPU is more than fast enough to do those matrix calculations but it still hits only 20% of speed in-game.

GCEmu gets its speed from not even trying to work on 'low end' systems meaning it requires a DX9 graphics card and a lot of optimizations in the recompiler to remove branch prediction problems with memory load/store access and jumping from one basic block to another.

Oh, and of course the idle loop detection helps as well. I have no idea how many instructions per frame the CPU should really do 'in the real world' assuming cache. So it is doing 15000 * 50 * 256 = 192MIPS right now and assumes the idle detection will remove the wasted time.

I had plans to do an AMD64 version where you can statically assign registers and make total use of SSE2 (assuming GPU on a thread) but I simply dont like emulating things other than the CPU and this is what is lacking in GCEmu. If the memory card and DSP would be improved a lot more games would boot and probably even work in-game. All the green screens are right now probably waiting for either DSP or memory card (they are related anyway )

There are no 'HLE' hacks in GCEmu except for the idle loop detection. If compatibility improves speed should not be affected too much. It might even improve because when all the emulation falls in place its much clearer on how to do overall optimizations.

The source is released, so feel free to take a look yourself. If someone is interested in improving compatibility then there is still work that can be done on the CPU.

 

[Allnatural]

For once or9, you are wrong. The Gekko operates at 485MHz.

 

[thakis]

Wooo, or9 is still alive

 

[PsyMan]

For once or9, you are wrong. The Gekko operates at 485MHz.

Knowing or9 and that most CPUs usually have frequencies a little higher (or lower) than the frequencies claimed by the manufacturers, then the Gekko CPU inside GameCube really operates at 486MHz.