Wgvk dynamic wgsl detection#9387
Open
manuel5975p wants to merge 2 commits intoocornut:masterfrom
Open
Conversation
… WGVK at compile time. Previously WGVK was hard-disabled from WGSL via #if !defined(IMGUI_IMPL_WEBGPU_BACKEND_WGVK), forcing the SPIRV fallback unconditionally. Now the WGSL path is attempted on all backends and an empty stage_desc is returned when the module fails to compile letting the existing SPIRV fallback at the call site kick in. on top of that, WGVK by default now builds with WGSL support (SIMPLE_WGSL/TINT) can now actually use WGSL, a build without it will return NULL from wgpuDeviceCreateShaderModule and fall through cleanly. A push/pop validation error scope is wrapped around the call to catch WGSL validation errors that surface as a nonnull but invalid module.
The block was a stub - find Vulkan, detect Wayland/X11, set the SUPPORT_*_SURFACE defines that wgvk.c needs, and link the right platform libs. Builds and runs on Linux now; previously failed at link with missing glfw symbols and at runtime with "Unsupported surface SType" when wgvk.c was compiled without the surface defines.
Closed
Owner
|
I don’t mind the cmakefile changes but they need to be done on all 3 similar cmakefiles. |
Owner
|
@manuel5975p Can you confirm that:
|
Author
|
As far as I know, Dawn and wgpu-native always include a wgsl parser (since it's required by the webgpu spec). But yes, that means WGSL shader creation will not
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two commits:
detect WGSL support at runtime instead of excluding WGVK at compile time.
Drops the
#if !defined(IMGUI_IMPL_WEBGPU_BACKEND_WGVK)guard around the WGSL shader modulecreation. Now WGSL is attempted on all backends; if the module comes back null (or fails the
wrapping validation error scope), an empty
stage_descis returned and the existing SPIRVfallback at the call site kicks in. Result: WGVK builds with
WGVK_WGSL_SUPPORT=SIMPLE_WGSLor
=TINTactually use WGSL now; builds without it fall through cleanly.GLFW+WGPU: wire up the IMGUI_WGVK_DIR path.The
if(IMGUI_WGVK_DIR)block in the example's CMakeLists was a stub. Filled in:find_package(Vulkan), pkg-config wayland-client,find_package(X11), set theSUPPORT_*_SURFACEdefines thatwgvk.creads, and assemble the LIBRARIES list.Without these the example failed at link (missing glfw/Vulkan symbols) and at runtime
("Unsupported surface SType" assertion in WGVK).
I wouldn't mind rebasing the cmake related commit out if youd rather keep it out of imgui and address it on the WGVK side.