Good looks that lack polish much. Is worse than DX11.
Just the fact that OpenGL is announced to be still around and still evolving talks aloud of Vulkan future chances, right from the very Vulkan creators. Updated flow chart here… even more paths leading to the “ignore Vulkan” end :evilgrin:.
Just had a fast look through slides.
Does this help with making games on linux for linux?
To me it looks like feasible for the game consumer market and we’ll see it on next gen game consoles.
There is a lot happening and not just one object that needs to be drawn. There is the UI, there might be several passes, e.g. to highlight the selected object and there is also a lot more happening. The multi-threading capabilities of Vulkan in combination with the expected lower CPU usage of it can even help in such a situation.
I strongly believe that Vulkan has the potential to make Blender faster. But this will not happen today or tomorrow. There are going to be a lot of driver issues as usual with new graphics APIs. As already mentioned, there will also be backward compatibility issues. And Blender itself is for sure not ready for it yet, not even close.
If you read the comment, it sounds like the early days of android os. “It’s better than this it just needs a firmware update”(of course that never happened). Do people know what they talk about? It uses 99% of the GPU and over 60% of CPU. What about battery life on handheld devices?
You’re talking about comparing a highly evolved and established graphics API with a brand new API that is just now getting initial driver support. It would probably be the same with OpenGL vs. Vulkan as well.
It may or may not be until the drivers improve or until the release of Vulkan 2.0 that we see the new API start to really shine. Rarely do things like API’s and software really shine right out of the gate (as in, the very first release).
As stated by The Talos Principle devs - it’s not optimised yet. It was made for DX11 and not Vulkan. It cannot just work out of the box as is.
Vulkan looks interesting for those who work with closed systems (game consoles, arcade cabinets, “showcase” systems like VR rides at carnivals, etc.) but I question how useful it will be for developers who have to actively support millions of possible hardware combinations across multiple different OS platforms, especially when there is zero announced support for it from Apple (presumably because they want to push their competing Metal standard).
As far as Blender goes? Despite Ton and others having access to early stuff, I wouldn’t put my money on seeing it any time even remotely soon. The struggle to drag Blender beyond OpenGL 1.2 has been ongoing for nearly a decade, and is just now starting to show tangible progress. If Blender suddenly saw a massive influx of dedicated experienced graphics developers and funding, I’d say maybe. As it stands now, I don’t hold out much hope, although I’d love to be proven wrong.
Nvidia
Drivers Nvidia GeForce 356.39 beta pour GeForce
Quadro Series: Quadro M6000, Quadro M5000, Quadro M4000, Quadro K6000, Quadro K5200, Quadro K5000, Quadro K4000, Quadro K4200, Quadro K2200, Quadro K2000, Quadro K2000D, Quadro K1200, Quadro K620, Quadro K420
Quadro Series (Notebooks): Quadro K5100M, Quadro K5000M, Quadro K4100M, Quadro K4000M, Quadro K3100M, Quadro K2200M, Quadro K2100M, Quadro K3000M, Quadro K2000M, Quadro K1100M, Quadro K1000M, Quadro K620M, Quadro K610M, Quadro K510M, Quadro K500M
GeForce 900 Series: GeForce GTX TITAN X, GeForce GTX 980 Ti, GeForce GTX 980, GeForce GTX 970, GeForce GTX 960, GeForce GTX 950
GeForce 700 Series: GeForce GTX TITAN Z, GeForce GTX TITAN Black, GeForce GTX TITAN, GeForce GTX 780 Ti, GeForce GTX 780, GeForce GTX 770, GeForce GTX 760, GeForce GTX 760 Ti (OEM), GeForce GTX 750 Ti, GeForce GTX 750, GeForce GTX 745, GeForce GT 740, GeForce GT 730, GeForce GT 720, GeForce GT 710, GeForce GT 705
GeForce 600 Series: GeForce GTX 690, GeForce GTX 680, GeForce GTX 670, GeForce GTX 660 Ti, GeForce GTX 660, GeForce GTX 650 Ti BOOST, GeForce GTX 650 Ti, GeForce GTX 650, GeForce GTX 645, GeForce GT 645, GeForce GT 640, GeForce GT 630
Amd
Drivers Amd Radeon Software 16.150.1009 beta pour Radeon HD 7000/8000/R-200/R-300/Fury Desktop/Mobility
I don’t think that is a good idea for most developers. If you use Vulkan as an earlier adopter, you will face way more driver bugs and have access to way less reference information. Also, if Vulkan fails in the market (which may well happen) then you will have wasted all that effort.
But. Once implemented in a game, shouldn’t the Vulkan driver outside the game optimize the speed and framerate? Or did I miss something here?
No, not necessarily. Just take a look at Mantle (AMDs low-overhead graphics API that inspired both Vulkan and D3D12) on AMDs new architecture: On GPU-limited scenes, it performed significantly worse than D3D11. The reason is that Mantle has failed in the market and AMD spends all its effort on optimizing the much more relevant D3D11 API.
Now, look at where Vulkan is right now, in a real-world application that doesn’t have workloads that make Vulkan shine:
It is slower across the board, even though it’s supposed to have less overhead (as seen in Vulkan-tailored demos). The Talos Principle developers may not have optimized as much as they can, nor are the drivers optimized yet, but it’s obvious that either of these efforts are necessary just to get a net performance benefit.
If Vulkan also fails in the market, then that optimization effort is unlikely to happen. Also, consider the scenario where only one vendor supports Vulkan efficiently (say, AMD) while the other vendor focuses on OpenGL extensions to reduce driver overhead (which NVIDIA already does).
Anyway, what I mean by “wasted effort” is the effort on the part of the developer who has a significant opportunity cost to learn this unproven API. If Vulkan becomes obsolete (like Mantle), but some program a developer wrote still runs 20% faster, that’s not gonna continue to write them a paycheck.
“Switching” to Vulkan (as some seem to suggest) would be completely irresponsible. If Vulkan fails, support for it may be dropped and OpenGL will remain the API of choice, despite its flaws.
Having said all that, I really hope that Vulkan does not fail, because it has a lot of architectural benefits that have good potential to make developer’s lives better. The performance advantages are really not that great across the board, but that’s apparently the only thing users get sold on.
For the time being, it’s best for most developers to wait how things develop, while users should not be asking to jump on the Vulkan bandwagen when there’s lots of other important things to do.
Vulkan failing would also mean that DirectX remains the superior API for the foreseeable future, because version 12 borrows a number of ideas from it. It also means a potentially major hit to the future of Linux as a viable gaming platform (or even a general 3D platform, because the better API then would be Windows 10 only).
In that sense, the Linux foundation should also jump in and do what they can to give Vulkan a bright future and make it the new standard for everything 3D.
There are many technical reasons why Linux is an unattractive platform for game developers, the graphics API is just one of them. The most important reason however is the fact that Linux users make up only a tiny fraction of the target audience.
Therefore, I wouldn’t say seeing Vulkan fail would hurt Linux. Linux having already failed is hurting Vulkan, especially since Apple isn’t supporting Vulkan (yet).
It’s sad that they released Vulkan in this state. At least they should have collaborated with some game companies to at least make it as fast as opengl.
10-15 frames/s lower compared to opengl is horrible. No gamer would buy a game with that tech and no dev would make anything with that either.
I just hope that Talos principle gets help to optimize their game with vulkan by the devs of vulkan.
@bigbad
That is not my point at all. Vulkan is in a very early state, so it’s not surprising that things don’t run smoothly yet, nor is it a matter of concern. The point is that performance doesn’t come for free, just because the API has lower base overhead (which it already does, as some Vulkan demos prove).
However, if in a few years Vulkan has failed to gain traction and isn’t being taken care of anymore (like Mantle today), then you’ll have a problem.
Lastly, this quote makes a pretty good point:
“Every API that has ever started at “direct access to hardware” usually becomes an abstraction within one revision.”
Yeah but if you’re going to take over an market then you have to make sure that it will sell (even if it’s not about profit). All I hear are google-words like “it’s beta”, “give it time” and so on.
They should have opened the vulkan with a bang by endorsing a game with great framerate by using it.
Windows is still about 90% of pc gaming market and apple like owns the handheld industri based on actual profit. PS4 and xbone don’t even care.
Only ones jumping over this as I understand are android gamers that want to play free games, legally or not.
I don’t know. Has any other gaming company put vulkan on their engine?
If you don’t have the use-case for a low-overhead graphics API, you’re not gonna get great framerates out of nowhere. The situation on PC is that literally all PC games released right now had to be developed with high-overhead APIs like D3D11 in mind, and all drivers have been optimized for that, as well.
They couldn’t develop a game with the assumption that they’ll have a trillion draw calls available. All they could do was show fancy demos with lots of gnomes or starships as individual drawcalls, where you really can see a massive speedup. Now, with D3D12 and Vulkan, this assumption can change, but it’s gonna take a while.
Windows is still about 90% of pc gaming market and apple like owns the handheld industri based on actual profit. PS4 and xbone don’t even care.
Only ones jumping over this as I understand are android gamers that want to play free games, legally or not.
I don’t know. Has any other gaming company put vulkan on their engine?
EPIC is on the record of promising Vulkan support for Unreal Engine, at least. The best thing that Vulkan has going for it is that D3D12 is Windows 10 only and that a significant amount of users are still sticking to Windows 7 (though that may change over time as well).
So something like the bge… (no optimizing and many many drawcalls) would do better with Vulcan?
at least until Tristan has instancing and static call batching running smooth?
Talos Vulkan code path is NOT yet optimized and it’s more like a dirty hack. WTF are you all talking about? Vulkan is not optimized, etc.
Vulkan and D3D 12 have very similar architectures - it’s not possible than the former is substantially slower than the latter.
Edwin,
engine design for Vulkan is basically consited of three major parts:\
Port. Make it work as fast as possible just by wrapping current engine design around Vulkan. Avoid all pitfalls and bottlenecks. This is what we did by now and released as patch for Talos.
Use Vulkan for multi-threaded rendering. Our engine is designed really well for multi-threaded rendering, but we have only our wrapper for it - calls to graphics API (like Vulkan) are not multi-threaded. Yet.
That being said, this is the next step what we’ll do. And probably release that also as patch for Talos. I tried to do that with Direct3D 11 long time ago (support for its deffered contexts), but it was too much pain and too little or even no gain.That’s just one of reasons why we decided to stick with our own approach for MT renderer for that long.
Redesign engine for Vulkan. This is the biggest step and can be split in two:
3a)
Precache all rendering states (which mostly mean materials in game) up front. This will make rendering calls much simplier and faster. So, instead of deciding at rendering time what is needed for a material to be rendered via Vulkan, do this at loading time and then when material needs to be rendered just give it to Vulkan, via one or two simple function calls.
3b)
Precache all geometry, material, textures, everything that is needed for rendering an object up front. This basically creates so called command buffer ready for Vulkan, and nothing extra needs to be set or created at render time.
3rd part of port is, obviously, the most complex one, and it’ll take time to change engine design for it, step-by-step.
Hope I explained this well.
DEN
Regards,
Artem S. Tashkinov
Perhaps this is nice for Steam, having no dependencies on operating systems;
Would allow for broader acceptance, they allready put Blender in steam.
So i can imagine that if some party would like to create a gameing platform that could work on any tablet/pc undependent of operating system. Then this might be a nice choise.
I think as tablets becomme more popular and powerfull, eventually something like this would be the next step.
Or something for game engines, who can then focus on other parts physics and gaming logic