What features are needed to not vendor librashader into sugarloaf?

[chyyran]

I noticed that your librashader implementation is done via vendoring the wgpu runtime into sugarloaf. It's probably OK but I can't officially recommend it because librashader-runtime and librashader-cache are implementation details and don't have a semver guarantee. Only what's exposed in the main librashader crate is covered under semver.

Given that, I'd like to know what features you would like to see in librashader-runtime-wgpu to no longer need to vendor the wgpu runtime into sugarloaf.

Would something like SnowflakePowered/librashader#153 be sufficient where you can pass in any instance of WgpuDeviceObjects, and have something like a FilterChainWgpu<&'a crate::context::Context> or do you need a context argument in the draw function? I'm a little worried about providing that as that would open up the possibility of passing in the wrong device...

[raphamorim]

Hey @chyyran thank you for the issue, i appreciate all the work you do 🙏

In the beginner I ported librashader-runtime-wgpu to sugarloaf because of the Arc as you pointed out and I believe SnowflakePowered/librashader#153 would be enough.

However lately I have been considering to use a fork of wgpu that enables f16 gfx-rs/wgpu#5701 and if I follow this path might be I will need to keep the wgpu code on Rio for now (so doesn't break compat).

Will move this issue to discussion but if you want to talk on discord please feel free to ping me there or in rio group https://discord.gg/zRvJjmKGwS