Every article tag can be clicked to get a list of all articles in that category. Every article tag also has an RSS feed! You can customize an RSS feed too!
We do often include affiliate links to earn us some pennies. See more here.

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

By - | Views: 24,360

With the absolutely huge NVIDIA 470 driver release now out the door, NVIDIA has just put up a fresh release of their open source NVAPI interface.

For those who haven't seen us report on it previously here's what it is: "NVAPI is NVIDIA Corporation's core software development kit that allows access to NVIDIA GPUs and drivers on all Windows platforms. NVAPI provides support for categories of operations that range beyond the scope of those found in familiar graphics APIs such as DirectX and OpenGL."

What's the use for Linux? NVIDIA say the version of nvapi.h that's now under the MIT license helps to enable "open source re-implementations of NVAPI for Windows emulation environments". The updated release adds in lots more Functions, Enums and Structures for developers to use. For us normal users, it doesn't mean too much but for developers (on projects like Wine, Proton, DXVK, VKD3D-Proton and so on) it can help get more features hooked up for running Windows games on Linux with compatibility layers.

Nice to see NVIDIA continuing to make steps to help Linux in various ways.

The new release can be downloaded here.

Article taken from GamingOnLinux.com.
15 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
10 comments

rustybroomhandle Jul 2, 2021
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.
Ehvis Jul 2, 2021
View PC info
  • Supporter Plus
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.
jens Jul 2, 2021
  • Supporter
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 :)
CatKiller Jul 2, 2021
View PC info
  • Supporter Plus
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.
jens Jul 2, 2021
  • Supporter
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?
CatKiller Jul 2, 2021
View PC info
  • Supporter Plus
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.
jens Jul 2, 2021
  • Supporter
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.
Valck Jul 16, 2021
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.
davidcantum Nov 17, 2021
Does this new NVAPI interface work on linux???
jens Nov 18, 2021
  • Supporter
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.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.