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
More of a long-term idea. We should get wgpu fully working first.
Vulkan exposes much more low-level functionality than wgpu and is significantly harder to use safely. As a point of comparison for the value proposition of caiman vs raw wgpu, it would be useful to have a vulkan backend that uses the more direct access while providing the same safety guarantees as wgpu.
Having the backend established would also make it easier to extend to other functionality that is exposed in vulkan but not wgpu (like raytracing pipelines).
The text was updated successfully, but these errors were encountered:
A more reasonable middle ground would be wgpu_hal, which has a very similar interface to wgpu. The general issue is that wgpu and caiman, at the lowest level, solve similar problems as far as it relates to usage correctness (dynamically vs statically respectively, though webgpu is additionally designed for security against adversaries) so building on top of wgpu creates some weirdness in that some warts that exist purely to serve the wgpu correctness needs are also manifesting as warts in caiman that would not exist with a lower level API.
More of a long-term idea. We should get wgpu fully working first.
Vulkan exposes much more low-level functionality than wgpu and is significantly harder to use safely. As a point of comparison for the value proposition of caiman vs raw wgpu, it would be useful to have a vulkan backend that uses the more direct access while providing the same safety guarantees as wgpu.
Having the backend established would also make it easier to extend to other functionality that is exposed in vulkan but not wgpu (like raytracing pipelines).
The text was updated successfully, but these errors were encountered: