LunarG, the software company that Valve sponsors who work on building out the ecosystem for the Vulkan API recently conducted a Vulkan developer survey with the results out now.
Before going over the results, just a reminder that Vulkan just recently turned four years old! The 1.0 specification went public on February 16, 2016. Since then, we've seen some pretty amazing things thanks to it. We've had Linux ports that perform really nicely, the mighty DXVK translation layer advanced dramatically, to the vkBasalt post-processing layer and so on—there's been a lot going on. However, as a graphics API do remember it's pretty young and has a long life ahead of it.
As for the LunarG survey: there were 349 replies to it, and while not a huge amount it gives us an interesting insight into what some developers think and feel about how Vulkan is doing as a whole. Overall, it gives quite a positive picture on the health of Vulkan with over 60% feeling the overall quality of the Vulkan ecosystem as "Good" and almost 20% rating it as "Excellent".
It's also a good way to find out what needs to improve, as a result of the replies to the survey LunarG noted the key areas that may be hindering adoption as (in order):
- Complexity of the API
- Driver quality and inconsistency
- Tutorials/samples/documentation
- Tool deficiencies
This has been improving though, with the Khronos Group announcing both a Vulkan Guide and a Samples Repository in the later half of last year.
Something else that's very interesting for us here at GOL is that just over 70% of the respondents said they are working on Desktop Linux as the target of their development. Not only that, over 50% said their Vulkan development environment was Linux too. Keep in mind that the survey isn't just game developers though and it does include a mix of people studying and working with Vulkan for commercial use.
You can see their blog post here, with the results PDF file here.
Article taken from GamingOnLinux.com.
Complexity of the API
I doubt that can be improved. Vulkan is complex by design due to being very low level. For higher level APIs, developers can use WebGPU, which is not really browser targeted only (so the name is unfortunate, it should have been named OpenGPU). According to gfx-rs project developers, WebGPU should play a role of higher level developer friendly API, that's built on top of solid foundation (Vulkan).
It's exactly what Khronos mentioned was needed as a companion API to Vulkan. I.e. those who are OK with given abstractions and want some comfort can use WebGPU. Those who need higher level of control and full customization ability, can use Vulkan directly.
Last edited by Shmerl on 23 February 2020 at 7:04 am UTC
Actually Vulkan drivers sit about the same "height" above a GPU as OpenGL drivers, but there's not as much bulk between that level and userspace.
I'd say not, because they don't impose all the state machinery that OpenGL drivers do. They sit as much high up to be generic enough for all GPUs. I mentioned assembly because going lower than what Vulkan provides would make such code already GPU architecture specific. Assembly is just putting it on the hardware command level.
Last edited by Shmerl on 23 February 2020 at 11:08 am UTC
Patreon
PayPal
See more from me