CUDA support detection

[yajo]

A system with an NVIDIA GPU card with CUDA capabilities shows this:

$ nvidia-settings -q CUDACores -t
2048

You can also get the CUDA version with nvidia-smi -q.

It would be nice to include that in reports. For example, you could enable CUDA automatically (or behind some option that allows facter enabling stuff that will cause mass rebuilds).

@moduon MT-9339

[clotodex]

Philosophical question on this: is this a (nixos) module problem or a report generation problem. Where should this info live?

My thinking is about the whole version hell of nvidia generally. I dont know exactly what makes what dependent on what but I feel like the report should just give the most simple base information where other things can be derived from in a module so it will give us flexibility down the line.
I.e. I would need the report to spit out exactly what GPU is connected how and where in the system.
But all the configuration tail of

• what version of drivers does this gpu support
• what cuda version does this support (which is in turn a function of the driver!!)
• what incompatibilities or known issues this specific gpu might have etc

I feel like if we have all of this supported in the report there would be at least two things hard to maintain:

• up to date information on the gpu - i.e if we learn something new about incompatibilities etc - this would need to update then in the facter output - even though you still have the exact same gpu
• potential new features (like cuda), e.g. its datacenter networking capabilities, etc would all also need to be in the report, even though this could be managed by a graphics-networking module or sth

On the other hand just knowing what a gpu can do, and not having to defer it from the exact model has the benefit of being able to support future models without much code changes i guess (this might be a gamble though).

Is there any line drawn in the sand already on what should be in a report and what should not? @brianmcgee

[yajo]

the report should just give the most simple base information

Isn't it the opposite? The report should be as detailed as possible. We want modules that react to facts. So, the more facts we gather, the better, right?

Regarding the scope of the modules, I think that discussion belongs to nix-community/nixos-facter-modules#72. In this repo we're only talking about gathering information, not about what to do with it.

[brianmcgee]

The approach is to gather as much interesting information as we can about a machine. We only remove info from the report if it could be considered sensitive or if it is likely to change between restarts (#207).

We want to allow module authors as much flexibility as possible later on, whilst presuming as little as possible. .

[clotodex]

Makes sense.
How does it work with "dynamic" information then?
I.e. is it possible to discover cuda capabilities statically? Or is that itself dependent on the newest cuda versions and their compatibility with your card. This is the thing I meant - I am unsure - specifically with nvidia - what is static, dynamic, should be inferred, or impossible to gather. I don't mind much either way, just tried to understand where what goes :)

[yajo]

To help you understand:

• static: the JSON file contents.
• dynamic: the tool that generates the JSON file.