Renaming fopen64 to intercept library calls feels like a brittle hack masquerading as "sandboxing." Why not just upstream this hardware support to nvtop instead of fragmenting the ecosystem?
steeve 5 days ago [-]
sadly, sandboxing is something that can't be upstreamed. this way, sandboxing is kept in zml instead of patching mesa.
as for nvtop, great program, but we missed a few features (such as sandboxing)
pstuart 10 hours ago [-]
It looks cool and I was excited to get monitoring for the NPU on my Ryzen AI 395+, unfortunately it does not show. NPU support in linux really seems to be an afterthought.
steeve 10 hours ago [-]
Weird, because we tried it. It doesn’t show anything?
We use the amdsmi to get metrics. I’ll investigate.
marwanet 10 hours ago [-]
If this logic were pushed into nvtop, wouldn't the codebase become unmaintainable? Each vendor's interception method is going to be different.
nareyko 9 hours ago [-]
[dead]
synergy20 3 hours ago [-]
would be nice to have cpu usage added so I have all in one?
currently I use btop which shows basic gpu load along with cpu, network, etc.
imcritic 3 hours ago [-]
Is it capable of exposing metrics in Prometheus format?
nvtop can actually support TPUs too via https://github.com/rdyro/libtpuinfo/ https://github.com/Syllo/nvtop/blob/76890233d759199f50ad3bdb...
as for nvtop, great program, but we missed a few features (such as sandboxing)
We use the amdsmi to get metrics. I’ll investigate.
currently I use btop which shows basic gpu load along with cpu, network, etc.