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
Lwgpu is just a rust GPU api based on the same hardware abstractions and core
Dsure but if it's just technical differences, then for the users it's "basically the same thing", all knowledge is transferable, and people can just use one or the other and the differences are a bit like "if you're on the web you don't have a filesystem" rather than "opengl vs vulkan" differences?
Llook idk what you are trying to accomplish obviously we dont agree and im not changing my viewpoint, and you arent changing your viewpoint
DI'm trying to understand what each thing is
DI'm not trying to change your viewpoint
Lwgpu is a rust GPU api
wgpu-native is an implementation of webgpu-native
wgpu-native is an implementation of webgpu-native
Lboth are based on wgpu-core and wgpu-hal
Lnothing more, nothing less
Dok, my point was not from the "I'm right you're wrong", it's from a "I found a link to this library, the readmes basically contradict each other" ... but it's fine, I get the points mentioned
Leverything else like the APIs it uses is an implementation detail, the readme's do not contradict
LSilk.NET was added to that list as a request from one of the devs after hearing i had added webgpu-native bindings to Silk
Lthey explicitly asked me to PR it in to the readme
Dimo one thing that is confusing in the readme is that it says WebGPU API, but it doesn't say how ... hence my initial question, because I came here after the "WebGPU is now in chrome stable", but this isn't the case with silk, because there's no wasm, it's via wgpu-native ... it may be an implementation detail, but implementation details are not irrelevant for shipping things
Leven if we had WASM merged right now itd still be through webgpu-native
Lbut itd be through the emscripten shim