View Full Version : Dolphin + GCEmu = ???
tehdarkknight
January 31st, 2006, 00:52
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
January 31st, 2006, 01:03
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
January 31st, 2006, 01:10
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
January 31st, 2006, 08:37
I find SSBM's speed to be faster on Dolphin than GCEmu.
Knuckles
January 31st, 2006, 14:31
yeah but the graphics are messed and it's realllly unstable :P
timmyhawky
January 31st, 2006, 15:47
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
January 31st, 2006, 17:37
I tried GCemu, and the speed isn't that fast at all. I guess only a few games would benefit in speed.
Opfer
January 31st, 2006, 23:12
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
February 1st, 2006, 02:23
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..." :-P
ChaosCode
February 1st, 2006, 18:31
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
February 1st, 2006, 19:44
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..." :-P
and the good dolphin grafX :P
tehdarkknight
February 2nd, 2006, 00:08
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
February 3rd, 2006, 22:56
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
February 4th, 2006, 00:06
For once or9, you are wrong. The Gekko operates at 485MHz.
BlueFalcon7
February 4th, 2006, 03:12
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
February 4th, 2006, 07:27
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
February 4th, 2006, 16:26
For once or9, you are wrong. The Gekko operates at 485MHz.
:rolleyes:
thakis
February 4th, 2006, 17:38
Wooo, or9 is still alive :-P :-)
PsyMan
February 5th, 2006, 10:21
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. :P
GCFreak
February 5th, 2006, 20:23
:P Wow, really? I never knew that.
Clements
February 5th, 2006, 20:33
For the record, most tech docs and homebrew sites I've seen state 486MHz - and I trust or9. Mostly non-technical sites state 485MHz.
ScottJC
February 5th, 2006, 21:29
Wow, 1mhz. that makes a world of difference.
Agozer
February 5th, 2006, 22:39
Wow, 1mhz. that makes a world of difference.
It does make a world of difference when you are trying to amulate something as accurately as possible.
ScottJC
February 6th, 2006, 07:34
Perhaps, but i'm willing to bet the human eye wouldn't notice the difference. In any case arguing over 1mhz is pointless. Its like me making my processor 3001mhz, It is trivial information and i'm sure GC Emu authors have got it right at 486mhz anyway.
ChaosCode
February 6th, 2006, 20:06
Perhaps, but i'm willing to bet the human eye wouldn't notice the difference. In any case arguing over 1mhz is pointless. Its like me making my processor 3001mhz, It is trivial information and i'm sure GC Emu authors have got it right at 486mhz anyway.
When writing a emulator and doing Timming it does matter a great deal.
Powered by vBulletin® Version 4.1.10 Copyright © 2012 vBulletin Solutions, Inc. All rights reserved.