-
-
Notifications
You must be signed in to change notification settings - Fork 10.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update wgpu backend to emscripten 2.0.20 and chrome canary 92 #4116
Conversation
@@ -331,7 +329,8 @@ void ImGui_ImplWGPU_RenderDrawData(ImDrawData* draw_data, WGPURenderPassEncoder | |||
// Create and grow vertex/index buffers if needed | |||
if (fr->VertexBuffer == NULL || fr->VertexBufferSize < draw_data->TotalVtxCount) | |||
{ | |||
SafeRelease(fr->VertexBuffer); | |||
if (fr->VertexBuffer) | |||
wgpuBufferDestroy(fr->VertexBuffer); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we still need to call SafeRelease
here and for the index buffer. Destroy
only destroy the data internal to the buffer but the CPU-side state tracking isn't freed. This is to allow to reclaim GPU memory faster.
backends/imgui_impl_wgpu.cpp
Outdated
@@ -419,9 +417,11 @@ void ImGui_ImplWGPU_RenderDrawData(ImDrawData* draw_data, WGPURenderPassEncoder | |||
} | |||
else | |||
{ | |||
WGPUBindGroup image_bind_group = ImGui_ImplWGPU_CreateImageBindGroup(g_resources.ImageBindGroupLayout, (WGPUTextureView)pcmd->TextureId); | |||
WGPUBindGroupLayout bg_layout = wgpuRenderPipelineGetBindGroupLayout(g_pipelineState, 1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Maybe this bindgroup could be stored so we don't re-query it all the time. There is little cost to doing that in native, but in WASM you will get a new JS object everytime.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The bind group is stored in g_resources
. Only the layout is created and released once a new bind group is created. I assumed, that the bind group would store a reference to the layout internally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah the bindgroup stores a reference to the layout internally, This was just to avoid the creation of new JS object for the layout for every texture used here. We could just store to a global variable at [1]. But this is a nit: so it's ok to skip.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems I've misunderstood you. Your suggestion makes perfect sense, consider it changed 👍
backends/imgui_impl_wgpu.cpp
Outdated
@@ -455,7 +455,10 @@ static void ImGui_ImplWGPU_CreateFontsTexture() | |||
tex_desc.dimension = WGPUTextureDimension_2D; | |||
tex_desc.size.width = width; | |||
tex_desc.size.height = height; | |||
tex_desc.size.depthOrArrayLayers = 1; | |||
#if !defined(__EMSCRIPTEN__) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Dawn in native should understand depthOrArrayLayers
too so this ifdef might not be necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is actually a work-around for an issue I've encountered in Dawn (latest commit 30.4.). The validator checks for depth != 0
, which triggers an error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It shouldn't AFAIK: https://source.chromium.org/chromium/chromium/src/+/main:third_party/dawn/src/dawn_native/Texture.cpp;drc=2dd2d67dbcbbf0a241fd13d4fccbc049ee39bfd4;l=288
What error message do you get?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for pointing it out. I had another look at the code. It seems like dawn is trying to fix 'wrong' settings in the wrong way:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/dawn/src/dawn_native/Texture.cpp;drc=2dd2d67dbcbbf0a241fd13d4fccbc049ee39bfd4;l=251
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, that's because it is assuming there is the C++ structure defaulting happening. https://source.chromium.org/chromium/chromium/src/+/main:out/Debug/gen/third_party/dawn/src/include/dawn/webgpu_cpp.h;drc=d3d0337463160599bde3ef97db67071148652b9c;l=1203
Keeping as is sounds good, but soon (as in this week) Dawn will remove depth since we're past the deprecation period.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, the default initialization in the cpp header explains a lot. I am going to convert the implementation eventually to use the cpp version.
I am going to remove depth
in this case, as Dawn users will probably stay at head anyways (this implementation anyway already uses most of the latest changes().
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok sounds good!
backends/imgui_impl_wgpu.cpp
Outdated
WGPUTextureDataLayout layout = {}; | ||
layout.offset = 0; | ||
layout.bytesPerRow = width * size_pp; | ||
layout.rowsPerImage = height; | ||
WGPUExtent3D size = { static_cast<uint32_t>(width), static_cast<uint32_t>(height), 1 }; | ||
#if !defined(__EMSCRIPTEN__) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not setting depth here leads to wgpuQueueWriteTexture
not being executed properly (no texture data written), however, not error message is produced.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, with some small comments. Thanks for doing the update!
|
||
ImGui_ImplWGPU_CreateFontsTexture(); | ||
ImGui_ImplWGPU_CreateUniformBuffer(); | ||
|
||
// Create resource bind group | ||
WGPUBindGroupLayout bg_layouts[2]; | ||
bg_layouts[0] = wgpuRenderPipelineGetBindGroupLayout(g_pipelineState, 0); | ||
bg_layouts[1] = wgpuRenderPipelineGetBindGroupLayout(g_pipelineState, 1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[1]
backends/imgui_impl_wgpu.cpp
Outdated
@@ -419,9 +417,11 @@ void ImGui_ImplWGPU_RenderDrawData(ImDrawData* draw_data, WGPURenderPassEncoder | |||
} | |||
else | |||
{ | |||
WGPUBindGroup image_bind_group = ImGui_ImplWGPU_CreateImageBindGroup(g_resources.ImageBindGroupLayout, (WGPUTextureView)pcmd->TextureId); | |||
WGPUBindGroupLayout bg_layout = wgpuRenderPipelineGetBindGroupLayout(g_pipelineState, 1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah the bindgroup stores a reference to the layout internally, This was just to avoid the creation of new JS object for the layout for every texture used here. We could just store to a global variable at [1]. But this is a nit: so it's ok to skip.
71f3005
to
03de8ae
Compare
Updated the PR with all the suggestions from @Kangz. Thanks for the review. |
LGTM no additional comments from the WebGPU side |
All merged now (as 83bdfef) thank you both very much! |
…n as introduced in 83bdfef (#6117, #4116, #3632) The feature was removed from WebGPU (gpuweb/gpuweb#2470)
This changeset introduces some implementation simplifications proposed by @Kangz here and updates the code to be compatible with Emscripten 2.0.20 as described here.
The major changes are: