Dolphin, the GameCube and Wii emulator - Forums

Full Version: Why do some games run faster the second time around?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
During specific areas of some games, it'll run noticeably jerkier the first time (especially after a couple hours). But after closing Dolphin and restarting the game at that spot, the speed will be back to normal. I've noticed games that usually do this are set to EFB to RAM. Anyone know what the issue is?
Shader caching. After the shader is compiled the first time the compiled code is stored in a cache. On subsequent function calls the emulator can pull code directly from the cache instead of compiling the shader again.
Is there a function, that Dolphin looks through the game-datas and caches every shader?
(11-11-2013, 11:19 AM)slax65 Wrote: [ -> ]Is there a function, that Dolphin looks through the game-datas and caches every shader?

I'm pretty sure the only way to generate those shaders is to run Dolphin. It's probably not as simple as having the data Dolphin needs conveniently stored in a predictable place on the ISO or game file.
Dolphin doesn't look through the game to find shaders to cache, it generates the shaders depending on what parameters the game asks the GPU to render with. The GameCube/Wii GPUs don't use shaders and are not shader-based in any way, and neither do the games ever use/generate shaders; Dolphin uses shaders to emulate various parts of those GPUs. The shaders are cached after compilation because, naturally, compilation isn't instant – gotta shave every cycle we can off the CPU's massive workload.

Preemptively generating/compiling/caching shaders is kinda ridiculous/impossible since you'd have to figure out every combination of parameters a game would want the GPU to render with. It's kinda similar to why you can't just pre-recompile a game's executable and instead have to use a JIT that recompiles the code as it's given to the CPU – you can't easily know everything a piece of software will want to do before you run it, and if you *do* figure out a way, there can be either an infinite or finite-but-really-fucking-huge amount of results that you'd have to generate and cache by brute-force, by which point the long waits for generation and the amount of disk space and the ever-increasing cache-lookup-and-fetch time easily kill off any benefits of caching all this shit anyway.
So is there any way to speed up the cache process? Would lowering the IR help? Or is using EFB to texture the only way to avoid this?
Lowering IR helps, but not by too much. It adds about 5-25 FPS (depending on the game).
Lowering IR should not boost fps by that much if your cpu is the bottleneck. Which in most systems it is.

I can't think of why it would speed up shader caching.

drhycodan Wrote:Or is using EFB to texture the only way to avoid this?

Using Efb copy to texture will not prevent shader caching from occurring. There is no way to prevent shader caching from occurring. And there would be no reason to do it even if there was a way as it would greatly reduce performance for no real benefit.