You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature detection of JS API features from inside Wasm #515
In implementations like Emscripten where there is a split between "SDK" (implementation of C on top of JS) and "user agent"/"UA" (implementation of JS on top of hardware), applications don't need to runtime-feature-detect the SDK (they can and should statically link it), but they do need to runtime-feature-detect the UA.
For things that are part of named features (WGPUFeatureName), feature detection is already solved.
We somewhat discussed wgpuGetProcAddress() for runtime feature detection of new function/methods in Feature-detecting functions when statically linking? #488, but it's kind of a shoehorned solution because those functions are actually provided by the SDK (not the UA), and function pointer calls are also slower.
What applications need to know is whether the function is going to actually work if it's called (or if it's going to crash). We could surface this by returning null for functions that will crash, but I say "shoehorn" because that forces people to actually use GetProcAddress instead of static linking.
In other words, anything that the JS API needs to provide feature detection for, there should be a way for Wasm applications to detect that too.
Now the question is whether this should be standardized, or if it's out of scope because it's detecting something at a different boundary (not the webgpu.h boundary). Emscripten could provide its own extensions for this, or we could just tell people to write e.g. EM_ASM({}) code to do it themselves from JS.
I would tend toward initially having Emscripten provide its own extensions for this (but of course if there are other Wasm implementations then they could implement some of Emscripten's extensions too.)
These seem kind of analogous to WGSLLanguageFeature, so maybe we could provide a wgpuInstanceHasAPIFeature or something. This would be kind of redundant on non-wasm though.
agreement GetProcAddress shouldn't try to provide this
concern about keeping up with everything that might need to be feature detected in any browser
KN: though the WG is already worrying about this so hopefully it won't be hard
CF: Think we should ignore this problem. It's a different enough environment that it's OK for applications to need to do their own checking from JS, if they really want to. Most applications will just try, crash, and show an error to the user.
KN: We'll watch and see if anyone using Emscripten really wants an Emscripten extension for this, instead of using EM_ASM.
In implementations like Emscripten where there is a split between "SDK" (implementation of C on top of JS) and "user agent"/"UA" (implementation of JS on top of hardware), applications don't need to runtime-feature-detect the SDK (they can and should statically link it), but they do need to runtime-feature-detect the UA.
For things that are part of named features (
WGPUFeatureName), feature detection is already solved.We somewhat discussed
wgpuGetProcAddress()for runtime feature detection of new function/methods in Feature-detecting functions when statically linking? #488, but it's kind of a shoehorned solution because those functions are actually provided by the SDK (not the UA), and function pointer calls are also slower.What applications need to know is whether the function is going to actually work if it's called (or if it's going to crash). We could surface this by returning null for functions that will crash, but I say "shoehorn" because that forces people to actually use GetProcAddress instead of static linking.
There are also other things that need to be detected, like support for a new dictionary member. (The best example we have of this right now is Add GPUCanvasContext getConfiguration() method gpuweb/gpuweb#4899 which may or may not be representative.)
In other words, anything that the JS API needs to provide feature detection for, there should be a way for Wasm applications to detect that too.
Now the question is whether this should be standardized, or if it's out of scope because it's detecting something at a different boundary (not the
webgpu.hboundary). Emscripten could provide its own extensions for this, or we could just tell people to write e.g.EM_ASM({})code to do it themselves from JS.I would tend toward initially having Emscripten provide its own extensions for this (but of course if there are other Wasm implementations then they could implement some of Emscripten's extensions too.)