It has been officially announced now, so Vulkan API it is! We are entering a new era of graphical performance.
The good news, is that Vulkan will be able to work on any chip that supports OpenGL ES 3.1 and upwards. So, it looks like it could work on cards as old as the Nvidia 400 series, but we still need to wait and see what cards the official proprietary drivers and open source drivers actually support before people with older cards get too excited.
I can't imagine them leaving it to only the newest generation of chips, as that would lock out too many people.
It may be a while before we see support for it in drivers, as the API probably isn’t completely finished just yet, and the open source drivers don’t have full OpenGL support just yet either.
Here's a choice quote from Gabe Newell, Valve:
It will be interesting to see what demos they have in store for us later at GDC!
See the official press release here.
There’s also the official Vulkan site here as well.
And finally, there’s the slides to look over that give you an overview. Article taken from GamingOnLinux.com.
The good news, is that Vulkan will be able to work on any chip that supports OpenGL ES 3.1 and upwards. So, it looks like it could work on cards as old as the Nvidia 400 series, but we still need to wait and see what cards the official proprietary drivers and open source drivers actually support before people with older cards get too excited.
I can't imagine them leaving it to only the newest generation of chips, as that would lock out too many people.
It may be a while before we see support for it in drivers, as the API probably isn’t completely finished just yet, and the open source drivers don’t have full OpenGL support just yet either.
Here's a choice quote from Gabe Newell, Valve:
QuoteIndustry standard APIs like Vulkan are a critical part of enabling developers to bring the best possible experience to customers on multiple platforms. Valve and the other Khronos members are working hard to ensure that this high-performance graphics interface is made available as widely as possible and we view it as a critical component of SteamOS and future Valve games.
It will be interesting to see what demos they have in store for us later at GDC!
See the official press release here.
There’s also the official Vulkan site here as well.
And finally, there’s the slides to look over that give you an overview. Article taken from GamingOnLinux.com.
0 Likes
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Mantle allows multiple command queues per GPU (see here: http://techreport.com/review/25683/delving-deeper-into-amd-mantle-api/2 ).
Current generation of GPUs allow executing multiple commands in parallel (Nvidia has "warps", AMD has "wavefronts" etc.). And to fully utilize that you need several command queues running in different threads. So that's what I'm asking about. Will Vulkan allow it?
Current generation of GPUs allow executing multiple commands in parallel (Nvidia has "warps", AMD has "wavefronts" etc.). And to fully utilize that you need several command queues running in different threads. So that's what I'm asking about. Will Vulkan allow it?
0 Likes
Quoting: ShmerlWill Vulkan allow it?
Vulkan is based on Mantle (source AMD blog) so most likely the behaviour is the same. While specifications are not available the few examples around show that the functions to submit command buffers are exactly the same, signature included, except for 2 chars vkQueueSubmit instead of grQueueSubmit for obvious reasons.
I really don't think Vulkan can have many flaws considering how much of the relevant industry is behind it and how much effort they are putting in it (e.g. Source 2 ported to Vulkan, Vulkan Intel drivers, PowerVR demo...)
0 Likes
From the GDC15 Vulkan API-Talk:
"Device" is a logical representation of a GPU. It's how you talk to it. Each has a number of queues, you control which ones you want plus what extensions. You opt-in to extensions. Plus, what layers should be enabled (layers used for things like validation, debugging, logging, etc.)
and
Queues are things like compute queue, graphics queue. GPUs will have various numbers of each kind of queue. All queues scheduled independently and run async.
and
Batch up commands in command buffers. Each is thread local. You tell Vulkan what kind of queue each buffer will be sent to.
basically suggests a Mantle-Like design, in which case I'd have been wrong (oops! :D). Didn't watch the full video yet (I'm at work), but if you have time before I do:
https://www.youtube.com/watch?v=EUNMrU8uU5M
"Device" is a logical representation of a GPU. It's how you talk to it. Each has a number of queues, you control which ones you want plus what extensions. You opt-in to extensions. Plus, what layers should be enabled (layers used for things like validation, debugging, logging, etc.)
and
Queues are things like compute queue, graphics queue. GPUs will have various numbers of each kind of queue. All queues scheduled independently and run async.
and
Batch up commands in command buffers. Each is thread local. You tell Vulkan what kind of queue each buffer will be sent to.
basically suggests a Mantle-Like design, in which case I'd have been wrong (oops! :D). Didn't watch the full video yet (I'm at work), but if you have time before I do:
https://www.youtube.com/watch?v=EUNMrU8uU5M
0 Likes
Patreon
PayPal
See more from me