Thanks for filing this issue. I’m trying to understand a couple things. Are you manually running a CLI directly on Linux, then copying the result file manually to Mac or using a remote connection from Mac that does the copy back automatically?
You mention:
The following ncu commands generate this error but using the ‘roofline’ option works.
/usr/local/cuda-12.2/bin/ncu --set detailed -f -o ncudxtc ./dxtc
But then also say
Using a duff argument also works but obviously will not give the report I would like:
/usr/local/cuda-12.2/bin/ncu --set details -f -o ncudxtc ./dxtc
Is the “details” vs “detailed” in these 2 commands just a typo? What is the difference here that causes one to work and one to fail?
Can you share the output of the CLI profile that runs on Linux?
Hi,
Yes, I am manually running a CLI directly on Linux then manually copying the report file over to the Mac using FTP.
The duff argument in this example is ‘details’, I spelt it incorrectly yet found I still got a ‘valid’ report file generated, i.e., file that the Nsight tool could read and reproduce a (valid?) report.
Yet using the -set options listed by the ncu --help produce the error “could not read the report”, except except ‘roofline’.
Hi, yes version Nsight for mac released 8/29/2023 v2023.2 update 2 is good. The different reports are read ok.
If the (Mac) Nsight tool is sensitive to which linux ncu version is used to generate the profiling reports it can open and read, perhaps it would be good to have the Nsight tool report it cannot read that version. Then have it explain what it can read and so allowing the user to correct the tool’s version alignment with other correct versions required. Just saying it cannot read a file is not very helpful :-)
Anyway, thank you for your help. It is appreciated.