unique: Designing a safe buffer writing API is hard#96
unique: Designing a safe buffer writing API is hard#96Firestar99 wants to merge 3 commits intomainfrom
Conversation
|
I really like this topic (data-race-free access) and I see the way you're trying to approach it "bottom-up" from initially guaranteed unique values, proven using the type system. It's a shame you found a flaw in this, but I think some ingredients from this idea will still be useful. As I said on the other thread, I was inspired by |
|
My concern is that a rayon-like API is better suited at a graphics API level on top of wgpu / vulkan, so I'm not quite sure what you want to do. Always feel free to PR stuff (or to send links to commits) |
|
Ah, I haven't seen enough graphics code to propose something there. I can do more research on that. OK. I think it would help if I wrote up a post and some examples I was thinking of for compute. Until then, I was inspired by some existing NVIDIA on-GPU utility libraries for CUDA C++. I assume they are mainly for compute applications, but I suspect some modern non-fixed function graphics may also use them too. It would be great for CUB (docs) seems like the leading option. Under "API documentation" they have utilities that work at sub-group (CUDA warp), workgroup (CUDA block), and device levels of abstraction. The algorithms available are classic parallel collection primitives: load, shuffle, store, merge, sort, reduce, scan, histogram, etc.
Thrust (docs) seems older, supports multiple backends (several on CPU, or CUDA), has similar algorithms to CUB. cuCollections (docs) has a few data structures -- various hash tables, some bitmaps -- but seems young and less capable for now. |
Blog link: https://github.com/Rust-GPU/rust-gpu.github.io/blob/unique_index/blog/2026-02-23-safe-buffer-writing.mdx
I just wanted to dump this out of my head, may make for a decent blog post.
May need some more refining towards the end too.