Unable to launch WezTerm with WebGPU front-end #3425
Labels
Comments
|
Please set Also, please open the debug overlay and type: and share the output here. |
|
Output of wezterm.gui.enumerate_gpus() from debug overlay: [ I have tried setting the webgpu_preferred_adapter with the options listed, but behavior persists. |
github-actions
bot
removed
the
waiting-on-op
|
It hasn't logged anything from the webgpu module, and there are no errors logged. When you say fails to launch, what happens? Is there a crash dialog? If so, are you in a position to attach a debugger? On Windows you need:
Then build and run the debug version like this: git clone --depth=1 --branch=main --recursive https://github.com/wez/wezterm.git
cd wezterm
git submodule update --init --recursive
cargo run --bin wezterm -- start |
|
When I try to launch wezterm (with the wezterm command or clicking the wezterm-gui.exe), nothing seems to happen. The window doesn't appear briefly before closing, there's no error message, and no other sign. I tried running the debug version, but ran into this error: Running I was able to build the release version, and am able to run that. I looked in the Windows Logs and did find these: The nvoglv64.dll module being part of the Nvidia drivers |
github-actions
bot
removed
the
waiting-on-op
|
It's likely that this issue is a bug in the nvidia drivers, especially because the faulting module is the nvidia drivers themselves, but also: wezterm doesn't know that it's nvidia and doesn't do anything different, and it works on other systems and combinations of drivers. There's not a lot I can do without a stack trace. Can you try launching the debug build of wezterm-gui.exe under a debugger? |
|
Here is what I got: |
github-actions
bot
removed
the
waiting-on-op
|
Thanks! Can you also share the git hash of the build you were running there? |
wez
added a commit
that referenced
this issue
Apr 7, 2023
|
I've pushed a speculative fix for the borrow error |
|
Unfortunately, it didn't seem to fix the issue for me. Stack trace above used e3e9821. I forgot to mention, a previous version I was using (20221119-145034-49b9839f) did not have this issue, and webgpu worked as intended. A quick git bisect points to commit 74dc74b as being the culprit. Here is the stack trace from the latest 36d5307: |
github-actions
bot
removed
the
waiting-on-op
wez
added a commit
that referenced
this issue
Apr 8, 2023
The stack trace in #3425 shows a recursive borrow triggered indirectly by spawning a subprocess and having that trigger the wndproc. This commit doesn't really fix the recursive problem, but may sidestep it, and it's probably best to avoid always running the `wsl` command to get this list anyway, similar to the change in 25255d9 refs: #3425
|
What's weird is that those panic traces are completely unrelated to webgpu; there's some kind of recursive call to the window proc being triggered as a side effect of the config stuff spawning the I've pushed a commit that should avoid doing that work until needed, which should hopefully help! |
|
Unfortunately, it didn't seem to fix the issue. However, I had some time to look into it today, and it seems like reverting the changes made in 74dc74b (basically going back to using 0.14 rather than 0.15 of the wgpu crate, as the changes were mostly connected to that) completely solves everything. Tried building and running on top of the latest commit with no problem. |
github-actions
bot
removed
the
waiting-on-op
|
Reverting back to 0.14 is not an option. Is there a revised stack trace on the latest nightly? |
wez
added
the
waiting-on-op
|
On the latest nightly, when I try to run, this is all I get: Windows did generate a dump file that might be helpful? |
github-actions
bot
removed
the
waiting-on-op
|
OK, now we're at something that is related to webgpu. Other things to try:
|
wez
added
the
waiting-on-op
|
I've tried setting the preferred adapter to all of the configurations listed by wezterm.gui.enumerate_gpus() and it did not seem to have any effect on the crash. I also tried to change webgpu_power_preference, and same thing. I can however build and run the examples from the wgpu repo with no problem, and both vulkan and dx12 as backend work fine (as well as both low and high wgpu power pref). I tried running through WinDbg, and here's what I get: |
github-actions
bot
removed
the
waiting-on-op
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What Operating System(s) are you seeing this problem on?
Windows
Which Wayland compositor or X11 Window manager(s) are you using?
No response
WezTerm version
20230330-074438-c766d5e4
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
Yes, and I updated the version box above to show the version of the nightly that I tried
Describe the bug
WezTerm fails to launch when front_end = "WebGpu" is set in the config. This is also the case when it's the only option set in the config file, as well as trying to launch with wezterm -n --config "front_end='WebGpu'"
However, if I launch a new instance of WezTerm with front_end = "OpenGL", then change the config file to use WebGpu and spawn a new window, sometimes the new window will be created as expected using the WebGpu front-end (I can confirm the setting has been applied properly by the font rendering). Occasionally, this workaround won't work.
I have tried various configurations of both webgpu_power_preference and webgpu_preferred_adapter, but the behavior persists. From my current working instance from the debug overlay:
OpenGL version: WebGPU: name=NVIDIA GeForce GTX 1650 Ti with Max-Q Design, device_type=DiscreteGpu, backend=Vulkan, driver=NVIDIA, driver_info=517.13, vendor=4318, device=8085
To Reproduce
Try to launch WezTerm with wezterm -n --config "front_end='WebGpu'"
Configuration
local wezterm = require("wezterm")
local config = {}
if wezterm.config_builder then
config = wezterm.config_builder()
end
config.front_end = "WebGpu"
return config
Expected Behavior
WezTerm to launch
Logs
Log when trying (and failing) to launch with front_end = "WebGpu"
Log when launching successfully with OpenGL, switching to WebGpu, trying to spawn a new window, and crashing
Log using workaround
Anything else?
No response
The text was updated successfully, but these errors were encountered: