WebGPU GLFW, SDL2 and SDL3 examples #8381
Conversation
|
Hello,
Thank you! |
|
In addition, if I try to compile imgui_impl_wgpu.cpp(66,41): error C2187: syntax error: 'WGPUComputeState' was unexpected here [C:\Omar\Work\imgui\examples\example_glfw_wgpu\build\example_glfw_wgpu.vcxproj]
imgui_impl_wgpu.cpp(273,5): error C2065: 'WGPUShaderSourceWGSL': undeclared identifier [C:\Omar\Work\imgui\examples\example_glfw_wgpu\build\example_glfw_wgpu.vcxproj]
imgui_impl_wgpu.cpp(273,26): error C2146: syntax error: missing ';' before identifier 'wgsl_desc' [C:\Omar\Work\imgui\examples\example_glfw_wgpu\build\example_glfw_wgpu.vcxproj]
imgui_impl_wgpu.cpp(273,26): error C2065: 'wgsl_desc': undeclared identifier [C:\Omar\Work\imgui\examples\example_glfw_wgpu\build\example_glfw_wgpu.vcxproj]
imgui_impl_wgpu.cpp(273,36): error C3079: an initializer list cannot be used as the right operand of this assignment operator [C:\Omar\Work\imgui\examples\example_glfw_wgpu\build\example_glfw_wgpu.vcxproj]
imgui_impl_wgpu.cpp(274,5): error C2065: 'wgsl_desc': undeclared identifier [C:\Omar\Work\imgui\examples\example_glfw_wgpu\build\example_glfw_wgpu.vcxproj]
imgui_impl_wgpu.cpp(274,29): error C2065: 'WGPUSType_ShaderSourceWGSL': undeclared identifier [C:\Omar\Work\imgui\examples\example_glfw_wgpu\build\example_glfw_wgpu.vcxproj]
imgui_impl_wgpu.cpp(275,5): error C2065: 'wgsl_desc': undeclared identifier [C:\Omar\Work\imgui\examples\example_glfw_wgpu\build\example_glfw_wgpu.vcxproj]
imgui_impl_wgpu.cpp(275,37): error C2065: 'WGPU_STRLEN': undeclared identifier [C:\Omar\Work\imgui\examples\example_glfw_wgpu\build\example_glfw_wgpu.vcxproj]
imgui_impl_wgpu.cpp(283,62): error C2065: 'wgsl_desc': undeclared identifier [C:\Omar\Work\imgui\examples\example_glfw_wgpu\build\example_glfw_wgpu.vcxproj]
imgui_impl_wgpu.cpp(288,39): error C2065: 'WGPU_STRLEN': undeclared identifier [C:\Omar\Work\imgui\examples\example_glfw_wgpu\build\example_glfw_wgpu.vcxproj]
imgui_impl_wgpu.cpp(288,29): error C2440: '=': cannot convert from 'initializer list' to 'const char *' [C:\Omar\Work\imgui\examples\example_glfw_wgpu\build\example_glfw_wgpu.vcxproj]
imgui_impl_wgpu.cpp(288,29):
The initializer contains too many elements
imgui_impl_wgpu.cpp(405,13): error C2065: 'WGPU_STRLEN': undeclared identifier [C:\Omar\Work\imgui\examples\example_glfw_wgpu\build\example_glfw_wgpu.vcxproj]
imgui_impl_wgpu.cpp(432,13): error C2065: 'WGPU_STRLEN': undeclared identifier [C:\Omar\Work\imgui\examples\example_glfw_wgpu\build\example_glfw_wgpu.vcxproj]
imgui_impl_wgpu.cpp(545,55): error C2065: 'WGPU_STRLEN': undeclared identifier [C:\Omar\Work\imgui\examples\example_glfw_wgpu\build\example_glfw_wgpu.vcxproj]
imgui_impl_wgpu.cpp(545,26): error C2440: '=': cannot convert from 'initializer list' to 'const char *' [C:\Omar\Work\imgui\examples\example_glfw_wgpu\build\example_glfw_wgpu.vcxproj]
imgui_impl_wgpu.cpp(545,26):
The initializer contains too many elements
imgui_impl_wgpu.cpp(612,9): error C2065: 'WGPU_STRLEN': undeclared identifier [C:\Omar\Work\imgui\examples\example_glfw_wgpu\build\example_glfw_wgpu.vcxproj]
imgui_impl_wgpu.cpp(720,45): error C2065: 'WGPUOptionalBool_False': undeclared identifier [C:\Omar\Work\imgui\examples\example_glfw_wgpu\build\example_glfw_wgpu.vcxproj]
imgui_widgets.cpp
Generating Code...Yet my copy of Dawn appears to be up to date, so I am quite confused about the build process it seems. |
|
Hi Omar, let me start with your last message. I tried to compile the GLFW example under Windows, again, and continue to get NO errors.
and always I get NO errors. I add, for full completeness, after cloning DAWN I run I also noticed that in your report appears
Moreover, I checked the state of the "undeclared identifier" that you report, and they exist (in my copy of dawn): And, searching the net, I found that This seemed to me the most important thing to clarify as soon possible, later I reply to your questions P.S. |
|
About your questions: About code styleNo problem to use your code style. About changes in RequestAdapter/DeviceRequestAdapter was changed because Currently this is the WGPUFuture wgpuInstanceRequestAdapter(WGPUInstance instance, WGPU_NULLABLE WGPURequestAdapterOptions const * options, WGPURequestAdapterCallbackInfo callbackInfo) WGPU_FUNCTION_ATTRIBUTE;In the previous code WGPUAdapter adapter;
wgpuInstanceRequestAdapter(instance, nullptr, onAdapterRequestEnded, (void*)&adapter);
return adapter; ^^^^^^^^^The 4th parameter was removed from google DAWN Same for WGPU_EXPORT WGPUFuture wgpuAdapterRequestDevice(WGPUAdapter adapter, WGPU_NULLABLE WGPUDeviceDescriptor const * options, WGPURequestDeviceCallbackInfo callbackInfo) WGPU_FUNCTION_ATTRIBUTE;About std::moveI make just a little example: std::string str1 {"AAAAAA"};
std::string str2 {"BBBBBB"};
std::string str1_out = str1;
std::string str2_out = std::move(str2);
The first assignment call the copy constructor/operator: it copy the full string "AAAAAA" into (I'm sorry for the short and simplistic explanation:
Absolute requirement, no. And again: About callbackIn principle, no problem, but (to understand well) you want that I remove all lambdas, not only the validation layers callbacks, right? |
|
Just to give an extra data point, I was able to successfully build and run I've never worked with WebGPU on this machine so the Dawn clone was as fresh as can be. I don't have This is with Windows 10 22H2, CMake 3.30.2, Python 3.12.5, Visual Studio 2022 17.12.4 (latest). I also have Visual Studio 2022 17.13.0p2.1 and Ninja 1.12.1 on this machine, but I don't think either were used while building the example.
I also ran this as per your mention, although judging by our (Also for @ocornut's sake: If you're like me and habitually add |
About SDL2 WebGPU example attached.As mentioned it uses a "made by me" module But I made and attached it exclusively to "present" an example without messages from the Validation Layer and consider/test the correct procedure also/already used in GLFW. So, give the premises, if you prefer, I take it off from the PR.
You did well to specify the developer tools releases and OS
Confirm that this is not necessary (on Linux I don't used it), and therefore is not necessary to insert this step in the CMake procedure, but given the doubts I wanted to follow all the "official" steps |
|
Last commit changes:
If you prefer RequestAdaper and RequestDevice declared as functions would have this code, in a #ifndef __EMSCRIPTEN__
static wgpu::Adapter localAdapter; // currently used as local declaration in InitWGPU, both
static wgpu::Device localDevice;
void RequestAdapter(wgpu::RequestAdapterStatus status, wgpu::Adapter adapter, wgpu::StringView message)
{
if (status != wgpu::RequestAdapterStatus::Success)
{
printf("Failed to get an adapter: %s\n", message.data);
return;
}
localAdapter = std::move(adapter);
}
void RequestDevice(wgpu::RequestDeviceStatus status, wgpu::Device device, wgpu::StringView message)
{
if (status != wgpu::RequestDeviceStatus::Success)
{
printf("Failed to get an device: %s\n", message.data);
return;
}
localDevice = std::move(device);
}
#endifAdded notes: |
|
Hi, Omar. It's frustrating to work on Dawn: last branch, downloaded Saturday, causes "segmentation fault" on WebGPU Vulkan backend. Edit - current problem is reported here: About the GLFW exampleExploring the Dawn Source Code (the documentation is poor) I made some optimizations and correction to the example: A new function has been inserted to directly create the device, without the use of callbacks Currently there is no similar option for Adapter, not for // Declare DAWN RAII instead of wgpu::Instance
dawn::native::Instance instance(&instanceDescriptor);
// Enumerate all devices
std::vector<dawn::native::Adapter> adapterList = instance.EnumerateAdapters((WGPURequestAdapterOptions*) nullptr);
assert(!adapterList.empty());
// we get first available
dawn::native::Adapter localAdapter { adapterList[0] };But works only with DAWN (even if it does not involve the EMISCRIPTEN side), for this I currently did not use it About GLFW viewport error:It occurs only on window resize, not always, and only when enlarging. This because, currently, GLFW does not manage the framebuffer, but only the frame size: it's the example that deals with the downsizing of the framebuffer/Surface, based on the FrameSize acquired through GLFW:
To avoid a further bothersome inconvenience that happens in this situation: This not happens in SDL because the "frame size" not change asynchronously, but only after a The only option that works with GLFW is the one in which the example passes the Surface sizes to Anyway here there is an online GLFW EMSCRIPTEN example where I have modified Currently the SDL example hasn't been changed yet |
| { WGPUVertexFormat_Float32x2, (uint64_t)offsetof(ImDrawVert, pos), 0 }, | ||
| { WGPUVertexFormat_Float32x2, (uint64_t)offsetof(ImDrawVert, uv), 1 }, | ||
| { WGPUVertexFormat_Unorm8x4, (uint64_t)offsetof(ImDrawVert, col), 2 }, | ||
| #endif |
There was a problem hiding this comment.
Is this fix compatible with the VertexAttribute struct in the Rust implementation? https://docs.rs/wgpu/latest/wgpu/struct.VertexAttribute.html
As far as I know, the nextInChain field at the front is exclusive to the Google Dawn implementation. I think #ifdef IMGUI_IMPL_WEBGPU_BACKEND_DAWN should be used here.
|
I made a distinct PR for the issue mentioned above at #8438. Because I'm working with IMGUI and Dawn and this is a compile error, I would prefer to have this fix merged sooner (if this larger PR takes longer to merge). I'm unsure if this is bad etiquette, feel free to disregard. |
Current status of
|
|
Last commits add Now the examples work well. Only the problem of the validation layer messages remains, and only in GLFW example running in X11. In the meantime I added others WGPU / ImGui examples: And a very simple wgpu imgui mandelbrot example just to test and support (with and w/o imgui) the [bug report opened](https://issues.chromium.org/issues/403297812 |
|
has there been any testing with SDL3, webgpu, and IMGUI? I didn't see an example, and this seemed to be closest. I'm using webgpu-native personally, but I could adapt it. |
|
@ocornut I am not sure what is the status of this PR, but I just wanted to let you know that in Emscripten 4.0.10 (which was just released), the flag The good news is that using this new syntax allow for using a much more recent version of Dawb/WebGPU both for the desktop and for Emscripten (v20250531.224602) as of Emscripten 4.0.10 and that includes all the API changes... |
That's correct. So currently remain always and anyway 4 development methods:
In the next few days I will also modify the examples (mentioned in this thread) to adapt them to the new version of EMSCRIPTEN |
Just to clarify, with |
Sorry, my bad ... (my bad English, in this case) Thanks for the clarification.
I just started working: I plan it can be ready tomorrow or the day after tomorrow. |
examples/example_glfw_wgpu/main.cpp
Outdated
|
|
||
| // Synchronously (wait until) acquire Adapter | ||
| auto waitedAdapterFunc { instance.RequestAdapter(&adapterOptions, wgpu::CallbackMode::WaitAnyOnly, onRequestAdapter) }; | ||
| instance.WaitAny(waitedAdapterFunc, UINT64_MAX); |
There was a problem hiding this comment.
Does this work in Emscripten? Doesn't it require to use -sASYNCIFY=1?
There was a problem hiding this comment.
Does this work in Emscripten? Doesn't it require to use
-sASYNCIFY=1?
Yes, it's required.
As I just posted below:
-
I had to modify the HTML "template" file for EMSCRIPTEN:
whoever wrote the first version of the example, inserted the Adapter and Device acquisition in JavaScript inside the HTML file. -
Changes in CMakeFiles.txt
- It was necessary to add the
-sASYNCIFYflag to EMISCRIPTEN linker, previously this was forced directly from the HTML file, JS code (now removed and moved internally)
- It was necessary to add the
There was a problem hiding this comment.
Would there be a way to avoid waiting on the cpp side? Adding -sASINCIFY is not a trivial change as it has some serious consequences (see doc)
1 (default): Run binaryen’s Asyncify pass to transform the code using asyncify. This emits a normal wasm file in the end, so it works everywhere, but it has a significant cost in terms of code size and speed. See https://emscripten.org/docs/porting/asyncify.html
Prior to this change, I could use ImGui (and I do) without using asyncify.
I suppose this change is only affecting the example and is not in the webgpu backend as far as I can tell so I guess I can try to find a way to initialize WebGPU in my project without relying on WaitAny / asyncify
There was a problem hiding this comment.
Yes, I meant in this example it is required, it's required by WaitAny
Before it was not necessary, because async() was set externally, via JS
I don't know if it will be possible to use WaitAny in the future without -sASYNCIFY=1 (with the previous method): based on this comment WaitAny (emwgpuWaitAny) will be removed via prepocessor, without the above EMSCRIPTEN flag
I suppose this change is only affecting the example and is not in the webgpu backend as far as I can tell so I guess I can try to find a way to initialize WebGPU in my project without relying on
WaitAny/ asyncify
asyncify should only be about the Future data type (like WGPUFutureWaitInfo parameter of WaitAny)
There was a problem hiding this comment.
I don't know if it will be possible to use
WaitAnyin the future without -sASYNCIFY=1 (with the previous method): based on this commentWaitAny(emwgpuWaitAny) will be removed via prepocessor, without the above EMSCRIPTEN flag
Thinking about it, it's actually doable:
Here is the "old" ImGui example_glfw_wgpu, adapted with few changes to EMSCRIPEN 4.0.10 with "--use-port=emdawnwebgpu" flag and linked w/o -sASINCIFY=1
https://github.com/BrutPitt/myRepos/tree/master/wgpu_examples/example_glfw_wgpu
I hope it can be useful to you
(async() module is only for the Adapter and Device acquisition, done externally, in the HTML template via JS)
There was a problem hiding this comment.
Thank you for providing an example that works without ASINCIFY!
|
FYI i have just added support for the new |
|
About changes
|
| throw Error("WebGPU not supported."); | ||
| } | ||
|
|
||
| const adapter = await navigator.gpu.requestAdapter(); |
There was a problem hiding this comment.
I noticed that you introduced support for both --use-port=emdawnwebgpu and -sUSE_WEBGPU=1 via CMake option. But this code removes the adapter/device entirely from the JavaScript section. How does it work with -sUSE_WEBGPU=1 then? I thought it was required as there was no other way to obtain the device.
There was a problem hiding this comment.
As reported in previous post, I moved it internally in the CPP source code, using EMSCRIPTEN EM_ASYNC_JS macro to call JS code directly from C/CPP
Then I call it here
I had to use EM_ASYNC_JSmacro (which then mandatory requires -sASINCIFY=1), instead of EM_JS, because await mandatory requires it
There was a problem hiding this comment.
I thought it was required as there was no other way to obtain the device.
Using JS is not the only method to acquire Adaper and Device using -sUSE_WEBGPU=1 flag, of course it can also be done via C/CPP, but it's just longer:
// Adapter and device request functions
WGPUAdapter requestAdapter(WGPUInstance instance, WGPURequestAdapterOptions const * options) {
struct UserData {
WGPUAdapter adapter = nullptr;
bool adapterAcquired = false;
} userData;
auto onAdapterRequest = [](WGPURequestAdapterStatus status, WGPUAdapter adapter, char const * message, void * pUserData) {
if (status == WGPURequestAdapterStatus_Success) ((UserData *) pUserData)->adapter = adapter;
else printf("Could not get WebGPU adapter: %s \n", message);
((UserData *) pUserData)->adapterAcquired = true;
};
wgpuInstanceRequestAdapter(instance, options, onAdapterRequest, &userData);
while (!userData.adapterAcquired) emscripten_sleep(100); // wait until adapter is acquired
assert(userData.adapter!=nullptr); // sanity check
return userData.adapter;
}
WGPUDevice requestDevice(WGPUAdapter adapter, WGPUDeviceDescriptor const * descriptor) {
struct UserData {
WGPUDevice device = nullptr;
bool deviceAcquired = false;
} userData;
auto onDeviceRequest = [](WGPURequestDeviceStatus status, WGPUDevice device, char const * message, void * pUserData) {
if (status == WGPURequestDeviceStatus_Success) ((UserData *) pUserData)->device = device;
else printf("Could not get WebGPU device: %s \n", message);
((UserData *) pUserData)->deviceAcquired = true;
};
wgpuAdapterRequestDevice(adapter, descriptor, onDeviceRequest, &userData);
while (!userData.deviceAcquired) emscripten_sleep(100); // wait until device is acquired
assert(userData.device!=nullptr); // sanity check
return userData.device;
}Subsequently to acquire Adapter and Device:
wgpu::Adapter adapter(requestAdapter(instance.Get(), {}));
wgpu::Device device(requestDevice(adapter.Get(), {}));;N.B.
This code has not been tested on this example
I took this from another code of mine, it should work the same, but it might also need some adaptation.
P.S.
Also this code requires -sASINCIFY=1 because emscripten_sleep requires it
|
@BrutPitt When you think you are done with your PR, I will be more than happy to test the Emscripten part locally if you want. Just let me know. |
|
To follow up on the use of ASYNCIFY, I changed my example code (on a branch for now) to get rid of ASYNCIFY entirely. You can see for yourself how I did it. The idea is to use Is it convoluted compared to the ASYNCIFY version, absolutely! But the end result is pretty dramatic: I am not suggesting we should change it for ImGui but my original concern about introducing |
|
Briefly about latest changes. Now the example covers all 4 compilation methods:
The differences between the four methods concern mostly the acquisition of Support for WGPU-Native has been introduced.Neither the previous code, nor my subsequent changes, supported WGPU-Native directly (it was only done through EMSCRIPTEN: obviously I'm talking about the To allow this I had to introduce a new file: @ocornut I await feedback, requests, suggestions and criticisms from everyone The example currently has been tested in:
P.S. |
|
This section in the CMakefile for GLFW+WGPU is a problem, the I removed them and adjust the logic in in example_glfw_wgpu/main.cpp and used |
789bc0a to
ceeb1f1
Compare
…en 4.0.10+ and latest Dawn-Native, WGPU-Native. (ocornut#8381, ocornut#8567, ocornut#8191, ocornut#7435)
|
I have now resculpted entire history to be nicer and merged as 4 commits in master:
This closes #8381, #8567, #8191, #7435 Could you verify that: #if defined(IMGUI_IMPL_WEBGPU_BACKEND_DAWN)
#include <webgpu/webgpu_cpp.h> // for wgpu::Device, wgpu::DeviceLostReason, wgpu::ErrorType used by validation layer callbacks.
#elif !defined(__EMSCRIPTEN__)
#include <webgpu/wgpu.h> // WGPULogLevel
#endifIs needed in imgui_impl_wgpu.h ? Thanks for your time and patience with this. I can safely say this has been one of the most frustrating PR i had to deal with but I am very glad this is done and mostly solved. Mostly the main problems were:
But we got to the end of it thanks to your patience and continued explanation. Thanks again! PS: I'm still not super excited about the amount of debug helpers we added. For this reason I am currently describing them as internals in the imgui_impl_wgpu.h file. It would have been better if WebGPU provided those in the specs. |
With the latest changes, it can be modified as follows: #include <webgpu/webgpu.h>
#if defined(IMGUI_IMPL_WEBGPU_BACKEND_WGPU) && !defined(__EMSCRIPTEN__)
#include <webgpu/wgpu.h> // WGPULogLevel
#endif
And in #include <webgpu/webgpu.h>
Already done! (both ... pushed in my fork) (I also optimized the headers in all
This weekend I'm taking a comprehensive test.
I'll look at it as soon as I finish the tests.
Thanks to you for ImGui!
I know you said that external files are difficult to maintain, but perhaps (at least) Since they will be removed when the respective frameworks support WebGPU (Hopefully soon.). Two changes (pushed):CMakeLists.txtI added the code for using Dawn “pre-built” library. There seem to be some problems in Windows, it seems to be the same as this one (already discussed) . Update: Simply put: the workaround described (in above link) is still valid (not fully resolved), so for Windows it is necessary to compile (still/always) with the following options enabled (also the version to be installed): option(DAWN_FORCE_SYSTEM_COMPONENT_LOAD "Allow system component fallback" ON)
option(TINT_BUILD_SPV_WRITER "Build the SPIR-V output writer" ON)or passing they via command line *Required: these options are not enabled by default. CreateWGPUSurface (in main.cpp)I moved it to the bottom of the file. I know you don't like it when I “move” functions ;-) , but there's a good reason for it: First, let's remove these lines. #undef Status // X11 headers are leaking this.
#undef Success // X11 headers are leaking this.Second, especially if the user wanted to modify the example may encounter further problems: there are many other X11 header entries that can cause issues (e.g. |
…sing Dawn “pre-built” library. (#8381)
…s have less differences. (#8381)
…ue to interference with X.h. (#8381)
I don't think this is good nor required. We want optimize headers or library ccode from unnecessarily including headers that are not needed. But we also want example code to be explicit and self-documenting, and the main.cpp can include this even if imgui_impl_wgpu.h already does.
Previously it was explicit that this is the workaround. So user carrying things into their file would find the solution at a glance. Now the situation is that user modifying the code might get into this "new" issue and not know what to do. I applied a modified commit with the I also fixed a few more inconsistencies (e.g. made declaration statics). Further changes should be made in a new PR probably. |
OK imgui/examples/example_glfw_wgpu/main.cpp Line 509 in 051a315 It can simply be: #if !defined(__EMSCRIPTEN__)*In Native, at least one Just to clarify the mechanism: And this also occurs in EMSCRIPTEN to differentiate the new syntax ( That said, it is important to note that by forcing this (it was already selected/controlled by the CMake option): imgui/backends/imgui_impl_wgpu.h Lines 36 to 40 in 051a315 You avoid the possibility of building the example (or any other project) with the old (deprecated) syntax even with EMS >= 4.0.10.
(and even the code in Of course it's fine, but it was important to point out that the above CMake option is no longer valid: will end up generating a compilation error with EMS >= 4.0.10 ... really the last thing: You may want to add in #if !defined(IMGUI_IMPL_WEBGPU_BACKEND_DAWN) && !defined(IMGUI_IMPL_WEBGPU_BACKEND_WGPU)
#error at least one of IMGUI_IMPL_WEBGPU_BACKEND_DAWN and IMGUI_IMPL_WEBGPU_BACKEND_WGPU must be defined!
#endifin addition to the control that already exists: imgui/backends/imgui_impl_wgpu.cpp Lines 58 to 60 in 051a315 Currently, this is also true in EMS. CMake already checks both things (for all examples), but obviously |
|
Pushed a simplification 86daa89 |
As already anticipated here, I send you the PR with the example GLFW in which the Swap-Chain was removed in favor of SurfaceConfigure.
But given the little troubles with GLFW (Validation Layer messages), I wanted to check with SDL2 if everything worked well.
So I created a function to acquire the surface in a native way on SDL.
It works and has been tested (with ImGui SDL2 WebGPU example) in Windows, Linux (X11) and Emscripten
There is also the possibility with Linux (Wayland) , but I haven't tried it yet.
The ImGui SDL2 WebGPU example works well: the web version is live here (obviously a browser with webGPU capabilities is required)
In SDL2 everything works perfectly and there are no warnings from the Validation Layer: it was tested in Linux, Windows and EMSCRIPTEN*