NVIDIA Continues Ramping Up Their Vulkan Articles

[blackout23]

On top of that, I would point people the Techpowerup's game reviews. They review the performance separately and that makes it obvious most games today are GPU limited.

However, if it Vulkan is not inherently faster than OpenGL if, between the hardware, drivers and graphics API, developing for Vulkan turns out to be faster/simpler, then we still gain.

I just hope that Vulkan is a good way to avoid the OpenGL driver mess and that's reason enough to use it. It's the same with DirectX12. The reason why AMD promotes it so much is because NVIDIA totally dominates with their DirectX11 drivers. I guess they simply have more manpower behind it.
I have seen Ashes of the Singularity and Fabel Legends DX12 Benchmarks and NVIDIA cards with DirectX11 are just as fast as AMD Cards using DirectX12. Actually the 980Ti was leading all benchmarks no matter if DX12 or DX11 or 1080p or 4K by 10% despite how crucial async compute is supposed to be and how much of a drama it is that NVIDIA has to emulate it and how much raw compute power AMD cards have on paper and how great HBM is supposed to be for 4K. NVIDIA cards didn't gain anything from DX12 in these benchmarks it only helped AMD to close the gap.

http://www.pcgameshardware.de/DirectX-12-Software-255525/Specials/Spiele-Benchmark-1172196/

http://www.pcgameshardware.de/Ashes-of-the-Singularity-Spiel-55338/Specials/Benchmark-DirectX-12-DirectX-11-1167997/

I think NVIDIA cards will gain some performance on Linux, because the OpenGL driver is still not as hyper optimized as the DirectX11 driver on Windows.

[Michael]

I'm not so sure about that anymore. Alex said at the xdc that it will be open source "eventually".
With the release of Vulkan being delayed, I see the a chance of free drivers initially at Vulkan launch. Especially when you keep in mind that the khronos group seems to have delayed the release in favor of day one support of all vendors

Khronos never said anything about waiting for "all vendors", but rather waiting for the first conformant, quality implementations.

[abu_shawarib]

It raises to me a question of why I see no one using OpenGL 4.5 extensions? Until now all I heard about them looks cool on paper. Compatibility might be a reason but could it be the only thing that's holding dev's from using 4.5? Are there applications that take advantage of these things?

[Philip]

EDIT: It comes down to VLIW architectures relying heavily on optimizing compilers and Scalar architectures having the right hardware to optimize transparently. Basically advanced knowledge of what's in flight at very low latencies, vs no knowledge of what's in flight and educated guessing at what might be the fastest path.

I think that issue is orthogonal to Vulkan. VLIW vs scalar is just about the instruction set of the shader cores, and Vulkan will typically use the same frontend shader language as OpenGL (GLSL) and Vulkan drivers will use the same compiler backend as OpenGL drivers, so Vulkan makes no real difference there. The Vulkan API is mostly focused on the rest of the GPU pipeline, getting it to feed data to the shaders as efficiently as possible.

(Probably the main problem with VLIW is that it works okay for shaders that process lots of vectors of 3 or 4 floats (vertex positions, matrices, colours, etc), because every operation on 4 floats maps nicely onto one VLIW instruction; but nowadays people do a lot more general-purpose compute which doesn't use many vec4s, and the compiler really struggles to efficiently map it onto the VLIW instructions, so it ends up doing a lot less useful work per instruction. Some mobile GPUs are still quite VLIWish (Mali Midgard is probably the worst) but seem to be slowly moving towards scalar architectures too, as people start caring more about compute performance and advanced graphics features over artificial peak GFLOPS-per-Watt.)

[Philip]

Mantle isn't even close to 90% of Vulkan... It's just a big myth. While it started off as based on Mantle, it's a very different design at this point.

Out of interest, what major differences are you aware of? From the various Vulkan presentations and the Mantle API reference, the main things I've seen are SPIR-V, render passes (for tile-based mobile GPUs), some allocation stuff like descriptor set pools, lots of syntax changes, presumably lots of precise clarifications of the vague Mantle documentation, but most of the basic concepts and most of the terminology look pretty similar to me.

[duby229]

I think that issue is orthogonal to Vulkan. VLIW vs scalar is just about the instruction set of the shader cores, and Vulkan will typically use the same frontend shader language as OpenGL (GLSL) and Vulkan drivers will use the same compiler backend as OpenGL drivers, so Vulkan makes no real difference there. The Vulkan API is mostly focused on the rest of the GPU pipeline, getting it to feed data to the shaders as efficiently as possible.

(Probably the main problem with VLIW is that it works okay for shaders that process lots of vectors of 3 or 4 floats (vertex positions, matrices, colours, etc), because every operation on 4 floats maps nicely onto one VLIW instruction; but nowadays people do a lot more general-purpose compute which doesn't use many vec4s, and the compiler really struggles to efficiently map it onto the VLIW instructions, so it ends up doing a lot less useful work per instruction. Some mobile GPUs are still quite VLIWish (Mali Midgard is probably the worst) but seem to be slowly moving towards scalar architectures too, as people start caring more about compute performance and advanced graphics features over artificial peak GFLOPS-per-Watt.)

Yeah, cool. Thanks for the insight.

The way I see it is that AMD had the D3D9 driver that performed well ahead of the OpenGL driver for a long time. And now the DX11 driver performance seems to be suffering the same way the OpenGL does. Nvidia doesn't have that problem. Although I don't have any evidence, I always associated that with (nvidia having) less reliance on optimizing compilers and more reliance on a scalar architectures hardware.

[triangle]

@Philip
I think "Vulkan drivers will use the same compiler backend as OpenGL drivers" is mostly false.
(nvidia does have an extension to compile GLSL in the Vulkan driver, but that does not count)

It is true that initially GLSL will be used to generate SPIR-V which will be sent to Vulkan,
but GLSL is not directly part of Vulkan at all.

[computerquip]

@Philip
I think "Vulkan drivers will use the same compiler backend as OpenGL drivers" is mostly false.
(nvidia does have an extension to compile GLSL in the Vulkan driver, but that does not count)

It is true that initially GLSL will be used to generate SPIR-V which will be sent to Vulkan,
but GLSL is not directly part of Vulkan at all.

SPIR-V uses extensions based on GLSL syntax, https://www.khronos.org/registry/spi...L.std.450.html
It's not unlikely.

[triangle]

SPIR-V uses extensions based on GLSL syntax, https://www.khronos.org/registry/spi...L.std.450.html
It's not unlikely.

hmmm... got me there.
Well, it will not stop anyone from inventing there own high level language to compile into SPIR-V

[bug77]

I'm talking about predicted launch windows. Additionally, AMD has even said that the first Polaris parts out the door will not be the ultra high-end chips, but more consumer focused chips. Nvidia, because of its supercomputer business, is more likely to roll out a larger chip "earlier" (relatively speaking) but the actual launch date will be after the first Polaris chips have been out for a while.

Both companies are attacking the market segments that they think will make them money with these plans.

Maybe, but you presented that as fact.
And I'm not even sure how you predict anything about Nvidia because, afaik, they've kept perfectly mum so far.