You need the source code and the OpenGL/D3D pipeline state. A shader may have to be recompiled when the state changes.
Here's what I know about the shader cache in Dolphin:
Every effect in every map, against every character, etc, and every last texture and ray of light, is something that needs to load. To fix this in Brawl, you would just play with every character, and every skin, on every stage, and use every single item, and the game will no longer hang at the beginning, or when effects are being used.
In Wind Waker's case, it's almost the same. Going to every single place and opening every chest (basically playing through the entire game), will lessen the stuttering issues.
The stuttering is worse when you have custom textures, because they are bigger files and have a slower load time because of that.
Playing a game in one version of Dolphin, then playing that same game in another version, will completely deplete your shader cache for that game.
Upgrading your graphics card (even just the drivers) or installing a new OS (e.g. Windows 10) will erase your entire shader cache.
Basically the more you play through a game, the less prevalent your issues with the shader cache will be.
If you don't want to deal with these issues, you can use the Ishiiruka build of Dolphin with Async Shaders enabled. You will no longer have stuttering problems, and you won't have to worry about updating Dolphin and new versions messing with your stuff.
shangry Wrote:If you don't want to deal with these issues, you can use the Ishiiruka build of Dolphin with Async Shaders enabled. You will no longer have stuttering problems, and you won't have to worry about updating Dolphin and new versions messing with your stuff.
Async shaders is not a solution! All it does is render black while the shader is being generated. So it's either stuttering or very obvious visual anomalies. It's great that Ishiiruka provides the option, but it's only a workaround and not a solution, so please do not give other users false hope!
(08-18-2015, 03:56 PM)MaJoR Wrote: [ -> ]shangry Wrote:If you don't want to deal with these issues, you can use the Ishiiruka build of Dolphin with Async Shaders enabled. You will no longer have stuttering problems, and you won't have to worry about updating Dolphin and new versions messing with your stuff.
Async shaders is not a solution! All it does is render black while the shader is being generated. So it's either stuttering or very obvious visual anomalies. It's great that Ishiiruka provides the option, but it's only a workaround and not a solution, so please do not give other users false hope!
This is true, sorry. It's just that I really don't notice it happening too often in any of the games that I play with Ishiiruka. On Brawl, it seems the only stage that suffers from terrible texture popping is Battlefield. Other than though, it plays just fine, as does Super Mario Sunshine and Donkey Kong Country Returns.
(08-18-2015, 07:13 AM)Fiora Wrote: [ -> ]You need the source code and the OpenGL/D3D pipeline state. A shader may have to be recompiled when the state changes.
I'm assuming the OGL/D3D pipeline state is specific to GPU model and/or driver version, right? So, sharing shader source to compile ahead of time isn't a solution then
Question related to shaders: does the hash of dumped vertex/pixel shaders depend on anything else other than the Dolphin build and the per-pixel lighting option (considering the D3D backend only)?
I made a bunch of shader modifications with 3Dmigoto and I don't know if they work for someone else. I didn't receive a positive or negative report yet.
You can try the ones I posted in my texture pack threads.
(08-18-2015, 05:45 PM)Jhonn Wrote: [ -> ] (08-18-2015, 07:13 AM)Fiora Wrote: [ -> ]You need the source code and the OpenGL/D3D pipeline state. A shader may have to be recompiled when the state changes.
I'm assuming the OGL/D3D pipeline state is specific to GPU model and/or driver version, right? So, sharing shader source to compile ahead of time isn't a solution then
The OGL/D3D state depends on the program being run and how it has things set up at the time the shader is used. But yeah, it doesn't just depend on the pipeline state; it depends on the GPU, drivers, OS, and so on. As far as I know, there's no real guarantee that shader binaries are even compatible between GPU firmware versions or board vendors or GPU silicon revisions, for example. There's no attempt to keep this kind of compatibility because it's not necessary (shaders are always compiled at runtime by the driver).
For the curious, I work on a shader compiler (admittedly, for mobile, not desktop) and have directly observed the following:
- Different GPUs (even of the same rough architecture) having significantly different instruction sets, since each generation evolves things from the previous.
- Hardware bugs, sometimes even specific to particular silicon revisions, which need workarounds in the shader compiler.
- "Revision-locks" between driver and compiler version, often as fast as every few weeks (e.g. if the driver changes how memory is laid out, adds a new feature, etc, the old compiler no longer is fully compatible).
- Different driver decisions regarding what instructions/texture formats/etc should be used depending on the GPU model, /even for GPUs in the same series/. So for example if you have a mid-end and high-end GPU, both with the same microarchitecture (only difference is one of them is bigger), the driver might still decide to do things differently on the bigger GPU for performance reasons.
And this is just a small taste; given the way that GPU drivers are developed, trying to compile shaders on anything but the computer they're run on is probably a bit of a fool's errand.
But the bottleneck is on CPU which is translating Wii to something that our GPU will understand (and this is cached) or on graphic card, which need to actually shade it and the result is cached here (IMO no, because GPU is now getting something that it would be getting from regular PC game?).
I'm just thinking loud, because for me C++ and OGL/D3D is black magic ... I'm just only "PHP guy" ... but it's really interesting for me
If no one can come up with a solution to this couldn't we just invent our own PCIe hardware to deliver the results to the GPU? kinda like the phys x cards?
First, nice bump.
Second, lmfao