Open BlueGoliath opened 2 years ago
Both Pascal and Maxwell are unsupported by the GSP firmware. The only thing that appears to be needed here is to document the possible NVML_ERROR_NOT_SUPPORTED return value on unsupported hardware.
The standard way of dealing with different behaviors is defining a new function version. See here:
For example, the symbol for nvmlDeviceGetGraphicsRunningProcesses_v2 exists in the library still despite being replaced by nvmlDeviceGetGraphicsRunningProcesses_v3.
Unrelated side note: just came across functions I haven't seen until now. Nerd sniped myself.
Edit: ...because Nvidia just introduced them in 515. Duh me. @aritger Big thanks to you or whoever made these NVML additions. They are massive!
How to enable GSP on Windows 11?
@ValeZAA: The NVIDIA Windows GPU driver does not currently make use of GSP.
How is this completed? None of the issues were fixed.
Blech; sorry. The buttons are right next to each other...
In 510.68.02, a function was introduced called nvmlDeviceGetGspFirmwareMode. This function has three issues with it:
On Linux, it will fill both pointers with zero(false) even on Pascal when it should instead return NVML_ERROR_NOT_SUPPORTED. This is different to what the previous GSP NVML function, nvmlDeviceGetGspFirmwareVersion does and gives users the impression that their GPU has GSP firmware when it does not.
On Windows with a Maxwell based GPU, nvmlDeviceGetGspFirmwareMode seems to always return NVML_ERROR_NOT_SUPPORTED, which is different than on Linux and Pascal. If you can't already, it should be possible to get the firmware version even on Windows.
NVML_ERROR_NOT_SUPPORTED is returned despite not being documented.
Given that this new kernel driver requires GSP, making sure that it's possible to get reliable information as to whether their GPU has GSP firmware is important. A nvmlDeviceGetGspFirmwareMode_v2 function should be introduced and the old function deprecated to fix these problems.