-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The octree tests get stuck in the Jetson Xavier and RTX 20xx GPUs #105
Comments
The octree code has a couple of issues on new CUDA hardware. I will try to test on our own Jetson Xavier device. When you don't get any error message, this is probably related to incorrect octree load-balancing. If you don't need the octrees, my recommendation would be to ignore those tests for the moment. One way to disable specific tests:
Do the remaining tests succeed? |
Now it finishes, but it returns an error TestOutput.txt I also have this issue in my tests with the method insertBoxIntoMap, this work with octrees as well right? and with new CUDA hardware do you also mean the GeForce 20 series? |
Thanks for the error log.
Do you have write access to your current working directory when you run the tests? The test tries to write a temporary file there (and also a
Which type of map are you calling |
I found inflated octree runtimes even back to compute capability 5.x (e.g. GTX 980) GPUs as well as 6.x ones. The new 2080 and similar 7.x GPUs are probably also affected. We have an ongoing bug hunt for these random runtime variations in octrees. Let me know if you also encounter this outside of the Xavier platform. |
Ah yes, thanks. Now there is no error in the test.
The map is MT_BITVECTOR_OCTREE. I tried with a probabilistic VoxelMap and everything works, thanks a lot.
Ok, until now I can tell you that it works in a:
|
The Jetson Xavier has compute capability 7.2, and should not require changes to maxrregcount. I could confirm the octree issues with all the octree tests on our Jetson Xavier board (Capability 7.2) and GeForce RTX 2080 Super (Capability 7.5). For these two platforms octrees appear to be unusable at the moment, much worse than for 5.x and 6.x devices. I will try to find a solution to this as quickly as possible. |
I also tried to use the library on a Jetson Xavier with CUDA Version 10.0 and Ubuntu 18.04.4 LTS. When I ran test_gpu_voxels_core, it also got stuck at:
If I outline the octree with
it finishes successfully. My actual intention is to load a PointCloud from a camera into an environment map. This works great when I use a MT_PROBAB_VOXELMAP with the Thank you very much in advance for your answer. |
Hi @kire93, unfortunately I was not yet able to fix this. The problem is caused by octree-related code written for much older CUDA architectures, with assumptions about warp scheduling and synchronization that are not valid any more on new hardware. Therefore fixing the buggy behavior you see involves rewriting at least part of the octree load balancing internals. As a stopgap measure I will replace the faulty tests and functions with a log message on affected hardware, which should save everyone a lot of time. On the positive side, the octree code base will be quite a bit smaller and run faster when the rewrite is done... |
Hi @cjue, thank you very much for your quick and detailed response. I am glad to hear that you are still working on the problem and I will follow your solution with great interest. |
I tried to use the library in the Jetson Xavier, but the test test_gpu_voxels_core is getting stuck at the begging when it prints this:
My setup is exactly this one:
I tried to change the line with the number 31 as is written there but nothing happened. In both cases, with 63 and 31, everything compiles without problems, but when I launch this test it doesn't work.
Any clue about this?
The text was updated successfully, but these errors were encountered: