Patrick Stotko

For reference, #351 tracks all affected functions which currently do not have proper support for custom `execution_policy`s such as `thrust::device.on(stream)`.

Thanks for further testing. I still believe that the issue is related to the default stream. Just to make sure, could be try calling another kernel on the default stream...

I have reproduced your observations. In fact, there are two issues: 1. The legacy default stream forces a strict order on the execution of the kernels and performs implicit (weak)...

If you are only concerned about the CPU blocking part and the stream ordering behavior is acceptable, then a workaround could be to create the `unordered_map` object in a different...

Author of stdgpu here. This has been fixed upstream in https://github.com/stotko/stdgpu/pull/408, so updating the dependency in Open3D should fix it there as well.

> Sadly with the last stdgpu version Open3D seems to be incompatible. It shows errors like: > > ``` > #13 247.4 /opt/Open3D/build/stdgpu/include/stdgpu/impl/unordered_base_detail.cuh(1230): error: a value of type "cuda::std::__4::pair *"...

I can reproduce these compilation errors on Ubuntu 22.04 + CUDA 12.5 + latest commit from master branch. Furthermore, only the CUDA backend seems to be affected and, more precisely,...

Using nvcc instead of g++ (or any other supported host compiler) would workaround the problem, but this is not the root cause of this issue. `iterator.cpp` is actually designed to...

Thanks for your interest in stdgpu! Supporting more container types would definitely be appreciated. Regarding `list` and `forward_list`, getting their design on the GPU right, however, seems not trivial. One...

Most of the functionality should support custom CUDA streams by taking a respective `execution_policy` which wraps the stream, see #351. Part of the `memory` API is one notable exception though,...