Closed diefans closed 3 years ago
The change introduced by that commit was moving from 24bpp -> 32bpp if 32bpp is available. Your opengl drivers may potentially emulate 32bpp with the Mesa swrast/llvmpipe renderer.
Please run and capture the output from this for me; it includes info on the matching GL configurations as well as the GL implementation that gets selected:
RUST_LOG=info wezterm 2>&1 | grep -i gl
It would be great if you can tell me about the GPU hardware available on that system; the glxinfo
command prints out a lot of info that can be helpful to understand this, to one skilled in the art of reading it!
see attached files: wezterm_master.log glxinfo.log
Ah, it looks like wezterm was unable to init opengl and has fallen back to doing its own CPU based rendering:
2020-09-23T16:22:01.617Z ERROR wezterm::frontend::gui::termwindow > OpenGL init failed: with_egl_lib failed: with_egl_lib(libEGL.so.1) failed: EGL CreateWindowSurface: BAD_MATCH, with_egl_lib(libEGL.so) failed: EGL CreateWindowSurface: BAD_MATCH
BAD_MATCH is the error that is returned when the gl surface depth/parameters doesn't match the X server display depth. Do you have any particularly special configuration for your X server depth?
The GL configuration wezterm tried to use was:
ConfigInfo { config: 0xcaf32c, alpha_size: Some(8), red_size: Some(8), green_size: Some(8),
blue_size: Some(8), depth_size: Some(24),
conformant: Some("OPENGL OPENGL_ES2 OPENGL_ES3 "),
renderable_type: Some("OPENGL OPENGL_ES2 OPENGL_ES3 "),
native_visual_id: Some(40), surface_type: Some("PBUFFER PIXMAP WINDOW ") }
which corresponds to this line from your glxinfo: (native_visual_id 40 -> 0x28 in hex)
visual x bf lv rg d st colorbuffer sr ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a F gb bf th cl r g b a ns b eat
----------------------------------------------------------------------------
...
0x028 24 tc 0 32 0 r y . 8 8 8 8 . s 4 24 0 16 16 16 16 0 0 None
I am wondering, since the working wezterm is successful in initializing opengl:
2020-09-23T17:58:18.678Z INFO window::egl > initialized EGL version 1.5
2020-09-23T17:58:18.686Z INFO window::egl > initialized libEGL.so.1
2020-09-23T17:58:18.865Z INFO wezterm::frontend::gui::termwindow > OpenGL initialized! Quadro K1100M/PCIe/SSE2 OpenGL ES 3.2 NVIDIA 455.23.04 is_context_loss_possible=false
At least I would assume, that opengl initialization must have changed in an unfortunate way...
The commit that introduced this change wasn't perfect and there have been a couple of changes since then to improve which configuration is selected. It's not clear to me whether you are running master or exactly that revision; do you see the same behaviour on master?
I have spotted some mismatch in the master logs, where x11 reports a different visual_id than egl:
x11: 0x23(35) vs egl: 0x28(40)
❯ RUST_LOG=info ./wezterm_master 2>&1 | rg "(Filtered down to these configuration|x11)" -A1
2020-09-24T06:45:49.274Z INFO window::os::x11::connection > picked depth 32 visual id:0x23, class:4, bits_per_rgb_value:8, colormap entries:256, masks: r=0xff0000,g=0xff00,b=0xff
2020-09-24T06:45:49.282Z INFO wezterm::mux::domain > spawned: Child { stdin: None, stdout: None, stderr: None }
--
2020-09-24T06:45:49.473Z INFO window::egl > Filtered down to these configuration(s):
2020-09-24T06:45:49.473Z INFO window::egl > ConfigInfo { config: 0xcaf32c, alpha_size: Some(8), red_size: Some(8), green_size: Some(8), blue_size: Some(8), depth_size: Some(24), conformant: Some("OPENGL OPENGL_ES2 OPENGL_ES3 "), renderable_type: Some("OPENGL OPENGL_ES2 OPENGL_ES3 "), native_visual_id: Some(40), surface_type: Some("PBUFFER PIXMAP WINDOW ") }
--
2020-09-24T06:45:49.497Z INFO window::egl > Filtered down to these configuration(s):
2020-09-24T06:45:49.497Z INFO window::egl > ConfigInfo { config: 0xcaf32c, alpha_size: Some(8), red_size: Some(8), green_size: Some(8), blue_size: Some(8), depth_size: Some(24), conformant: Some("OPENGL OPENGL_ES2 OPENGL_ES3 "), renderable_type: Some("OPENGL OPENGL_ES2 OPENGL_ES3 "), native_visual_id: Some(40), surface_type: Some("PBUFFER PIXMAP WINDOW ") }
Hi there,
I just pulled and built master and am facing the same issue.
Here are the logs:
env RUST_LOG=info cargo run --release --bin wezterm 2>&1 | grep -i gl
2020-10-14T00:08:30.947Z INFO window::egl > ConfigInfo { config: 0xcaf367, alpha_size: Some(0), red_size: Some(8), green_size: Some(8), blue_size: Some(8), depth_size: Some(24), conformant: Some("OPENGL OPENGL_ES2 OPENGL_ES3 "), renderable_type: Some("OPENGL OPENGL_ES2 OPENGL_ES3 "), native_visual_id: Some(118), surface_type: Some("PBUFFER WINDOW ") }
glxinfo
0x076 24 dc 0 24 0 r y . 8 8 8 0 . s 4 24 8 16 16 16 16 16 1 None
On Debian/Nvidia with no specific tinkering. The only oddity about the setup is the extra wide monitor.
P.S: Another gl accelerated terminal kitty
seems to be working. Haven't looked into how it selects a particular entry from that table or if it uses a different mechanism.
I pushed a commit that tries to use all detected configs until one sticks. I'd appreciate you giving that a try and reporting all of the gl
log lines from the RUST_LOG=info
trace output, as that should show the original set of configs, the filtered set of configs, and which one worked (hopefully!).
Awesome. This commit seems to have fixed it.Thanks!
Here are the logs for reference
Great to hear! Looks like I flubbed logging the final configuration; if you could pull master again and share:
env RUST_LOG=info cargo run --release --bin wezterm 2>&1 | grep -C1 Success
That should be the last piece of info, thanks!
Of course. Here you go!
2020-10-14T02:56:32.516Z INFO window::egl > ConfigInfo { config: 0xcaf367, alpha_size: Some(0), red_size: Some(8), green_size: Some(8), blue_size: Some(8), depth_size: Some(18), conformant: Some("OPENGL OPENGL_ES2 OPENGL_ES3 "), renderable_type: Some("OPENGL OPENGL_ES2 OPENGL_ES3 "), native_visual_id: Some(76), surface_type: Some("PBUFFER WINDOW ") }
2020-10-14T02:56:32.524Z INFO window::egl > Successfully created a surface using this configuration
2020-10-14T02:56:32.524Z INFO window::egl > ConfigInfo { config: 0xcaf32d, alpha_size: Some(8), red_size: Some(8), green_size: Some(8), blue_size: Some(8), depth_size: Some(18), conformant: Some("OPENGL OPENGL_ES2 OPENGL_ES3 "), renderable_type: Some("OPENGL OPENGL_ES2 OPENGL_ES3 "), native_visual_id: Some(7e), surface_type: Some("PBUFFER PIXMAP WINDOW ") }
Thanks! Looks like the key difference is the alpha_size. I was slightly concerned that trying all the different configs might be slow, but it looks like ~30ms overhead on startup in your case, so I think just looping over the options seems OK. If it does prove to be noticeably slow when starting up or opening new windows, then I think I can tweak the ordering to put the first alpha_size==0
and then the first alpha_size==8
entries at the front of the list, but hopefully we can avoid adding more complexity.
I can also confirm this fix works! Thanks a lot!
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Describe the bug
I am observing a performance degradation introduced by 627a1c6c1b78b0169be728e0c202fbc501da0037. When typing, wezterm is not as responsive as before.
I made a load test with
xdotool
andtop
to send a lot of keys to the specific wezterm versions and monitor the load. To sum up the aforementioned commit introduces 5-6 times more load in this test - see wezterm.top.txtEnvironment
To Reproduce
Start wezterm, send some keys to it and monitor the load.
Additional context
I also made a
strace
to count changes of syscalls. The most significant changes are, that the degraded version has a lot moregetpid
calls, whilesched_yield
dropped to only 2.I tried to make any sense of 627a1c6c1b78b0169be728e0c202fbc501da0037, but since I am not an rust/wezterm insider I cannot say what could be the impacting piece of code. So please take my poor mans debug session with a grain of salt.