Skip to content
This repository has been archived by the owner on Jun 18, 2021. It is now read-only.

HAL Interop #34

Closed
kvark opened this issue Jul 7, 2019 · 1 comment
Closed

HAL Interop #34

kvark opened this issue Jul 7, 2019 · 1 comment
Labels
enhancement New feature or request

Comments

@kvark
Copy link
Member

kvark commented Jul 7, 2019

We know that gfx-hal (with Rendy) provides a different set of trade-offs versus wgpu-rs. It makes the choice for library vendors to limit the future use of the libraries. If a library is simple enough that it could be using gfx-hal directly, and the author considers going this path, it means the wgpu-rs applications would not be able to use it, and visa versa. The issue is inspired by servo/pathfinder#213

It would be interesting to try to define a foreign library interface (FLI?), such that the user can unsafely provide the necessary glue bits in order for wgpu-rs to be able to use the logic bits of the foreign library. This could be enclosed into a "glue" library, e.g. "pathfinder_wgpu", which anyone could then use as a regular library when their graphcis stack is based on wgpu-rs.

The difficulty here is defining where the boundary should be drawn, and how to provide all the tracking info to wgpu. It might be infeasible completely, just needs to be investigated.

@kvark
Copy link
Member Author

kvark commented Jun 3, 2021

I think it's a generic issue, to be solved with more concrete proposals for external texture/buffer support.

@kvark kvark closed this as completed Jun 3, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant