KhronosGroup / KhronosGroup/Vulkan-Docs
Lost devices makes it hard to write robust programs
- Dominant language
- JavaScript
- Stars
- 3.3k
- Forks
- 549
- Avg merge
- 5d 5h
- Merged PRs (30d)
- 2
Description
Imagine a program that wants to perform some GPGPU operation:
- The program submits a command buffer that executes a compute shader.
- This compute shader writes data to a mapped buffer.
- The program waits for the fence.
- The program reads the content of the buffer and processes it.
According to the "Lost Device" section of the specifications, the device can become lost at any time and will cause some commands to return a `VK_ERROR_DEVICE_LOST` error.
This means that in the situation above the device can become lost while the buffer is being read by the program, even when waiting for the fence previously returned `VK_SUCCESS`.
Since the content of mapped memory becomes undefined (presumably instantly) when a device is lost, and since a device can become lost at any time, you can never know whether the data you are reading from a buffer is valid or not.
Right now if a program wants to be sure that their data is valid, they have to submit some dummy work and check whether the call to `vkQueueSubmit` returns `VK_ERROR_DEVICE_LOST`.
I guess we could agree that it's a bit stupid to have to have to do so.
I feel like either there should be a function to check the device's status without having to submit something, or even better change device lost errors (eg. by making it possible for `InvalidateMappedMemoryRanges` to return a device lost error, and by removing the fact that data becomes undefined).
Contributor guide
Assessment
This issue has not been assessed yet.