search

jp7677 / dxvk-nvapi

Alternative NVAPI implementation on top of DXVK.
MIT License
353 stars 32 forks source link

Add low hanging NVML 515 fruits #94

Closed jp7677 closed 1 year ago

jp7677 commented 2 years ago

As a follow up to https://github.com/jp7677/dxvk-nvapi/pull/89

There are a few more low hanging fruits which can be implemented using new functions:

Implementation for all three should be pretty identical.

Saancreed commented 2 years ago

Out of curiosity, are you aware of any applications actually calling any of the 2 remaining functions?

NvAPI_GPU_GetCurrentPCIEDownstreamWidth using nvmlDeviceGetCurrPcieLinkWidth

This always returns 8 for me on both Windows and Linux, which kind of makes sense for an Optimus laptop.

NvAPI_GPU_GetIRQ using nvmlDeviceGetIrqNum

While I was testing this one in my Windows VM using GPU passthrough, I've noticed that, while the returned interrupt number is the same for both, it's also equal to 0 which is obviously incorrect. On the other hand, nvmlDeviceGetIrqNum does return valid numbers like 73 when called on Linux host so this is probably just some virtualization weirdness.

Makes me wonder what sort of stuff would applications want to do with this number :thinking:

jp7677 commented 2 years ago

I'm pretty certain that adding those two methods makes no difference at all in reality for the applications/games that are used with DXVK-NVAPI. There are games querying that info (I think Batman Arkham Knight was one of them), but don't ask me why. My guess would be solemnly for reporting or usage statistics. Tools like GPUCapsViewer do query those and a lot more, but running tools like this in Wine isn't a real use case if you ask me. I remember that DAZ-Studio queries PCIe-Link-With, but having it not implemented wasn't an issue, so it didn't ended up being implemented.

I've created this issue mostly to have the info from the PR slightly more prominent here. May be it would look cool to show this info in the nvapi64-tests output to compare with the NVIDIA control panel... :)

SveSop commented 1 year ago

I think the reason stuff like that is being called in various instances (outside when using diagnostics software like GPUCapsViewer or similar) is that game dev's uses some "nvapi runtime api" thing from NVIDIA. Eg. some UE engine games calls loads of completely unneeded stuff when launching a game.

My theory is that the companies buys some pre-built .dll from NVIDIA that does this call as a "data dump", and then its up to the game devs to make use of whatever they need. It is all a theory, but from my longtime battle with nvcuda runtime api, it is imo likely that whatever thing they (game comps) buy have some sort of "gather info" function to them.

Eg. DLL call: nvapiGetGpuInfo And then you can get various info in a table like nvapiGetGpuInfo->AvailableVram and so on (and this runtime api would query "broadly" for data).

As i said - just a theory, but i find it unlikely that game devs actually write calls for something they absolutely will never need, and since they (NVIDIA) obviously push using nvcuda runtime api on various apps do exactly stuff like that it might aswell be some nvapi runtime api blob the game companies buy to be able to use nvidia settings/optimization for games.