By the way, for anyone wondering about the logo: it's composed of various standard 3D test models. The Stanford Bunny, Dragon, & Armadillo, and of course the Utah Teapot.
I wouldn't put many hopes into that, seeing that it's not even submitted for conformance review. AMD themselves say it's in alpha/beta stages which (knowing AMD) means it actually works sometimes.
I can confirm that AMD driver can be considered non-working.
1) Tried NV demo – crashed. Well, it was expected... (And no AMD demos for Vulkan.)
2) Searched for SDK and it seems the only one available is LunarG SDK. Installed latest version (1.0.3.1) – nothing works there: demos say "Cannot find a compatible Vulkan installable client driver (ICD).", vulkaninfo-1-1-0-3-1.exe says "Cannot create Vulkan instance. C:\releasebuild\LoaderAndValidationLayers\demos\vulkaninfo.c:691: failed with VK_ERROR_INCOMPATIBLE_DRIVER".
Well, tried vulkaninfo-1-1-0-2-0.exe from runtime bundled with driver. It works, but with warning "WARNING: [loader] Code 0 : Using deprecated ICD interface of vkGetInstanceProcAddr instead of vk_icdGetInstanceProcAddr". How nice is to have deprecated interface in the first driver release!
Diggen into manifest file amd-vulkan64.json – it says "abi_versions" : "1.0.0", NV one says "abi_versions" : "1.0.3" and corresponding dll does have vk_icdGetInstanceProcAddr export.
Tried to find LunarG SDK 1.0.2.0 or earlier – no luck, all versions redirect to 1.0.3.1.
Conclusion: absolutely no way to develop for or even test this AMD Vulkan implementation.
NVIDIA's demos seem to rely on NVIDIA-specific GL/VK extensions (GL_NV_draw_vulkan_image, VK_NV_glsl_shader), so they won't work anywhere else. Maybe they're convenient features for early demos, but it's unfortunate that NVIDIA is encouraging fragmentation already.
Possibly the SDK demos would work better if you replaced their uses of VK_API_VERSION with VK_MAKE_VERSION(1, 0, 0) (the default defined in the SDK's vulkan.h is (1,0,3)), assuming there were no serious incompatible changes between those versions. Or they might not.
I don't think Nvidia is encouraging fragmentation, but they're actually doing the sensible thing here. If you read through the announcements, nearly every game maker has announced the first step towards a Vulkan migration is wrapping the current OpenGL stack into a translation layer. Then there's also the possibility of using OpenGL for your game engine and using Vulkan only for the critical paths (seeing as it is more complicated to program from Vulkan anyway). It can be argued that it's too soon to do the integration between OpenGL and Vulkan, but there's definitely a move in that direction in the industry, regardless of what Nvidia does.
Hm, in theory that would mean much higher OSX game wrapper performance over the old ones (bridging DX11 to OpenGL is no fun both ways). But I hope Apple just adopts Vulkan natively.
No mention of OSX, huh. I was really hoping they'd adopt it along side Metal, Metal is ok for iOS to OSX ports, but having one low overhead API span across Windows, Linux, and OSX would be a big boon.
As far as i know only small iOS games and if im not wrong even OpenGL on Mac OS is crappy 3.x or something.. I tried on 1 hardware with Nvidia card - Windows, Linux and Mac OS Witcher 2 a Mac OS version was much slower than even Linux One.
"Like DirectX 12, Vulkan’s transition to a low-level API will unquestionably make it harder to use".
That statement is a little mis-leading. *Real-world* OpenGL applications are extremely hard to develop, especially if you are targeting multiple platforms / GPU vendors. - GLSL compilers are different with every vendor / OS with their own quirks and bugs (lots of bugs, especially mobile GPUs). - Driver performance is a huge factor with OpenGL and means that if you want anything close to optimal performance you have to customize your rendering approach for each vendor generation. - Each platform has it's own way of initializing the API. i.e. in windows OS case, you literally create an ancient OpenGL 1.x context and use that to initialize a newer version etc. It's madness.
Trivial OpenGL examples might appear easier to comprehend from a code stand point, but for people who actually write GPU-enabled applications Vulkan will be much less frustrating (assuming good drivers). OpenGL was designed in the early 90s and while the API has evolved, it's still a giant hidden state-machine with endless side-effects. The last 30 years have taught software developers in general that those types of APIs are incredibly hard to use, especially as complexity scales up.
I won't disagree that OpenGL was more difficult to use than it should have been (this being part of the reason DX became so dominant). However with developers required to maintain their own state on Vulkan, it's going to be harder still, and Khronos has been trying to make it clear that it's not meant to be as accessible as OpenGL.
Also, remember that developers have been programming OpenGL for a long time, so even if it IS complicated, there is a lot of knowledge around that kind of diminishes that aspect. This is an entirely new ballgame.
How to test it, on Win 7? I have last Nvidia stable driver and Talos principles demo game - no Vulkan renderer options - only DX9,DX11 and OpenGL. What next i need?
While it states nVidia has passed conformance testing, it does not state that nVidia has released a driver with that support. It will most likely be in a beta version long before its in a release version.
They aren't biased in that way. The info they give is of a different story than you'd get from most tech/gaming sites and focuses on Linux driver development. It's a complicated area which means "working" has different meanings than what you're probably used to. For instance, you could say that the hardware is "working" once the drm-kms driver had been written. That doesn't mean you'll be able to play game X, but that the "full" capabilities of hardware are now available. Even that is a simplification, but the point is that the ARTICLES, let alone the information provided, aren't biased against Windows.
I believe this not to be super likely. Fermi only has 128 binds for objects, so implementation of Vulkan for Fermi would run into a performance brick wall which will need to be worked around by software title developers, at which point targeting classic GL and DX11 seems like an almost more apt proposition. Kepler added bindless object support, meaning any draw operation can refer to any existing shaders and textures without binding them first, and this required hardware changes.
DX12 might be facing a similar issue. At one point, NVidia promised DX12 for Fermi, but no signs of it coming along yet, while Kepler and Maxwell were supported up front. Perhaps you can wait for a few months, and if DX12 support doesn't hit Fermi, then don't count on Vulkan coming either. So there are two possibilities for now, either the expected first wave of software titles with DX12 support is not coming along quickly enough to warrant the driver release, or they hit implementation difficulties which could probably also affect Vulkan.
I suspect the announcements were in part based on NV intending to recycle Fermi again in the 900 generation for the lowest end units, but it looks like they could be skipping it this time around - a lot of time has passed, and still no sign of those. No low end units launched on mainline at all, and lowest end units on mobile are based on recycled Kepler GT730M, which has initial DX12 support.
My apologies that this is super speculative, but i guess it's fair given that you asked for opinion.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
Facebook
Twitter
RSS
40 Comments
Back to Article
Ryan Smith - Tuesday, February 16, 2016 - link
By the way, for anyone wondering about the logo: it's composed of various standard 3D test models. The Stanford Bunny, Dragon, & Armadillo, and of course the Utah Teapot.CajunArson - Tuesday, February 16, 2016 - link
It's about Vulkan time we got this API out!Agent_007 - Tuesday, February 16, 2016 - link
"and with GDC 2015 taking place next month"it is GDC 2016
Krteq - Tuesday, February 16, 2016 - link
Hey Ryan, here is the AMD driver - http://support.amd.com/en-us/kb-articles/Pages/Rad...bug77 - Tuesday, February 16, 2016 - link
I wouldn't put many hopes into that, seeing that it's not even submitted for conformance review. AMD themselves say it's in alpha/beta stages which (knowing AMD) means it actually works sometimes.Senti - Tuesday, February 16, 2016 - link
I can confirm that AMD driver can be considered non-working.1) Tried NV demo – crashed. Well, it was expected... (And no AMD demos for Vulkan.)
2) Searched for SDK and it seems the only one available is LunarG SDK. Installed latest version (1.0.3.1) – nothing works there: demos say "Cannot find a compatible Vulkan installable client driver (ICD).", vulkaninfo-1-1-0-3-1.exe says "Cannot create Vulkan instance. C:\releasebuild\LoaderAndValidationLayers\demos\vulkaninfo.c:691: failed with VK_ERROR_INCOMPATIBLE_DRIVER".
Well, tried vulkaninfo-1-1-0-2-0.exe from runtime bundled with driver. It works, but with warning "WARNING: [loader] Code 0 : Using deprecated ICD interface of vkGetInstanceProcAddr instead of vk_icdGetInstanceProcAddr". How nice is to have deprecated interface in the first driver release!
Diggen into manifest file amd-vulkan64.json – it says "abi_versions" : "1.0.0", NV one says "abi_versions" : "1.0.3" and corresponding dll does have vk_icdGetInstanceProcAddr export.
Tried to find LunarG SDK 1.0.2.0 or earlier – no luck, all versions redirect to 1.0.3.1.
Conclusion: absolutely no way to develop for or even test this AMD Vulkan implementation.
Excors - Wednesday, February 17, 2016 - link
NVIDIA's demos seem to rely on NVIDIA-specific GL/VK extensions (GL_NV_draw_vulkan_image, VK_NV_glsl_shader), so they won't work anywhere else. Maybe they're convenient features for early demos, but it's unfortunate that NVIDIA is encouraging fragmentation already.Possibly the SDK demos would work better if you replaced their uses of VK_API_VERSION with VK_MAKE_VERSION(1, 0, 0) (the default defined in the SDK's vulkan.h is (1,0,3)), assuming there were no serious incompatible changes between those versions. Or they might not.
Senti - Wednesday, February 17, 2016 - link
I've tried changing VK_API_VERSION and abi_versions but vkCreateInstance returns VK_ERROR_INCOMPATIBLE_DRIVER anyway.Senti - Wednesday, February 17, 2016 - link
Update: changing VK_API_VERSION to VK_MAKE_VERSION(1, 0, 2) does work.bug77 - Wednesday, February 17, 2016 - link
I don't think Nvidia is encouraging fragmentation, but they're actually doing the sensible thing here. If you read through the announcements, nearly every game maker has announced the first step towards a Vulkan migration is wrapping the current OpenGL stack into a translation layer. Then there's also the possibility of using OpenGL for your game engine and using Vulkan only for the critical paths (seeing as it is more complicated to program from Vulkan anyway).It can be argued that it's too soon to do the integration between OpenGL and Vulkan, but there's definitely a move in that direction in the industry, regardless of what Nvidia does.
Ryan Smith - Tuesday, February 16, 2016 - link
Thanks!coordz - Tuesday, February 16, 2016 - link
It looks like MetalVK https://moltengl.com/metalvk/ may bridge Vulkan onto Apple devices.tipoo - Tuesday, February 16, 2016 - link
Hm, in theory that would mean much higher OSX game wrapper performance over the old ones (bridging DX11 to OpenGL is no fun both ways). But I hope Apple just adopts Vulkan natively.bug77 - Wednesday, February 17, 2016 - link
You can hope for whatever you want, but right in this article it's stated Apple has withdrawn from Vulkan working group for a while now.tipoo - Tuesday, February 16, 2016 - link
No mention of OSX, huh. I was really hoping they'd adopt it along side Metal, Metal is ok for iOS to OSX ports, but having one low overhead API span across Windows, Linux, and OSX would be a big boon.Gothmoth - Tuesday, February 16, 2016 - link
apple is so full of s*it i expected no less.trparky - Tuesday, February 16, 2016 - link
But if it supports Metal it should be fully supportable on Mac OSX since Metal is now part of Mac OSX.Gothmoth - Tuesday, February 16, 2016 - link
apple must have it own sausage of course. morons.....xype - Tuesday, February 16, 2016 - link
They needed their own sausage way before Vulkan got out. Metal is shipping games already, Apple didn’t have time to wait.ruthan - Tuesday, February 16, 2016 - link
As far as i know only small iOS games and if im not wrong even OpenGL on Mac OS is crappy 3.x or something..I tried on 1 hardware with Nvidia card - Windows, Linux and Mac OS Witcher 2 a Mac OS version was much slower than even Linux One.
VertexMaster - Tuesday, February 16, 2016 - link
"Like DirectX 12, Vulkan’s transition to a low-level API will unquestionably make it harder to use".That statement is a little mis-leading. *Real-world* OpenGL applications are extremely hard to develop, especially if you are targeting multiple platforms / GPU vendors.
- GLSL compilers are different with every vendor / OS with their own quirks and bugs (lots of bugs, especially mobile GPUs).
- Driver performance is a huge factor with OpenGL and means that if you want anything close to optimal performance you have to customize your rendering approach for each vendor generation.
- Each platform has it's own way of initializing the API. i.e. in windows OS case, you literally create an ancient OpenGL 1.x context and use that to initialize a newer version etc. It's madness.
Trivial OpenGL examples might appear easier to comprehend from a code stand point, but for people who actually write GPU-enabled applications Vulkan will be much less frustrating (assuming good drivers). OpenGL was designed in the early 90s and while the API has evolved, it's still a giant hidden state-machine with endless side-effects. The last 30 years have taught software developers in general that those types of APIs are incredibly hard to use, especially as complexity scales up.
Ryan Smith - Tuesday, February 16, 2016 - link
I won't disagree that OpenGL was more difficult to use than it should have been (this being part of the reason DX became so dominant). However with developers required to maintain their own state on Vulkan, it's going to be harder still, and Khronos has been trying to make it clear that it's not meant to be as accessible as OpenGL.extide - Tuesday, February 16, 2016 - link
Also, remember that developers have been programming OpenGL for a long time, so even if it IS complicated, there is a lot of knowledge around that kind of diminishes that aspect. This is an entirely new ballgame.Flunk - Tuesday, February 16, 2016 - link
All those logos on their supported OSes pages can be boiled down to just two OS families, Windows and Linux.tuxRoller - Tuesday, February 16, 2016 - link
IOW, the overwhelming majority of user facing computers.ruthan - Tuesday, February 16, 2016 - link
How to test it, on Win 7? I have last Nvidia stable driver and Talos principles demo game - no Vulkan renderer options - only DX9,DX11 and OpenGL.What next i need?
Stuka87 - Tuesday, February 16, 2016 - link
While it states nVidia has passed conformance testing, it does not state that nVidia has released a driver with that support. It will most likely be in a beta version long before its in a release version.ruthan - Tuesday, February 16, 2016 - link
I read elsewhere (Phoronix) that even driver is released and after this post i found one:https://developer.nvidia.com/vulkan-driver
I installed it, but this not Vulkan options in Talos principle, but maybe i need restart of Windows, maybe game is not ready yet.
These Phoronix articles are usually biased - by Linux like point of view - something is promised, half working = something is working.
ruthan - Tuesday, February 16, 2016 - link
Here is solution, Talos beta - Steam flag magic is needed:https://steamcommunity.com/app/257510/discussions/...
tuxRoller - Wednesday, February 17, 2016 - link
They aren't biased in that way. The info they give is of a different story than you'd get from most tech/gaming sites and focuses on Linux driver development. It's a complicated area which means "working" has different meanings than what you're probably used to. For instance, you could say that the hardware is "working" once the drm-kms driver had been written. That doesn't mean you'll be able to play game X, but that the "full" capabilities of hardware are now available. Even that is a simplification, but the point is that the ARTICLES, let alone the information provided, aren't biased against Windows.529th - Tuesday, February 16, 2016 - link
Great write up! The outlining of the industry creates a clear picture of where key players stand with the future of Vulkan.Well written!
tuxRoller - Tuesday, February 16, 2016 - link
https://lists.freedesktop.org/archives/mesa-dev/20...Driver actually supports gpus back to ivb.
siriq - Tuesday, February 16, 2016 - link
Do you guys think Fermi will get Vulkan support?Ryan Smith - Wednesday, February 17, 2016 - link
No. If NVIDIA was going to develop Vulkan support for Fermi, I believe they would have announced so to begin with.jabbadap - Wednesday, February 17, 2016 - link
Afaik they did in siggraph 2015(slide 50 in vulkan on nvidia gpus presentation):http://www.nvidia.com/object/siggraph2015-best-gtc...
siriq - Wednesday, February 17, 2016 - link
Well, nvidia did announce Vulkan support to Fermi last year.Siana - Sunday, February 28, 2016 - link
I believe this not to be super likely. Fermi only has 128 binds for objects, so implementation of Vulkan for Fermi would run into a performance brick wall which will need to be worked around by software title developers, at which point targeting classic GL and DX11 seems like an almost more apt proposition. Kepler added bindless object support, meaning any draw operation can refer to any existing shaders and textures without binding them first, and this required hardware changes.DX12 might be facing a similar issue. At one point, NVidia promised DX12 for Fermi, but no signs of it coming along yet, while Kepler and Maxwell were supported up front. Perhaps you can wait for a few months, and if DX12 support doesn't hit Fermi, then don't count on Vulkan coming either. So there are two possibilities for now, either the expected first wave of software titles with DX12 support is not coming along quickly enough to warrant the driver release, or they hit implementation difficulties which could probably also affect Vulkan.
I suspect the announcements were in part based on NV intending to recycle Fermi again in the 900 generation for the lowest end units, but it looks like they could be skipping it this time around - a lot of time has passed, and still no sign of those. No low end units launched on mainline at all, and lowest end units on mobile are based on recycled Kepler GT730M, which has initial DX12 support.
My apologies that this is super speculative, but i guess it's fair given that you asked for opinion.
ruthan - Wednesday, February 17, 2016 - link
Supports Vulkan like DX12, multiple GPU (i dont mean SLI or Crossfire) or even multiple multi-vendor GPU mode?tuxRoller - Wednesday, February 17, 2016 - link
Yes, since spir-v is consumed by the drivers. However, it's up to the games themselves to support multi GPU.tuxRoller - Wednesday, February 17, 2016 - link
Why are you saying the ivb/hsw support is "unconfirmed"?