Looking forward to it. And great to see that it's coming out on GOG. Paradox own games have some issues with Steam lock-in. I suppose Obsidian managed to convince Paradox to avoid it.

View this comment - View article - View full comments

I have 3D Atomic edition on GOG. And it's indeed gone now from the store for those who don't have it. Why can't Gearbox play nice and keep it in stores? Devolver should have kept the rights. They are way better owners than Gearbox.

View this comment - View article - View full comments

Except actual OpenVR isn't open (i.e. SteamVR). I've just red some news that Collabora are actually working on open replacement for SteamVR.

View this comment - View article - View full comments

I'm waiting for them to support Vulkan in Unigine.

View this comment - View article - View full comments

Quoting: swickCaching shaders (or rather pipelines, because shaders can compile to different variants with different pipelines) is the responsibility of the application. https://www.khronos.org/registry/vulkan/specs/1.0-wsi_extensions/xhtml/vkspec.html#pipelines-cache [External Link]

It's good if developers know that and implement such caching. Do actual current Vulkan games implement it?

View this comment - View article - View full comments

Yes, Vulkan should allow better management and offloading of such tasks to multiple threads. That helps, but it will still be up to developers when to load certain shaders. Some tend to do it at startup, which results in massive compilation right away (that's why some games load so slowly first). Some do it gradually, and try to spread the load more evenly. Either way, as you said, caching should better be done as well. I hope radv developers are planning to implement it. Not sure what happens with radeonsi in this regard (with GLSL shaders).

View this comment - View article - View full comments

To clarify for those who aren't familiar with how shaders work. Basically, to make cross platform games (i.e. cross hardware), their graphics commands need to be presented in some generic bytecode fashion. In case of Vulkan it's SPIR-V. Then at runtime, special compilers translate that bytecode into hardware specific instructions (differently on each GPU naturally). Optimization happens on that compilation step, but SPIR-V itself isn't as suitable for optimization as NIR (intermediate format used by the Intel drivers). If I understand correctly, runtime compilation will work like this: SPIR-V → NIR → llvm IR → GPU machine code. That's quite some sequence, but it allows producing better optimized result. Trouble is, since it all happens at runtime, it can cause noticeable delays. Caching of compiled result is a common solution of this issue.

View this comment - View article - View full comments

By that time, radv can be even better already. AMD developers are also considering stopping their current tedious pre-opensourcing review efforts, and instead complete radv with missing pieces. In the end, as long as result is working well and is open, everyone will be happy.

My only concern now is that radv is using extra step of translating SPIR-V into NIR. That makes compilation of sharders longer, and unless they'll be cached (they aren't yet as far as I know), some parts in games will be slower (any time when new shaders are loaded, like at startup, new levels opening and so on). According to developers, using NIR in the middle actually helps getting better optimized result to feed to the GPU, but as I said, actual compilation with extra step is longer.

View this comment - View article - View full comments

Things are really getting good for AMD. I hope by the time Vega 10 cards will come out, amdgpu + Mesa will be in good shape already. Then I'll finally ditch Nvidia for it (and hopefully the added power of Vega will mitigate some performance lacking that still could remain in Mesa).

View this comment - View article - View full comments

I hope they'll finish it before next Mesa release.

View this comment - View article - View full comments