Weird behaviour for long running compute shaders

[BLaZeKiLL]

OS - MacOS 14.2.1 GPU - Apple M1 WGPU - 0.18

I implemented https://raytracing.github.io/books/RayTracingInOneWeekend.html using rust, wgpu, and compute shaders. It works fine, but If I try to do a render with a large scene (like the cover page scene shown in the end) more accurately whenever it takes more than 7 seconds for the program to run. I get an empty image as output.

I assume it's either device timeout or out of memory; I also read somewhere that the OS may reset the GPU if we exceed the default timeout limit.

I have the env logger set to trace and have added the on_uncaptured_error callback, but I don't see any panics or errors logged. How do I find out what the exact issue is here?

One more thing I saw in the wgpu examples was the following comment.

// Poll the device in a blocking manner so that our future resolves. 
// In an actual application, device.poll(...) should 
// be called in an event loop or on another thread.

Currently, I am calling device.poll on the main thread. Could this be the issue? I am not sure how to go about calling device poll on another thread

Source code - https://github.com/BLaZeKiLL/wgpu-app/tree/main/vexray

More specifically, you can look at - https://github.com/BLaZeKiLL/wgpu-app/blob/main/vexray/src/renderer/kernel.rs
where I have my submission and wait for finish code

Also, if I have a simple compute shader that has a divide by zero error when I run the Rust program, I don't get any errors logged or panics; essentially, I am not getting any errors from my compute shaders. Can I do anything to get errors logged from my compute shaders?

[Hneuschmidt]

OS: Linux 5.15.0-1051-kvm x86_64
GPU: NVIDIA Quadro GP100
WGPU: 0.19

I ran into the same issue, in a similar situation.
I am also working on a renderer with a long running compute shader. When the scene gets too big and the shader runs for too long, I get no output (not just in the texture but also not in other buffers),
even though I call pol with Maintain::wait().
It seems to be a timeout issue somehow, because the problem goes away
if I let the polling thread sleep for a sufficiently long amount of time before calling device.poll.

EDIT: For the next person: This is the same issue as #5000 where there is a link to the pull request that should fix this issue.

[cwfitzgerald]

Yup, this is the same problem. I have a partial solution for it on a branch, but unfortunately it caused a bunch of other issues to rear their heads.