Emulator

BTW, my video card is NVIDIA GeForce GT 330M, on a laptop with a Core I7-620M.

This is more of a driver issue than anything. GL 3.2's been around since 2009, but some graphics drivers (especially open-source drivers) still don't completely support it and/or have performance issues with it.

Protip: if you're not using the closed-source Nvidia drivers, try those out. nouveau, the open-source drivers, may be a marvelous piece of reverse-engineering work, but... they don't exactly work well with Dolphin right now.

Sorry, I was not clear enough. I am not using Nouveau because the reclocking is not done for my video card and the 3D performance is awful. I am using the closed Nvidia drivers (I tested with series 29x and 3xx). Using the latest Dolphin revision before GLSL merge, I had a decent framerate, but not after. Also, I am sure the video card is at maximum performance.

Which "lastest Nvidia driver" have you installed? Debian unstable still uses the old 304 one. In experimental, there is a 319 one. iirc, there was some UBO performance chances in this versions ...

The hacked buffer itself shouldn't blur. It usually may crash or results in a black screen, but else it should work.

Do the game uses efb2ram or efb access? This features are known to be slower, else it should be faster. Maybe you could also try to reduce internal resolution.

I tried with all nvidia drivers from stable to experimental (319 included). But again, reverting to the pre-GLSL version gives a decent speed, so I don't see why it should be (strongly) driver-related.

Well, for the hacked buffer, "blurred" is not well chosen, the right description is "flickering", with a rapid switch between image and black screen.

For the IR, I am at the minimum. And for EFB, EFBtoTexture is used in the games I tested, and if I disable EFB, there is no real speed improvement.

In fact, I could understand a small change after GLSL-merge, but there is a huge performance loss by a factor 3 without changing the config parameters, so there should be something fishy...

results from the forum: (GLSL testing thread)

• frame-rate limited: 1xIR ->12 FPS, 2xIR -> 7 FPS
• copy everything to vram doesn't help
• same for disabled ubo
• same for dummy fragment shader
• same without efb copys
• same with "maximal performance" gpu setting

As the hacked buffer may flicker if you are gpu bottlenecked, but you are the first one reporting this issue.

I think we have to start with some GPU debugger like apitrace. I don't see where dolphin could waste so many gpu cycles ...

Thanks, it is indeed what I wrote on the forum.

For apitrace, what do I have to do?

Too much to describe here, do you want to join us on #dolphin-emu on freenode?
eg webchat.freenode.net

It will be difficult for me to join soon. Could you please tell me first which package I should install? The ubuntu package?

I have the same problem, incredible regretion. Please revert the changes or fix it.

I have the same problem too.
I am under GNU/Linux Ubuntu 13.04 x86_64. I use Nvidia proprietary drivers (319), that I have installed with sgfxi (http://smxi.org).
I was using 3.5-1566 (from PPA). I would like to play to The Last Story, that have beautiful 3D graphics. But, it was laggy and the sound was horrible during battles, even with 50 images/sec. I have downgrade to 3.5 stable and it works greatly with 60 images/sec.

Just an idea: the glsl merge reduces cpu load to the point the cpu is automatically downclocked(more often) - paradoxically leading to a situation where dolphin-emu runs slower. To verify this, setting all cpufreq scaling governors to "performance" should restore or improve performance and make the "old" versions slower than the new ones.

Setting the scaling governor to performance can be accomplished by
echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
The current active governor can be retrieved by looking at /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor. Replace "cpu0" with all the cpus you find in /sys/devices/system/cpu/. The cpufreq-set utility may be easier to work with.

It seems I'm dump. All those hints say we stall anywhere. I'm pretty sure it's the glBufferSubData call, so can someone please try the other upload methods please?

Just hack in one line in: https://code.google.com/p/dolphin-emu/source/browse/Source/Plugins/Plugin_VideoOGL/Src/StreamBuffer.cpp#41

m_uploadtype = BUFFERDATA; // This may never stall, but it's the slowest one
m_uploadtype = MAP_AND_ORPHAN; // Is usually one of the fastest without threaded driver. Maybe it's worth a try

Thanks for the advices. I put the performance settings to the maximum, but it does not change anything.

__GL_THREADED_OPTIMIZATIONS=1 is always activated for me since the beginning, and it does not solve the problem.

m_uploadtype = BUFFERDATA; -> 10 fps in Budokai Tenkaichi 2
m_uploadtype = MAP_AND_ORPHAN; -> 13 fps

With the old version -> 20 fps

Note that without setting m_uploadtype, I get severe glitches and bad rendering, but it is solve with this setting.

Any other idea for testing the problem?

It's the same for me, dolphin is unplayable on Linux with an Nvidia gpu since the GLSL merge. Guess I'm forced to stick with 3.5.

Any news about this problem, any idea, any tester wanted?

games are unplayable with dolphin 4 as it is much slower than 3.5; could we please have dolphin no-glsl-merged branch for nvidia? or maybe a patch to remove this glsl-merge for dolphin 4 series? Please!

here's Need for Speed: The Run, performance comparison

on Dolphin emu 3.5 - 25 fps
http://youtu.be/Iz8gmFkkZPo?t=38s

on Dolphin emu 4.0-277 - 15 fps (terrible)
http://youtu.be/g-csXXV8g7w?t=40s

obviously the game is unplayable with such low frame rate.

What do you say?

Any updates? It hurts me deep down to have to use such an outdated version.

It only hurts once.

Yes, chopping the leg off only hurt once!

I have today (22-12-2013) compile the last version of dolphin-emu on Debian GNU/Linux 7 amd64. Unfortunately, I have still a big problem of performance.

However, I have managed to compile the 3.5 that works fine :

1. sudo apt-get install make cmake git g++ libgtk2.0-dev libsdl1.2-dev libxrandr-dev libxext-dev libao-dev libasound2-dev libpulse-dev libbluetooth-dev libreadline-gplv2-dev libavcodec-dev libavformat-dev libswscale-dev
2. But you will have a problem with ld -Cg and ld -CgGL at compilation time. So you also need non-free packages (available in Debian repos) :( : libcg, libcg, libcggl, nvidia-cg-toolkit and nvidia-cg-dev.
3. Download 3.5 source code ("Download zip") https://code.google.com/p/dolphin-emu/source/browse/?name=3.5
4. Unzip in dolphin-emu_3-5/
5. cd dolphin-emu_3-5/ && mkdir build && cd build
6. cmake ..
7. make && make install
8. sudo aptitude purge nvidia-cg-dev nvidia-cg-toolkit
9. Enjoy, even if you need to keep libcg and libcggl that are not free.
10. In the build folder, you have to keep "install_manifest.txt". You can remove dolphin-emu with : cat install_manifest.txt | sudo xargs rm

Note: for anyone (like me) trying to follow nicolasp's instructions in #28 but who's running into compilation errors in CommonFuncs.h (e.g. "error: expected ‘)’ before ‘x’":

The problem is this bug: https://code.google.com/p/dolphin-emu/issues/detail?id=6198 . That thread has a patch, but it's against a version of the code from 2013-04-03 (which is post-GLSL) and doesn't apply cleanly older versions.

Solution:

1. Checkout commit 8767b30f75d. This is from 2013-03-15, which is just before the GLSL stuff starts.

2. Apply the attached patch, which applies cleanly to this commit. (The only difference between this and the patch in the other thread is whitespace).

That makes it build without errors for me.

We've fixed some performance issues on nvidia fermi GPUs by disabling coherent mapping. Maybe this issue was also affected by this change. So is this issue still valid?

It seems good to me now I believe. I'm not sure exactly what commit fixed it or even a general idea of when, but compiling from git seems to be working really well for me again for the last month or so. Thank you!