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. |
|
|
||
| // 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. |
…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 |
…+ '--use-port=emdawnwebgpu' ports. (ocornut#8381, ocornut#8898)
|
@BrutPitt do you know why <emscripten/html5_webgpu.h> doesn't seem to exist in Emscripten 5.0.1 but it works with Emscripten 5.0.0 ? Using https://github.com/ocornut/imgui/actions/runs/22188320971/job/64168427672 |
|
With #include <webgpu/webgpu.h>
#include <webgpu/webgpu_cpp.h>I do not know exactly what happened, but my guess is that |
|
If I use those includes then: em++ -DIMGUI_DISABLE_FILE_FUNCTIONS -I../.. -I../../backends -Wall -Wformat -Os -s USE_SDL=2 -s DISABLE_EXCEPTION_CATCHING=1 --use-port=emdawnwebgpu -c -o main.o main.cpp
main.cpp:446:5: error: unknown type name 'WGPUSurfaceDescriptorFromCanvasHTMLSelector'
446 | WGPUSurfaceDescriptorFromCanvasHTMLSelector html_surface_desc = {};
| ^
main.cpp:447:37: error: use of undeclared identifier 'WGPUSType_SurfaceDescriptorFromCanvasHTMLSelector'
447 | html_surface_desc.chain.sType = WGPUSType_SurfaceDescriptorFromCanvasHTMLSelector;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
main.cpp:455:21: error: use of undeclared identifier 'wgpuSurfaceGetPreferredFormat'
455 | preferred_fmt = wgpuSurfaceGetPreferredFormat(wgpu_surface, {} /* adapter */);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
|
I am currently traveling and I have very limited access. You can take a look at this example I have which was adapted from the ImGui one to use ImGui as a port. But the logic for webgpu should be the same... |
|
While working on #9257 I learned about how to compile with latest emscripten 5.0.1. Attaching diff in case that helps. tl-dr? remove most of the Here is the Dawn codepath fixed:
diff --git a/examples/example_glfw_wgpu/main.cpp b/examples/example_glfw_wgpu/main.cpp
index 02e3bfeda..67a8fa642 100644
--- a/examples/example_glfw_wgpu/main.cpp
+++ b/examples/example_glfw_wgpu/main.cpp
@@ -19,9 +19,6 @@
#ifdef __EMSCRIPTEN__
#include <emscripten.h>
#include <emscripten/html5.h>
-#if defined(IMGUI_IMPL_WEBGPU_BACKEND_WGPU)
-#include <emscripten/html5_webgpu.h>
-#endif
#include "../libs/emscripten/emscripten_mainloop_stub.h"
#endif
@@ -461,30 +458,14 @@ static bool InitWGPU(GLFWwindow* window)
instanceDesc.requiredFeatures = &timedWaitAny;
wgpu_instance = wgpuCreateInstance(&instanceDesc);
-#ifdef __EMSCRIPTEN__
- getAdapterAndDeviceViaJS();
-
- wgpu_device = emscripten_webgpu_get_device();
- IM_ASSERT(wgpu_device != nullptr && "Error creating the Device");
-
- WGPUSurfaceDescriptorFromCanvasHTMLSelector html_surface_desc = {};
- html_surface_desc.chain.sType = WGPUSType_SurfaceDescriptorFromCanvasHTMLSelector;
- html_surface_desc.selector = "#canvas";
-
- WGPUSurfaceDescriptor surface_desc = {};
- surface_desc.nextInChain = &html_surface_desc.chain;
-
- // Create the surface.
- wgpu_surface = wgpuInstanceCreateSurface(wgpu_instance, &surface_desc);
- preferred_fmt = wgpuSurfaceGetPreferredFormat(wgpu_surface, {} /* adapter */);
-#else // __EMSCRIPTEN__
-
+#ifndef __EMSCRIPTEN__
#if !defined(IMGUI_IMPL_WEBGPU_BACKEND_WGVK)
wgpuSetLogCallback(
[](WGPULogLevel level, WGPUStringView msg, void* userdata) { fprintf(stderr, "%s: %.*s\n", ImGui_ImplWGPU_GetLogLevelName(level), (int)msg.length, msg.data); }, nullptr
);
wgpuSetLogLevel(WGPULogLevel_Warn);
#endif
+#endif // __EMSCRIPTEN__
WGPUAdapter adapter = RequestAdapter(wgpu_instance);
ImGui_ImplWGPU_DebugPrintAdapterInfo(adapter);
@@ -500,7 +481,6 @@ static bool InitWGPU(GLFWwindow* window)
wgpuSurfaceGetCapabilities(wgpu_surface, adapter, &surface_capabilities);
preferred_fmt = surface_capabilities.formats[0];
-#endif // __EMSCRIPTEN__
#endif // IMGUI_IMPL_WEBGPU_BACKEND_WGPU
wgpu_surface_configuration.presentMode = WGPUPresentMode_Fifo; |
|
Also this compiler error while trying to fix the the emcc+webgpu backend, hinting that pure webgpu is no longer supported as far as I could read: probably would be good to allow that codepath only if emcc <= 5.0.0 |
|
@r-lyeh this option was removed well before 5.0.0 (the version numbering in Emscripten is completely meaningless and does not follow any breaking API changes unfortunately...) |
|
@r-lyeh I cannot seem to get this patch to work there are too many other changes involved in main.cpp and in backend e.g. Feel free to add changes to your WGVK PR if it compiles with everything I would extract changes out of it. |
|
I also wanted to point out that I posted in this very thread about |
|
No-one can humanly parse a 143 messages topic especially when GitHub enforce collapsing by default :( |
|
@ocornut It is version 4.0.18 for the flag. I can take a look at the PR next week (as I am traveling this week) |
|
The flag was marked obsolete in 4.0.10 and still supported, and 4.0.18 removed it. I am totally confused as where you are finding documentation about WebGPU api. Every time I search for a keyword I land on sub-standard amount of information. |
|
@ocornut I am not the one who worked on this PR and I do not know the code well enough. Maybe @BrutPitt could help? As I mentioned I am traveling and cannot take a look at it at the moment, but I should have some spare cycles next week and don't mind getting rid of the old way to at the minimum clean up the code. I know it might not be a suggestion you like but when I ported WebGPU Shader Toy from |
|
Ah it turns out the main reason was the version check was incorrect: #ifdef __EMSCRIPTEN_MAJOR__
#if (__EMSCRIPTEN_MAJOR__ >= 4) && (__EMSCRIPTEN_MINOR__ >= 0) && (__EMSCRIPTEN_TINY__ >= 10)
#define IMGUI_IMPL_WEBGPU_BACKEND_DAWN
[...]This would fail with 5.0.0+. Fixed with 2b415e6 Now all examples are building for me. SDL3 doesn't run tho. |
|
Glad you found a quick fix! Another casualty of nonsensical Emscripten version numbering... |
To be fair that was my mistake, the logic was wrong. dear imgui use IMGUI_VERSION_NUM which is easier to use because it is a single number but make it less obvious to support LTS on old versions (which dear imgui doesn't do anyhow). |
I have now some free time and I am going to spend time on "cleaning" up the code of This will require dropping support for Emscripten < 4.0.18 (released on 2025/10/24) Thanks |
|
Sorry I was wrong about dropping support for 4.0.18. Since the new port was introduced in 4.0.10, no change is required. |
9 participants
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*