Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone with no article paywalls. Just good, fresh content! Alternatively, you can donate through PayPal, Liberapay or Buy us a Coffee. You can also buy games using our partner links for GOG and Humble Store.
Nvidia are talking about Vulkan a little more now, which is really good to see. Looks like they will have a little bit of support for it on "day-zero" too.

I hope people aren't expecting Vulkan to come along and instantly blow away OpenGL, even Nvidia are now keeping people's expectations in check.

They don't ease you into it, as the blog post is very developer orientated, and not really meant for idiots like me to read over, but it's very interesting anyway.
QuoteNVIDIA believes strongly that Vulkan supplements OpenGL, and that both APIs have their own strengths.

Vulkan’s strengths lie in the explicit control and multi-threading capabilities that by design allow us to push more commands to the GPU in less CPU time and have finer-grained cost control. OpenGL, however, continues to provide easier to use access to the hardware. This is especially important for applications that are not CPU-limited. Current NVIDIA technologies such as “bindless”, NV_command_list, and the “AZDO” techniques for core OpenGL, can achieve excellent single-thread performance.

I see what they are saying here, but I have yet to see any game developer use AZDO on Linux with OpenGL. In fact, we have seen nothing but game developers complain about OpenGL. For AAA titles, or just heavy titles in general Vulkan sounds like a good fit, but for smaller indie games, OpenGL will probably remain king for being easier to use. That's what I am taking away from this.

QuoteThere is a new level of complexity to Vulkan, that didn’t really exist in OpenGL before.

Don't be scared by that quote, as with all new things it will take time to learn.

They are also making the transition to Vulkan easier with stuff like this:
QuoteStarting with a new API can involve a lot of work as common utilities may not yet be available. NVIDIA will therefore provide a few Vulkan extensions from day zero, so that you as developer can enjoy less obstacles on your path to Vulkan. We will support consuming GLSL shader strings directly and not having to use SPIR-V. Furthermore we leverage our industry leading OpenGL driver and allow you to run Vulkan inside an OpenGL context and presenting Vulkan Images within it. This allows you to use your favorite windowing and user-interface libraries and some of our samples will make use of it to compare OpenGL and Vulkan seamlessly.

To be clear, when they say "NVIDIA will therefore provide a few Vulkan extensions from day zero", they are talking specifically about using it inside OpenGL:

@gamingonlinux using Vulkan inside OpenGL and using GLSL directly inside Vulkan are the extensions I meant

— Christoph Kubisch (@pixeljetstream) January 15, 2016

@gamingonlinux So far NVIDIA has a really good track record on providing driver with OpenGL version release, intend to keep it for Vulkan :)

— Christoph Kubisch (@pixeljetstream) January 15, 2016

There's a fair bit more to the post, so I do suggest giving it a look over. Go read the developer post here, and get interested.

I am more excited than I have ever been to be a Linux gamer, and I am getting more excited as the days go by. I can't wait to see Vulkan actually be used in a game. It's not going to be a silver bullet though remember, developers still have to learn how to use it and get the best out of it. We could be looking at quite a while before we see the first game with it, and it will probably be Valve with something like Dota 2 which they already had a demo of a while ago with Vulkan. Article taken from
Tags: NVIDIA, Vulkan
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG and Humble Store. See more here.
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
The comments on this article are closed.
Page: «2/4»
  Go to:

mirv 15 Jan, 2016
View PC info
  • Supporter Plus
Quoting: TheBossVulkan is a clean slate, this is just Nvidia providing a way to run Vulkan in OpenGL for testing, it doesn't change anything to do with Vulkan.

Not quite. They already stated that they will allow GLSL strings to be directly consumed (basically means without the SPIR-V step being exposed). Absolutely no reason why a helper library couldn't be used instead for that.
Of course, my concerns could be baseless, but when a company starts talking about something that will change how developers use an API before that API is released....I can't help but not like it.

Note: Vulkan will allow for extensions, but they must be explicitly enabled at initialisation time. Whatever happens, let's hope nvidia at least stick to that.
PublicNuisance 15 Jan, 2016
While I hope they support it I doubt they are really going to very well. Nvidia is the Apple of the GPU world. If they can't make it part of their closed garden where only their customers can benefit from it then they don't care about it. I'll take technology like TressFX over HairWorks anyday. It doesn't care if you have an Nvidia or an AMD GPU.
TobiSGD 15 Jan, 2016
Quoting: mirvI'm going to go against what a lot of people will intuitively think, and say that providing extensions to "ease into it" from day one is a very, very, very bad idea. Vulkan is a clean slate, let's keep it that way.
Trying to bridge the gaps might seem a good idea, but such ideas have a very bad habit of sticking around for a long, long time, and you get the worst of both worlds instead of the best.

Perhaps I'm being too negative, but I am truly concerned about Vulkan turning into another OpenGL3.0 debacle.
As long as AMD and Intel don't provide the exact same extensions you wouldn't see this in released software anyways, since it would mean that videochips from those two companies wouldn't be able to run the game. So, I don't think that this really is a problem.
Samsai 15 Jan, 2016
Quoting: runeIf the game is rather demanding in the first place, then you will definitely notice a difference (if it's a DirectX game). Rewriting an engine, and optimizing the code takes time, and time is money. I guess that they (Feral, Aspyr, etc.) can not afford to spend that much time optimizing the code.

Unless you have optimized code, you can not compare DirectX to OpenGL. I don't believe that the games we're getting now are 100% optimized, not even close.
In a purely theoretical world (read perfect) OpenGL and DirectX might perform the same but, as we have seen, that is not typically the case in our practical world. Code is never 100% optimized. Currently ports seem to choke especially when it comes to multithreading due to technical differences between OpenGL and DirectX.

Simply put, you cannot write DirectX in OpenGL and expect it to perform well but you also cannot completely rewrite renderers for big game engines because it would take too much time and resources. Vulkan might work better in those types of scenarios which would lead to performance improvements for future games.
mirv 15 Jan, 2016
View PC info
  • Supporter Plus
Quoting: TobiSGDAs long as AMD and Intel don't provide the exact same extensions you wouldn't see this in released software anyways, since it would mean that videochips from those two companies wouldn't be able to run the game. So, I don't think that this really is a problem.

Hmm....I might normally agree, but having seen what happened with OpenGL, I'm not so sure. A lot of GL code has vendor specific code paths just because they can use extensions to improve performance. Ok, sure, this isn't about performance, but if nvidia get out there early enough and convince enough developers to do things "their way", then you're looking at day one fragmentation of real-world Vulkan usage.

It's why I think helper tools would be better, and not vendor specific helper tools. There's no reason we can't have a GLSL -> SPIR-V offline reference compiler, and a few lines of wrapper to insert the object as appropriate into Vulkan. It really doesn't need to be an extension, does not need to be in the driver itself, and can be done properly in a vendor-neutral manner.
Working on Vulkan data from within OpenGL itself is a different matter. There...ok, I can think of "better" (in my own opinion) approaches, but also ones requiring a lot more work. As a stepping stone I can understand; in porting existing code. It's just that compatibility profiles with OpenGL were there for a similar reason since GL3.0, and compat profiles are still heavily used.

All this is just me saying why I'm concerned - I'm not in any way saying what will or won't happen, just what I think & why. I sincerely do hope that developers pick up any offered tools that help them, and use those tools to transition to full, cross-platform, Vulkan development.
tuubi 15 Jan, 2016
View PC info
  • Supporter Plus
Quoting: mirvThere's no reason we can't have a GLSL -> SPIR-V offline reference compiler, ....
Khronos has promised exactly this, and experimental support for SPIR-V output is already provided by glslang. There's also this quote from the Khoronos SPIR page:
QuoteSPIR-V also supports OpenCL 1.2, 2.0, 2.1 kernel languages as well as the GLSL shader language for Vulkan (under development).

Don't know how useful that particular NVIDIA extension will turn out to be.
BabaoWhisky 15 Jan, 2016
As a French like me, your big messages are complicated for me. So, I have a simple question :

This article is a very good news/good news/bad news for Linux gamers and futures Aaa games?
pete910 15 Jan, 2016
View PC info
  • Supporter Plus
So basically, we will end up with dev's coding to suite NV hardware again ?

Wasn't Kronos making sure that all the tools are available out the door on release of the final spec?
DrMcCoy 15 Jan, 2016
Quoting: berillionsThis article is a very good news/good news/bad news for Linux gamers and futures Aaa games?


(Or, in other, less jerkish words: it depends. It depends on how exactly it will go and on your personal view on several issues.)
Guest 15 Jan, 2016
Quoting: TheBossI am of course excited about the possibility of Vulkan, as OpenGL has shown many times it just isn't comparable with DirectX for the heavier games we are now getting.

How is it then that it has been possible for an eON wrapper game from VP to get equal and sometimes in a scene higher performance than windows running the same game natively using the very same api & code ?

(although with dx12 & vulkan native starts to make other older technologies seem more abstracted )

Were those games that met windows performance whilst simultaneously using emulated or 'wrapped' DX-D3D9/10 on Linux not using a software pipe via OpenGL -> to GPU ?

How is OpenGL any restriction in this case ? The way I see it is that OpenGL is just tricky and time consuming. The engines, the middle ware and the dev have in most cases less than 100% knowledge and even less time.

Surely its just a case that D3D/DX is more established and has a slightly lower step of entry. So I don't see Vulkan doing any more than just becoming established in the same way as D3D / DX, but the knowledge of the API will still be needed.

Its going to take time and money, its not a silver bullet and that's going to disappoint a lot of Linux gamers. However the hope is that more engines have such a great API code base that the indie dev and lower end studios make source engine / unity engine games with Vulkan faster and easier.

Last edited by on 15 January 2016 at 4:20 pm UTC
While you're here, please consider supporting GamingOnLinux on:

Patreon, Liberapay or PayPal Donation.

This ensures all of our main content remains totally free for everyone with no article paywalls. We also don't have tons of adverts, there's also no tracking and we respect your privacy. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.