Development Thread Please test 'GLSL-master'

[Sonicadvance1]

This branch has been a long time in the making. I think I started this somewhere around two years ago at this point and it is nearly done.

First I'll explain what this branch is for.

In the master branch, we currently are taking advantage of a library from Nvidia called CG. This is a do it all library that takes our CG shaders and compiles them in to "ARB" shader that the OpenGL backend can understand. The advantage of this library is it makes most operations "just work" on any form of GPU, and it is stupidly quick at it. Our OpenGL backend is basically garbage code at this point, and Nvidia CG is able to chew through all of it and provide amazing framerates considering.
Now the disadvantage of using Nvidia CG is it locks you down to using their proprietary library and shaders that aren't supported on other platforms, eg Android, *BSD, ARM Linux. We only get it on hardware and software that Nvidia provides binary blobs for. Another issue is that it compiles down in to ARB shaders, which is grossly outdated at this point as the world has moved on to GLSL shaders.

This is where the GLSL-master branch comes in. This branch was first started by me, then a lot of work was put it by Degasus (Markus Wick) to really clean it up.
Others have also contributed a fair bit to it. So the GLSL-master branch isn't just about switching from ARB to GLSL shaders, there is a lot more work that has been done to it.

Basically any feature that has relied on GLSL getting merged in to master has been merged in to this final branch for the upcoming merge. This includes but isn't limited to

• Speed increases everywhere.
• Speed decreases everywhere.
• Virtual XFB speed ups
• Using GLSL shaders instead of Nvidia CG obviously
• Bunch of other things.

Now that's not all, but these changes come at a price. We are dropping hardware that was prior supported in the OpenGL backend.
Supported GPUs are as follows

• Intel HD series Graphics (Clarkdale, Arrandale, Sandy/Ivy Bridge)
• ATI Radeon HD 2000 or above
• Nvidia Geforce 6 or above

Note on Geforce 6/7 series graphics, support for those may be restored in the future once we support GLES3 devices.

A couple currently known bugs already.

1. AMD/ATI Pinned memory seems to be causing some issues recently. [19-03-13]
2. AA inaccuracies(Appear in master, but not in OGL) [22-02-13]
3. Post-processing shaders are broken. We are working on revamping post-processing. [07-03-13]
4. OSX support is currently broken. We don't have a OSX dev, but we are working on it.
5. There is a bug on Mesa9 + Intel architectures of a dithering bug that is noticeable in rendering. Fixed in Mesa 9.1 or 9.1.1
6. Pixel lighting seems to darken things. [22-02-13]
7. Running multiple games causes weird EFB problems, probably due to some missing cleanup [22-02-13]

Known issues with OSX.

1. wx creates the common rendering window, but the agl glinterface creates a new one, so the input would be fetched from wx one, the gl context draws on the agl one
   
2. Vertex Loader Jit crashes sometimes - Disabled due to instability, didn't really cause any speed increases anyway.
3. Slow performance on hd3000 with ubo - Intel HD3000 drivers don't provide support so it falls back on to software, can't be fixed.
4. Dropping OSX 10.6 support. - Won't be "fixed"

[Edit]
Update here. A option has been added to the video options.
This option is called, "Hacked Buffer Upload." This is basically a option that may or may not work depending on hardware/software configurations.
This option is only needed for non-ATI/AMD based cards.
Basically this option works around drivers not providing a "Pinned Memory" extension that AMD offers.
This /could/ potentially cause quite a few speed ups, but isn't technically allowed by OpenGL spec without the extension support.
If you could, and own non-ATI hardware, try this option out and see if it works or not, that would be great.

The new download links are below.

21-02-2013
724 update which will improve the speed on Nvidia hardware without using the hacked buffer upload.

22-02-2013
728 update which fixes some rendering issues most noticeable in starfox

26-02-13
Support for Geforce 6 and 7 devices were re-added with version 737

06-03-2013
OSX support has been recently "fixed." It's working, but not all that great.

07-03-2013
Post Processing shaders have been fixed and translated to GLSL in 942

14-03-2013
OSX creating multiple windows has been fixed.

19-03-2013
MSAA inaccuracies have been fixed.
[/Edit]

Here are the binaries for Windows.
x64: http://dl.dolphin-emu.org/builds/dolphin-master-3.5-1056-x64.7z
x86: http://dl.dolphin-emu.org/builds/dolphin-master-3.5-1056-x86.7z

Binary for OSX.
http://dl.dolphin-emu.org/builds/dolphin-master-3.5-1056.dmg

Binary for x64 Ubuntu 12.10.
http://dl.dolphin-emu.org/builds/dolphin-master-3.5-1056_amd64.deb

For other Linux, check out the latest Master branch since it has been merged now.

When you give us your results, make sure to give Operating System, Graphics card make and model, and driver version.

[Shonumi]

A few things I need to clear up before I start contributing reports. My current version of GCC (4.5.2) doesn't support nullptr for C++0x, so I've just done Find & Replace with NULL. Let me know if this could cause any difference in performance.

Additionally, Line 263 refuses to compile; GCC says "GLEW_AMD_pinned_memory" was not defined in this scope. My drivers aren't the latest (297.xx, sorry not at my computer atm, so I can't look it up) so I'm not sure if that's an issue. Commenting it out lets Dolphin compile just fine though. Let me know if any of the above code modifications invalidates my results. I'm still using Slackware 13.37 64-bit with a GTX 550 Ti.

Comparing 29d43ef897275bd200cee0ec4492b1c2052902f3 on both master and GLSL-master (3.5-419 and 3.5-739 respectively, I think) Super Smash Brother Melee runs significantly slower on GLSL-master than on master on the Fountain of Dreams stage. I consistently get 25~30 FPS as opposed to a constant 60 FPS.

On Super Mario Galaxy 2, Mario's models appear to have darker lighting on GLSL-master than master. If your game file icon is the Mario head, you'll know the difference before you play the game. In-game, Mario looks darker, but the rest of the game's lighting appears fine.

Sorry for reporting regressions, I only just tested it barely. I'll have more free-time tonight, and I'll post screenshots and I will update you on my exact driver version as well. Again, tell me if the slight modifications I made (only way I've gotten recent revs to compile) are potentially affecting the results.

[Sonicadvance1]

The nullptr replacement is fine.
The Glew line is because your OS needs Glew 1.8 or higher. Uninstall glew to pull in Dolphin versions to fix that error, or install 1.8 when your OS supports it. It won't invalidate your results since it is only used on ATI hardware.

Try the hacked buffer upload as well, it may give you the speed difference.

[JMC47]

I tested the GLSL on my main rig (core i5 760 @ 3.8GHz with a GTX 470) and found huge speed boosts in some games! Most games saw pretty impressive improvements. Considering I tested multiple builds, I labeled the results as clearly as I could considering that I was trying to test as much as I could, as fast as I could.

Hbuffer is the Hacked Buffer Upload, which changed between 724 and 724+. In 724+, Hacked Buffer Upload is marked as Hbuffer+. 724+ is a hacked version of 724 that is unsafe, it works around a bug in my video cards drivers.

Mario Super Sluggers World Map, EFB to Texture

Master - 72 fps
GLSL723 - 74 fps
GLSL724 - 72 fps
Hbuffer - 72 fps

Mario Super Sluggers Challenge Map, EFB to TExture

Master - 64 fps
GLSL723 - 64 fps
GLSL724 - 63 fps
Hbuffer - 64 fps

New Super Mario Bros Wii EFB to Texture - Opening Crawl (averaged)

Master - 160 fps
GLSL723 - 154 fps

New Super Mario Bros Wii EFB to RAM

Master - 50 fps
GLSL - 41 fps
GLSL724 - 46 fps
HBuffer - 44 fps

Xenoblade Chronicles Opening (EFB to RAM)

Master - 83 fps
GLSL723 - 77 fps
GLSL724 - 79 fps
Hbuffer - 84 fps

Twilight Princess (Wii, EFB to RAM)

Master - 50 fps
GLSL723 - 40 fps
GLSL724 - 54 fps
HBuffer - 52 fps

Mario Party 4 Start Menu (EFB to RAM)

Master - 89 fps
GLSL723 - 50 fps
GLSL724 - 243 fps
Hbuffer - 93 fps

Mario Galaxy (EFB to Texture) - Main Menu

Master - 69 - 97 fps
GLSL723 - 42 - 45 fps
Hbuffer - 89 - 110 fps

Mario Galaxy (EFB to Texture) - Castle

Master - 53 fps
GLSL - 46 fps
GLSL724 - 69 fps
Hbuffer - 56 fps
Hbuffer+ - 78 fps

Mario Kart Wii (EFB to Texture) - Wario in Time Trial Luigi Circuit

Master - 86 fps
GLSL724 - 91 fps
Hbuffer+ - 94 fps

Fortune Street (Efb to Texture) Castle Trodain

Master - 36 fps
GLSL724 - 45 fps
Hbuffer+ - 46 fps

[Rhys]

On my laptop changing from full screen to windowed or vice versa has a high chance of causing the entire system to restart (not even a bsod shows!). I'm getting this with every game I have. I'm using the x64 build currently in the top post (3.5-724), all settings are default apart from IR, which is set to Auto (Window Size).

If I set the IR to anything else, the screen stays black, and the crash doesn't happen when toggling fullscreen.

This problem doesn't happen on my PC, which has a 660ti and desktop equivalent cpu, so I'm assuming it may be a problem with nvidia laptop cards. Laptop specs are in my sig.

[Xalphenos]

Probably a stupid question but you want tests using the OpenGL backend right.

[Sonicadvance1]

yes

[Xalphenos]

Using this release I get lines going through Mario outlining parts of him almost. Here is a pic. SMG1 btw.


It is far more noticeable in game than in this pic. All settings the same it doesn't happen in 3.5 stable or the latest master.

Specs:
Windows 8 pro x64
Gigabyte GTX 660 windforce 2GB GDDR5
Driver 310.90
I just checked and newer drivers released a few days ago so ill try again with updated drivers and some more games over the weekend.

[isamu]

sonic does this GSLS affect GC games or just wii?

[delroth]

Both.