Looks like Wizz has already implemented it:
On NVIDIA GeForce RTX 5090/5080/5070 Ti with no driver installed, report the ROP count as “Unknown” instead of using a hardcoded fallback
That’s from the changelog from just released version 2.64.
Very useful indeed.
Like I said, I’ve tried that already. nvapi_QueryInterface(0xfdc129fa) returns nullptr on Linux.
My understanding of things is that the string name doesn’t matter at all. The low-level dynamic library shipped with the driver only provides the nvapi_QueryInterface symbol. All the other functions only have numeric IDs and have to be queried through nvapi_QueryInterface.
Now, the higher-level static library that developers link against is a different story. It contains wrappers for all the functions and they have symbolic names. Internally, these wrappers just load the low-level dynamic library and use nvapi_QueryInterface to get the function address. The static library becomes part of the application and the symbolic names get lost. You can search the GPU-Z excutable (after un-UPX-ing it) for nvapi and all you’ll find is nvapi_QueryInterface.
The public static library (for Windows, there’s none for Linux) can be found here: nvapi/amd64/nvapi64.lib at main · NVIDIA/nvapi · GitHub
But it does seem to be missing wrappers for private functions like the ROP count getter. I’m assuming only developers under NDA get the full version. So, unless I’m missing something, NvAPI_GPU_GetROPCount and NvAPI_GPU_GetRasterBackendCount are just guesses by different reverse-engineers and they could only know the real name from material behind NDA.
I have a feeling they aren’t capable of understanding the function name is almost meaningless.
Obviously we do not, because we are idiots and you are amazingly intelligent. Feeling better now?
Thank you @Miro256. It makes sense. We are out of luck, notably there is not even certainty that this value is even accessible via the Linux API. Only nvidia engineers could help here, but they have not commented here.
Btw, does any one of the private fct addresses return something (in Linux)? Or all return null pointer? In other word, are these fct adresses windows only, or are they only partially supported/implemented on Linux?
Yes, going by the NVApiWrapper table, 80 / 354 of the private ones are available on Linux (570.86.16 driver). Whether they actually work, I don’t know.
…those aren’t function addresses.
This is generally a COM style interface, probably a compatibility remnant from before the beginning of time ;-)
That’s a long, rambling post about absolutely nothing, other than you venting your half-baked ideas about the rest of the world.
could we please please not re-flame this unnecessary drama? This is supposed to be a technical discussion about getting ROP count in Linux: if you think something is out of place, then just flag it instead of adding to it. Thanks!
I ended up on this post because after hearing about the ROP case with the 5090, I was hoping that on Linux I would find something that would tell me for example similar information as
Mainly stuff like
My reasoning is that, if by luck gpu-z was the only on Windows that showed this problem, could this have happened on previous cards, or other properties for the card and is there a way to always be able to transparently test this without having a just by luck moment like what happened with gpu-z with the 5090 and someone noticing that.
Took me 2 days testing stuff to see (not even cuda, nvtop or even clinfo game me the information), then I see this post.
I am mainly researching to see if there is any way of knowing if a card we are using on Linux, offers the ability to audit the card and see that the properties and hardware that is expecting to be there, will be there basically.
Can check some things with nvapi.
Native Linux
But as already mentioned there are missing calls such as the UEFI Driver version call above which works in the Windows version of the same program. At least overclocking works well.
For ROP maybe ask at envytools on github if it can be read using BAR0 but this will mean elevated privileges.
So I found out the kernel module supports reporting the ROP count: open-gpu-kernel-modules/src/common/sdk/nvidia/inc/ctrl/ctrl2080/ctrl2080gr.h at 25bef4626e6c5ccf5b433e1c22b6b1bd59e6f1bd · NVIDIA/open-gpu-kernel-modules · GitHub
I wrote a little program to get it and it seems to work on my machine:
rop.txt (6.7 KB)
Rename to rop.c (the forum does not allow .c extensions 🙄), then compile with gcc or clang and run (without arguments).
The output should look something like this:
ROP unit count: 12
ROP operations factor: 8
ROP operations count: 96
I suspect the last number is what NVAPI/GPU-Z reports (unit count * 8).
oh man! how on earth have you found it? grepping for ‘rop’ across the sources?
Now let us all contemplate how much less time we would have lost, if some nice Nvidia eng had given us this link 10 days ago… how awesome would that have been? LOLz… ;-]
Ladies and gentlemen, with great sadness and regret, I must announce that the god ChatGPT has failed us. Hindsight 20/20 we should have searched publicly released official material(or, in birdie’s case, illegally downloaded) but that required effort and skills far beyond entering a prompt into a text box, so it wasn’t done for checks notes 10 days.
Thankfully there are skilled individuals like miro256 who walk among us.
Many thanks @Miro256, I confirm it works on my 5090 (and 4060Ti), here’s the 5090 output:
gcc rop.c -o rop
./rop
ROP unit count: 22
ROP operations factor: 8
ROP operations count: 176
This is fantastic, thank you @Miro256. At least, contrary to some trolls here, who are just big mouth but contributed nothing except unnecessary flamng, you found a solution.
My output is:
./rop
ROP unit count: 14
ROP operations factor: 8
ROP operations count: 112
All good.
There are a lot of useful functions returning stats there. Could be of interest to the author of CPU-X, I will contact him.