Vulkan 1.2.140 Released With New Extensions For Private Data, Custom Border Color

[phoronix]

Phoronix: Vulkan 1.2.140 Released With New Extensions For Private Data, Custom Border Color

Vulkan 1.2.140 is out as the latest version of the Vulkan API for high performance graphics and compute. Besides the usual assortment of documentation clarifications/fixes, this round does bring two new extensions...

http://www.phoronix.com/scan.php?page=news_item&px=Vulkan-1.2.140-Released

[allquixotic]

VK_EXT_private_data sounds like a perfect conduit for proprietary "blob data" that's going to end up being used as secret sauce in 3d engines. Ugh. I'm a little concerned that some sort of unofficial or de facto standard will arise about what kind of blob data should go in there, because Nvidia will use their market share and proprietary driver lock-in to make developers comfortable with using it. Then, the game either won't run, or will have much poorer performance using AMD or Intel hardware.

Leave it to Nvidia to basically force the concept of proprietary vendor extensions into an open standard. This is what made OpenGL a mess to begin with! If you want something added to the standard, work with the standards body to get it standardized -- don't resort to this kind of escape hatch.

[rmfx]

The Khronos group is quite corrupted by nvidia anyway, like the raytracing extension that is made the way nvidia likes.

Vulkan is already bloated with extensions of all sorts, like they never learn form past.

[skeevy420]

rmfx


VK_KHR_ray_tracing(3) Manual Page

Contributors

• Matthäus Chajdas, AMD
• Greg Grebe, AMD
• Nicolai Hähnle, AMD
• Tobias Hector, AMD
• Dave Oldcorn, AMD
• Skyler Saleh, AMD
• Mathieu Robart, Arm
• Marius Bjorge, Arm
• Tom Olson, Arm
• Sebastian Tafuri, EA
• Henrik Rydgard, Embark
• Juan Cañada, Epic Games
• Patrick Kelly, Epic Games
• Yuriy O’Donnell, Epic Games
• Michael Doggett, Facebook/Oculus
• Don Scorgie, Imagination
• Dae Kim, Imagination
• Joshua Barczak, Intel
• Slawek Grajewski, Intel
• Jeff Bolz, NVIDIA
• Pascal Gautron, NVIDIA
• Daniel Koch, NVIDIA
• Christoph Kubisch, NVIDIA
• Ashwin Lele, NVIDIA
• Robert Stepinski, NVIDIA
• Martin Stich, NVIDIA
• Nuno Subtil, NVIDIA
• Eric Werness, NVIDIA
• Jon Leech, Khronos
• Jeroen van Schijndel, OTOY
• Juul Joosten, OTOY
• Alex Bourd, Qualcomm
• Roman Larionov, Qualcomm
• David McAllister, Qualcomm
• Andrew Garrard, Samsung
• Lewis Gordon, Samsung
• Ralph Potter, Samsung
• Jasper Bekkers, Traverse Research
• Jesse Barker, Unity
• Baldur Karlsson, Valve

Does that mean AMD should fire their contributors since they've been making Nvidia compatible code and are therefore undermining their company?
(I shouldn't have to explain that that's a joke)

[pinguinpc]

d9vk still works in this driver version and dxvk possible use various of this new extensions in future releases

[plonoma]

This "private data" isn't private in the sense of security or DRM minded but for attaching arbitrary payloads to Vulkan objects. The VK_EXT_private_data extension allows for private data slots to be attached to Vulkan objects and are for application-defined data.

Then why call it 'private' data? Why not call it payload/arbitrary payload/application/application defined/other/... data. They should really work on their names more and come up with better ones.

[smitty3268]

Then why call it 'private' data? Why not call it payload/arbitrary payload/application/application defined/other/... data. They should really work on their names more and come up with better ones.

Seems like a pretty good name to me.

I'm very curious about the use case driving this, though. Debugging tooling seems to be one place where it could be used to great effect, but somehow I doubt that's what NVidia plans on using it for.

[cute2dgirl]

The private data extension is designed in such a way that the driver cannot identify the kind of data you're passing to it since there is no metadata whatsoever. It's just an arbitrary uint64.

Why is this useful? Presumably because layers can now store a pointer to their own per-object data inside the object, without having to resort to globally locked lookup tables.

[Weasel]

Then why call it 'private' data? Why not call it payload/arbitrary payload/application/application defined/other/... data. They should really work on their names more and come up with better ones.

I suggest you look up the C++ private keyword.

[Stefem]

rmfx


VK_KHR_ray_tracing(3) Manual Page

Contributors

• Matthäus Chajdas, AMD
• Greg Grebe, AMD
• Nicolai Hähnle, AMD
• Tobias Hector, AMD
• Dave Oldcorn, AMD
• Skyler Saleh, AMD
• Mathieu Robart, Arm
• Marius Bjorge, Arm
• Tom Olson, Arm
• Sebastian Tafuri, EA
• Henrik Rydgard, Embark
• Juan Cañada, Epic Games
• Patrick Kelly, Epic Games
• Yuriy O’Donnell, Epic Games
• Michael Doggett, Facebook/Oculus
• Don Scorgie, Imagination
• Dae Kim, Imagination
• Joshua Barczak, Intel
• Slawek Grajewski, Intel
• Jeff Bolz, NVIDIA
• Pascal Gautron, NVIDIA
• Daniel Koch, NVIDIA
• Christoph Kubisch, NVIDIA
• Ashwin Lele, NVIDIA
• Robert Stepinski, NVIDIA
• Martin Stich, NVIDIA
• Nuno Subtil, NVIDIA
• Eric Werness, NVIDIA
• Jon Leech, Khronos
• Jeroen van Schijndel, OTOY
• Juul Joosten, OTOY
• Alex Bourd, Qualcomm
• Roman Larionov, Qualcomm
• David McAllister, Qualcomm
• Andrew Garrard, Samsung
• Lewis Gordon, Samsung
• Ralph Potter, Samsung
• Jasper Bekkers, Traverse Research
• Jesse Barker, Unity
• Baldur Karlsson, Valve

Does that mean AMD should fire their contributors since they've been making Nvidia compatible code and are therefore undermining their company?
(I shouldn't have to explain that that's a joke)

That should tell you the kind of level of conspiracy NVIDIA put in place... it's so pervasive that competitors work for them without knowing! it must be that because there is no other explanation as everything NVIDIA do must be bad, evil, close and of course proprietary with the only purpose to gain control of the entire world.
And remember, always wear sunglasses or they will flash you with a neuralyzer