Vulkan 1.3 Released With Dynamic Rendering In Core, New Roadmap Guidance For Modern GPUs

[Imroy]

I don't remember 1.2 being released. Oh, it was released in January 2020. I guess much more memorable things were about to happen. 2020 just turned into a memory hole.

[sl1pkn07]

NVIDIA <[email protected]>	20:00 (hace 12 minutos)
para mí

inglés
español

Traducir mensaje
Desactivar para: inglés

VULKAN 1.3 BETA DRIVERS AVAILABLE NOW The Vulkan 1.3 specification was released today by Khronos and mandates support for a number of popular extensions including Dynamic Rendering, Buffer Device Address, and more. NVIDIA has posted conformant beta drivers for Vulkan 1.3 on the Vulkan Driver Page. LEARN MORE

and in the https://developer.nvidia.com/vulkan-driver link

Vulkan Beta Driver Release Updates


January 25th, 2022 - Windows 473.11, Linux 470.62.22

• New:
  • Fully conformant Vulkan 1.3 implementation
    • Includes full support for Roadmap 2022
  • VK_KHR_global_priority

great!

[onlyLinuxLuvUBack]

i guess it will be a while before techpowerup updates their video cards list with vulkan version support for cards

[foobaz]

Vulkan is to OpenGL like C is is to .net/java.

This is true for legacy OpenGL with the fixed-function pipeline, but modern core profile OpenGL is almost as low level as Vulkan. And fixed-function OpenGL is not very good. Its graphics capabilities are very basic by modern standards - it's impractical to make anything that looks better than Quake 3 or a Playstation 2 game using the fixed-function pipeline. Additionally, legacy OpenGL is very slow, both because it's not well-adapted to GPU acceleration, and because the API is from the '90s and was optimized for the much smaller and simpler scenes that you were limited to back then. It's useless for modern game development and inertia is the only reason it's still used at all.

For small teams or individual developers, it's also impractical to make a game using a low level API like Vulkan or core profile OpenGL. But the solution is not legacy OpenGL, the solution is 3rd party engines, like Godot, Unreal, Unity, VulkanSceneGraph, Open 3D Engine, etc. These are all quite good and offer modern graphics capability far beyond what legacy fixed-function OpenGL can do.

[bug77]

This is true for legacy OpenGL with the fixed-function pipeline, but modern core profile OpenGL is almost as low level as Vulkan. And fixed-function OpenGL is not very good. Its graphics capabilities are very basic by modern standards - it's impractical to make anything that looks better than Quake 3 or a Playstation 2 game using the fixed-function pipeline. Additionally, legacy OpenGL is very slow, both because it's not well-adapted to GPU acceleration, and because the API is from the '90s and was optimized for the much smaller and simpler scenes that you were limited to back then. It's useless for modern game development and inertia is the only reason it's still used at all.

For small teams or individual developers, it's also impractical to make a game using a low level API like Vulkan or core profile OpenGL. But the solution is not legacy OpenGL, the solution is 3rd party engines, like Godot, Unreal, Unity, VulkanSceneGraph, Open 3D Engine, etc. These are all quite good and offer modern graphics capability far beyond what legacy fixed-function OpenGL can do.

Fair enough. but even then, would you go low-level using an API you're somewhat familiar with or would you go for something entirely new?
Me, I haven't had the pleasure for 15+ years, but even then, there was glut, you weren't supposed to do everything yourself.

[coder]

I wonder if they'll incorporate some type of upscaling like FSR, DLSS, or the Intel one at some point.

I think that's a lot higher-level than existing Vulkan features or extensions. At most, you might get some extensions that make it easier for people to write & utilize interchangeable upscaling filters.

[coder]

Pay attention the version of Vulkan supported

That's what the profiles exist to solve. Google defined the Android profile, because most devices support common extensions beyond Vulkan 1.0, even though too many of them are still below 1.1-compliance.

[coder]

Concerning Vulkan adoption, it’s slow only because it requires a broad and complex work to be fully adopted. 64bit, Wayland, Vulkan, these key steps always take much more time than planned unfortunately. But when they land, it’s solid and it stays.

The story they seem to paint is that it's being slowed in part because developers have trouble knowing which extensions they can safely count on. Profiles are designed to simplify this, greatly.

[billyswong]

That's what the profiles exist to solve. Google defined the Android profile, because most devices support common extensions beyond Vulkan 1.0, even though too many of them are still below 1.1-compliance.

So Vulkan Android profile is something like 1.05?

[linuxgeex]

The story they seem to paint is that it's being slowed in part because developers have trouble knowing which extensions they can safely count on. Profiles are designed to simplify this, greatly.

Extensions basically let them as a standards body say "Ok, you folks do what you want over on the side here and we'll let you call X implementation Vulkan so long as it passes this suite of tests. You can extend it and we won't have to promise that your extensions will be supported here or elsewhere in future."

So then for example, Wayland support can exist as an unsupported extension while developers A and B are coming up with a de-facto API based on their experiences trying to use it. A & B then contribute their work to Kronos for adoption, who then round-table the API with stakeholders. If they're lucky Kronos hires A or B to create a reference implementation and test suite for conformance and performance testing. That goes back to Kronos for evaluation and they schedule it for inclusion in their next stable API release.

I can't find any reference to their policy around stable release timing, but from their history, they seem to be doing a stable release in January every second year.

So I don't think there's any need to artificially slow the process down, lol.

Interestingly they say they are making profiles mandatory for Vulkan 1.3 compliance. I say it's interesting because it's unclear whether profiles are based on capability and conformance (predictable performance), or conformance alone (software won't crash but performance isn't predictable.)

I get that profiles will be handy for creative developers. I'm just a bit confused where the line is drawn for system developers and marketers. I'm concerned how that ends up impacting end users and creators. Mostly because they keep claiming that they are fitting core into GLES3.1-class hardware, and there's some pretty poor GLES3.1-class hardware. Various Intel Atoms with PowerVR spring to mind.