Dolphin, the GameCube and Wii emulator - Forums

(04-20-2011, 08:09 PM)LordVador Wrote: [ -> ]

(04-20-2011, 09:59 AM)NaturalViolence Wrote: [ -> ]Getting back to serious business.

Quote:Sorry if I keep repeating myself, but someone please poke marcosvitali. His last fifo commits are most of the reason why performance is worse once again and some games are crashing.

Are you sure it was 7185?

I haven't had time to track down the revision that caused the crashing with SMG/SMG2.

Quote:linux is slower by nature and so on emulators & Co

No it isn't. I don't know where you got that idea from.

still one of my bad joke...

Whoa... I was about to get more confused... Anyway, why would you say Linux is by nature slower than Windows? Even if we take the particular case of Dolphin, what would be making it slower on Linux than on Windows? Maybe still OpenGL being slower than DirectX since a certain rev?

(04-24-2011, 03:35 PM)ZLRK Wrote: [ -> ]

(04-20-2011, 08:09 PM)LordVador Wrote: [ -> ]

(04-20-2011, 09:59 AM)NaturalViolence Wrote: [ -> ]Getting back to serious business.

Quote:Sorry if I keep repeating myself, but someone please poke marcosvitali. His last fifo commits are most of the reason why performance is worse once again and some games are crashing.

Are you sure it was 7185?

I haven't had time to track down the revision that caused the crashing with SMG/SMG2.

Quote:linux is slower by nature and so on emulators & Co

No it isn't. I don't know where you got that idea from.

still one of my bad joke...

Whoa... I was about to get more confused... Anyway, why would you say Linux is by nature slower than Windows? Even if we take the particular case of Dolphin, what would be making it slower on Linux than on Windows? Maybe still OpenGL being slower than DirectX since a certain rev?

I repeat I was joking but you're right OpenGL could be blamed for a few things

Marcosvitali is denying his fifo commits have anything to do with the slowdowns or crashes, even though evidence proves otherwise. :/

Don't expect the regressions with the fifo to be fixed for 3.0 unless everyone can do some testing, report what fifo commits broke which games and caused performance issues.

---

Someone should also test if the switch to VS2010 is responsible for any of these regressions I just tested the r7107 fifo code and had different results than before. When I last tested r7107 performance was great and that was compiled with VS2008, I tested again compiled with VS2010 and get the same performance as I do in recent builds. I will do more testing later.

I think part of the problem is VS2010, the switch to VS2010 seems to have caused slowdowns as well. When I tested r7107 compiled with VS2008 before there was no performance issues, now when I test the r7107 fifo changes compiled with VS2010 there are performance issues. Not sure if that's a coincidence or if switching to VS2010 actually caused some crashing and performance issues.

There does seem to be some issues with the more recent fifo commits as well, that myself and others are reporting.

I think my performance issues may be due to EFB to Ram getting much slower over the past revisions. I used to be able to leave EFB to Ram and CPU EFB Access enabled and get 28 FPS - 30 FPS in Hyrule Field without the ZTP speed hack enabled. Now when I have EFB to Ram and CPU EFB Access enabled I can barely get 22 FPS to 25 FPS. EFB to Ram alone causes framerates to drop by 5 FPS - 8 FPS, enabling EFB to Texture will give me full FPS in Hyrule Field without the speed hack. My Core i7 950 system is overclocked to 4.2 Ghz, I have 6 GB DDR3 1600 ram in tri channel and two Geforce GTX 460's in SLI. I think this may be a combination of issues, both the conversion to VS2010 and marcos fifo commits. Even in NSMB EFB to Ram performance is crippled.

Is the cache still working by the way? It seems I can disable and enable the EFB to Ram cache and it makes no difference to performance, it doesn't even seem to work like it did in the past. :/

your system is limited by its uncore though, you won't get the best out of it without taking the bclk to 200 for the 28.8GB/s qpi bandwidth.

It is at 200, the performance issue is due to EFB to Ram performance getting much slower, probably due to either marcosvitali's latest fifo commits or the transition to VS2010 or both. I'm not even sure if the enable cache option is working for EFB to ram since enabling or disabling the option doesn't seem to make a difference.

wfm,

but the texturecache rewrite builds are speedy ;P

@xtreme

It's not JUST efb to ram. I use efb to texture and just like everyone else I have watched performance drop significantly in some games and not at all in others over the course of recent revisions.

Developers don't care about performance issues and neither do I. I'm more concerned about the stability. I just want someone to track down the specific revision that is causing a lot of games to crash (sonic adventure 2, SMG2, SMG to name a few). It's between 7150-7200, that's all I know.

All I can contribute with to this thread is that Dolphin works really good here and I don't find any of the newer SVN revisions slower at all.
I'm not an developer so I don't know anything about coding or Visual Studio.
I think it's on the contrary, I see small improvements the more of the newer revisions I try out.
Could be just me though