NVIDIA puts out a new release of their open source NVAPI interface

While it's nice of them to make this stuff open source, it's probably not tech that anyone should be using, since it's hardware specific and serves as a vector to lock-in.

Quoting: rustybroomhandleWhile it's nice of them to make this stuff open source, it's probably not tech that anyone should be using, since it's hardware specific and serves as a vector to lock-in.

Maybe, but it's already used on Windows, so it's definitely something good for Wine. Even implementing the functionality separately would be a possibility (although not necessarily useful). And then make it run on AMD would at least be hilarious.

Quoting: Ehvis

Quoting: rustybroomhandleWhile it's nice of them to make this stuff open source, it's probably not tech that anyone should be using, since it's hardware specific and serves as a vector to lock-in.

Maybe, but it's already used on Windows, so it's definitely something good for Wine. Even implementing the functionality separately would be a possibility (although not necessarily useful). And then make it run on AMD would at least be hilarious.

Well, those are header files to build an alternative implementation of NVIDIA's own nvapi library. The library surface is huge, Nvidia put everything in it from display configuration to Direct3D extension plus it grew heavily of the years. Fortunately lots of games use only a small subset or even just a few methods. So it is absolutely doable to create an nvapi compatible library which provides some usefulness, even for AMD cards. In fact, I did exactly that :)

A lot of the stuff that's in NVAPI, which people have been using and wasn't included in OpenGL or DirectX, is in scope for Vulkan. Things like device discovery and capability enumeration. With Nvidia being more open about it, especially if there are alternative implementations, there might be room to start having those functions as part of Vulkan for everyone to use. Maybe as Nvidia extensions, or maybe add as part of the core specification.

Quoting: CatKillerA lot of the stuff that's in NVAPI, which people have been using and wasn't included in OpenGL or DirectX, is in scope for Vulkan. Things like device discovery and capability enumeration.

Do you have a specific example?

Quoting: jensDo you have a specific example?

Not a specific example, I'm just going from the description from here

QuoteSome of the features that programmers can access using NVAPI include:

Driver Management: Initialization and driver version controls.
GPU Management: Enumeration of physical and logical GPUs. Thermal and Cooling controls.
Display Management: Enumeration of NVDIA displays, display postion and timings controls.
System Management: Ability to query chipset and system specific information.
Connecting and Configuring Monitors: Ability to set views on multiple target monitors.

and the stuff on assigning handles for GPUs and the like.

Maybe the thermal management stuff is too hardware specific, but being able to find GPUs and what they can do, how to address them, how to allocate memory, and things like that, are things that Vulkan covers. Being able to map those functions from NVAPI, that people are already using, to Vulkan, that people might want to use in the future, seems like it might be handy. There may well be other functions in there that Vulkan could do, but doesn't yet do, that would just be a good idea. NVAPI seems to me like Nvidia's grab-bag of handy things that they couldn't get done another way (pre-Vulkan) and Vulkan so far has worked well as a means of standardising everyone's good ideas so that more people can benefit.

I have no idea if Nvidia, Khronos, or anyone else, would actually do it, but it seems to me to be something that could be done.

Quoting: CatKiller

Quoting: jensDo you have a specific example?

Not a specific example, I'm just going from the description from here

QuoteSome of the features that programmers can access using NVAPI include:

Driver Management: Initialization and driver version controls.
GPU Management: Enumeration of physical and logical GPUs. Thermal and Cooling controls.
Display Management: Enumeration of NVDIA displays, display postion and timings controls.
System Management: Ability to query chipset and system specific information.
Connecting and Configuring Monitors: Ability to set views on multiple target monitors.

and the stuff on assigning handles for GPUs and the like.

Maybe the thermal management stuff is too hardware specific, but being able to find GPUs and what they can do, how to address them, how to allocate memory, and things like that, are things that Vulkan covers. Being able to map those functions from NVAPI, that people are already using, to Vulkan, that people might want to use in the future, seems like it might be handy. There may well be other functions in there that Vulkan could do, but doesn't yet do, that would just be a good idea. NVAPI seems to me like Nvidia's grab-bag of handy things that they couldn't get done another way (pre-Vulkan) and Vulkan so far has worked well as a means of standardising everyone's good ideas so that more people can benefit.

I have no idea if Nvidia, Khronos, or anyone else, would actually do it, but it seems to me to be something that could be done.

Thanks for your response. As far as I know, the Nvidia Vulkan driver implements all things that Vulkan specifies for GPU and capability discovery. Other things like memory management are up the application developer when programming against Vulkan. Not sure if display management and thermal stuff should become part of it. It doesn't really fit into a graphics API and it is indeed either vendor specific or platform specific (or both). To be honest, I think all that sysinfo stuff should stay in vendor controls panels and as far as possible in the background. Game developers should possibly stay away of that and focus more on the renderers itself ;).

PS: The Nvidia drivers for Linux ships NVML (https://developer.nvidia.com/nvidia-management-library-nvml), some of the NVAPI methods for querying temperature etc can be mapped to that library.

So what was the big news here? Of course you want to "open source" an API if you want others to make use of your stuff.

This is literally three header files (ie. long lists of variable name definition) and one C source file that implements a couple of helper functions.
No revolutionary insights into Nvidia's secret source or anything, just stuff to help you access their stuff so they can sell more of it. Which is fine, of course, they're a business after all. Just that it isn't newsworthy at all in my opinion – news about the corresponding driver release was, on the other hand.

It's a bit like saying "The supermarket got a new delivery of toilet paper" in one news item, and this here being the belated corresponding "Oh and by the way, you have to pay for it too", which is both obvious and implicit.
Maybe I just don't like corporations making headlines for the sake of making headlines.

Does this new NVAPI interface work on linux???

Those released header files are just a bunch of source code files useful for developers. They can be used to create a library that is compatible with NVIDIAs own implementation but somebody has to develop it first.
There is the DXVK-NVAPI project on GitHub that uses those interfaces to create a library which is supposed to be used with Wine/Proton like DXVK and friends.