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...
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.
For short, the term Interpreter I think is misunderstood here.
Definitely, but I strongly think it’s you who is wrong here.
No, it’s not compiled on the fly. With an interpreter, there is never a sequence of CPU instructions corresponding to the source code. All of the CPU instructions that run on the CPU are from the interpreter’s executable. The source code (or sometimes bytecode, which is still not CPU instructions) is treated as data. New machine code is never created.
Compiling means creating new machine code that can run on the CPU. This happens in JIT. It doesn’t happen in an interpreter.
Compiler does not mean it will produce machine code, it just means the entire program is analyzed in its full and converted to something else (usually machine code, but it could be from JavaScript into TypeScript in example).
Interpreter on the other hand takes source code and compiles one line after another in realtime. In terms of programming languages, depending on the environment it can produce machine code or call a function from another program. It can but does not have to produce machine code.
There is also Bytecode and Just in Time compilation, which makes it even more confusing to explain.
I don’t know what to say other than your description doesn’t match the opening paragraphs on Wikipedia (which I linked earlier), which AFAIK match the common meaning of the terms. The existence of cross-compilation really muddies the water here, so to clarify, in this context when I’m talking about compilation I’m talking about compiling to machine code that can run natively on the hardware in question (CPU or GPU). Compiling to anything else (bytecode, different programming language, whatever) is irrelevant for the discussion IMO.
And interpreters do not compile to machine code. If they do, it’s called JIT compilation, not interpretation.
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.
Definitely, but I strongly think it’s you who is wrong here.
No, it’s not compiled on the fly. With an interpreter, there is never a sequence of CPU instructions corresponding to the source code. All of the CPU instructions that run on the CPU are from the interpreter’s executable. The source code (or sometimes bytecode, which is still not CPU instructions) is treated as data. New machine code is never created.
Compiling means creating new machine code that can run on the CPU. This happens in JIT. It doesn’t happen in an interpreter.
Compiler does not mean it will produce machine code, it just means the entire program is analyzed in its full and converted to something else (usually machine code, but it could be from JavaScript into TypeScript in example).
Interpreter on the other hand takes source code and compiles one line after another in realtime. In terms of programming languages, depending on the environment it can produce machine code or call a function from another program. It can but does not have to produce machine code.
There is also Bytecode and Just in Time compilation, which makes it even more confusing to explain.
I don’t know what to say other than your description doesn’t match the opening paragraphs on Wikipedia (which I linked earlier), which AFAIK match the common meaning of the terms. The existence of cross-compilation really muddies the water here, so to clarify, in this context when I’m talking about compilation I’m talking about compiling to machine code that can run natively on the hardware in question (CPU or GPU). Compiling to anything else (bytecode, different programming language, whatever) is irrelevant for the discussion IMO.
And interpreters do not compile to machine code. If they do, it’s called JIT compilation, not interpretation.