NVidia introduces framework to simplify Vulkan

Status
Not open for further replies.

NTMBK

Lifer
Nov 14, 2011
10,400
5,635
136
We'll provide an overview of VHKL, a framework that can simplify your Vulkan development by using features like RAII, resource tracking, and providing interfaces for functionality like sub-allocation.

https://mygtc.gputechconf.com/events/37/schedules/3682

Who wants to bet that it "simplifies" things in a way that hurts AMD?


This thread doesn't start in a good place. If you'd like to continue a serious discussion about it (like Elixer is doing) rather than starting off on the wrong foot, we can try for a new thread. This one is too poisonous.

AT Moderator ElFenix
 
Last edited by a moderator:

Qwertilot

Golden Member
Nov 28, 2013
1,604
257
126
99% certain (judged in a relative manner anyway) due to the nature of a low level framework I'd have thought.
 

Krteq

Golden Member
May 22, 2015
1,005
713
136
Proprietary High Level framework for Vulkan? Do I smell "CrapWorks" again? :/
 
Last edited:

crisium

Platinum Member
Aug 19, 2001
2,643
615
136
I'd prefer id Software to lead on the Vulkan front, if they were willing to do so. They have written magic into the Vulkan code of Doom, though I don't know how simple it is compared to NVDA's designs.
 
  • Like
Reactions: Bacon1

Carfax83

Diamond Member
Nov 1, 2010
6,841
1,536
136
I'd prefer id Software to lead on the Vulkan front, if they were willing to do so. They have written magic into the Vulkan code of Doom, though I don't know how simple it is compared to NVDA's designs.

That "magic" is called intrinsic shader functions, and is primarily responsible for AMD's advantage in Doom. Eventually, the Khronos Group will implement it for NVidia as well.
 

dogen1

Senior member
Oct 14, 2014
739
40
91
This isn't news and it's basically just a tool to help devs integrate vulkan in smaller steps.
 

MajinCry

Platinum Member
Jul 28, 2015
2,495
571
136
The right thing to do, would be to drive Vulkan development on OpenSceneGraph. But that wouldn't allow for anti-competitive hijinks.
 

Elixer

Lifer
May 7, 2002
10,371
762
126
https://mygtc.gputechconf.com/events/37/schedules/3682

Who wants to bet that it "simplifies" things in a way that hurts AMD?

Well, it can add significant cost depending on the usage pattern (they say that themselves), for basically reference counting, and some other extra things. It really isn't anything that special here skimming the code.
Vulkan-Hpp is what most everyone is still using.

https://github.com/nvpro-pipeline/VkHLF
VkHLF is an experimental high level abstraction library on top of Vulkan. It adds features like transparent suballocation, resource tracking on the CPU & GPU and simplified resource creation while staying as close as possible to the original Vulkan API. In contrast to Vulkan-Hpp, which was carefully designed to be a zero-overhead C++ abstraction for Vulkan, this library adds significant higher-level functionality. Even so, it has been designed for high-performance, but it can cost performance relative to native Vulkan if not employed with the intended usage patterns.

Since this project is in its early stages and under heavy development expect bugs and interface changes for a while. It should not be used for production code yet!
 
Status
Not open for further replies.