I found this linked on the Khronos website, it's a talk about how ray tracing works in Vulkan, and expectations that the cross vendor extension will be a superset of the nVidia vendor extension:
Info Vulkan Ray Tracing talk
- Thread starter soresu
- Start date
Fanatical Meat
Lifer
- Feb 4, 2009
- 35,862
- 17,400
- 136
Sort of disappointed with Vulcan.
I’ve been reading about all this great stuff Vulcan is going to do but nothing great ever happens.
Getting pretty tired of this.
I’ve been reading about all this great stuff Vulcan is going to do but nothing great ever happens.
Getting pretty tired of this.
If you were building a car then DX11 gives you your choice of standard chassis, wheels and an engine. You just tweak it a bit and choose your colours. Vulcan gives you a big lump of metal and some basic hand tools - no concept of cars at all, just some very basic building blocks and you have to do the rest. Theoretically you can make the most amazing car ever, in reality you spent the first 100 hours re-inventing the wheel and are scratching your head where to go from there 
Fanatical Meat
Lifer
- Feb 4, 2009
- 35,862
- 17,400
- 136
If you were building a car then DX11 gives you your choice of standard chassis, wheels and an engine. You just tweak it a bit and choose your colours. Vulcan gives you a big lump of metal and some basic hand tools - no concept of cars at all, just some very basic building blocks and you have to do the rest. Theoretically you can make the most amazing car ever, in reality you spent the first 100 hours re-inventing the wheel and are scratching your head where to go from there
Excellent summary
I’ve yet to hear of a game that works better in Vulcan vs dx11.
DeathReborn
Platinum Member
- Oct 11, 2005
- 2,786
- 789
- 136
If you were building a car then DX11 gives you your choice of standard chassis, wheels and an engine. You just tweak it a bit and choose your colours. Vulcan gives you a big lump of metal and some basic hand tools - no concept of cars at all, just some very basic building blocks and you have to do the rest. Theoretically you can make the most amazing car ever, in reality you spent the first 100 hours re-inventing the wheel and are scratching your head where to go from there
Small thing but... expecting Spock etc to do more with a 21st century human made API is asking a bit much. Vulkan is and always will be a work in progress, they are trying to avoid the problem OpenGL had with being behind the curve and lacking quick adoption of features/tools.
Fanatical Meat
Lifer
- Feb 4, 2009
- 35,862
- 17,400
- 136
Glo.
Diamond Member
- Apr 25, 2015
- 5,930
- 4,990
- 136
Doom. The reality is it will take some time devs to adjust to Vulkan development, compared to DX's. DX is on the market for decades. Vulkan is just few years. There is not that much of experienced devs out there with Vulkan.
True to an extent, but far more so if you are writing an engine from scratch rather than using something like Unreal or Unity, both of which have, if not exact feature parity on Vulkan, then certainly close to it.If you were building a car then DX11 gives you your choice of standard chassis, wheels and an engine. You just tweak it a bit and choose your colours. Vulcan gives you a big lump of metal and some basic hand tools - no concept of cars at all, just some very basic building blocks and you have to do the rest. Theoretically you can make the most amazing car ever, in reality you spent the first 100 hours re-inventing the wheel and are scratching your head where to go from there
DX12 is modelled in a similar way to Vulkan, and unless I am mistaken DX12 is needed to use DXR anyway - so where ray tracing is concerned the point is moot between low and high level abstraction API's.
Something to also bare in mind about the explicit low level nature of Vulkan is that it allows the devs to be far more sure about the origin of software bugs, and how to fix them, and theoretically less dependent on the GPU vendors to optimise their drivers at launch time - in my mind that outweighs the increased effort of maintaining the gfx code.
Between the Unreal team, the Unity team, the iD team, the Valve/Source team, the DXVK/D9VK team, the ANGLE team, the MoltenVK team, all the driver devs out in AMD, nVidia, ARM, Qualcomm, Intel and the various OSS driver initiatives - not to mention several emulators now running functional Vulkan backends (Dolphin, RPCS3, PPSSPP, Cemu), and a smattering of Linux game ports from Windows (Feral), to name only the ones off the top of my head.
Not a huge amount, but relatively huge given the age of Vulkan - the various compatibility layers have the potential to give various platforms a new lease of life where gaming is concerned, and simplify development for newer platforms like Fuchsia coming forward.
There is a tangible benefit to Vulkan over DX11 if the engine is properly coded - that is CPU utilisation, and therefore battery life if using a laptop.
Vulkan exists because of Khronos Group's previous standardization effort failures such as OpenGL/ES and OpenCL ...
Mobile hardware graphics vendors were not fans of OpenGL but what really killed it off was because AMD wanted to sabotage it as well since it wasn't a good match with their modern hardware designs ...
OpenCL died off for obvious political reasons. Nvidia and Apple later on didn't want to play the diplomatic game so AMD eventually killed it off as well since none of their customers wanted OpenCL as well ...
Vulkan was Khronos Group's only true success when no sane vendors in the future would ever support OpenCL/OpenGL drivers in any real capacity since they were effectively depreciated tools. The industry isn't giving many developers much of a choice so it was either extremely verbose APIs like D3D12/Vulkan or dealing with broken OpenGL drivers or falling back to D3D11 which had no new features. Heck, even Nvidia doesn't want people using OpenGL since they'll eventually want to stop maintaining millions of lines of code worth of driver hacks ...
To sum it up, OpenCL/OpenGL are huge maintenance burdens not worth supporting (no modern applications will use them) while Vulkan is significantly less of a maintenance burden and is gaining far more momentum than Khronos Group's previous APIs did so it's worth supporting ...
ANGLE is working on a desktop GL front end for their Vulkan backend which already supports GL ES 2.0 and much of 3.0 - when it is complete it will make portable GL support a real thing, and something easily debugged by all given ANGLE's open source nature.
DXVK/D9VK is already effectively doing the same for DX9-11, and some pre DX9 fixed function stuff too.
I wouldn't say AMD was purposefully sabotaging OpenGL so much as lacking the money for a decent team to properly maintain a fully featured AND slick driver - I've followed the Mesa development of RadeonSI/AMDGPU and it is a monstrous amount of code to get to OpenGl 4.5 (4.6 is still not fully supported even now by all but Intel), and that's before you start farting about with game specific opts/hacks.
From what I have heard is that Vulkan is mostly explicit in spec - whereas OpenGL is either mostly implicit, or enough of the spec is to make it a real pain to code drivers for, it's almost the opposite problem to coding Vulkan game engines.
Some OpenCL code can be salvaged and run on Vulkan drivers using CLSPV - which Adobe have already done with code from their Mercury Engine from Premiere Pro so it can run on mobile platforms.
In some ways Vulkan compute will supersede OpenCL given how prevalent Vulkan support has become, even to MacOS using MoltenVK.
Cleaner threading/CPU utilisation in Vulkan makes it much better for mobile use and battery life, I think Android is transitioning its UI to purely Vulkan presentation at least partly because of this.
MajinCry
Platinum Member
- Jul 28, 2015
- 2,495
- 571
- 136
Vulkan and Direct3D 12 both use Mantle, which was developed by AMD. The only real difference is that they rejiggered Mantle to be supported by all the GPU vendors rather than just AMD. Unfortunately, Vulkan's adoption has been almost entirely upon the shoulders of indie devs, whereas Direct3D 12 is used by the big studios.
Fanatical Meat
Lifer
- Feb 4, 2009
- 35,862
- 17,400
- 136
Pretty much my point. I was super excited about it years ago but now I have to accept the reality that it never works better than the next option.
Vulkan is based on Mantle, but only as a starting point to get the ball running at Khronos during its development cycle, which still took roughly 2 years despite that jumpstart.
From what I can gather, there was significant input across the industry from more than just AMD and nVidia on the development of Vulkan, including many hardware and software vendors.
Also both Unreal and Unity engines have extensive Vulkan backend support, which means a whole host of games made from them can support Vulkan with not a great deal of extra effort over DX12.
Stadia is supposedly exclusively using Vulkan for its games, so whatever works on Stadia already has Vulkan pumbed in.
Switch also supports Vulkan though its main API is NVN, this is probably why several Bethesda games are on the Switch.
Last edited:
Why on earth would anyone want to use ANGLE ? It's also a pile of crap with tons of slow paths that doesn't match modern hardware designs. WebGPU is a far better bet if you want a simple high level abstraction over D3D12/Metal/Vulkan that is remotely performant. D9VK sucks too BTW so only DXVK is the sane one out of the bunch but again since it's a translation layer it'll lose performance in comparison native drivers from vendors ...
AMD definitely started sabotaging OpenGL ever since Vulkan released. They don't even care what goes on anymore in the OpenGL working group so from here on out with AMD it's either D3D11/D3D12 or Vulkan but eventually they'll want to get rid of D3D11 as well since the only developers who are going to be using it in the future are indies or online only game developers ...
Mesa drivers are terrible since they don't work with tons of legacy applications or many professional applications either. Only Nvidia has the most stable OpenGL driver stack but I guess that's the benefit of having an iron fist control early on with OpenGL standards yet even they don't want to keep maintaining the monstrosity that it is anymore ...
It's pretty obvious that OpenCL/OpenGL cannot coexist with Vulkan since the industry obviously doesn't like the idea of maintaining two standards ...
I'm not surprised since OpenCL is effectively a dead/zombie standard in everything but name only. Nvidia never cared because they had CUDA. AMD went off into the deep end so they eventually ditched OpenCL for HIP because even their own employees (former included as well) admire CUDA's programming model too! Apple was the one who originally proposed OpenCL because of a fear of vendor lock-in from Nvidia but in the end it's ironic how they rolled out Metal however to be fair OpenCL was never a real 'standard' and anybody would get extremely tired of dealing with the crazy bureaucracy that is Khronos Group. I guess that just leaves Intel as the only official de-facto representative of OpenCl left but it won't be long before they disappear too ...
The industry didn't want to end the tyranny of CUDA, they wanted freedom from OpenCL and it showed why the Khronos Group was so wrong on many accounts but I guess it's not totally their fault since they can't control what all of their members (AMD/Apple/ARM/Google/Imagination/Intel/Nvidia/Qualcomm) will do so I guess they all have to somehow operate in good faith (compromise) to make these things work otherwise they'll end up with uglies like OpenCL instead of Vulkan ...
D9VK is directly based on DXVK code, the main coder on D9VK does work in DXVK and vice versa - the plan is to merge D9VK in once it has gone far enough.
As for D9VK's suckage, it's not perfect to be sure, but it's much younger than Wine and has come a very long way in a short time frame - and even though it lacks features, its performance is pretty great from what I've been seeing from tests on Youtube comparing it against pure Wine and Windows.
As far as ANGLE goes, I don't think absolute performance was ever the aim.
It was maintained to keep WebGL usable on systems that lack GL ES drivers - considering the Vulkan backend is still fairly young, it's a bit early to cast judgement on its performance anyway.
Whatever its current/previous performance, Google have been pushing ANGLE into the limelight recently, so I would not be surprised to find they have increased the resources allocated to it for future improvements.
On the WebGPU front, just like WebGL it is yet another abstraction - so I certainly wouldn't excite yourself over it just yet, especially as it isn't even finished, and WebGL2 took a looong time to finally publish a v1 standard.
Like a red rag to a bull... Broken record much?
CUDA wasn't even mentioned, I was talking about running OpenCL code on Vulkan.
The point being the end of OpenCL and the rise of Vulkan compute, which unlike CUDA is becoming largely ubiquitous with Android support, as well as MoltenVK allowing VK code to run a lot of it on iOS/MacOS platforms.
The new Vulkan backend coming for Otoy's Octane Render shows there is some real promise there too.
Sure Vulkan compute will replace OpenCL but OpenCL didn't have much to begin with! As far as MoltenVK or Android is concerned I'm not all that hopeful them since their Vulkan driver implementation is advanced enough like AMD/Nvidia or even Intel's so I doubt they'll be able to cope with more complex cases like professional rendering or other DCC applications. Vulkan on desktop platforms is already inadequate for quite a few scientific applications but Vulkan on mobile platforms (MoltenVK included) has even more limitations ...
I don't expect anything drastically fancy on mobile, though I've no idea how complex the Mercury engine code is that Adobe ported - the Dolphin ubershader is another chunky bit of GPU code, but I've not heard anything about it since its initial debut, which was quite a while ago now, it might be interesting to see if th 8cx or SQ1 processors could handle it.
It has had quite a few extensions added since 1.1 and subgroups for various uses have popped up.
The v1.1 update came out roughly 2 years after v1, and we are less than 6 months from 2 years after v1.1 now - I'd expect a healthy update next year.
As for scientific applications, not really interested as far as GPU's go (assuming you mean the HPC supercomputer stuff) - ML and graphics work are my main interests in GPU compute, and they are getting plugged pretty well for the time being.
On an interesting note, there is actually a branch of dav1d that partially accelerates AV1 decode with Vulkan - not a great amount, but it could help platforms that will never get ASIC support for AV1 decode.
Meh, emulation of old game systems with fixed function hardware isn't all that much of a complex case compared to creating game engines, render engines, CAD, etc ...
While subgroup operations are good, Vulkan is still missing some bindless extensions and the other essentials for wider use cases ...
As far as machine learning is concerned, Vulkan will never be able to run the full featured suite. Only inferencing will be an appropriate fit. If you need to train some models then you're still effectively stuck with either CUDA or HIP ...
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 24K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads
- Started by Tigerick
- Replies: 20K
-
-
-
Facebook
Twitter