but how is the wgpu API itself different from webgpu API?
but 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
Doh hmm
L(there is a draft PR for WASM support)
Lits just not done because WASM in dotnet is Bad
Lhopefully .NET 8 rectifies that, but as it currently stands it is not possible to implement actual good WASM support into Silk
Dtoo bad 
Dbut at least bright future I guess
Lwell, its been a few years
Lnot much has changed
Lnot too bright
KHave a look at https://en.wikipedia.org/wiki/WebGPU
MHey folks! I am new to Silk.Net and computer graphics in general. I am trying to integrate SkiaSharp's OpenGL back-end so I can draw 2d shapes easily without having to render textures unto 3d objects, but I end up crashing when I try to create a GLFW-backed Skia backend here https://github.com/Machinarius/DooMThing/blob/broken_silkdotnet/SilkWrappers/SilkRenderer.cs#L12
GitHub
Contribute to Machinarius/DooMThing development by creating an account on GitHub.
Lwhy are you passing both IWindow and GLFW?
MTring to follow this sample code https://github.com/mono/SkiaSharp/issues/2418 - I think I might be trying to fit a square peg on a round hole here, as the OP used Silk's GLFW code directly, instead of creating a window
GitHub
Description In Processing, you can find a performance example demonstrating the rendering of 50,000 lines in an 800x600 window in Examples -> Demos -> Performance -> LineRendering. This ru...
MMy noob reasoning is that I can get the GLFW context off the window, but alas that doesn't seem possible with the API? I've been throwing darts for a bit
Lwhy do you need the GLFW context?
MSkiaSharp needs to locate GL functions
LIWindow.GLContext.GetProcAddress or similar names
Lsomething like that
Li think the
GLNeat! I will try those. Thank you
MWow... How did I not notice IWindow exposes a GL context? 
Lwe all miss things
