You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems that ResizableBar simply doesn't work on NVIDIA GPUs. On my PC with Intel i9 10850k and RTX3060Ti, NVIDIA exposes DEVICE_LOCAL_BIT | HOST_VISIBLE_BIT | HOST_COHERENT_BIT on a 8G device local memory heap. Allocation and memcpy into this memory type is fine, but if ray tracing workload is running simultaneously, there is a 50% chance that the screen would freeze for a few seconds during startup when assets were copied into video memory with Rust's copy_from_slice. vkWaitForFences subsequently returns VK_ERROR_DEVICE_LOST. The fault seems to happens during memcpy.
To reproduce, run the castle example with debug settings. When using release, things happen so fast that the scene would be loaded into memory before the first frame shows up on the screen.
The workaround at the moment is that we disable ResizableBar entirely on NVIDIA GPUs. The codepath involving ResizableBar would therefore only apply to AMD discrete GPUs. (Intel discrete GPUs only expose 256MB of device-local, host visible memory at the moment)
The text was updated successfully, but these errors were encountered:
It seems that ResizableBar simply doesn't work on NVIDIA GPUs. On my PC with Intel i9 10850k and RTX3060Ti, NVIDIA exposes
DEVICE_LOCAL_BIT | HOST_VISIBLE_BIT | HOST_COHERENT_BIT
on a 8G device local memory heap. Allocation and memcpy into this memory type is fine, but if ray tracing workload is running simultaneously, there is a 50% chance that the screen would freeze for a few seconds during startup when assets were copied into video memory with Rust'scopy_from_slice
.vkWaitForFences
subsequently returnsVK_ERROR_DEVICE_LOST
. The fault seems to happens during memcpy.To reproduce, run the castle example with debug settings. When using release, things happen so fast that the scene would be loaded into memory before the first frame shows up on the screen.
The workaround at the moment is that we disable ResizableBar entirely on NVIDIA GPUs. The codepath involving ResizableBar would therefore only apply to AMD discrete GPUs. (Intel discrete GPUs only expose 256MB of device-local, host visible memory at the moment)
The text was updated successfully, but these errors were encountered: