Emulator

Does the issue persist if you force Dolphin to be put into high performance mode in the nvidia control panel?

@NeoBrainX, manually selecting the high performance dedicated graphics option in the NVIDIA control panel for dolphin.exe did indeed resolve the issue. Thanks for the suggestion.

This has been happening to me as well; it seems to be very, very recent though.

Oh, this may be a result of the new NVIDIA drivers rather than dolphin, perhaps?

It does happen to me too, while I don't have NVIDIA. I'm having Intel(R) HD Graphics 4000

iv got a nvidia card gtx 760, the only game i get crash straight away when using opengl is with CRASH NITRO KART, i get a popup saying dolphin.exe has stopped responding, if i use direct3d the game will run without crashes, i hope someone can look into this game

I don't have crash nitro kart, but I do have a GTX 760. I don't know what else to say though. There's no games that crash for me, and I haven't found a reasonably priced crash nitro kart locally.

Not just NVIDIA- Happens for me on an AMD R9 270X with OpenGL backend on Linux with open source radeon drivers.

Issue 7802 has been merged into this issue.

I'm running into this as well. I have an Intel(R) HD Graphics 4400 and an Nvidia GT 740m 2GB dual GPU setup. I can run games fine the first time, but then any time after crashes. I have tried specifically running the emulator on the Intel and the Nvidia chipsets, but both crash.

You need to set your Optimus stuff to be in high performance; they won't let us select the Graphics Card in those situations.

I think we should try to add the gl_rederer string within this cache and to only load them, if this string matches.

I don't know if this will affect the performance of the game (I encounter same levels of performance when I do this or run a fresh install) but, when I make 3 notepad files in the "C:/Users//Dolphin Emulator/ShaderCache" directory and rename them (Along with their filetypes) to the names of the files already IN that folder, I can run OpenGL any number of times without a crash.

Issue 7833 has been merged into this issue.

Hi am getting this issue on a GTX970 desktop with no Intel HD graphics onboard

I initially thought OpenGL was crashing but in fact it's writing a 5GB(!) file

Hi just tried again and allowed Dolphin to run after trying to exit -now an 11GB(!!) file

Tried with driver shadercache on and off -no difference

Issue 8138 has been merged into this issue.

I have to bring this important issue up, when playing "Baten Kaitos: Eternal Wings and the Lost Ocean" the game creates a file named "ogl-GKBEAF-shaders.cache" inside the "ShaderCache" folder and the file takes a lot of space, last time i checked it had 17GB!!!

This issue needs some attention, hope the developers take a look at this.

This was tested on the latest Dolphin revisions "4.0-4969" and "4.0-5328".

Sorry to bring the topic here but this thread is closely related to this issue, i also have a GTX 970.

Pinging this again. We don't know what's going wrong exactly. Something to do with asynchronous shutdown causes this to be able to happen. We don't know what or how, and I don't think it's Armada's bug, as much as one uncovered.

Pinging this again. We don't know what's going wrong exactly. Something to do with asynchronous shutdown causes this to be able to happen. We don't know what or how, and I don't think it's Armada's bug, as much as one uncovered.

To fix this issue we really need to know what kind of shaders (if any) are taking up so much space. Can anyone with such a huge shader file compress it and upload it somewhere? (Assuming it compresses well)

Luckily it does! 4Gb->600kb(!) lol

I worked around this by symlinking the cache file to a 128MB partition, it keeps the load/close time down and doesn't seem to do anything else weird. It just fills the whole partition.

When I open Baten Kaitos and then close it as the intro cinematic starts, it seems to add around 1.4GB to the file each time(in a large partition). I did that a couple times and have a 6GB file. I'll go ahead and upload both since they compress so well.

As expected the cache is just full of zeros. Maybe it keeps caching failed compilations?

Does this only happen with OGL or also with D3D?

Only happens with OGL, the dx11 files are all below 12KB

If you enable the Side-by-Side stereoscopy mode, does it work or does it give you a warning that it is unsupported?

Could you also have a look at my ticket more closely to mark it as not dupe (the one that were merged with this)?
https://code.google.com/p/dolphin-emu/issues/detail?id=8138

I think this is different issues.
No crash for me, no 16 GB shaders cache and I run games that does not apply to this ticket starter requirements "2. Launch an ISO that has never been launched
"

It works, but with the same huge file writing behavior.

Please try this build: http://dl.dolphin-emu.org/prs/pr-2164-dolphin-latest-x64.7z

That build seems to have fixed it, there's no huge file anymore.

Ok, that means that either one of these 3 cases apply that cause huge shaders to be written to the disk:

1. Shaders that have been deleted are being written to disk.
2. Shaders that have failed to link are being written to disk.
3. Non-existant shaders are being written to disk.

Are any such shaders ever supposed to be part of the cache?

1. We don't delete shaders at all.
2. Would result in a panic alert, but maybe they are disabled by the user. We don't delete them as we don't them to be recompiled that often.
3. I have no idea what this could be.
4. Driver issue ;)

It's happened on my NVIDIA in F-Zero GX before.

Question: Does this allow Intel HD to boot OpenGL multiple times without crashing now?

Also, does using that build actually reduce the size of cache files that are already huge? We might have to implement a method to clean up those shader caches.

using a new build (with a new git hash) should clear this cache, so this
issue will be solved by itself

2015-03-02 17:08 GMT+01:00 dolphin-emu@googlecode.com:

I'm getting this error on 4.0-5991 and 5993, same scenario as described above.