In our offline discussion earlier, we were trying to establish if the smi python bindings were being used in downstream projects like NVDashboard, dask/distributed, and dask-CUDA. As far as I can tell, these three projects are using the nvml bindings directly (not smi).
Those familiar with nvml usage in dask-CUDA and dask dashboard (@jacobtomlinson , @pentschev, @quasiben, @charlesbluca), pease do correct me if I am mistaken here.
The smi bindings are awesome to have, but if they are not a requirement for these projects, we can treat smi-feature completeness as a "nice-to-have" priority for now. With that said, it is clear that NVDashboard and Dask-Dashboard should use the same handle-caching approach you are using in smi (it seems that both dashboard projects are currently defining fresh device handles for every query)
Thanks @kenhester!
In our offline discussion earlier, we were trying to establish if the smi python bindings were being used in downstream projects like NVDashboard, dask/distributed, and dask-CUDA. As far as I can tell, these three projects are using the nvml bindings directly (not smi).
Those familiar with nvml usage in dask-CUDA and dask dashboard (@jacobtomlinson , @pentschev, @quasiben, @charlesbluca), pease do correct me if I am mistaken here.
The smi bindings are awesome to have, but if they are not a requirement for these projects, we can treat smi-feature completeness as a "nice-to-have" priority for now. With that said, it is clear that NVDashboard and Dask-Dashboard should use the same handle-caching approach you are using in smi (it seems that both dashboard projects are currently defining fresh device handles for every query)