Allow to disable RenderingDevice and/or its renderers while compiling#103100
Allow to disable RenderingDevice and/or its renderers while compiling#103100YeldhamDev wants to merge 1 commit into
RenderingDevice and/or its renderers while compiling#103100Conversation
|
How much of a size decrease did you measure? |
470f20f to
b8c3795
Compare
|
@clayjohn I've updated the OP with the info. |
b8c3795 to
ace65ea
Compare
There was a problem hiding this comment.
Tested locally, it works as expected.
Linux x86_64 release export template stripped binary size (production=yes lto=full):
- Default: 72,126,160 bytes
vulkan=no: 69,537,616 bytesvulkan=no opengl3=no: 67,690,552 bytesrendering_device=no: 62,368,304 bytesrendering_device=no opengl3=no: 60,611,224 bytes- The resulting binary doesn't include any rendering drivers but will still try to spawn a window (and fail with an error; see below). I suppose it should automatically run in headless mode instead to mimic 3.x's headless binaries, but that can be done in a future PR.
When you disable all RenderingDevice drivers for the target platform, rendering_device=no should be implied so you get the smallest possible binary size (unless there is a reason to keep it I'm not aware of).
On Linux and Android, this is the case when using vulkan=no. On Windows, this is the case with vulkan=no d3d12=no, and on macOS/iOS, this is the case with vulkan=no metal=no. The web platform should always imply rendering_device=no.
Error when running a binary with no rendering drivers:
❯ bin/godot.linuxbsd.template_release.x86_64 --path /tmp/test_empty_project
ERROR: No renderers available.
at: setup (main/main.cpp:2249)
Godot Engine v4.4.beta.custom_build.b8c37952b (2025-02-21 00:13:28 UTC) - https://godotengine.org
ERROR: Video driver not found.
at: DisplayServerX11 (platform/linuxbsd/x11/display_server_x11.cpp:6883)
WARNING: Display driver x11 failed, falling back to wayland.
at: setup2 (main/main.cpp:3017)
ERROR: Can't connect to a Wayland display.
at: init (platform/linuxbsd/wayland/wayland_thread.cpp:3909)
ERROR: Could not initialize the Wayland thread.
at: DisplayServerWayland (platform/linuxbsd/wayland/display_server_wayland.cpp:1421)
ERROR: Can't create the Wayland display server.
at: create_func (platform/linuxbsd/wayland/display_server_wayland.cpp:1395)
ERROR: Unable to create DisplayServer, all display drivers failed.
Use "--headless" command line argument to run the engine in headless mode if this is desired (e.g. for continuous integration).
at: setup2 (main/main.cpp:3027)
WARNING: ObjectDB instances leaked at exit (run with --verbose for details).
at: cleanup (core/object/object.cpp:2378)
When running the same binary with --headless, an error is printed but the program keeps on running correctly:
❯ bin/godot.linuxbsd.template_release.x86_64 --path /tmp/test_empty_project --headless
ERROR: No renderers available.
at: setup (main/main.cpp:2249)
Godot Engine v4.4.beta.custom_build.b8c37952b (2025-02-21 00:13:28 UTC) - https://godotengine.org
If I'm not mistaken, I think it's possible to create custom renderers that use |
b17bb08 to
e22f208
Compare
|
I've updated the PR to silence the error about no renders being available if the binary is running in headless mode. |
e22f208 to
56d2bcd
Compare
56d2bcd to
c414d0e
Compare
akien-mga
left a comment
There was a problem hiding this comment.
Looks good overall! I don't love the added boilerplate and hacks but the size gains are worth it, and the hacks are still reasonable.
| #ifdef RD_ENABLED | ||
| virtual RenderingDevice::DeviceType get_video_adapter_type() const override { return RenderingDevice::DeviceType::DEVICE_TYPE_OTHER; } | ||
| #endif // RD_ENABLED |
There was a problem hiding this comment.
This is a bug that we should fix, GLES3 shouldn't depend on RenderingDevice.
I think it's just a mistake here and the DeviceType enum should likely be define somewhere else. I understand that it makes sense exposed in a class named RenderingDevice but if it's used elsewhere it should be in a more generic class (RenderingServer maybe?).
And well actually it's not even supported here, it's just something that shouldn't be part of the abstract API in this form.
CC @clayjohn
| #ifdef RD_ENABLED | ||
| // This is needed because the main RD is created on the main thread. | ||
| RenderingDevice::get_singleton()->make_current(); | ||
| #endif // RD_ENABLED |
There was a problem hiding this comment.
That's also a hack we should solve somehow, this breaks encapsulation.
CC @godotengine/rendering
| #ifdef RD_ENABLED | ||
| RenderingDevice *get_rendering_device() const; | ||
| RenderingDevice *create_local_rendering_device() const; | ||
| #endif // RD_ENABLED |
There was a problem hiding this comment.
These also break encapsulation, but I guess solving that will be trickier / not possible.
| // In due time this will need to be enhance to return the correct INTERNAL RID for the chosen rendering engine. | ||
| // So once a GLES driver is implemented we'll return that and the implemented plugin needs to handle this correctly too. |
There was a problem hiding this comment.
FYI @BastiaanOlij @dsnopek - the OpenGL driver is implemented ;)
There was a problem hiding this comment.
I'm not sure why we have this. Is this a utility function meant to be used by child classes of XRInterfaceExtension? If so, I don't think they need it, there's RenderingServer::texture_get_rd_texture() exposed. Maybe this is something that can be deprecated?
Given that we have OpenXR in Godot itself now, it's possible XRInterfaceExtension was never fully baked...
There was a problem hiding this comment.
Or, hm, this takes the render target, not the RID of the RenderingServer texture. So, maybe we do need this as a utility function? Would be nice for it to be on RenderingServer, though, and not here
There was a problem hiding this comment.
This is something I wrote waaaaaaaaaaay at the beginning and probably came from translating the implementation in Godot 3 to Godot 4. I'm not even sure if there are implementations that use this. Maybe the TiltFive GDExtension? Though that works with OpenGL so more reason to think this is a defunct method...
6b135ac to
efa82f3
Compare
fdd5075 to
64806e6
Compare
|
I tried compiling on Windows with and I'm getting lots of compilation errors about undefined RD. |
64806e6 to
3ecc3ed
Compare
b254e00 to
2b7ad5e
Compare
|
Still does not compile: (sorry for non-English errors, you can look up their error code) |
2b7ad5e to
55f575c
Compare
|
It compiles on Windows now and the editor seems to work correctly. The |
55f575c to
e4d0278
Compare
|
I've added a |
e4d0278 to
c78590e
Compare
137b494 to
eab2f1a
Compare
eab2f1a to
4acc400
Compare
|
Rebased, again...
No clue why. CC @godotengine/xr |
4acc400 to
05e81e6
Compare
05e81e6 to
8ab5085
Compare
8ab5085 to
b0d2b35
Compare
This PR makes so that the engine can be compiled without
RenderingDevice, and/or the renderers that make use of it (Forward+ and Mobile). This allows for builds that only make use of the compatibility render to cut extra fat from their binaries.I mainly tested this on GNU/Linux, testers from other OSes are appreciated.
Here's a comparison of binary sizes (GNU/Linux, Template Release):
Sponsored By: 🐺 Lone Wolf Technology / 🍀 W4 Games.