-
-
Notifications
You must be signed in to change notification settings - Fork 21.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add OpenGL renderer #53150
Add OpenGL renderer #53150
Conversation
A couple notes:
|
I think that it should be temporary to CI to see progress by adding godot/.github/workflows/linux_builds.yml Lines 115 to 127 in 8abd460
|
That's likely because of one of two reasons:
The renderer will be modified to use core profile eventually, but this will take a while. Also, remember that Sandy Bridge IGPs don't have fully functional OpenGL 3.3 support. It's nonexistent on Windows and very limited on Linux (to the point of being unusable). |
Is Godot 4.0 launching without html5/web support then? |
It depends on whether we can finish this OpenGL renderer (+ the WebGL platform port) in time for 4.0's release. We can't promise anything yet. Either way, WebGPU isn't likely to be implemented until 4.1 at least, so OpenGL via WebGL is our only option for HTML5 in the short term. |
Would love a concise answer. I understand 3.x is supported, but my question was specific to 4.0. I'm not looking for promises, it would just be nice to be clear about this so developers can plan accordingly. From other contributer comments, it seems Vulkan is going to be the only supported initial backend for 4.0. Connecting the dots would therefore mean that web export won't be supported in 4.0 correct? WebGPU isn't a viable option right now, nor the relatively near future. I think this is an important platform to confirm this one way or the other. |
I guess the PR of the actual renderer impl isn't the best place to ask these questions, but it would be nice to know if the plan is to have this available in 4.0 or not. It's fine either way, just nice to know so people can plan and adjust accordingly. |
Indeed, the HTML5 export and web editor won't be available in 4.x until some way to render graphics is implemented in the |
8fb7caf
to
81d4982
Compare
The Windows build (compiled with MinGW) seems to crash on startup, but Vulkan also crashes in the same branch anyway. I haven't investigated this yet. I tested X11 again today and it still works as expected, both with OpenGL and Vulkan (from the same binary). |
15ea9d0
to
6d7522e
Compare
This is a good start! I was able to get it running on Windows (PR here Calinou#6) A couple of things we need to take a look at still:
|
I think the next step should be to remove our usage of the GLES2 API. That will allow us to use renderdoc and diagnose why viewports are not working correctly. |
3647d7a
to
77968a3
Compare
Just a question: Wouldn't it be feasible to implement the OpenGL backend as a RenderingDevice? For example wgpu-rs is implementing the same interface in their GLES implementation as Vulkan (and DX12, Metal ... etc.): Yes, there are a lot of quirks they also list in their mod.rs, but it could still be worth it if the rest of the renderer (probably only the mobile version) could be reused. Shaders are of course an issue, but they could be handled by e.g. SPIRV-Cross. |
@kisg There are several issues I can see with using RenderingDevice for an OpenGL (ES) renderer:
|
Okay, I've submitted a pull request that removes much of the deprecated GLES2 functions (enough to get core profile working anyway). I have also fixed the bug that made viewports not display. Calinou#7 So right now we have a minimal 2D renderer in OpenGL 3.3 on Windows. @Calinou If you can set the X11 platform to core profile and verify that it works there as well then I think we have a minimal working example here! |
First implementation with linux display manager Co-authored-by:clayjohn <claynjohn@gmail.com> Co-authored-by:Fabio Alessandrelli <fabio.alessandrelli@gmail.com>
…ing work - Mark the driver name setting as requiring a project restart.
This also enables building OpenGL for Windows.
This is consistent with `VULKAN_ENABLED`.
@clayjohn's pull request was merged, which means the 2D editor now works as expected: Using single-window mode is still recommended for now, as the main window will currently appear to freeze when a subwindow is open (at least on Linux). Edit: Rebased against the latest |
3be502c
to
d5c32e8
Compare
@Calinou What is needed to get this out of draft? Perhaps just removing rasterizer_array? In my opinion, we should be merging this sooner rather than later, even in its incomplete state so that we can unblock contributors. |
Build fix: diff --git a/drivers/opengl/shader_compiler_opengl.cpp b/drivers/opengl/shader_compiler_opengl.cpp
index 9638626d78..3b4ea1d30c 100644
--- a/drivers/opengl/shader_compiler_opengl.cpp
+++ b/drivers/opengl/shader_compiler_opengl.cpp
@@ -860,7 +860,7 @@ Error ShaderCompilerOpenGL::compile(RS::ShaderMode p_mode, const String &p_code,
print_line(itos(i + 1) + " " + shader[i]);
}
- _err_print_error(NULL, p_path.utf8().get_data(), parser.get_error_line(), parser.get_error_text().utf8().get_data(), ERR_HANDLER_SHADER);
+ _err_print_error(NULL, p_path.utf8().get_data(), parser.get_error_line(), parser.get_error_text().utf8().get_data(), false, ERR_HANDLER_SHADER);
return err;
}
Could also be |
Sounds good to me. We should see if we can hide the 3D editor (and use 2D as the default editor) when using OpenGL, but this can be done in a future PR. |
I don't think we need to worry. We won't expose OpenGL as an option under the "New Project" menu until we add the 3D renderer (which shouldn't take long as we will mostly be copying the GLES2 renderer). |
Yeah I think it's fine if there are obvious broken things in 3D, no need to work it around. Bugs in WIP features are expected :) That can be an incentive for contributors to help fix some of the issues if they're interested. |
platform/android/export/export.cpp
Outdated
@@ -31,6 +31,2833 @@ | |||
#include "export.h" | |||
|
|||
#include "export_plugin.h" | |||
//#include "core/config/project_settings.h" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Im guessing we can get rid of all the commented out code?
platform/iphone/export/export.cpp
Outdated
@@ -31,6 +31,1929 @@ | |||
#include "export.h" | |||
|
|||
#include "export_plugin.h" | |||
//#include "core/config/project_settings.h" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment as above? Should we really be adding thousands of lines of commented out code?
@@ -32,6 +32,678 @@ | |||
|
|||
#include "export_plugin.h" | |||
|
|||
/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am seeing a theme. Perhaps @lawnjelly knows why this code is included but is commented out
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bear in mind this is originally from a very WIP branch. I've a feeling I copied these files either from the existing 4.x branch or 3.x and the compiler was complaining about them, so I just commented them out - had no idea whether they were still needed so keeping them commented allowed examining them later. I know very little about the exporters.
Actually I think they were during the rebase, so it may have represented changes in the exporters that had happened in the 6 months in between when I originally wrote it, so if the comments are the only difference in the diff, they are probably safe to delete.
It'd be nice if (maybe in a future PR) OpenGL could automatically be used if Vulkan isn't supported instead of having to manually specify to use OpenGL with the |
The renderer can still be changed in the Project Settings or using the `--rendering-driver opengl` command line argument.
I removed commented out code and some OpenGL debugging prints. The renderer dropdown is also temporarily hidden until OpenGL support is more mature. You can still change the rendering driver in the advanced Project Settings or using There's still an issue with errors appearing on startup on a brand new project: Vulkan
OpenGL
The |
Superseded by #54307. |
Based on @lawnjelly's efforts on the GLES2 renderer here: #44399 🙂
Despite the news article stating that OpenGL support will return in Godot 4.1, this pull request is targeting a merge for Godot 4.0. However, we don't expect this OpenGL renderer to be fully complete (especially on the 3D side) when Godot 4.0 is released. Nonetheless, it may still be sufficient for many 2D games and non-game applications that want to maximize compatibility.
Commits are unsquashed for now to ease troubleshooting and tracking regressions. Most of them should be squashed before merging this PR.
This closes godotengine/godot-proposals#877.
OpenGL renderer's advantages over Vulkan
When targeting desktop platforms, using Vulkan is still recommended for several reasons:
Vulkan renderer's advantages over OpenGL
Nonetheless, for mobile platforms, I expect OpenGL to be more prevalent for a while.
Differences from lawnjelly's pull request
gles_common
abstraction as there will only be one OpenGL renderer.--rendering-driver opengl
to force a project to start with the OpenGL renderer, or use the dropdown in the top-right corner of the editor.Current limitations
TODO
GLES_ENABLED
andOPENGL_BACKEND_ENABLED
defines. Should we merge them withOPENGL_ENABLED
to be consistent withVULKAN_ENABLED
?Preview