Support us on Patreon to keep GamingOnLinux alive. This ensures we have no timed articles and no paywalls. Just good, fresh content! Alternatively, you can donate through PayPal, Flattr, Liberapay or Buy us a Coffee. You can also buy games using our partner links for GOG and Humble Store.

LunarG's Vulkan developer survey results out now - Vulkan also turns 4

By - | Views: 13,504

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.
19 Likes, Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG, Humble Store and Paradox Interactive. See more here.
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
6 comments

Shmerl 23 February 2020 at 7:03 am UTC
QuoteComplexity 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
mirv 23 February 2020 at 10:28 am UTC
View PC info
  • Supporter
  • Top Supporter
Strictly speaking, Vulkan is neither complex nor low level by design. It's designed to be low overhead, which necessitates making it match modern GPU architectures (giving an appearance of low level), and also requires the user (developer) to be very explicit about what they want to do.
Most I've talked to (granted people coming from GL4.x, so they're already familiar with how modern graphics are supposed to work) don't find it complex, just verbose! One exception would be the synchronisation mechanisms, which Khronos have been working to improve.

What really helps are tutorials, documentation, helper libraries such as VMA, and so on. While it doesn't make Vulkan any less explicit, it does help developers understand and manage easier. Explicit and verbose, complex or not, still requires a lot of effort to create and maintain.

It's nice to see Khronos (of which LunarG and Valve are a part) have realised much of this early on and haven't focused purely on the API, but also the documentation, examples, tooling, feedback, and community in general. These surveys are heeded and directly help to focus the resources of Khronos and interested parties.
Shmerl 23 February 2020 at 10:30 am UTC
Going much lower level you'd need GPU assembly already. So I'd say Vulkan is low level by design, not just in appearance.
mirv 23 February 2020 at 10:48 am UTC
View PC info
  • Supporter
  • Top Supporter
ShmerlGoing much lower level you'd need GPU assembly already. So I'd say Vulkan is low level by design, not just in appearance.

Well, by the same token you could say original OpenGL was low level as well in that case.

I mean, Vulkan is obviously not hiding much, and exposing what was previously hidden in drivers, but it's still very far from GPU assembly. But it was not designed to be low level; low overhead, multithreaded, portability are the main design goals. I'll have to find the talk, it's from a while ago, but that was stated rather clearly.

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.
Shmerl 23 February 2020 at 11:07 am UTC
mirvActually 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
mirv 23 February 2020 at 11:28 am UTC
View PC info
  • Supporter
  • Top Supporter
Shmerl
mirvActually 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.

The state machinery used to be how video cards worked. And shaders were originally written in a form of assembly. It's just that OpenGL no longer matches how modern video cards function; OpenGL is no longer aligned to how drivers communicate to a video card.

This is the assumption really, that Vulkan matches the underlying architecture. If it doesn't, then the driver would need to morph to keep the userspace interface the same. In 50 years, maybe Vulkan drivers (if still around) will be as bulky as current OpenGL drivers. Vulkan in the driver stack sits as high above a GPU as OpenGL, from the perspective of the GPU, but that still aligns very closely to the API seen from userspace - giving the impression of low level.

I point this out for expectations and perspective. Yes, it has all the appearance of low level, but being a side effect rather than a design goal might impact what happens as the API is developed. Being explicit simply means the driver can be written very cleanly, no guessing at what the user wants, but perhaps a lot of heavy lifting could be done because it's always the same. Being low level would mean that heavy lifting always needs to be done by the user, regardless of whether the driver could easily do it instead. Subtle, but important difference.
While you're here, please consider supporting GamingOnLinux on Patreon, Liberapay or Paypal. We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!

You need to Register and Login to comment, submit articles and more.


Or login with...

Livestreams & Videos
None currently, submit yours here!
Popular this week
View by Category
Contact
Latest Comments
Latest Forum Posts