28
SCSKiller v1.4.4 - Linux support is no longer experimental: Heroic, Lutris and Faugus Launcher join Steam. Get the AppImage from the release page. (github.com)
submitted 6 days ago by to c/linux_gaming@lemmy.world
23 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 2 points 6 days ago (8 children)

I started writing something in response but I quickly realized I'm also not knowledgeable enough to even discuss this further..

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 2 points 6 days ago (7 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 2 points 5 days ago (6 children)

    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).

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 1 point 5 days ago (5 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 1 point 5 days ago (4 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 5 days ago (3 children)

    No - they don’t.

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 5 days ago (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 5 days ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 5 days ago

    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.

  • permalink
  • fedilink
  • source
  • parent