Kit's an implementation detail
L^
Kas much as... idk amdgpu and vulkan
Kthey are related as in they are in the same field, but they aren't tied directly to each other
Kthey have an interface where they exchange things
Kbut they are just different things
Kone is an implementation detail of another
Lwebgpu-native is an API
wgpu-native and Dawn are implementers
the projects are not directly related
wgpu-native and Dawn are implementers
the projects are not directly related
Lyou can just swap wgpu-native and Dawn out and ideally everything should still just work in your app
Dmaybe I'm stupid but the wgpu readme literally says "Safe and portable GPU abstraction in Rust, implementing WebGPU API." ... how is it unrelated if it implements the webgpu API
I get that it's rust and not C and you can't swap it out for another webgpu implementation, but like ... "it's the same thing, but in rust?"
I get that it's rust and not C and you can't swap it out for another webgpu implementation, but like ... "it's the same thing, but in rust?"
DI get that it's not direct bindings
Dand that it has RAII while the C API does not
Limplementing an API does not make you related to said original project
KThe AMDVLK readme literally says "The AMD Open Source Driver for Vulkan® is an open-source Vulkan driver for ...", but vulkan is still an indepentend concept and if your app works with vulkan, it'll work just fine regardless of AMDVLK/amdgpu or whatever else
D
V
DI get it's not the same project
Lyes, webgpu-native is an API definition
wgpu-naitve is software
wgpu-naitve is software
Kok maybe this will clarify, it'll be hard to understand wgpu without understanding webgpu
Kbut webgpu is completely understandable without wgpu
Kso webgpu is conceptually, as well as organizationally, as well as whatever else, unrelated to wgpu
Dmaybe we have a different meaning of the word unrelated ... opengl and directx are unrelated to me, if I'm using wgpu, I'm literally reading the webgpu spec to understand how some things work
Lhttps://github.com/webgpu-native/webgpu-headers
these are the raw headers for webgpu-native, it is only an API specification
these are the raw headers for webgpu-native, it is only an API specification
Dokay so if I say "wgpu is a nice high level wrapper around a webgpu implementation", is that accurate?
Lno
Lwgpu (without the -native) is a Rust API unrelated to webgpuLwgpu-native is an implementation of the webgpu-native API
Lweb engines like gecko, will for example wgpu-core or wgpu-native or Dawn directly to implement the webgpu API
Lnote the webgpu API is not the same as the webgpu-native API
Dokay maybe it's just obvious and I'm missing it but ... how is the wgpu API and webgpu API different on a fundamental level, other than wgpu is "safe wrappers with RAII and stuff"?
DI get that it's not the same exact API as the C headers
Dbut wgpu bind groups and webgpu bind groups are the same bind groups? etc.
Lwgpu is not "safe wrappers" of WebGPU
Lwgpu does not use wgpu-native
Lit uses wgpu-core and wgpu-hal
Dwell yes it has more backends than just wgpu-native
Dbut how is the wgpu API itself different from webgpu API?
Lit doesnt reference wgpu-native at all, its different
Lits just not the webgpu api, webgpu is JS, and functions differently
D... okay but if everything like bind groups, layouts, pipelines, etc. are the same ... then it's clearly related from the user perspective?
Lits not the same
Lits SIMILAR in a lot of ways, but thats out of convenience
Dcan you give me one example of a difference? because wgpu people have been linking the webgpu spec as a reference a lot
DI haven't used webgpu itself directly, I literally use wgpu and read the webgpu spec
Lshader modules are created differently in both webgpu and webgpu-native, theres no "wgsl" object you put in the "source" parameter
in webgpu-native you do struct chaining of a few structs, in webgpu you just pass the source directly, due to there being no SPIRV in the webgpu specification
in webgpu-native you do struct chaining of a few structs, in webgpu you just pass the source directly, due to there being no SPIRV in the webgpu specification
Dokay, but that's like a small technical detail no? like this doesn't really change how the graphics API behaves
Lany changes and extras in the wgpu api will not effect and are not effected by changes in the webgpu api
Dright
Ltheres a reason wgpu does not claim to implement the WebGPU api
Lwgpu-native is what claims to implement the webgpu-native api