Emulator

I've attached a screenshot. This is on a Triple Core AMD machine that runs near perfect under Windows 7 x64, but is over 60% slower in Linux. This is with Compiz disabled, and nothing else open.

Issue 2542 has been merged into this issue.

Really?!? I'm going to boot into Linux right now!

I would post this as solved. Linux was actually much faster last time I booted it!

Right now i can't try to reproduce this issue again. Based on what rhyviolin said, you can close this.

While I haven't booted into Windows to test yet, and probably won't since my drive with all the stuff on it is ext4, my discussions in IRC indicated that some games on Linux are still much slower than they are on Windows. For instance, Brawl is not 100% smooth for me; it is mostly smooth during gameplay, but the cutscenes occasionally literally play in slow-motion. Mario Galaxy runs at 30 FPS. From IRC, these things are not the case on Windows.

Though this bug is kind of useless without more detail anyway, I guess.

This issue is DEFINITELY not solved. I've done further extensive testing, and Dolphin is almost 1/2 speed of Windows version in Linux x64. Dolphin is unplayable in Linux, and fully playable in Windows. In IRC they were claiming this is due to dx9 being a much more efficient plugin than OpenGL. At any rate it is definitely an open issue, and should not be closed.

I still haven't tested in Windows for comparison, but I've just upgraded my CPU from C2D E6600 to i7 2600K and the difference is huge. Everything that used to be a trouble from a performance point of view is now completely smooth. Perhaps this indicates that the JIT's Linux performance is the main culprit, not OGL. Is there a way to benchmark just the JIT on different systems? I'd be interested in comparing the performance between Win7 and Linux in a definable, numerical way without worrying about interference from video plugins.

I recently discovered that at least on my system the speed difference between the OGL backend on linux versus the same on windows was not an issue with dolphin at all. I tweaked the cpu frequency governor settings on linux and now I get just as good if not better performance on linux with the ogl backend, than on windows with the ogl backend. It turns out that the default settings for the ondemand cpu frequency governor are too conservative.

Of course with the DX backends in windows things are even faster, so there definitely is an issue with how the OGL backend in dolphin.

I have been looking into this on Linux and there is certainly a difference between OGL and DX11 (havent looked at DX9). The below was done with Linux 2.6.32, r7129, NVIDIA 8800, NV 195.36.24 driver. Tested Super Smash Bros, Mario Kart Wii, Wii Sports.

without code changes

copy2ram enabled: 15-30 FPS
copy2tex enabled: 50-60 FPS, some textures dont render (i.e. Mii faces)

in BPFunctions.cpp on line 83, disable copy2ram check

copy2ram enabled: 15-30 FPS
copy2tex enabled: 15-30 FPS, everything renders correctly

Obviously the texture copy is necessary to get correct rendering, but now why is there is a performance difference between OGL and DX11?

It turns out that it is due to a slight API difference. With copy2tex enabled, render2texture is used on both DX11 and OGL. DX11 does not require a separate container (OGL FBO) to render to a texture. OGL requires a FBO for render2texture and the way it is currently implemented in OGL is to use a temporary FBO and attach a texture every time TextureCache::FromRenderTarget() is called. The result is the FBO is essentially re-created every time the function is called and that is expensive. In other words, DX11 does not incur an expensive FBO creation call.

There is a secondary issue with TextureCache in OGL. When a texture already in cache changes format, it is simply deleted rather than just changing the format. This is also expensive. I dont know if DX11 does this too; have not looked.

To workaround this, I created a FBO for every texture and only attach the texture upon texture creation. Then when the texture format changes, it is changed not deleted then recreated.

results

Super Smash - 60 FPS, renders correctly
Mario Kart Wii - 50-60 FPS, renders correctly
Wii Sports - 50-60 FPS, tennis and baseball do not render (looking into it)

conclusion

Obviously I am missing something because this breaks Wii Sports. However my question is a higher level one: why is it programmed this way? It seems that every game I have tested incurs a large number of texture copies. As a graphics programmer, this screams inefficient regardless of API. Maybe there is a good reason to do this for Wii emulation, but I would love to know why.

Excellent job dude! This totally sounds like an area where there is plenty of room for improvement.

I don't think video backend is the culprit, I've noticed OpenGL is just as fast (maybe a tad faster) than DX9 and I'm on Windows. Can't try DX11 since I'm stuck on Windows XP.

I may also change from game to game though, I only tested one (Pokémon XD).

If it is not the culprit, why did the frame rate double after my hack to avoid FBO creation? Honestly it is probably not the only issue, but to say the video backend is not at fault at all is disingenuous.

Another OGL performance improvement would come from using vertex buffer objects. I see some VBO code but it is commented out. Most likely, geometry processing would be sped up a lot. Quads are drawn in many places and if a single VBO was used instead of glBegin() that would also speed things up a little.

could you post a patch?

The patches are not commit worthy, but are fine for testing. Like I said, this does break tennis and baseball in Wii Sports. More specifically, using an FBO per texture breaks it.

I also tested Wii Sports Resort and saw no performance difference.

As of r7369 this is definitely still an issue. I've done extensive testing and am always 20 fps slower in Linux no matter the emulator or gfx plugin settings.

I have found that some games such as Smash Bros are quite disk IO bound. Setting CONFIG_HZ=1000 in the kernel makes a huge difference. The default on Ubuntu is 250. Of course the right solution is to reduce disk IO so that 250 is an okay value. This is assuming it is even possible to do so.

I just did extensive testing, and have found that OpenGL is much slower in Win7 x64 as well. Dx11 is actually fastest on my machine, but using Win7 at all overheats my video card after a few mario kart races.

I can confirm that r7469 is still way slower on Linux than Windows. I've tried dolphin on Windows 7 64bit and it's amazingly fast with hi-resolutions, FSAA, AF and such. On linux I have to turn every single gfx option down and it still runs at 35~45fps =/

System Specs: AMD64 x2 (@3ghz), 2gb DDR3, GeForce GTS 250 2gb (latest drivers).

Same as everyone else confirmation of slower Linux Dolphin-emu. Get average 25-40 fps in game on Galaxy 2 all settings turned down, efb copy to texture not RAM and Internal Res 2x. Playable and pretty enough but completely out performed by windows same hardware full frame rate all settings on.

System Specs:AMDPhenom2 X4 (@3.6ghz),4gb DDR3, ATI Radeon HD2600XT (latest drivers)

I don't know the "Linux world" very well, but couldn't it be a "simple" driver problem, I mean I don't think that Nvidia and Ati care very much about their Linux drivers, because all their money comes from Windows users...

Maybe not quite: http://www.phoronix.com/scan.php?page=news_item&px=ODgwMA Linux seems to perform pretty well with Nvidia.

95% of the driver code is shared between DX and GL and Windows and Linux for both NVIDIA and ATI. The quality of the ATI driver is slightly less on Linux, but not enough to make a huge difference for Wii games which are so simple from a graphics point of view.

You can close this now. In Linux Mint 11 x64 with the proprietary ATI driver I get MORE FPS in Linux than I do in Windows 7 x64 ultimate. Even with less options disabled in the graphics options.

Can we pin point what the bottlenecks are from this? From what Rhyvio says it would appear Dolphin is pretty much fine, so what is different in Mint 11 from other Linux distros in regard to opengl or cpu throttling or anything else people think is causing the problem? Personally not all that keen on just changing distro but if its the only option... Might give this a whirl in a few days.

No off topic talk about how anyone "really should switch" their distro, thanks.

Seriously, stop it, it doesn't belong here. Complain to the forum if you want, but don't spam this issue report with useless information.

Maybe it's a nvidia related issue?

I kinda doubt it as my hardware is similar to yours except with ab ATI GPU and we get similar performance. I'm kinda stumped but if Mint 11 fixes this issue I doubt its driver related and therefore not hardware specific and probably something more to do with opengl of the way 64bit cpus are handled. I really don't know enough to pin point though at all. I will probably try another distro to confirm though.

Still deleting comments like a nazi. Well here's some pertinent information: Multiplayer is still slower in Linux. All my testing yesterday (most of the results of which have been deleted by neobrain) was single player and there was more FPS in Linux. Today I played some multiplayer and that is not the case. Looks like I'm still dual booting to play multiplayer mario kart.

What colin said seems pretty important. The problem cannot be considered solved until the reason for the problem is pin pointed. I will make some tests with Ubuntu, Mint and (suggestion) on Intel hardware and compare it with Windows7 tests next week for more input data.

The reason is pretty simple: GL backend can be improved significantly. You can look at my posts further up. Usually if DX code is faster than GL, it is because it easier to shoot yourself in the foot with GL. Not because DX is inherently faster than GL like many claim.

Looking through the code, I see the use of glBegin(), vertex arrays, misuse of FBOs, too much texture creation/deletion, unnecessary shader generation, not using GLSL, etc, etc. In other words, just about every bad practice possible in GL is utilized to some extent.

My recommendation is to rewrite the entire renderer using OpenGL ES 2.0. This will force developers to use best practices. Yes I know most will think rewrite is overkill but it really is that bad.

I also recommend abandoning DX because it adds no real value if the project is meant to be cross-platform. Then development resources can be focused on the GL renderer which is supported on all platforms.

My two cents.

Here is a short list of things that affect dolphin performance:

• libc(inter-thread synchronization)
• kernel(like above, but also scheduling)
• graphics driver(dolphin spends up to 40% in there when there are many texture environment(shader) changes)
• compositing window manager
  and the usual internal choices like graphics backend, JIT/JITIL, DSPHLE/LLE

Why would the OpenGL renderer improve on a different distribution? Or is this a case of several rather than one trigger causing slow downs. If its OpenGL then its Dolphinemu but that wouldn't explain any distribution variations would it? If its completely unrelated we still need to prove and determine what if anything makes a different distro so significantly faster than another. I use Maverick but had similar performance on newer. and older ubuntu releases.

rped...@gmail.com: if you find out how the fix the recreation of the textures, please send a patch. The last time i tried to fix that, i just got masses of bad/black textures, because some state was not reset correctly, and i couldn't find out which one. neither could the gl debugger bugle.

I've done a lot more testing. This is still definitely a valid issue, especially in multiplayer with 3 or more players (testing Mario Kart Wii).

So just to recap we can improve performance somewhat by switching distros but that still leaves low performance in some games and in all multiplayer scenarios. So what Rpedela says is correct and Dolphin-emu's opengl renderer is now the primary confirmed cause for an up to 50% decrease in framerate performance. As there are so many more Windows users I kinda feel this problem wont be resolved for a long time, if ever at the rate Direct X maintenance is progressing. Any chance the priority of this issue can be raised slightly? Not only because it might get a few rough fixes faster, but just to raise more awareness of the problem. Further fracturing might result in dolphin-emu no longer being a true cross-platform emulator.

At the moment my Linux (3.6ghz Phenom2X4 4gb ddr3) is consistently out-performed by around 10-20fps by a Windows (2.2ghz Athlon2 2gb ddr2)

Just wanted to drop a bit more data. Since previous posts have rechecked Dolphin-emu 3.0 in both Ubuntu Maverick and Natty as well as Mint versions 10 and 11 and Fedora 14. I can report on my setups that Dolphin-emu shows no performance increases across any of these distributions and if any, almost unnoticeable at around 5fps slower or faster. Unsure yet if this is the current release version 3.0 at fault, but if not pretty much discredits any distro related claims on performance increase.

I upgraded to a core i5, and now I get better speed in Mint 11 than in Windows 7 x64 Ultimate. Those are the only two OSes I use. I can turn the resolution up to 1920 and have auto window size textures and also V-Sync in Linux and get full speed. In Windows I have to lower one of those 3 settings.

Oh yeah, are you guys using the glennrics PPA? I am.

I'm trying dolphin-emu-trunk from the ppa and Mario Kart Wii still runs @ 23fps on Linux Mint 11 32bit. It runs @ full speed on Windows 7 64bit.

wing...: You should look into the cpu performance governor settings on your linux system. I found that the default settings are too conservative and slowed dolphin down. I get about the same performance from dolphin under both windows and linux when using the OpenGL backend (in particular with Mario Kart Wii) after tweaking the governor. That being said, I get a massive speed improvement in windows if using one of the DirectX backends.

I'm gonna look into it, thanks for the tip!

Well I just tried trunk, and not only is it much slower than 3.0, but it also crashed immediately when I started a race. The race in question is the beach in the shell cup.

I've run dolphin on ubuntu 11.04 with the original kernel 2.6.38-11 (CONFIG_HZ=100) and then with a customized kernel 3.0 (CONFIG_HZ=1000).
The difference is quite notorious (faster using CONFIG_HZ=1000).
Maybe there is a bug somewhere that is more noticeable under a kernel with low frequency.

Just tried on Arch x86_64 with linux-ck 3.2.9 compiled with CONFIG_HZ=1000, still way slower than on Windows 7 & 8 (and 8 is faster than 7^^). I get 30FPS in SSBB with 4 characters when it runs fullspeed on both Windows (50FPS, I've got the PAL version) with the OGL plugin.
Tested with a HD4870 and a Core 2 e8400, latest Catalyst drivers on all three OSes, and xorg 1.11.4 on Linux. BTW, Cache Display Lists on Linux will result in a silent crash with most games (the log is empty).

Tested with HD3000 sandy bridge graphics with a core i5 2500k clocked at 4.0 ghz - Windows 7 Ult SP1 64 bit runs the games perfectly, max resolution for my monitor (1600x900), while Linux 3.2.11 runs at 30 fps and under. Disappointing, but I'm going to try the kernel latency fix (1000hz). I'll post back with my results.

/me wonders if it is simply gfx drivers or actual emulation?

95% of the code is shared between the Windows and Linux GL drivers for both NVIDIA and AMD. If you run on Windows with GL instead of DX, you should see similar poor performance. So no, the graphics drivers are not the issue. The issue is how the GL code is written. My full critique of the code is several posts up. To be fair, historically the Intel Linux driver has poor performance, but I do not think that is relevant since it is slow on NVIDIA and AMD cards too.

OpenGL could perform for better or worse. I'll test the dolphin-emu in my mac os x partition and let you know how things go, see if it's really opengl. I know certain games that run on OpenGL run just fine with graphics that are more demanding that what many gamecube games demand. I'll post back with my results - oh! and the 1000 hz kernel latency fix is not really a fix. It does supposedly provide the best latency, but the difference is not notticeable in dolhin-emu for linux.

I appreciate your critique of the code from several posts ago, but let me be frank. Although your statements are logical, I would like to bluntly state that I run 3 operating systems on my home desktop with Sandy Bridge graphics. Mac OS X Lion 10.7.3, Windows 7 Ultimate SP1, and Arch Linux. If you could tell me what's different in the Mac OS X version of dolphin over the windows and linux versions that maybe my observations can easily be explained. In any event, like Linux, Mac relies on OpenGL. I just booted up Mac on the same hardware I run Linux on and what do you know - I ran Super Smash Brothers Melee perfectly at 60fps, 100% emulation. Definitely much noticeably smoother than when I tested it in Linux, at a mere 30 fps and 90 - 100 % emulation. Now you may tell me that driver support it poor in Linux. I feel that a lot of those days are past and as proof I ran TF2 through wine without problems.

Maybe there's more than meets the eye on why dolphin-emu performance in Linux seems slower than the other two OS's.

First of all, one game on one machine is not nearly enough testing to come to any conclusion. From my own tests, I remember Super Smash performing quite well because it avoids some of the texture bottlenecks in the GL backend due to how the game gets emulated. What specifically? I dont remember off the top of my head. One game that did consistently have poor performance was Wii Sports especially when you increase the number of players.

As for OSX, I know little about their driver stack, but I would be surprised if it is the same as Linux. However I do know that there is a lot of difference between the Windows and Linux Intel drivers. Intel's Linux driver conforms to the standard Linux graphics stack and as such much of the code must be different from Windows. NVIDIA and AMD bypass the Linux graphics stack which allows them to share a lot of code between Windows and Linux.

The bottom line is that many people have reported poor performance on Linux but not Windows on a variety of hardware, drivers, dolphin versions, GFX backends. In an earlier post, I have shown minor tweaks in the code can have significant performance improvement in certain cases. In addition, I have pointed out a list of improvements that could be made to the GL backend.

To me, it is conclusive it is the code and there is no point in further performance testing until the GL backend has been changed. I personally do not have the time to improve the GL backend, but what I can do is point out its flaws. I hope that is at least somewhat helpful as I would like to see this project work well on all platforms.

Regardless, even if you are right and there is something else besides the GL backend which I bet is true. Shouldn't the GL backend be improved anyway? Lets fix one thing at a time.

It's interesting you say that. I am waiting for a Radeon HD 6870 in the mail, so I'll be able to compare running OpenGL on that using the catalyst drivers over the Intel drivers.

Interestingly enough, in my experience Mac performed the best using OpenGL, as Windows using OpenGL had glitches, while Direct3D didn't.

I don't like DirectX becuase of it's lack of platform support. As you said, OpenGL is a great concept because it's intended to provide multi-platform support.

Unfortunately history isn't on OpenGL's side, as Mircrosoft did as much as it could to erase it from history. At least today os x relies on OpenGL which will hopefully bring improvements that will trickle down to every platform running openGL (Linux, and consoles, making it easier for devs to create games that run on every platform).

As for as my poor testing techniques, I'm sorry xD - I only had access to Super Smash Bros Melee. Though in any event, I do think my perespective is valuable because I run all 3 common operating systems natively on the same hardware. I appreciate your input.

Hi, the emulator run faster in Sabayon 32 bits than Ubuntu 32 bits.
If someone needs to perform some test on Ubuntu or Sabayon 32 bit or 64 bit Sabayon, to tell me.
I'm happy to help to improve the emulator on Linux.

Just to add another datapoint here. This issue definitely still exists. However, I'm not so sure it's necessarily a performance issue. Something seems to be blocking, and or limiting the framerate when running Dolphin in Linux.

See the below video; in Windows, with FPS limits disabled my machine is capable of running Wind Waker at well over twice the speed it can in Ubuntu.

http://www.youtube.com/watch?v=l6n1cGE6br8

In the fairy fountain, windows runs about 108fps; in Ubuntu I can barely crack 45. In Direct3D9 I get about 125fps so while there is a difference between D3D9 and OpenGL, it is not major within Windows.

By the way, that video shows a best-case scenario in Ubuntu and a worst-case in Windows (resolutions, anisotropic filtering, etc) but I tried just about every permutation of options in order to eliminate the difference with no success.

The reason I think something is limiting FPS or blocking rendering is because if I try a similar test in Super Smash Bros Melee, once I get into a battle rendering is locked at 30fps (literally locked, every single second) whereas I am comfortably between 60-70fps in Opengl on windows and 100+ on D3D9. The key difference, however, is performance fluctuates as you would expect, whereas on Linux is it is rock-solid at 50% of game speed. For completeness, I pulled these numbers from using Mario+Fox+Metaknight+Link on Shadow Moses Island.

Hello,

I am currently experimenting with OpenGL ES and had a startling realization. It should be possible to implement the "Hollywood"/"Flipper" GPU with a stack-like state machine based upon OpenGL ES. (OpenGL ES is much more portable than standard OpenGL and forces "well written" code as part of the API.

The reasoning is that since the "gpu" interprets opcodes, it should be possible to implement both a stack based VM and optimization passes with an increase in speed, whereas the drawing is done by the OpenGL ES API.

From what I see, the OpenGL Programming Model is inherently stack-based (buffer based), therefore by utilizing "intelligent" buffer allocation (VBOs, etc) it should be possible to substantially increase performance.

I had become interested in doing this since my laptop's gpu (Nvidia 9400M G) should be more than ample to run games at full speed on Linux and Mac OS X, however I barely get above 30fps at the lowest of settings of the OpenGL Plugin.

If anyone has any insight into the graphics/gpu emulation code and documentation on the gpu's instruction set, please message me. I am indeed interested in making a proof-of-concept in the coming weeks.

should fix this soon...

I know I am a little late... but maybe this has something to do with Nvivdia Optimus and AMD Switchable Graphics.
I have a Radeon HD 7670M and can play most games 70+ bare default settings on windows (terrible, I know)
But on Linux (Ubuntu 12.04) I get 45-50 fps. It also has no option to select GPU in Linux.
Also like to point out that I can't turn off my integrated GPU because of the way my DGPU was made.
Maybe dolphin is running on our integrated GPU's...?

Nope. I have the same problem and my integrated graphics is turned off in uefi/bios.

Damn. Booted into windows and used OpenGL. That's definitely the problem as I experienced the fps drop while using it in Mario Kart. This definitely needs more attention.

:D I fixed the lag for my computer (Ubuntu 12.04 LTS) :D
Have no idea what option it was so I'll list what I changed

1. I installed 3.0-776 by typing 'sudo apt-get install dolphin-emu-master
2. In ~/.dolphin-emu/config , I open 'gfx_opengl.ini' and 'changed Adapter = 0' to 'Adapter = 1'
3. Disable framelimit.

Not sure which did the trick but I was playing Mario Kart, and it was lagging like usual, then a little bit into Luigi Circuit, it got my 70+ FPS :D

Also what does pressing '5' do?
It seems to toggle between three states for me,

1. Normal speed, glitchey box in lower right corner
2. Slow speed, looks like contrast has been turned up way to high
3. Normal speed, looks normal
   So try pressing '5' during gameplay

1. disable efb
2. efb2ram
3. efb2tex

Cool, thanks.
Did my options help with framerate?

Sorry, I don't have a Windows to test this, so I don't know what causes my slow performance.
I have a NVIDIA 8400GS and a Pentium Dual Core 3Ghz, I'm trying to play Resident Evil. The game runs like, in 10FPS indifferently of the native resolution (which is odd, 1080p runs exactly like 528p); is it the game, the hardware, or dolphin OpenGL? (I'm using NVIDIA 310 drivers over Ubuntu 12.10)

#72 didn't help
#73 only make graphics glitches
#74 small difference
The best game I've played in this computer was Amnesia at 1080p(all low) and 720p(all high - no antialiasing)

pedro: if IR doesn't matter, you are CPU bound. But you're right, it is usually because of the gpu thread (so ogl backend)

#74 is a direct answer to #73 and both are no hints for performance. efb2tex should usually be choosen for performance (default), efb2ram only if you want to fix some graphic effects.

Also, I have experimental drivers so I could play Steam for Linux games.
Not sure if it changes anything, but every little bit helps I guess.
1.Add pre-released sources by going Ubuntu Software Center> Edit> Software Sources
2.Update the Update Manager
3.Go into Additional Hardware and install the experimental drivers.
If that doesn't help, I'm out of options shrug

Since the unix-fastmem merge ports over the only other performance advantage Windows had over Linux (that I'm aware of), the only possible causes of Dolphin being slower under Linux should now be the OpenGL backend (which degasus is fixing up) and graphics drivers (Intel's GPU drivers do OpenGL faster on Windows than on Linux in most cases according to Phoronix, but I dunno about Nvidia/ATI).

Glad this is finally getting attention again.
It's been what, a little less than 3 years? XD

FYI

I have been working on a HTPC based on Gentoo Linux for some months now. One of the challenges was bad performance in Dolphin playing Super Mario Kart, especially in multiplayer mode (2 players).

I have been able to solve that to acceptable levels by changing the frame limit to 'audio'. During the game the cpu usage is around 165%, which is 10% lower (and it varies much less!) than using any other frame limit setting, while framerates increased.

Any other settings (other than default, e.g. offloading textures to gpu) don't make a noticeably difference.

Based on this observation my guess is that the main performance bottleneck has to do with synchronisation between sound and video, but I have almost zero knowledge on game-development or the internal working of dolphin-emu.

My hardware is: intel i5 2500t, ssd, 8 gb ram at 1866 mhz, Gainward Geforce GT 630 1GB GDDR5 videocard.

Feel free to contact me (I'll subscribe to this issue as well) if you need more info.

Thanks for that email! This is probably the info that the devs need to
solve this.

Hopefully it is helping at least a bit :-)

In #82 Paul mentions that Degasus is working on a new implementation of the OpenGL backend. Is there some place where we can track progress and get experimental versions?

I just reread the full thread and my biggest worry is that no-one did some code profiling while dolphin was running. How much time is spend on which code? Likely the bottleneck can be found in a synchronization (wait time) between threads (otherwise my cpu would be used 2 cores for 100%), which maybe gets improved with the 1000 Mhz 'fix'.

Is it not possible to perform this kind of analysis?

Commits: http://code.google.com/p/dolphin-emu/source/list?name=GLSL-master
Builds: http://dl.dolphin-emu.org/builds/ (I'm not sure why there's no Ubuntu/Debian packages here, let alone why GLSL-master doesn't show up on http://dolphin-emu.org/download/branches/, but there's Windows and OS X builds of GLSL-master here.)

Please keep in mind that this rewrite is quite incomplete, plus it requires a GPU/drivers/GL stack that supports most of OpenGL 3.2 and at least GLSL 1.3. (My Intel HD 3000 can run it under Mesa 9.0 + current Intel i965 drivers, but I get graphical glitches with the EFB that are caused by a driver(/Mesa?) bug pertaining to UBOs). Also, performance is currently worse than master by about 5-10 fps (even worse on ATI GPUs under Windows, I hear), and there'll be plenty of graphical issues in games.

compiled GLSL-master, tested, no significant difference noticed...

Sounds like you're CPU limited

Or your GPU is crap, one of the two.

sorry Sonic, but you're wrong. As he gets the same performance with higher IR, the gpu is faster than the cpu.
pedro: just be sure efb2ram is disabled and also try the hacked buffer upload. And dolphin needs a very recent cpu :-(

btw: it isn't fixed completely as d3d has some optimizions not in ogl (eg state tracker)

Finally I found some time to try with the latest code that is in SVN.

The performance improvement is really noticable!

Playing super mario kart with 2 players, only changing the graphics settings to 2xInternal. Framerate used to be somewhere around 20-25 with a lot of trial-and-error configuration hacks, but now with just using the defaults I get framerates >50.

Well done!

BTW: my hardware is still: intel i5 2500t, 8 gb ram at 1866 mhz, Gainward Geforce GT 630 1GB GDDR5 videocard. Only things that changed are updated kernel and updated nvidia drivers.

Now the question is: who deserves a free beer?

Mario Kart Double Dash is indeed running very fast! It runs at a steady 60fps (1920x1080 4xInternal) now while it used to run at 25~30fps.
Metroid Prime is pretty playable too with frameskip set to 1.

... however OGL will be broken for me.