Closed
Description
Similar to #205 but for Device
properties. Currently we return all of them at once, with the C enumerator names as the keys
cuda-python/cuda_core/cuda/core/experimental/_device.py
Lines 82 to 85 in 213baf4
We should perhaps make the returned object a Python class instead of dict, with nice, pythonic attributes.
Activity
leofang commentedon Nov 1, 2024
xref: our C++ counterpart (
cudax
) NVIDIA/cccl#2084ksimpson-work commentedon Jan 18, 2025
Piotr suggested we base the exposure on cudaDeviceAttribtues rather than cudaDeviceProperties to reduce the minor version compatibility considerations. WDYT @leofang
leofang commentedon Jan 18, 2025
Inside you
DeviceProperties
class we could consider using that. But I don't know how does this help withksimpson-work commentedon Jan 20, 2025
I guess if cuda 13.x.y came out and .y had some great new property we wanted to expose, we would have to wait for 13.z if we used the property struct in the backend, whereas we could expose it right away if we used the attributes. I will look into it and wee what the trade-offs are
leofang commentedon Jan 20, 2025
Yeah followed-up internally, the device prop struct is frozen by major.0, so any new attributes added in major.minor will not be exposed to the prop struct until the next major release, whereas the attribute query API can immediately gain support by the minor release that adds the new attribute. Let's move away from the device prop struct, and query & cache the attributes lazily (on the as-needed basis).