Comments (3)
All right, I think that, finally, the PR is ready! Note that it was a bit more complicated than I expected due to low processor usage mode but according to my tests, it fixes the problem!
Here it is: #93684.
from godot.
All right, so, after a short panic, I think I got it.
Funnily enough, another user reported this to me in a more exotic usecase and I, out of experience, shrugged it off as a driver bug (oh was I naive). Note that they used vsync, so this is certainly not a vsync issue.
It looks like putting wl_surface_commit
inside some asynchronous methods (namely WaylandThread::_frame_callback_on_done
) made a threading issue evident, after the huge "explicit sync revolution" (apparently also firefox has this issue1).
If, due to multithreading, the command gets queued while an explicit sync is getting set up and before a buffer is set, the no_buffer
error rightfully shows up and it explodes.
This apparently got also noticed while developing the new protocol2 and it has been concluded as misuse of the protocol by clients like us, so we ought to fix that by limiting commits to at least the same thread (ideally once by the renderer). I already tried reducing commits before, but wasn't able to do so because I forgot about low-consumption mode (my archnemesis).
I think I got a quick patch that should remove even more unneeded commits and sync the only one needed for frame timeout to the main thread . It's not pretty, but if it works we can look to perhaps only spam-commit if in low-usage mode or only when checking, not sure. (this should get only called each frame anyways so whatever).
What?
If all of that flew over the reader's head, don't worry, I'm still a bit panicking :gdsweat: . Please try this patch:
UPDATE: There's a PR now which is a bit more complex: #93684
diff --git a/platform/linuxbsd/wayland/display_server_wayland.cpp b/platform/linuxbsd/wayland/display_server_wayland.cpp
index 3fad8c2987..363c14bbcd 100644
--- a/platform/linuxbsd/wayland/display_server_wayland.cpp
+++ b/platform/linuxbsd/wayland/display_server_wayland.cpp
@@ -1192,6 +1192,7 @@ void DisplayServerWayland::process_events() {
wayland_thread.keyboard_echo_keys();
+ wl_surface_commit(wayland_thread.window_get_wl_surface(MAIN_WINDOW_ID));
if (!suspended) {
if (emulate_vsync) {
// Due to various reasons, we manually handle display synchronization by
diff --git a/platform/linuxbsd/wayland/wayland_thread.cpp b/platform/linuxbsd/wayland/wayland_thread.cpp
index 63a8db07df..02b204f6be 100644
--- a/platform/linuxbsd/wayland/wayland_thread.cpp
+++ b/platform/linuxbsd/wayland/wayland_thread.cpp
@@ -968,7 +968,6 @@ void WaylandThread::_frame_wl_callback_on_done(void *data, struct wl_callback *w
ws->frame_callback = wl_surface_frame(ws->wl_surface),
wl_callback_add_listener(ws->frame_callback, &frame_wl_callback_listener, ws);
- wl_surface_commit(ws->wl_surface);
if (ws->wl_surface && ws->buffer_scale_changed) {
// NOTE: We're only now setting the buffer scale as the idea is to get this
@@ -3241,10 +3240,6 @@ void WaylandThread::window_create(DisplayServer::WindowID p_window_id, int p_wid
ws.frame_callback = wl_surface_frame(ws.wl_surface);
wl_callback_add_listener(ws.frame_callback, &frame_wl_callback_listener, &ws);
- // NOTE: This commit is only called once to start the whole frame callback
- // "loop".
- wl_surface_commit(ws.wl_surface);
-
if (registry.xdg_exporter) {
ws.xdg_exported = zxdg_exporter_v1_export(registry.xdg_exporter, ws.wl_surface);
zxdg_exported_v1_add_listener(ws.xdg_exported, &xdg_exported_listener, &ws);
Note: I've not tested the above as I don't have an explicit sync setup (yet), I'm working on getting one ASAP.
See also: NVIDIA/egl-wayland#110
Edit: made wording a little bit clearer, it sounded like the protocol was wrong or something. We're in the wrong and have always been, it popped up just now.
Footnotes
from godot.
Ok, update, I managed to set up an environment with explicit-sync and I can indeed replicate this bug.
It seems indeed that the aforementioned patch fixes the issue! I'd be tempted to make a PR as-is, but I'll look at it harder to make sure whether committing each process frame is a problem (I don't think) and if so whether I can avoid doing that (detecting low-usage mode?)
from godot.
Related Issues (20)
- Button icon's are getting clipped HOT 4
- Selected property in inspector shows blurry text when collapsed then expanded HOT 1
- Godot crashes when importing project data HOT 22
- [TRACKER] Metal rendering driver issues
- "--test" cannot be used as a user-provided argument after the separator (either "--" or "++") anymore HOT 2
- "add_child" does not work in @exported_storage node HOT 2
- Can't start Godot on Intel Haswell IGP on Windows anymore after 4.3.stable HOT 5
- V4.3 Audio is broken/loops when playing from inside an animation player with an animation tree HOT 1
- Custom build is throwing an error on the Android platform: The type initializer for 'Godot.Viewport' threw an exception. HOT 1
- 2D physics interpolation ghosted sprite2d HOT 3
- get_debug_mesh doesn't generate any valid surfaces HOT 3
- Subresources saving without NOTIFICATION_EDITOR_PRE_SAVE firing
- Deadlock in `EditorNode::immediate_confirmation_dialog` when importing in headless mode with GDExtension HOT 2
- InputEventScreenDrag and InputEventScreenTouch event.index are bug values on iOS/iPadOS web export HOT 1
- Massiv Lag in editor when working with tile maps / tile map layers (Godot 4.3 stable release, Windows 11) HOT 11
- MultiMeshInstance3D completely broken LOD HOT 2
- [Web] Bus volume ignored for `AudioStreamPolyphonic` HOT 3
- Native File Dialogs export bug
- Revert button not work for `ShaderMaterial::render_priority` and `ShaderMaterial::next_pass` like it does for `StandardMaterial3D`
- Debugger does not open external text editor on error/breakpoint HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from godot.