Low FPS with Dolphin [Archive]

Toasty

July 9th, 2007, 12:42

I read the FAQ's beforehand and spent quite some time doing it, i just can't seem to figure it out, I'm not a dumbass or a lazy fu** trying to make other people figure out my problem.
What exactly did you spend quite some time doing? This is the relevant question in the FAQ:

Q: Whoa, Dolphin is running as fast as a pregnant snail, what am I doing wrong?
A: The Nintendo Gamecube is a very advanced platform and (todays) computers are not fast enough yet to emulate it with the techniques we use. So... you aren't doing anything wrong! Upgrading a CPU or GPU won't gain you much more performance (you will only gain 1-5 fps). IF you decide to upgrade just besure to get a 64-bit CPU and a GPU which supports (at least) 2.0 pixelshaders.
In simpler language, decent speed emulation is not going to happen with today's technology and emulators.

kerkelenz

July 9th, 2007, 13:28

[SS] Starscream

July 9th, 2007, 15:17

In the future your computer specs will be able to run a gamecube emulator at a nice speed, but at this time no one has devoted enough time into this hard to emulate console to get great results yet.

Agozer

July 9th, 2007, 15:29

In short, you're computer isn't fast enough to emulate the GameCube at full speed, no matter how high-end your computer might be. True, future versions of Dolphin could very well bring change when it's optimized for multi-core processors.

But until then, get yourself a Wii or a GameCube.

Doomulation

July 9th, 2007, 18:04

Well I ignored that one due to the fact that the GameCube hardware is by far outdated with Quad core CPU's and DX10 GPU's supporting shader model 4.0, so why would it be so slow, I am running a computer with an Intel Core 2 Extreme and dual 8800GTX's, I really dont' get it.

A simple answer to your question:
When you play a PC game - you play a PC game on the CPU and the graphics on the GPU and the rest of the work on the rest of the hardware. When you play an emulator game, you play the game plus do all the hardware (that includes GPU; though not the rendering) work on the CPU ALONE (most of the time anyway). There are far more interesting explanations somewhere on the board, though I can't remember where.
Of course, you can always ask for us to indulge you further as to why this phenomenon happens.

Tagrineth

July 9th, 2007, 22:51

Keep in mind emulation is significantly more difficult than running code natively.

For comparison, my first PC, a 233MHz Pentium MMX, couldn't run some SNES games at full speed with sound and effects.

That's SNES. For reference, SNES has a 3.58Mhz CPU. Do the math.

My old 800MHz Pentium 3 couldn't emulate N64 or PS1 fullspeed either, and those are 94.5 and 33.4MHz CPUs, respectively.

Emulation takes a metric fuckton of extra horsepower. :)

[SS] Starscream

July 9th, 2007, 23:00

I don't think that's true. The problem is the dev teams for all these emulators are guessing and really do not have a good idea of what works and what does not and basically flying blind here. If Nintendo were to emulate their own console (having all the info needed as they do) they could do it on what would be considered a weak PC of today.

enix-sama

July 9th, 2007, 23:39

Oh I'm sure that's true. I saw some "making of" type video on games and saw wind waker being run on a pc, and it didn't look like video capture. So I think they probably exist and are used for testing within gamecube game development.

Allnatural

July 10th, 2007, 01:08

Starscream;384025']I don't think that's true. The problem is the dev teams for all these emulators are guessing and really do not have a good idea of what works and what does not and basically flying blind here. If Nintendo were to emulate their own console (having all the info needed as they do) they could do it on what would be considered a weak PC of today.
On the contrary. As developers learn more about the hardware and increase emulation accuracy the hardware requirements generally go up (e.g. MAME, bsnes).

Could Nintendo do it better? I don't know, but I suspect they're using a fair amount of HLE with their existing emulators (i.e. the Wii's virtual console).

Doomulation

July 10th, 2007, 17:23

Starscream;384025']I don't think that's true. The problem is the dev teams for all these emulators are guessing and really do not have a good idea of what works and what does not and basically flying blind here. If Nintendo were to emulate their own console (having all the info needed as they do) they could do it on what would be considered a weak PC of today.

Ha! You know not of what you speak!
Create an emulator yourself and see if you truly are right.
Emulation is a complex operation and that's true - now if you can prove all authors that create emulators out there that they are wrong, that they are lazy - I'd love to see you try. Yes, do it yourself. There's lots of documentation on how systems work out there.

[SS] Starscream

July 10th, 2007, 17:41

No. Not for me to do it myself. Not that they are lazy, but they do not know nintendo as well as nintendo does. I'm not knocking the dophin teams hard work or effort, but i believe it is possible to run a gamecube emulator on a single core 64 bit OS with all the proper information that nintendo knows that the devs have to guess and figure out on their own and that takes a whole lot of time.

Don't be one of those retards who like to say "well make your own emulator". Don't be one of those guys who can't come up with something original or worth while to say.

kerkelenz

July 11th, 2007, 07:55

Well as a Game developer I can understand where this is going and I am indeed a dumbass for saying what I said, A computer has RAM, CPU's, and GPU's as three seperate things for a good reason - the operating system and the programs secretely running in the background, games developed on computers are built to take use of cpu's, ram, and gpu's for mostly different things, RAM for pre-processing and temporarilly storing data, then transfer it to the GPU to be rendered, and then other data like AI and other Scripted functions to the CPU. But then creating an emulator makes this process a wee bit harder, and I personally think it would be easier to reverse engineer (or get a sourcecode) of a certain game and since they're all developed on PC's anyway, re-compile it for PC, after a lot of scripting that is..

Sorry again for that stupid remark.

Doomulation

July 11th, 2007, 17:09

Starscream;384065']No. Not for me to do it myself. Not that they are lazy, but they do not know nintendo as well as nintendo does. I'm not knocking the dophin teams hard work or effort, but i believe it is possible to run a gamecube emulator on a single core 64 bit OS with all the proper information that nintendo knows that the devs have to guess and figure out on their own and that takes a whole lot of time
Now, this I sincerely doubt. Why? Because emulation is not a simple task. The GameCube has about a 450 MHz processor, right? Well, let's think it this way... If each instruction executed on the GC needs 4 instructions to execute on PC, you'll need 450 x 4 = 1.8 GHz of processor power. Of course, this is just an estimation. There are more factors as well. Different opcodes take more/less opcodes to execute, then we have API overhead, then we have background processes and all that and the worst of all is that after this, we've just emulated the processor. The rest of the hardware needs to be emulated too! Now do you see why it is so hard?
Will we get to see it full speed sometime in the future? Yes, most likely. But only on those which have 2 or mores cores, I believe. Perhaps the sweet spot is 4 cores, and when optimized enough, then maybe 2. 2 when we push up the speed of the processors enough. And maybe if we enlist the GPU for help with some number crunching. But I doubt that... emulation isn't that much about number crunching...

Don't be one of those retards who like to say "well make your own emulator". Don't be one of those guys who can't come up with something original or worth while to say.
Then don't be a retard and insult the authors. Come with some good arguments, make sure you really know what you're talking about and I'll not call you a retard if you call authors lazy.

But then creating an emulator makes this process a wee bit harder, and I personally think it would be easier to reverse engineer (or get a sourcecode) of a certain game and since they're all developed on PC's anyway, re-compile it for PC, after a lot of scripting that is..

Sorry again for that stupid remark.

Perhaps it is... but again, you must remember that though they're developed and compiled on PCs, they're run on the console hardware and written for it. Perhaps it is easier to write an emulator, and then again, perhaps not. I don't know. And we're not talking about speed here, just getting it working. But porting it wouldn't be easy either. But that's just what I believe.

[SS] Starscream

July 11th, 2007, 17:51

I never insulted the authors and i never called them lazy, those are your words.

Doomulation

July 11th, 2007, 19:35

I didn't say you insulted them, did I (or I really? :P)?
Anyhow, whatever you did, you did mention that you think emulation of GC can run on one core only full speed. My thoughts on that is: not possible. GC emulation is just too demanding.

However, you DID mention that authors really have no (pretty much; guessing anyway) idea what they're doing and that Nintendo could create a GC emulator on a weak PC (single core, yes?). Well, to that the answer is simply no.
I will mention this again just so we're clear, yes? It's not that authors do not know the system. If they don't, the emulators tend to be faster actually (because of less emulation)! But as they know more, it gets slower due to more emulation...
Nintendo themselves couldn't create a better emulator on a PC, as you would see... It just isn't possible. And I'm sure you'd hear the same from a lot of others.

Now. I'm not insulting you or calling you anything, okay? You are just a little misguided with wrong information. That will be all.

Falcon4ever

July 11th, 2007, 19:45

Starscream;384188']I never insulted the authors and i never called them lazy, those are your words.

pff that's no insult, most emu authors are lazy ;)... they are almost like real people =]

[SS] Starscream

July 11th, 2007, 19:47

Then don't be a retard and insult the authors

First you make up things and put them in others peoples mouthes, then you try to use it against them as if they said it. You obviously do not know what you're talking about if you cannot remember what you said from one post to he next, After all that the rest of what you have to say is worthless.

I say it can be done with a good AMD64 processor and a 64bit OS, we will just have to wait till someone gets it right.

kerkelenz

July 11th, 2007, 22:43

Isnt it stated somewhere in the rules to stay on topic, because I dont think this is on topic, quite far from it actually..

[SS] Starscream

July 12th, 2007, 09:37

Nope, no such emulator. Emulation is hard and the GC architecture just eats away at resources. We'll be needing more cores to get faster emulation!

not really Doom. the 64 bits version of dolphin (unreleased) is already running quite fast in most games even on my system. A system like his should prolly run even faster.

Gekko's int right now is really promising in term of speed comparing with other emus. I won't say much about this right now....

Taken from another thread. I would think a beta tester knows how the thing plays right in front of him.

Doomulation

July 12th, 2007, 17:11

Starscream;384209']First you make up things and put them in others peoples mouthes, then you try to use it against them as if they said it. You obviously do not know what you're talking about if you cannot remember what you said from one post to he next, After all that the rest of what you have to say is worthless.

I say it can be done with a good AMD64 processor and a 64bit OS, we will just have to wait till someone gets it right.
I take it back. You are a retard. You don't listen to what others say.

Starscream;384267']Taken from another thread. I would think a beta tester knows how the thing plays right in front of him.
But it still contradicts what you say. 64-bit dolphin runs on two cores AFAIK. Having written a interpreter myself, I know a little about emulation. Though I haven't written a dynamic recompiler, I would still say that you can't get it working on a single core. We're talking about FULL speed here!

Dolphin and Gekko has achieved pretty good speeds now, but do they run on single core? I think not. Dunno much about Gekko, but Dolphin is dual core now AFAIK.

I'm tired of arguing this. So... who votes that GC emulation will run on a single core? Yay or nay?

Toasty

July 12th, 2007, 22:44

This is kind of a silly argument. A GC emulator will certainly run at full speed on a single core CPU - if the single-core CPU is fast enough. Just like a GC emulator will run at full speed on a dual-core CPU if it is fast enough. If the GC emulator happens to be multi-threaded, the clock speed of the dual-core CPU might not have to be quite as high as that of a single-core with the same architecture (perhaps even close to half). Right now it's a completely irrelevant point because there are no GC emulators (at least, no publicly available ones) that can run at full speed on today's single-core or dual-core processors.

Until there are, the only discussion that can be had is, "I think a well-optimized GC emulator will run on this CPU." While another person says, "No, no, NOOO. That won't work; I think a well-optimized GC emulator will only run on this CPU." Without an actual, well-optimized GC emulator with which to conduct tests it's a pointless argument.

That said, emulation tends to require at least an order of magnitude more power on the host platform than the emulated platform. So, at this point, some dual-core CPUs may have enough raw power, but with how difficult it is to program an application (particularly one as complicated as an emulator) to take full advantage of multiple processors, it's still going to be a daunting (if not impossible) task to get one up to full speed on them. Intel and AMD have retired most of their single-core efforts to budget lines and reserve the higher clock speeds for their mainstream and enthusiast lines (which are pretty much all multi-core CPUs). That being the case, if a mature GC emulator emerges in the near future, I doubt that current single-core CPUs will have the power to run it at full speed, at least initially.

That's not a failing in single-core CPUs, but rather a result of manufacturers devoting less attention to their budget lines. Eventually, as long as manufacturers keep making single-core CPUs and keep speeding up clock speeds and/or IPCs, I have no doubt that single-core CPUs will eventually be able to tackle this well-optimized GC emulator that doesn't quite exist yet. Anyway, that's my opinion. If yours differs from it, more power to you, but arguing about it and trying to use a vote to decide the requirements of future software will accomplish nothing.

Tagrineth

July 13th, 2007, 06:29

I love you toasty, be mine forever :flowers:

Doomulation

July 13th, 2007, 12:01

Eh... There's one thing we're forgetting here...
The reason we're going dual core (or more) is because we're hitting the limit on how much speed we can cram into a single core. Single cores just can't get much faster in terms of speed, at least not for long. It's physics and we can't do anything about that.
This is why I'm proposing that GC emulator will need at least dual core.

It may be possible to get said emulator to run on a single core maybe... long in the future when the architecture is much more refined and smaller and faster clock speeds. But at that point, we'll probably all use dual, quad core or maybe even more cores and single cores will be of the past, so there will be little use for any said emulator to run on a single core anyway...

This is just my theory, of course...

Toasty

July 13th, 2007, 13:13

That's a valid point and I agree with you. (Though only time will tell.) It's unfortunate that right now we're seeing a pattern with multiple cores similar to the one a few years ago with ever increasing clock speeds. Not that having more cores is a bad thing, but some tasks really can't benefit from multiple processors, and even when a task can be multi-threaded, that doesn't mean it will be easy to do. I'm hoping AMD's new architecture will be good competition against Core, because architecture improvements are really in everyone's best interest since we've kind of hit a clock speed barrier for the moment.

I love you toasty, be mine forever :flowers:
Aw, shucks. Add on another flower and we'll talk. ;)

[SS] Starscream

July 13th, 2007, 14:17

I don't know why you guys are so hung up on two processors... you're forgetting about a 64bit OS's that can take up the slack. A 3.0GHZ AMD 64 processor should be able to run a GC emu when the emu is optimized in the future.

On another note, i don't think the devs will try to make it run full speed on one processor because that will take alot more optimizing and work than dual core, but it can be done.

Doomulation

July 13th, 2007, 15:53

Starscream;384477']I don't know why you guys are so hung up on two processors... you're forgetting about a 64bit OS's that can take up the slack. A 3.0GHZ AMD 64 processor should be able to run a GC emu when the emu is optimized in the future.
A 3 GHz AMD64 processor? Hardly. A new architecture long in the future? Perhaps.
Did we forget about 64-bit? No. Does it really help? Yes, but it's not a miracle. 64-bit dolphin still does not run full speed on two cores.
Remember that even with new architectures comes speed boosts of 50-60%, but this is not a miracle either. Don't expect everything to gain a speed boost such as that.

Starscream;384477']On another note, i don't think the devs will try to make it run full speed on one processor because that will take alot more optimizing and work than dual core, but it can be done.

Again, you're just guessing. Prove me it can be done and I'll believe you. Otherwise, stop pretending like you know. The keyword is maybe. MAYBE it can be done. There's no 100% guarantee.

[SS] Starscream

July 13th, 2007, 16:16

Prove to you? What should i write you a GC emulator right here in this thread? I don't have to prove anything to you and neither do you, just stop responding to my posts already, you're useless.

Clements

July 13th, 2007, 19:08

I am certainly not convinced that any GC emulator will run full speed on a 3GHz Athlon64 with at least half of the games. PCSX2 doesn't even run full speed with that CPU, or even an Athlon64 X2 with the majority of games with full dual-core, SSE2 optimisations and a dynarec - and a GC has more powerful hardware than a PS2. To me, that seems like an arbitrary guess with no evidence, or simply wishful thinking.

Athlon64 architecture is really crippled with regards to how many SSE operations it can handle in a single clock cycle, which slows the frame rate on PCSX2 considerably, and it will be the same with GC.

pubjoe

July 14th, 2007, 04:06

I believe that these are very early days in powerpc emulation. The developers are treading new ground in it's development. Correct me if I'm wrong (because I may well be), but isn't it to be expected that the gamecube's cpu emulation alone is going to be far from optimized. And certainly emulated at a high level.

Being able to run on a specifically powered (3ghz or whatever) cpu might technically be possible. And I presume that, running on a single core ppc processor is more easily possible. But I agree that the question is irrelevant.

But, Nintendo themselves are not much more qualified (if at all) to emulate their own console than experienced emulator developers are, nintendo, sega and sony have all employed known emulator developers in the past.

Well as a Game developer...
...and I personally think it would be easier to reverse engineer (or get a sourcecode) of a certain game and since they're all developed on PC's anyway, re-compile it for PC, after a lot of scripting that is.

The fact that gamecube games are developed in-house on workstations (not "PCs") is beside the point. They are not merely "compiled" for the GC. Nintendo game engines are written from the ground up for nintendo's set of hardware. A workstation is not a PC. And a "PC" is too loose a description anyway, a PC With one ppc processor, or ten x86 processors is still a PC... But it doesn't help compatibilty for us with our windows boxes does it?

And as for reverse engineering a game being easier? No such task would ever be considered for a modern game! What do you suggest? Bosh out a game a week? Simple as that. Or does somebody phone up shigeru miyamoto, and say "Shiggsy mate, how you doing? Have you still got the source code for that zelda game on the gamecube? I couldn't, er, borrow it could I? Yeah.. I just want to show it to the missus. ...Nice one!"

Doomulation

July 14th, 2007, 11:02

lightchris

July 14th, 2007, 20:59

I am certainly not convinced that any GC emulator will run full speed on a 3GHz Athlon64 with at least half of the games. PCSX2 doesn't even run full speed with that CPU, or even an Athlon64 X2 with the majority of games with full dual-core, SSE2 optimisations and a dynarec - and a GC has more powerful hardware than a PS2. To me, that seems like an arbitrary guess with no evidence, or simply wishful thinking.

The Gamecube may be more powerful in some respects, espacially concerning the graphics chip (the Graphics Synthesizer has a very small featureset compared to the Flipper), but not in all. I figure the Emotion Engine with it's 2 Vector Units (with all needed to be synchronized) should be harder to emulate than the Gekko.

I'd say PCSX2 is already very good optimized for speed while Gamecube emulation just isn't so far yet.

Clements

July 14th, 2007, 22:14

The Gamecube may be more powerful in some respects

I would say most respects. The PS2 hardware has numerous limitations, especially in the graphics department (no hardware texture compression or anti-aliasing). Part of the reason why the GC version of Resident Evil 4 looked a lot better than the PS2 version. The PS2 may have a complex architecture, the GC is still a more powerful system overall, so will probably have higher requirements as a result. The fact that the Gekko is a PowerPC chip and not MIPS-based (like a number of other consoles that have already been well emulated such as Playstation and N64) makes it very difficult too. No notable console before the GC has a PowerPC chip. The PSCX2 team have a lot of experience with MIPS already (PCSX).

lightchris

July 14th, 2007, 22:34

I would say most respects.

Ok, you can put it this way.

The PS2 hardware has numerous limitations, especially in the graphics department (no hardware texture compression or anti-aliasing). Part of the reason why the GC version of Resident Evil 4 looked a lot better than the PS2 version.

The missing texture compression is indeed a huge disadvantage, especially when you consider the PS2 only has 4 MB of dedicated VRAM. Anti-Aliasing however is not, because it is used in virtually no game of the last console generation.
In my opinion the greatest disadvantage of the PS2 is that you've no appropiate texture filtering (because of the low VRAM and missing hardware mip mapping) which partially causes horrible flickering.

But I think a good part of the reason why the GC version of RE4 looked much better than the PS2 version is because the game was originally programmed for the GC and it's specifications; even a good port will never be as good as if you'd design the game form scratch for one console.
By the way: The PS2 version runs at a slightly higher resolution.

The PS2 may have a complex architecture, the GC is still a more powerful system overall, so will probably have higher requirements as a result. The fact that the Gekko is a PowerPC chip and not MIPS-based (like a number of other consoles that have already been well emulated such as Playstation and N64) makes it very difficult too. No notable console before the GC has such a chip. The PSCX2 team have a lot of experience with MIPS already (PCSX).

You've got a point there, but still it's harder to emulate a multiprocessor system than a singleprocessor system (for the coders as well as for the hardware that has to run the emulator). Maybe the more powerful Gekko makes up for the difference, but I think we both are not deep enough into the topic to be judging that (at least I am not).

Clements

July 14th, 2007, 23:41

Anti-Aliasing however is not, because it is used in virtually no game of the last console generation.

The Flipper has hardware support for FSAA, the PS2's GS does not (so will do it in software if at all). I am not aware of the number of games for GC that used it, but it is an example of a hardware advantage of the Flipper chip over the GS nonetheless.

You've got a point there, but still it's harder to emulate a multiprocessor system than a singleprocessor system (for the coders as well as for the hardware that has to run the emulator). Maybe the more powerful Gekko makes up for the difference, but I think we both are not deep enough into the topic to be judging that (at least I am not).

Technically, the GC is a 'multi-processor' system as well, in that it has a general purpose CPU (Gekko), dedicated GPU (Flipper) and also a DSP for sound. The PS2 may have more processors overall, but some additional functionality doesn't need to be emulated to play most games (such as Dev9, USB, Firewire, Hard drive and so on).

lightchris

July 15th, 2007, 09:59

The Flipper has hardware support for FSAA, the PS2's GS does not (so will do it in software if at all). I am not aware of the number of games for GC that used it, but it is an example of a hardware advantage of the Flipper chip over the GS nonetheless.

Yep but it doesn't make the hardware weaker for games or emulation because it isn't used anyway. By the way I'm not sure what sort of AA the Flipper can handle. If it's only supersampling with an ordererd grid the GS should be able to do the same (as does any graphics chip that can render sufficient resolutions).

Another advantage of the Flipper ist hardware support of bump mapping, while the biggest disadvantage imo is that it can't run full 32 bit color all the time which not seldom results in color banding.

Technically, the GC is a 'multi-processor' system as well, in that it has a general purpose CPU (Gekko), dedicated GPU (Flipper) and also a DSP for sound. The PS2 may have more processors overall, but some additional functionality doesn't need to be emulated to play most games (such as Dev9, USB, Firewire, Hard drive and so on).

The GC has one main processor (Gekko). The PS2 has in addition its two MIPS cores one FPU and two VUs (all together called Emotion Engine). Both have a SPU and a graphics chip (of course). You can't deny that the PS2 is a multiprocessor architecture while the GC is not.
This is also the reason why the PS2 is said to be hard to program and why it took a long time until we saw the potential of the hardware in games (and some devs still say it's not actually fully exploited yet).

edit: Just to make it clear: I'm not saying the PS2 is more powerful than the GC (in practice it's usually the other way round), but it may be harder to emulate nevertheless.

Clements

July 15th, 2007, 13:47

Yep but it doesn't make the hardware weaker for games or emulation because it isn't used anyway. By the way I'm not sure what sort of AA the Flipper can handle. If it's only supersampling with an ordererd grid the GS should be able to do the same (as does any graphics chip that can render sufficient resolutions).

In the specs it is listed as FSAA (Full Scene Anti-aliasing). Sure, PS2 can do similar (supersampling), but since it would have to be in software (no dedicated hardware acceleration for it), so it comes at a much larger performance penalty. Same reason 3DMark's 2D tests are dog slow (not run in hardware).

The GC has one main processor (Gekko). The PS2 has in addition its two MIPS cores one FPU and two VUs (all together called Emotion Engine). Both have a SPU and a graphics chip (of course). You can't deny that the PS2 is a multiprocessor architecture while the GC is not.
This is also the reason why the PS2 is said to be hard to program and why it took a long time until we saw the potential of the hardware in games (and some devs still say it's not actually fully exploited yet).

Gekko also has an integrated FPU (and ALU), as do almost all modern processors. It just mainly lacks the vector units of the EE.

If you were to say multi-CPU/multi-core on the same die or similar, I would definitely agree with you, but 'multi-processor' merely implies more than one processor for a certain task, which the GC has.

The PS2 is hard to develop for mainly because of the poor design. The vector units are hard to exploit, but are often used as a crutch for graphics processing. Does not necessarily mean the units themselves are inherently harder to emulate from a reverse engineering perspective.

edit: Just to make it clear: I'm not saying the PS2 is more powerful than the GC (in practice it's usually the other way round), but it may be harder to emulate nevertheless.

You also have to account for the fact that the PS2 has already been emulated at fullspeed in many 3D games, while with GC, 3D games are generally about 10 fps with the latest unreleased Dolphin (which has 64-bit and dual-core optimisations), in about the same time frame (Teaser was released in 2004 and was in development for longer, 1st release of PCSX2 was around 2003). PCSX2 has been running full 3D games fast for well over a year. More projects have been started with the GC than PS2 as well.

If one were to say that the PS2 is harder to emulate, it contradicts what has actually happened so far. You may be right, but it is difficult to believe.

lightchris

July 15th, 2007, 16:11

In the specs it is listed as FSAA (Full Scene Anti-aliasing). Sure, PS2 can do similar (supersampling), but since it would have to be in software (no dedicated hardware acceleration for it), so it comes at a much larger performance penalty. Same reason 3DMark's 2D tests are dog slow (not run in hardware).

Actually the "FSAA" says absolutely nothing about what type of AA is meant. It can be supersampling, multisampling (both with ordered or sparsed grid), edge anti-aliasing or something even different. Sadly there don't seem to exist any detailed information.

As for supersampling: It can't be accelerated in hardware (as it's just a higher resolution in principle). It might be that Flippers AA is nothing more than that.

Gekko also has an integrated FPU (and ALU), as do almost all modern processors. It just mainly lacks the vector units of the EE.

If you were to say multi-CPU/multi-core on the same die or similar, I would definitely agree with you, but 'multi-processor' merely implies more than one processor for a certain task, which the GC has.

The PS2 is hard to develop for mainly because of the poor design. The vector units are hard to exploit, but are often used as a crutch for graphics processing. Does not necessarily mean the units themselves are inherently harder to emulate from a reverse engineering perspective.

Well, of course the definition of a multiprocessor system can vary. But from my perspective, the need to use the main processor along with the 2 VUs with all it's problems with e.g. synchronzing them all (but also the advantages) speak for a multiprocessor system. The PCSX2 devs are also calling it that way. Let me add a few more statements from refraction:

EE (Emotion Engine) core = The PS2's main processor which runs 8x faster than the PSX processor with registers twice the size (128bits) altho in general cases only 64 bits are used, where the PSX uses 32bits as a general rule. The other difference is the R5900 (EE) has many extra instructions, multimedia instructions and extra co processors which arent in the PSX, so we have a processor thats 8x faster and at least 3 times more complex. (http://forums.ngemu.com/pcsx2-official-forum/70174-why-pcsx2-slow.html)

Which means MIPS isn't MIPS and the advantage of their experience with the PS1 emulator PCSX is limited. And:

VU (Vertex Unit) = The PS2's equivilant to the graphics engine on the PSX, it is seen as an extra processor (yes another one) altho the PSX one was 4 times slower than the VU and also the VU has its own memory and run independantly from the main CPU where as the PSX one is cpu dependant. This is the main reason for the slow 3d games on PCSX2, intense vertex processing done by the game using 4 32bit vertex's which makes up the 128bit floating point registers that it contains. This unit also processes textures and 2d information on a part of the unit called the VIF which unpacks texture data and sends it to the GS. (http://forums.ngemu.com/pcsx2-official-forum/70174-why-pcsx2-slow.html)

Independent CPUs --> multiprocessor system (in my opinion)

What you call "poor" design is nothing more than that the work with the different kinds of processors is difficult. The design of the Gameucbe or Xbox is easier to understand and to program because of that. Another factor is that there weren't good development tools for the PS2 for a relatively long time.

You also have to account for the fact that the PS2 has already been emulated at fullspeed in many 3D games, while with GC, 3D games are generally about 10 fps with the latest unreleased Dolphin (which has 64-bit and dual-core optimisations), in about the same time frame (Teaser was released in 2004 and was in development for longer, 1st release of PCSX2 was around 2003). PCSX2 has been running full 3D games fast for well over a year. More projects have been started with the GC than PS2 as well.

If one were to say that the PS2 is harder to emulate, it contradicts what has actually happened so far. You may be right, but it is difficult to believe.

The difference is that PCSX2 has been constantly worked on over years. No other Gamecube emulator has had that much develoment time (at least no public one that we would know of). As far as I know Dolphin makes no exception there and had a very low acitivty the last 2 years.

Clements

July 15th, 2007, 16:48

Actually the "FSAA" says absolutely nothing about what type of AA is meant. It can be supersampling, multisampling (both with ordered or sparsed grid), edge anti-aliasing or something even different. Sadly there don't seem to exist any detailed information.

As for supersampling: It can't be accelerated in hardware (as it's just a higher resolution in principle). It might be that Flippers AA is nothing more than that.

From what little we do know, the GC's FSAA is hardware accelerated. This information is widely available on the web. Here is a full feature list of the Flipper:

Fog, Subpixel Anti-aliasing, 8 Hardware Lights, Alpha Blending, Virtual Texture Design, Multi-texturing, Bump Mapping, Environment Mapping, MIP Mapping, Bilinear Filtering, Trilinear Filtering, Anisotropic Filtering, and Real-time Hardware Texture Decompression (S3TC).

Well, of course the definition of a multiprocessor system can vary. But from my perspective, the need to use the main processor along with the 2 VUs with all it's problems with e.g. synchronzing them all (but also the advantages) speak for a multiprocessor system. The PCSX2 devs are also calling it that way. Let me add a few more statements from refraction:

Refraction is only comparing the PSX with the PS2 here. Nothing is mentioned about the GC, so there is no meaningful evidence that the PS2 emulation is more difficult to emulate at full speed. What Refraction said is fairly common info. Search this board for quotes from FiRES and ector as to why GC emulation is difficult and very slow.

Which means MIPS isn't MIPS and the advantage of their experience with the PS1 emulator PCSX is limited. And:

MIPS is still MIPS architecture. It is widely documented and has appeared in two consoles before PS2. The EE may have more instructions, but it is still based on MIPS. Gekko is a totally novel CPU for a console. The Athlon XP is still an x86 CPU despite having support for SSE and MMX which was not seen in earlier x86 CPUs.

Independent CPUs --> multiprocessor system (in my opinion)

Okay.

What you call "poor" design is nothing more than that the work with the different kinds of processors is difficult.

Especially when certain processors that comprise the EE are not general purpose.

The difference is that PCSX2 has been constantly worked on over years. No other Gamecube emulator has had that much develoment time (at least no public one that we would know of). As far as I know Dolphin makes no exception there and had a very low acitivty the last 2 years.

PCSX2 development was also rocky in the early days, with many devs leaving and plugins becoming discontinued. GSMax (?), GStaris and GSsoft to name a few. On the GC side, we have at least 4 discontinued emulators, which suggests that GC emulation is difficult. Difficulty reduces motivation.

lightchris

July 15th, 2007, 17:33

From what little we do know, the GC's FSAA is hardware accelerated. This information is widely available on the web. Here is a full feature list of the Flipper:

Fog, Subpixel Anti-aliasing, 8 Hardware Lights, Alpha Blending, Virtual Texture Design, Multi-texturing, Bump Mapping, Environment Mapping, MIP Mapping, Bilinear Filtering, Trilinear Filtering, Anisotropic Filtering, and Real-time Hardware Texture Decompression (S3TC).

As I said: The information is very poor. We don't know anything about the Flipper's AA.

Refraction is only comparing the PSX with the PS2 here. Nothing is mentioned about the GC, so there is no meaningful evidence that the PS2 emulation is more difficult to emulate at full speed. What Refraction said is fairly common info. Search this board for quotes from FiRES and ector as to why GC emulation is difficult and very slow.

I know that. I only quoted the statements for the parts I highlited.

MIPS is still MIPS architecture. It is widely documented and has appeared in two consoles before PS2. The EE may have more instructions, but it is still based on MIPS. Gekko is a totally novel CPU for a console. The Athlon XP is still an x86 CPU despite having support for SSE and MMX which was not seen in earlier x86 CPUs.

Okay, that's right.

PCSX2 development was also rocky in the early days, with many devs leaving and plugins becoming discontinued. GSMax (?), GStaris and GSsoft to name a few. On the GC side, we have at least 4 discontinued emulators, which suggests that GC emulation is difficult. Difficulty reduces motivation.

Yes, work on PCSX2 was not at all times as good as the last few years. Nevertheless it has been worked on intensely for a few years by now while it's different in GC emulation.

The question why so many GC emulators got discontinued is a open-ended question. It may be because it's difficult (let's say more difficult than PS2 emulation). But the reason might just as well be that the PS2 is much more popular (120 vs. 20 mio. sold) or it may be just a coincidence that more devs found together for a PS2 emulator (I think this is most likely). Also there have been other PS2 emulators than PCSX2 which are now discontinued (Neutrino SX2, PS2Emu).

Doomulation

July 15th, 2007, 18:33

There can be several definitions to a poor design or architecture, as I would like to call the PS3 (and the PS2 too I believe, even though I know not much of it). The reason is often due to bottlenecks of engineering, making the system for an entirely different purpose than it was meant to be for, or simply because the engineers found it fun in making it complex (though maybe with a little added power, as recently found in the PS3).
The PS3 has a lot of complexity and the fact that the Cell processor was made for media in mind (not gaming), doesn't really help... To add that the system memory on the console is limited, and other factors I don't remember, also continued to make the Xbox 360 about equal in terms of performance due a better designed architecture.

Just a thought anyway... Carry away!

Tagrineth

July 16th, 2007, 03:42

What you call "poor" design is nothing more than that the work with the different kinds of processors is difficult.

No, no, the PS2 really is poorly designed in many ways. The GIF-to-GIS bus (aka the path between the Emotion Engine) is heavily over-taxed most of the time due to the graphics chip having no direct access to system memory (oops), and the GS can only read/write to its own embedded memory.

On top of that the VUs are kinda separate processors but at the same time they kinda aren't. VU0 is the most adept of the two at running something akin to general purpose code, but even then it can hardly be considered a separate processor. VU0 and VU1 are almost useless without the 5900i they're bolted onto. VU1 often complements the GS almost exclusively, too, running graphics code more often than anything else as it is very very fast at specific tasks.

Anyway, the PS2 is a fascinating system but in many aspects Sony made some very strange and borderline fucked up design choices with it. There's definitely a lot more to the "badly designed" argument than "multiple processors = hard" though.

lightchris

July 16th, 2007, 08:32

No, no, the PS2 really is poorly designed in many ways. The GIF-to-GIS bus (aka the path between the Emotion Engine) is heavily over-taxed most of the time due to the graphics chip having no direct access to system memory (oops), and the GS can only read/write to its own embedded memory.

On top of that the VUs are kinda separate processors but at the same time they kinda aren't. VU0 is the most adept of the two at running something akin to general purpose code, but even then it can hardly be considered a separate processor. VU0 and VU1 are almost useless without the 5900i they're bolted onto. VU1 often complements the GS almost exclusively, too, running graphics code more often than anything else as it is very very fast at specific tasks.

Anyway, the PS2 is a fascinating system but in many aspects Sony made some very strange and borderline fucked up design choices with it. There's definitely a lot more to the "badly designed" argument than "multiple processors = hard" though.

Thanks for the explaination. :) Sounds interesting.

You seem to know about things pretty well (at least way more then me) - may I ask you what you would think: Is Gamecube emulation more hardware intensive than PS2 emulation or is it comparable?