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
There are times, such as when computing one off jobs on the gpu, you need to run something on the next frame once.
For example: In the PR #159 there is a method to copy textures from the GPU to the cpu. For this to work we need to enqueue a command to the gpu and wait for the next frame cycle so that it is completed.
As another example, we could compute bounding boxes on the gpu and then copy them back to the cpu next frame for collision or raycasting analysis.
This is a tracking issue to discuss how should we implement it.
The text was updated successfully, but these errors were encountered:
Async method that allows us to await a frame change, have some std::future::Future object that completes once a frame has incremented
Make cycle could an Arc<AtomicU32> and expose methods to share it. This could be abusable if them modify it.
Make systems cancel-able in some way. For example if a system returns STOP then we remove it. This way the user can enqueue a system do what every they need like check cycle count and act on it and remove when done.
There are times, such as when computing one off jobs on the gpu, you need to run something on the next frame once.
For example: In the PR #159 there is a method to copy textures from the GPU to the cpu. For this to work we need to enqueue a command to the gpu and wait for the next frame cycle so that it is completed.
As another example, we could compute bounding boxes on the gpu and then copy them back to the cpu next frame for collision or raycasting analysis.
This is a tracking issue to discuss how should we implement it.
The text was updated successfully, but these errors were encountered: