Switch deno-wgpu from wgpu-rs to wgpu-core

[kvark]

There is a project of getting wgpu to work with Deno: https://github.com/chances/deno-wgpu

I think it's important, because there are users who would want to work with wgpu or WebGPU in JS on native. They can do it via NodeJS bindings of webgpu-headers, that is in progress, and we aim to get compatible with it in wgpu-native. There is a special sub-group now called WebGPU-NAPI that is also looking into this, see https://github.com/Kings-Distributed-Systems/webgpu-napi

It would be nice to explore possible collaboration with Deno further. First step would be changing deno-wgpu to use wgpu-core and wgpu-types directly instead of wgpu-rs.

[crowlKats]

@kvark oh well, so i just saw this.
I am a contributor over at deno, and am currently implementing webpgu in deno directly, but am currently using wgpu-rs and implemented the majority of the spec already.

[kvark]

@crowlKats that's super exciting! Let us now if we can help 🚀

We are aware of the work bridging NodeJS with Dawn together, via NAPI. The plan there is to go through https://github.com/webgpu-native/webgpu-headers instead of Dawn headers, and this will be implemented by https://github.com/gfx-rs/wgpu-native, which in turn is based on wgpu-core... My hope is that Deno + wgpu would be a much superior tandem to run similar workloads (e.g. TensorflowJS) with less overhead, and faster.

The difference between wgpu-core and wgpu-rs is that the latter is slightly higher level. So you get 1-level longer dependency chains, and longer stack traces. wgpu-rs needs a level of abstraction to be able to call into web-sys, and this is something Deno is not interested in, if I understand correctly.

Also, if your data doesn't map to wgpu-rs interface perfectly, you can get away with less overhead in the binding by using wgpu-core.

[kvark]

This is done in denoland/deno#7977
If it's not going to land, there will be no point to keep the issue open anyway.