NVIDIA Continues Ramping Up Their Vulkan Articles

[log0]

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

From what I read there this extension is provisional. It proposes adding a bunch of built-in functions. Those are taken from glsl but not exclusive to it. You will find the same functions in directx.

[pixeljetstream]

Those nvidia articles give an atmosphere as if nvidia isn't happy at all about Vulkan, they are basically saying that Vulkan has the same flaws that OpenGL has and that it will require specific hardware code paths like OpenGL does... Also all the effort they are doing to mix OpenGL with Vulkan smells like their drivers is going to run Vulkan in top of OpenGL and not the other way around...
...

As the author of those articles, I can ensure we are happy about Vulkan. Not being CPU-limited and saving energy on mobile platforms is very relevant to our interest. We don't care so much what API is being used, as long as the hardware is being used well. Imo it's fair to say that Vulkan will just require more work by the developer than OpenGL. And as mentioned in the articles and by folks here the situation will improve for Vulkan over time with middle-ware in the long run. Some developers will not shy away from that work, and will do a really good job, for others it may be a tad too much responsibility/frustrating and then imo it's still legit for the time being to consider OpenGL. The API is just a tool to each your actual goal to leverage hardware acceleration well. That decision is of course influenced by tons of factors.

These articles are not targeting the top game engine developers, they are used to the multi hardware/platform/api situation already. But many traditional OpenGL using developers are not.

It's not easy to balance the "hype" and expectations about something new and cool as Vulkan, with the reality.

[pixeljetstream]

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.

What you describe, all the small things, is exactly why it's not a 90% thing anymore. Yes the principle setup is still similar, many of the names... but there is tons of details in how things interact, what usage flags, how allocations work in detail, what can be re-used or used in parallel... that have changed. Both because of hardware and software developer feedback.

Say some feature (a tiny flag or new function argument) didn't exist because it doesn't map well to the hardware, however the feature would map to other vendors hardware well and would be nice for software developers. So one needs to come up with a compromise. Hardware can be very different, so there is always the need for some compromise and always something that isn't super great for some hardware. You don't want to go too low-level to completely force software developers to write specific code for all details, and at the same time if you go too high-level you end up similar to OpenGL again

Having a Vulkan driver is actual work for AMD as well, despite having provided the "high-level" design. It's not like all they have to do is some string replacements on their Mantle driver and call it a day. Their engineers as well as ours and other companies were actively engaged in forging the Vulkan details that went beyond the initial draft and it doesn't stop at 1.0

[Philip]

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

What I meant is that all OpenGL drivers have a frontend that compiles GLSL into some intermediate representation (LLVM IR, PTX, AMD IL, TGSI, NIR, whatever), and a backend that compiles that IR into fully-optimised device-specific machine code. The GPU vendors often have multiple frontends (for OpenGL GLSL, OpenGL ARB shaders, DirectX, OpenCL, etc) that compile different languages into the same IR, and share the same backend between them all(*). For Vulkan they just need to write another frontend that translates SPIR-V into their own IR (which is designed to be a relatively straightforward translation), and can keep using the same backend.

So OpenGL is doing GLSL -> vendor IR (using vendor's GLSL frontend) -> vendor machine code (using vendor's backend). Vulkan is doing GLSL -> SPIR-V (using Khronos's GLSL compiler) -> vendor IR (using vendor's SPIR-V frontend) -> vendor machine code (using vendor's backend), or in the future you could replace the GLSL step with something else. The only thing that really cares about e.g. VLIW vs scalar shader cores is the backend, which doesn't need to change, so it'll have exactly the same benefits and drawbacks in Vulkan as it does in OpenGL.

( * Actually it seems reasonably common for them to have a completely proprietary compiler stack for graphics, and a separate LLVM-based one for OpenCL. I suspect that's largely for historical reasons (they started the graphics drivers before GPU compute was a big deal, so they didn't need advanced compiler features like pointers, and LLVM was less mature at that time; but it's really hard to write an OpenCL compiler without piggybacking off LLVM/Clang). I don't know how much they're trying to converge the two nowadays. Still, they're likely to use one of those existing compiler backends for Vulkan, not start a new one from scratch.)

((Though I suppose in some cases it's much messier because there isn't just a single company involved. E.g. Intel has closed-source graphics and OpenCL compilers, but their hardware's also supported by Mesa drivers, and by open-source Beignet for OpenCL, and LunarG did some experimental work putting their LLVM GLSL middle-end into Mesa, and LunarG's Intel Vulkan driver also seems to be based on LLVM to some extent, so who knows what we're going to end up with.))

[Philip]

What you describe, all the small things, is exactly why it's not a 90% thing anymore.

Thanks for the clarification! It sounds kind of like the first 90% of the work was provided by Mantle and the second 90% was done by Khronos members, and now we just need engine developers to do the remaining 90% (multiplied by the total number of engines) to make use of it, and then we'll be done

(and then the hardware people will come up with some radically new architecture and we can start the whole process again)

[pixeljetstream]

radical new architecture would cost a lot of money at this point don't get your hopes up, but lots of small incremental is good, too. There is a great article on hardware development by one of Imagination Technologie's developers: http://techreport.com/review/28126/s...dea-to-product

that said there is still a lot of potential floating around with what we have. I am always amazed to see how much developer pull out of same hardware over the years, if you look at the first uncharted on ps3 and the last one, for example...

And your description about the GLSL/SPIR-V is spot on. We have multiple frontends, and to a degree also multiple IRs (PTX/nvvm for Cuda, HLSL bytecode for DX, GLASM https://www.opengl.org/registry/spec...u_program5.txt for GLSL, a historical grown mess, that gets improved over time). That gets fed into a backend compiler that generates the actual hardware specific assembly.

The open-source Khronos GLSL to SPIR-V compiler is not as feature complete and also doesn't have the vendor specific extensions, as what the vendors have on their own. Being open-source that will improve over time, but also motivated us to keep our GLSL front-end available in Vulkan for now. Very likely developers will make use of the capability to directly translate their own representations into SPIR-V and not go through GLSL at all. For example those that are actually writing things in HLSL today and cross-translate.

[justmy2cents]

I think the move to explicit APIs like DX12 and Vulkan is beneficial to AMD. Regarding Vulkan though their director of VR did say the below

"DX12 and it's integration into Windows is a great development environment and has great compatibility. Does that mean that Vulkan doesn't have a place? No. I think that answer has to come from the dev community, not from us."

i never said it is not beneficial. they are probably just tied with contracts on hyping. you simply cannot be paid to help with one product like dx12 and when it is developed hype vulkan

[chuckula]

These articles are not targeting the top game engine developers, they are used to the multi hardware/platform/api situation already. But many traditional OpenGL using developers are not.

It's not easy to balance the "hype" and expectations about something new and cool as Vulkan, with the reality.

First of all, THANK YOU for the articles.
Second of all, you are raising an excellent point that some people here aren't considering. We aren't talking about some future piece of software that won't be written and released 3 years from now, we are talking about complex existing programs that already use OpenGL today. Doing a lot of work to rewrite an existing program just to use Vulkan may very well not be worthwhile if the program is already being somewhat efficient with OpenGL. It's an opportunity cost that needs to be considered properly.

[pixeljetstream]

i never said it is not beneficial. they are probably just tied with contracts on hyping. you simply cannot be paid to help with one product like dx12 and when it is developed hype vulkan

To me the statement you quoted from the AMD guy doesn't sound hype vs non-hype, nor would I imply any "greater agenda" in this statement... I second that it is a reality that Vulkan's importance to gaming on Windows is more driven from the community and therefore yet to be seen. As developer you have to make a choice do you use the open-source tools that were partially sponsored by Khronos members like Valve, do you contribute back to improve their quality... or do you use the Microsoft supported SDK (debug runtime, hlsl compiler...), tools, certified drivers... there is a lot more than just the API itself. And because this time the responsibilities lie more outside of the driver than inside, this is more of a community thing.

[blackout23]

To me the statement you quoted from the AMD guy doesn't sound hype vs non-hype, nor would I imply any "greater agenda" in this statement... I second that it is a reality that Vulkan's importance to gaming on Windows is more driven from the community and therefore yet to be seen. As developer you have to make a choice do you use the open-source tools that were partially sponsored by Khronos members like Valve, do you contribute back to improve their quality... or do you use the Microsoft supported SDK (debug runtime, hlsl compiler...), tools, certified drivers... there is a lot more than just the API itself. And because this time the responsibilities lie more outside of the driver than inside, this is more of a community thing.

I wonder how well a Vulkan game that was developed today will work unmodified on an new NVIDIA card 4 years from now. Right now NVIDIA makes sure that new games work well with their GameReady Drivers, but now I guess the app developer will have to make sure that an old game runs good on newer hardware? How much driver optimization is still there for NVIDIA & Co to tune the driver for newer games? I fear that an OpenGL application will run better on a card 4 years into the future without ever touching it again than the same game on Vulkan, because the OpenGL driver will always see development but applications might be abandoned.