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.
Announcement
Collapse
No announcement yet.
Vulkan 1.3 Released With Dynamic Rendering In Core, New Roadmap Guidance For Modern GPUs
Collapse
X
-
inglésNVIDIA <[email protected]> 20:00 (hace 12 minutos)
para mí
español
Traducir mensaje
Desactivar para: inglésand in the https://developer.nvidia.com/vulkan-driver linkThe 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.
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
- Fully conformant Vulkan 1.3 implementation
great!Last edited by tildearrow; 28 January 2022, 01:14 PM.
Comment
- New:
-
Originally posted by bug77 View PostVulkan is to OpenGL like C is is to .net/java.
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.
- Likes 4
Comment
-
Originally posted by foobaz View Post
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.
Me, I haven't had the pleasure for 15+ years, but even then, there was glut, you weren't supposed to do everything yourself.
- Likes 1
Comment
-
Originally posted by Mitch View PostI wonder if they'll incorporate some type of upscaling like FSR, DLSS, or the Intel one at some point.
- Likes 2
Comment
-
Originally posted by bug77 View PostPay attention the version of Vulkan supported
- Likes 1
Comment
-
Originally posted by rmfx View PostConcerning 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.
- Likes 1
Comment
-
Originally posted by coder View PostThat'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.
Comment
-
Originally posted by coder View PostThe 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.
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.Last edited by linuxgeex; 26 January 2022, 03:46 AM.
Comment
Comment