That's Steam backend compiling shaders for specific architecture on the server, and then downloading and using it for local games. Not what they called online in the above quote.

View this comment - View article - View full comments

I think by online compilation they mean what I said above. Online → runtime. That should make it more clear. Simply compilation of shaders on your computer during game execution. Nothing to do with online as "on the network".

View this comment - View article - View full comments

Quoting: torbidoBecause in its announcement they mentioned "online compilation of game shaders

Do you have an exact quote? I'm not sure what "online compilation" means. Possibly just on demand, during game execution.

View this comment - View article - View full comments

If this isn't clear, here is how it works. Games or anything else GPU targeted, ship GPU programs, that are called "shaders". To address the issue of multiple GPUs that exist (that have different hardware architecture), you can't just ship shaders in the form of the machine code, like you do for regular compiled CPU programs.

So what happens is (simple case, not covering complex ones like translation layers and Wine), that your shader written in high level language like GLSL or HLSL is compiled into portable intermediate representation (bytecode) i.e. SPIR-V during your development. This shader is shipped with the game. When the game runs, it passes the shader to the graphics backend (i.e. Vulkan "driver"). It has to use a compiler, to compile that SPIR-V shader into GPU machine code. That compiler is arleady specific to the GPU it's targeted at. I.e. the same game would work with Intel, AMD or Nvidia, in each of those cases, relying on different compilers to turn SPIR-V into machine code to be executed on the GPU.

This way developers themsleves don't need to compile shaders before hand into machine code, which makes games more portable and future proof. I.e. if you'd be shipping machine code shaders with your game, it would break on each new GPU generation or so, plus you'd need to compile for every existing GPU architecture yourself, and then select it at runtime yourself too. Basically - too messy.

Until now, Mesa used amdgpu (llvm based) compiler for AMD cards for Vulkan and OpenGL use cases:

* https://github.com/llvm-mirror/llvm/tree/master/lib/Target/AMDGPU [External Link]
* https://github.com/llvm-mirror/llvm/blob/master/docs/AMDGPUUsage.rst [External Link]
* https://llvm.org/docs/AMDGPUUsage.html [External Link]

Now developers are working on standalone compiler, that's not relying on llvm. Again, this has nothing to do with Steam service, but Valve developers are leading the effort though.

View this comment - View article - View full comments

Quoting: torbidoIs there any review or an article to backup your words?

That's what it is. A shader compiler for the Vulkan driver (radv). I.e. why do you assume it's something to do with Steam (service)? If you think so, you should have a source for such assumption, not the other way around.

View this comment - View article - View full comments

Quoting: torbidoI don't think that it will provide any noticeable results with non Steam games. Correct me if I am wrong.

It makes a difference for Vulkan games. Nothing to do with Steam specifically.

View this comment - View article - View full comments

Quoting: torbidoThe shaders are available to be downloaded from Steam. How is it available for non Steam games?!

Shaders come with games, Steam probably only provides cached versions of compiled shaders for some games that have too much stutter on startup without the cache. I.e. Steam has nothing to do with the concept of shaders themselves.

https://en.wikipedia.org/wiki/Shader [External Link]

View this comment - View article - View full comments

Nice progress! Some clarification from ACO developers about upstreaming and usage of their development Git repos:

This github repo [External Link] will include some optimizations that haven't yet been upstreamed for a while.

The contents of the aco-navi branch [External Link] is not upstreamed, so you will need it to test ACO with Navi.

View this comment - View article - View full comments

In theory, but in practice it's not always that simple.

View this comment - View article - View full comments

Quoting: RedfaceAs far as I remember then libraries that interface with drivers will have to be the same version, so nvidia and mesa will have to be a current version in the container. The programs in the container run on the same kernel.
And in the Ubuntu world frozen does not mean unmaintained, even if it sometimes seems like it or even is. Security and other bugfixes will be backported to the "frozen" version.

Why do you need containers then, if libraries there will be recent? Multiarch already works fine for that. Containers make sense for frozen case, when there are no more upstream updates coming.

View this comment - View article - View full comments