[WIP] Godot 4 GLES2 2D renderer + linux display manager #44399
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Crash when opening - fixedI can't open Godot with Vulkan video driver when compiled with GLES 2 and 3 also crashes with similar errors |
lawnjelly
force-pushed
the
jarjar
branch
2 times, most recently
from
0e32d7a to
6b7148b
Compare
Fixed@qarmin : Yes this is probably due to something akien let me know earlier that I'd been confusing the display driver string with the renderer driver string. It is not clear in the existing source (and no comments) and it had some left over code from 3.2 which was using this string for gles2, gles3 selection, where now it may be used for wayland, x etc.I'll have a look at that soon, it should not be a big deal. For now run it without specifying driver in the command line. It will run the project manager in vulkan. You can only select vulkan for new project (as reduz doesn't want to be able to select gles2) but once in the project there is an API selection box in the top right, and you can change it to GLES2. Note that currently it can only work in x11, in windows I had to compile it out with a #define, because there are some compile errors and I don't have windows so can't fix / debug that platform. I'll be able to do middle layers for linux and probably android, clayjohn should be able to do windows. We'll need someone else to do iOS / mac, but that can wait as we can get onto GLES3 first, as GLES3 is the main target for Godot 4, the middle layers will work with both APIs, and GLES3 may be easier for others to debug as it works with renderdoc. |
lawnjelly
force-pushed
the
jarjar
branch
5 times, most recently
from
e238572 to
9f109f2
Compare
Allocation memory fails when opening - fixedOpening project in editor -RegressionTestProject.zip with GLES 2 cause crash due to too big allocation size |
Fixed> Opening project in editor -[RegressionTestProject.zip](https://github.com/godotengine/godot/files/5719816/RegressionTestProject.zip) with GLES 2 cause crash due to too big allocation size > EDIT: It happens with all, even new projects, example CI - https://github.com/godotengine/regression-test-project/pull/9/checks?check_run_id=1584212594I'll take a look. This may be because some new Godot 4 shaders for 3d gizmos created by the editor do not compile in GLES2. It could be that because they don't compile this is causing errors down the line. I haven't thought about how to deal with these shaders yet, as they are for 3d they haven't been high priority as I'm only getting 2d working for now. But yeah having them cause errors is not good. EDIT: This is now fixed. It does seem to be as I hypothesized above. Some The correct fix later on will take a little more thought: maybe to get these shaders to compile, or prevent them being attempted, not sure yet. |
|
Now I have when opening and closing empty project(with only empty e.g. |
|
When opening this project in editor - THE_WORST_WITHOUT_SCRIPTS.zip - (just a few scenes with almost all available nodes without any scripts), then I have crash almost immediately: |
There is an error in the project file, to select GLES2, the project setting has changed. The line should be: The old |
These leaks seem to be in vulkan + 3d. (see above). There probably are some leaks in 2d however! 😁 |
|
This lines in To run project in editor I used this two commands: so I'm sure that I opened project with correct renderer. I wrote about memory leaks, because I checked that they happens only with GLES2. Also when opening |
|
Not quite sure what is happening for you at the moment. EDIT Detecting prime with multiple GPUs is in after all, I just didn't realise it worked by setting an environmental variable, so hopefully that isn't a problem. I did just try the Unfortunately I had rebased and pushed since your original post and the line numbers don't line up any more so it's difficult to pinpoint what is happening. Leaks in There can also be a shed load of warnings in the log: I think this is the 3d gizmo shaders not compiling. This happens when you have a 3d scene open (as there is no 3d in GLES2 yet, and presumably the dummy stub functions return INSTANCE_NONE). |
|
At this point anyone running it successfully reporting info would be useful too, you can use the artifacts from the CI builds I think. (This is linux only at the moment). For me it runs fine in normal (multi window) mode and also with the @Faless has also reported a threading issue in some of the new Godot 4.0 APIs which can cause a crash in some circumstances. This may be because OpenGL calls should be made on the main thread (or rather the GL context can only be current in 1 thread, but I think we are just using main thread), and the APIs can be called from other threads. Reduz is aware and says he will work on a fix. This may be responsible for the deadlock I saw when running with the |
|
Now I can't open any project(even empty) in editor due crashes Looks that this is issue with Nvidia, because in CI everything works fine without any crashes - https://github.com/qarmin/RegressionTestProject/runs/1686662513 Godot crash inside |
|
I haven't changed much, only added the bootscreen and vsync. The place where it crashes isn't very informative, it suggests maybe GL is in a bad state, something has caused an error earlier on, or it is a threading problem. In fact it most likely is calling GL from the wrong thread looking at the call stack. This may be related to why some of the previews don't work on mine, maybe it has better error fallback on some drivers than others. The threading problem which @Faless reported has still to be fixed - there were some changes to the API in 4.0, which reduz said he was going to fix (although he has a long todo list). There may be some assumptions that have been made in 4.0 about multithreaded rendering which just don't work with GLES, so will either need rewriting in the calling code, or workarounds in the renderer (like in this case I can perhaps defer generating the GL id until the texture is used from the main thread - a similar problem may occur with upload to the texture). I will do what I can, but at the moment we are partly waiting for reduz to stabilize the API with the vulkan stuff so we can merge GLES2 and iron out these problems and start on GLES3. He said he will need another month or so to finish up. EDIT : I would double check your project is set to |
|
Yes I'm now pretty convinced the crash is occurring on some drivers because the GL functions are being called from non-main thread. It is only 'working' on mine because the driver is gracefully handling the error, and this finally seems to be the reason for the black texture for the small preview for the default icon in the IDE. I've put in some basic protection for this situation - it records the main thread ID at initialization, and ERR_FAILS if the current thread is not the main thread for the texture create and set calls. So the threaded resource previews is broken, but hopefully we can get it not to crash. I had a look at deferring these calls but it is quite messy, it would be easier if we could just call generate editor previews single threaded when using GLES renderers, so I'll enquire as to whether this is possible. |
First implementation with linux display manager Co-authored-by:clayjohn <claynjohn@gmail.com> Co-authored-by:Fabio Alessandrelli <fabio.alessandrelli@gmail.com>
|
The threading issue causing crashes / bugs from EditorResourcePreview should now be fixed.
It is still possible that there might be somewhere else in the engine which tries to use the renderer from a non-main thread, let me know if there are any more problems / crashes and I will try to fix them too. |
|
This really broken project(must be run from CLI not editor to avoid spam about using invalid functions etc.) - TheWorstGodotTestProject.zip - after importing and running crash with this backtrace: |
Fixed. And another similar bug in texture->set_data. It seems to run now ok for me (although I only ran it for 30 seconds or so). It does seems to be continually using up memory though, I don't know if that is expected with your project. So it will probably eventually fail from lack of memory. |
|
Superseded by #54307. Thanks again for doing the initial work 🙂 |
First implementation with linux display manager
Co-authored-by:clayjohn claynjohn@gmail.com
Co-authored-by:Fabio Alessandrelli fabio.alessandrelli@gmail.com
Explanation
The GLES backends consist of 3 modules:
The middle layers are rewritten compared to 3.2, notably they should handle multiple windows and context sharing, although they share some code with 3.2. They act as a middle man between the display module (x11, windows etc) and the renderer, and get the API into the correct state for everything to work.
As such there will be a certain amount of writing / debugging / alpha testing middle layers. The main priority at first is getting some usable middle layers for linux and windows, the other platforms can be added at leisure.
The 2D is bare bones to get the basics working, and batching is commented out for now. 3D is just stubs so will not display.
Notes