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
Apart from inline join points, fences can't escape the scope they were created in. This is a problem for interacting with external wgpu code, which must create its own fence after the caiman code has run and sync later than might be necessary. It also means that some very reasonable cpu <-> gpu scheduling patterns will have more aggressive synchronization. Synchronization between frames on only part of a frame's submissions in a renderer won't be possible, for example.
This issue occurs because fences need to be represented as a pinned box in Rust when crossing the function boundary, so they need to be converted from the local impl Trait either at creation time or later. The latest wgpu has a different method of handling synchronization, so that's yet more headache. Theoretically, we could resolve this by creating fences in a cpu buffer handed from the calling context. Another slight wrinkle is that fences, in the caiman core language, are effectively treated as memoryless abstract objects. It's a useful simplification, but predictably a flawed one.
I'm inclined to ignore this for as long as possible because I don't care enough about wgpu to want to build a tailor-made solution. The problem is that it might be necessary depending on what examples we need to write.
The text was updated successfully, but these errors were encountered:
Apart from inline join points, fences can't escape the scope they were created in. This is a problem for interacting with external wgpu code, which must create its own fence after the caiman code has run and sync later than might be necessary. It also means that some very reasonable cpu <-> gpu scheduling patterns will have more aggressive synchronization. Synchronization between frames on only part of a frame's submissions in a renderer won't be possible, for example.
This issue occurs because fences need to be represented as a pinned box in Rust when crossing the function boundary, so they need to be converted from the local impl Trait either at creation time or later. The latest wgpu has a different method of handling synchronization, so that's yet more headache. Theoretically, we could resolve this by creating fences in a cpu buffer handed from the calling context. Another slight wrinkle is that fences, in the caiman core language, are effectively treated as memoryless abstract objects. It's a useful simplification, but predictably a flawed one.
I'm inclined to ignore this for as long as possible because I don't care enough about wgpu to want to build a tailor-made solution. The problem is that it might be necessary depending on what examples we need to write.
The text was updated successfully, but these errors were encountered: