This build isn't code-signed yet, so the first run will probably show SmartScreen's "Windows protected your PC".
Click More info, then Run anyway. Updates never show it.
To check the download arriv...
Edit: Ah, I wanted to reply to another user who asked what this software does. I replied to the post instead, sorry.
I just learned about this program last night thanks to Digital Foundry video “Scskiller - The Beginning of the End for PC #StutterStruggle?” Nov 3, 2026 YouTube / Invidious.
A community project that tries to precompile Shaders of games that need it the most. This can help in some cases to have smoother gameplay.
Compiling is a process to translate generic Shader code into something your personal hardware can use. PC games are plagued by stutters from Shader compilation. Shaders are graphics units deployed with the game for good graphics. But these are generic and every graphics card needs to compile them before using. In example if you meet a new graphics in the game for the first time, then it needs to compile and cache on the drive, so it can be reused. The first time such compilation happens the game would stutter. To combat this, developers can integrate a Shader compilation process before you play, which takes time depending on the hardware. But the result is a smoother gameplay. But not every game has good precompilation process or any at all. And this tool tries to help with that.
This does not help with other type of stutters, such as traversal stutter from Unreal Engine. That is a completely different problem. And consoles don’t have Shader compilation issues, because for each game the precompiled Shaders are already delivered with the game, because the hardware is known.
Interesting. My first thought upon reading this is: I wonder if anything akin to Dolphin’s Ubershaders is viable for PC games? Specifically hybrid mode. If a game implements this, it would completely solve this issue. When a shader is first needed, it will start asynchronously compiling, but the ubershader (which would be compiled at game launch) would immediately be able to render it - albeit less efficiently than the fully compiled shader. This would replace stutters with temporary framerate dips, which might not even be noticeable (since only a handful of newly-encountered shaders actually need this slower treatment in any given frame).
Heck, if this is viable, it can be implemented in the GPU (or its driver) and solve the problem for every game. That would be sweet.
I’m not knowledgeable enough to know the answer. One thing that is different with Dolphin is, that the hardware they emulate is known and the games itself do not change with updates either. So they semi half-pre-compile them maybe, so the rest of the compilation process for your hardware is less work? The Gamecube games itself doesn’t have any Shaders to compile, so there is nothing in the system implemented to compile. Dolphin itself introduced this step.
Meanwhile on PC, the entire GPU and driver architecture provides steps to compile. The developers just don’t do it properly, while SCSKiller does the job the developers would have done; by asking the GPU to compile what the game should do.
I don’t fully understand Ubershaders, even with reading parts of the post. So I don’t know if this could be applied to generic PC games where the hardware is completely unknown and the games get updates.
I don’t mind discussing this for fun. As long as we acknowledge our unknowledge (yes I created a new word) and any reader understands that. I just wanted to add another thing.
On the Steam Deck, which is still a PC architecture, it has known hardware. So Valve can ship precompiled Shaders for the games. So its a PC, but with the benefit (which also is a limitation to upgrade) of a console. :-) And Steam itself even has an option to share user generated Shaders, that others can download if you tick the box to upload them. This doesn’t solve the issue for the first players with that specific GPU, but for common graphics cards it can help to eliminate this issue for most.
Okay, so the way I imagine the ubershader is as an interpreter for uncompiled shaders. It may be much slower than the compiled shader, but it doesn’t need to wait. Just like JavaScript or Python or Lua can be interpreted instead of compiled. So if a shader is required for this frame but isn’t compiled yet, you use the ubershader to render it right now while asynchronously sending it to be compiled for full-speed rendering on future frames.
But yeah, it might be completely impossible, I really know nothing about how shaders work (both before and after compilation).
As I understand, Ubershaders are huuuge Shaders that can be used instead many small ones. That’s why they are smaller, but apparently. I still don’t entirely understand why its better.
Just like JavaScript or Python or Lua can be interpreted instead of compiled.
I’m not sure what you mean by that. Those are script languages that are shared by its source code. They still need to be compiled. Shaders are also just source code that need to be compiled, they are script languages too. Python compiles to Bytecode, that sits in between the final compilation and the source code, basically a cache. Modern JavaScript engines on the other hand uses JIT, Just-in-Time compilation which only compiles what is needed right now.
I’m not sure what you mean by that. Those are script languages that are shared by its source code.
Yes, that’s why I chose them.
They still need to be compiled.
No - they don’t. Sometimes they can be compiled, but when using a “pure” interpreter, there is no compilation step. The source code is read and executed on the fly.
https://en.wikipedia.org/wiki/Interpreter_(computing)
“In computing, an interpreter is software that executes source code without first compiling it to machine code.”
JIT is actually a kind of middle-ground, where it does compile the source code (or sometimes just the most critical parts of it) for better performance.
Python is traditionally only interpreted AFAIK, but it’s nuanced and it’s a rabbit hole I can’t hop into right now.
So, my basic understanding is that shaders currently use a JIT compilation model: the first time a shader is needed, it is compiled first and then executed. Which obviously causes stutters. If there was a GPU shader-interpreter that could skip the compilation step at the cost of execution speed (but still be faster than fully compiling the shader) then, well, that would be what I mean.
I really don’t understand what you mean. Off course they are compiled, otherwise they cannot be executed. Script language does not mean “run without compile” (whatever that would mean). It means, compile the moment it is needed. Python compiles the entire code in one step, while JavaScript compiles only parts of the script the moment it needs.
The source code is read and executed on the fly.
By compiling on the fly.
Python is traditionally only interpreted AFAIK
And what do you think “interpreted” does mean? It means it compiles the code when it needs. Shaders work like Python, you distribute the source code and the code is compiled on demand.
If there was a GPU shader-interpreter that could skip the compilation step at the cost of execution speed
GPU Shader compilers are interpreters, like with Python. Python interpreter produces a Bytecode cache that only needs half of the compilation process on your specific machine.
For short, the term Interpreter I think is misunderstood here. An Interpreter just means it compiles the code right now on demand, and executes it right now. While a Compiler compiles the code ahead and produces code that you can execute later. JIT is an Interpreter that only compiles parts of the code that is needed right now.
Edit: Ah, I wanted to reply to another user who asked what this software does. I replied to the post instead, sorry.
I just learned about this program last night thanks to Digital Foundry video “Scskiller - The Beginning of the End for PC #StutterStruggle?” Nov 3, 2026 YouTube / Invidious.
A community project that tries to precompile Shaders of games that need it the most. This can help in some cases to have smoother gameplay.
Compiling is a process to translate generic Shader code into something your personal hardware can use. PC games are plagued by stutters from Shader compilation. Shaders are graphics units deployed with the game for good graphics. But these are generic and every graphics card needs to compile them before using. In example if you meet a new graphics in the game for the first time, then it needs to compile and cache on the drive, so it can be reused. The first time such compilation happens the game would stutter. To combat this, developers can integrate a Shader compilation process before you play, which takes time depending on the hardware. But the result is a smoother gameplay. But not every game has good precompilation process or any at all. And this tool tries to help with that.
This does not help with other type of stutters, such as traversal stutter from Unreal Engine. That is a completely different problem. And consoles don’t have Shader compilation issues, because for each game the precompiled Shaders are already delivered with the game, because the hardware is known.
Interesting. My first thought upon reading this is: I wonder if anything akin to Dolphin’s Ubershaders is viable for PC games? Specifically hybrid mode. If a game implements this, it would completely solve this issue. When a shader is first needed, it will start asynchronously compiling, but the ubershader (which would be compiled at game launch) would immediately be able to render it - albeit less efficiently than the fully compiled shader. This would replace stutters with temporary framerate dips, which might not even be noticeable (since only a handful of newly-encountered shaders actually need this slower treatment in any given frame).
Heck, if this is viable, it can be implemented in the GPU (or its driver) and solve the problem for every game. That would be sweet.
I’m not knowledgeable enough to know the answer. One thing that is different with Dolphin is, that the hardware they emulate is known and the games itself do not change with updates either. So they semi half-pre-compile them maybe, so the rest of the compilation process for your hardware is less work? The Gamecube games itself doesn’t have any Shaders to compile, so there is nothing in the system implemented to compile. Dolphin itself introduced this step.
Meanwhile on PC, the entire GPU and driver architecture provides steps to compile. The developers just don’t do it properly, while SCSKiller does the job the developers would have done; by asking the GPU to compile what the game should do.
I don’t fully understand Ubershaders, even with reading parts of the post. So I don’t know if this could be applied to generic PC games where the hardware is completely unknown and the games get updates.
I started writing something in response but I quickly realized I’m also not knowledgeable enough to even discuss this further…
I don’t mind discussing this for fun. As long as we acknowledge our unknowledge (yes I created a new word) and any reader understands that. I just wanted to add another thing.
On the Steam Deck, which is still a PC architecture, it has known hardware. So Valve can ship precompiled Shaders for the games. So its a PC, but with the benefit (which also is a limitation to upgrade) of a console. :-) And Steam itself even has an option to share user generated Shaders, that others can download if you tick the box to upload them. This doesn’t solve the issue for the first players with that specific GPU, but for common graphics cards it can help to eliminate this issue for most.
Okay, so the way I imagine the ubershader is as an interpreter for uncompiled shaders. It may be much slower than the compiled shader, but it doesn’t need to wait. Just like JavaScript or Python or Lua can be interpreted instead of compiled. So if a shader is required for this frame but isn’t compiled yet, you use the ubershader to render it right now while asynchronously sending it to be compiled for full-speed rendering on future frames.
But yeah, it might be completely impossible, I really know nothing about how shaders work (both before and after compilation).
As I understand, Ubershaders are huuuge Shaders that can be used instead many small ones. That’s why they are smaller, but apparently. I still don’t entirely understand why its better.
I’m not sure what you mean by that. Those are script languages that are shared by its source code. They still need to be compiled. Shaders are also just source code that need to be compiled, they are script languages too. Python compiles to Bytecode, that sits in between the final compilation and the source code, basically a cache. Modern JavaScript engines on the other hand uses JIT, Just-in-Time compilation which only compiles what is needed right now.
Yes, that’s why I chose them.
No - they don’t. Sometimes they can be compiled, but when using a “pure” interpreter, there is no compilation step. The source code is read and executed on the fly. https://en.wikipedia.org/wiki/Interpreter_(computing)
“In computing, an interpreter is software that executes source code without first compiling it to machine code.”
JIT is actually a kind of middle-ground, where it does compile the source code (or sometimes just the most critical parts of it) for better performance.
Python is traditionally only interpreted AFAIK, but it’s nuanced and it’s a rabbit hole I can’t hop into right now.
So, my basic understanding is that shaders currently use a JIT compilation model: the first time a shader is needed, it is compiled first and then executed. Which obviously causes stutters. If there was a GPU shader-interpreter that could skip the compilation step at the cost of execution speed (but still be faster than fully compiling the shader) then, well, that would be what I mean.
I really don’t understand what you mean. Off course they are compiled, otherwise they cannot be executed. Script language does not mean “run without compile” (whatever that would mean). It means, compile the moment it is needed. Python compiles the entire code in one step, while JavaScript compiles only parts of the script the moment it needs.
By compiling on the fly.
And what do you think “interpreted” does mean? It means it compiles the code when it needs. Shaders work like Python, you distribute the source code and the code is compiled on demand.
GPU Shader compilers are interpreters, like with Python. Python interpreter produces a Bytecode cache that only needs half of the compilation process on your specific machine.
For short, the term Interpreter I think is misunderstood here. An Interpreter just means it compiles the code right now on demand, and executes it right now. While a Compiler compiles the code ahead and produces code that you can execute later. JIT is an Interpreter that only compiles parts of the code that is needed right now.