vulkano: Radv leading to panicked main thread in triangle example
Running the triangle example code gives me:
WARNING: radv is not a conformant vulkan implementation, testing use only. Using device: AMD RADV POLARIS10 (type: DiscreteGpu) thread 'main' panicked at 'called Result::unwrap()on anErrvalue: Timeout', /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libcore/result.rs:837 note: Run withRUST_BACKTRACE=1for a backtrace.
I am not sure whether this is a RADV bug or one I could fix. Any ideas here? Will you test with Mesa/Radv as well?
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 19 (9 by maintainers)
Ah, so I can stop the hang by either switching to FIFO presentation, or setting the timeout to
u64::max_value(). Using a finite timeout seems to result in some sort of deadlock in radv. I’m not sure if there’s something else we’re doing wrong, but I can reproduce it in my C program, so I’m leaning toward a bug in radv.I’m also using radv, and have this problem with the triangle/teapot example. You can match on the error instead of unwrapping (as well as handle recreating the swapchain):
However, this leads to a different panic:
It looks like in https://github.com/tomaka/vulkano/blob/master/vulkano/src/swapchain/swapchain.rs :285 a semaphore is removed form the pool, but never put back in if acquiring the image fails for any reason.
I don’t know if this is a proper solution, but for messing around on amdgpu+radv, the semaphore can just be put back in: