Support us on Patreon
PayPal
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 GamingOnLinux.com.
0 Likes
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Quoting: GuestI'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.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.
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.
1 Likes, Who?
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.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.
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.
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.
4 Likes, Who?
Quoting: GuestThere'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.
0 Likes
BabaoWhisky Jan 15, 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?
This article is a very good news/good news/bad news for Linux gamers and futures Aaa games?
0 Likes
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?
Wasn't Kronos making sure that all the tools are available out the door on release of the final spec?
0 Likes
Quoting: berillionsThis article is a very good news/good news/bad news for Linux gamers and futures Aaa games?
Yes.
(Or, in other, less jerkish words: it depends. It depends on how exactly it will go and on your personal view on several issues.)
0 Likes
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
0 Likes
Quoting: mr-eggQuoting: 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 ?
Different games, different way of doing things. You can't really compare ports from different people fairly like that.
0 Likes
QuoteNVIDIA believes strongly that Vulkan supplements OpenGL, and that both APIs have their own strengths. <...>
Current NVIDIA technologies such as “bindless”, NV_command_list, and the “AZDO” techniques for core OpenGL, can achieve excellent single-thread performance.
They ignore the elephant in the room. OpenGL is plagued by incompatible implementations and spec violations by all parties (so called "optimizing" for individual titles), for which Nvidia bears a major part of the blame.Therefore no, Vulkan is not supplementing OpenGL. It should really replace it completely when possible. Because it's very unlikely for vendors to now magically start honoring OpenGL spec. That train is long gone. But Vulkan has a chance to set things right from the start. OpenGL can still be useful for supporting legacy cases which otherwise can't switch, but everything else should move away from it.
Last edited by Shmerl on 15 January 2016 at 4:55 pm UTC
2 Likes, Who?
Quoting: TheBossQuoting: mr-eggQuoting: 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 &amp; code ?
Different games, different way of doing things. You can't really compare ports from different people fairly like that.
My central point is not about the specific developer. The point you quoted is about how OpenGL was used ( presumably) to run a game on Linux where by the advantage you spoke of DX / D3D over OpenGL meant nothing because using them both together in an eON wrapped game resulted in identical or better performance ..
In laymans terms OpenGL provided no restriction to the 'more powerful ' API wrapped behind it, so how can OpenGL present a bottleneck ? The answer is it doesnt, its just fiddly and harder to work with. Often a game engine hasn't got the best implementation and the middle ware is also lacking in basic performance.
Thats not to say OpenGL doesnt have its flaws, its just to say that if you were to make a like for like game using DirectX vs OpenGL and had all the money and time in the world .. the performance would be nigh identical.
Last edited by on 15 January 2016 at 5:50 pm UTC
0 Likes
See more from me