Godot: GLES3 freezes with Mesa 18.3+ [upstream]

Created on 5 Jan 2019  路  15Comments  路  Source: godotengine/godot

Godot has just started locking up at seemingly random recently.

I had it working fine, then did some OS updates (I'm running Manjaro Linux) and now it locks every now and then and gives no indication of what is going on.

I have the latest master branch (as of today 5/01/2018 - Git head: 5e6c6f3bb)

I run through a debugger and broke when the lock up was occurring and the problematic line is this:
glLinkProgram(v.id);

in shader_gles3.cpp line 475.
this line blocks and causes godot to lock up.

this does not occur if i change to GLES2 rendering.

bug linuxbsd thirdparty

Most helpful comment

Looks like a nice fix is on it's way to mesa, compiling mesa seems a bit much for my PC but I'll be able to test whenever an updated mesa hits arch's testing

All 15 comments

Duplicate of #24362 and #24340, someone should report it to Arch maintainers.

I've raised the issue on the Manjaro bug tracker and also on the Mesa bug tracker.
https://bugs.freedesktop.org/show_bug.cgi?id=109229

Thanks! Relevant info to provide to Arch/Manjaro dev, as they might be hit by the same issue that Fedora and Debian had with a recent GCC + Mesa update: https://github.com/godotengine/godot/issues/23423#issuecomment-435877238

Is there any chance this might be caused by something else? I _believe_ arch's gcc and mesa are both patched and built after gcc it's self got an update that fixed the mesa compile issue, yet I'm still getting this issue on arch in both 3.1 beta and 3.0.6

if it is still the same issue, what exactly should I be reporting? 'cause the whole thing is a bit messy and confusing

Zip file attached contining build scripts
and README on how to repo the issue.

build.zip

contents of README.md:

run ./godot_build.sh this will checkout and build godot

either edit shader_gles3.cpp:475 to look like this:

print_line("===== CALLING glLinkProgram");
glLinkProgram(v.id);
print_line("===== FIN glLinkProgram");

or use the file I have supplied.

run ./godot_build.sh to build with these changes

go into Build/godot/bin
run godot.x11.tools.64 in a terminal

you can get sample projects from here:
https://github.com/godotengine/godot-demo-projects

when checked out get godot

navigate into godot-demo-projects/3d/material_testers/

run exe we just built using gdb:
gdb --args /home/fabian/Projects/build/Build/godot/bin/godot.x11.tools.64 --editor

watch the console log.

Reopening for now since it seems not to be the same as the GCC bug that broke Mesa on Fedora/Debian a month ago. It's still a third-party issue, but it's probably worth having a bug report open for affected users to refer to.

Just to test fully for my self and confirm, following @supagu 's steps I get the same thing too. Lots of calls to glLinkProgram are fine (on startup for instance), but for example making a new MeshInstance then applying a new SpatialMaterial seems to call glLinkProgram a few times, each one freezing for at least 5-10 seconds each while Godot uses a lot of cpu (but this will then be instant next time, and so on)

on Godot v3.1.beta.custom_build.1ff170e _(but also on binaries for 3.1 alpha 5, beta 1 and 3.0.6)_
running POLARIS11, DRM 3.27.0, 4.20.0-arch1-1-ARCH, LLVM 7.0.0, using Mesa 18.3.1

An interesting development, I was playing around with Ubuntu 18.10 and while Godot (beta 2 and git) works on the official, stable mesa (18.2.2), switching to a PPA with 18.3.1 immediately caused the hanging on glLinkProgram again. Purging the PPA and downgrading to 18.2.2 then causes Godot to run fine once more, so I suppose this may be an issue with mesa or Godot more generally (or at least more widespread than Arch), though I don't have anything more useful beyond that unfortunately

Can confirm that I seem to be running into this same problem on Ubuntu 18.04 with Mesa 18.3.1 (Padoka Stable PPA). Purging the PPA and downgrading to Mesa 18.0.5 seems to fix the issue.

Looks like a nice fix is on it's way to mesa, compiling mesa seems a bit much for my PC but I'll be able to test whenever an updated mesa hits arch's testing

I've just compiled and installed mesa from source and the problem is fixed here!

I can also confirm that it is fixed on mesa-git.

Seems like a new build was pushed to the unofficial binary mesa-git repo and I can confirm it's working good here too :tada: (Mesa 19.0.0-devel (git-69edc972fc))

The upstream contributor who fixed it mentioned that it should be included in the next 18.3.x release (18.3.3) as well as 19.0.0.

Keeping open for now for others would might experience the issue, we can close it once 18.3.3 is released.

It's now fixed in 18.3.3, good job guys!
https://mesa3d.org/relnotes/18.3.3.html

Was this page helpful?
0 / 5 - 0 ratings