You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The UUID related calls return a fixed sized array. It might make sense to return arrays of those instead of vectors.
I don't have a strong opinion on that, I just thought I bring it up, while I'm working with those function calls. In my code, where I use the uuid_khr(), I convert it into an array, so I thought It would be nice if it was already an array.
The text was updated successfully, but these errors were encountered:
Related to this (let me know if I should open a separate issue). It would be great if cl3::ffi::cl_ext::CL_UUID_SIZE_KHR could be re-exported into opencl3, so that I can create such a fixed sized array without importing cl3.
Hi Volker, my opinion on the UUID related calls is that they are just defined in an extension at the moment and it's possible to access the data using the device functions as you have done.
It may be nice to convert UUIDs to arrays now. However, it may be even nicer to convert them into UUIDs from the uuid crate. Or, in the future, when 128 bit integers are likely to be available in rust it wouldn't be so nice. So I'd rather not make that change at the moment.
I'm happy for cl3::ffi::cl_ext::CL_UUID_SIZE_KHR to be into opencl3. Would you like to submit a PR?
The UUID related calls return a fixed sized array. It might make sense to return arrays of those instead of vectors.
I don't have a strong opinion on that, I just thought I bring it up, while I'm working with those function calls. In my code, where I use the
uuid_khr()
, I convert it into an array, so I thought It would be nice if it was already an array.The text was updated successfully, but these errors were encountered: