[build][CMake] REVIEWED: DRM software renderer configuration

[Peter0x44]

#5720 (comment)

In this comment, it was pointed out that LibraryConfigurations.cmake still tries to find and link egl, gbm, and glesv2, even when using the software renderer is it not necessary.

This patch addresses that.

[Peter0x44]

@Bigfoot71 Can you test this out?

[Peter0x44]

Also @raysan5 I noticed that build.zig also makes similar assumptions and doesn’t currently expose the software renderer option, so you may want to ask zig maintainers to review that.

[Peter0x44]

I also noticed DRM is setting: set(GRAPHICS "GRAPHICS_API_OPENGL_ES2")
unconditionally. Is this intended? is opengl es3 or desktop gl not intended to be usable here?

[raysan5]

@Peter0x44 Thanks for the review!

Also @raysan5 I noticed that build.zig also makes similar assumptions and doesn’t currently expose the software renderer option, so you may want to ask zig maintainers to review that.

Yeap, not all build systems are updated for the software renderer backend yet. @michaelfiber, @Not-Nik please, could you take a look to build.zig to support the software renderer option on (at least) PLATFORM_DESKTOP_SDL, PLATFORM_DRM?

I also noticed DRM is setting: set(GRAPHICS "GRAPHICS_API_OPENGL_ES2") unconditionally. Is this intended? is opengl es3 or desktop gl not intended to be usable here?

PLATFORM_DRM was a remake of the old PLATFORM_RPI, that only supported OpenGL ES 2.0, since OpenGL ES 3.0 support was added a while ago, that option can also be added to build system. I don't know if PLATFORM_DRM supports other desktop OpenGL versions.

[Peter0x44]

PLATFORM_DRM was a remake of the old PLATFORM_RPI, that only supported OpenGL ES 2.0, since OpenGL ES 3.0 support was added a while ago, that option can also be added to build system. I don't know if PLATFORM_DRM supports other desktop OpenGL versions.

OK, that's something I can look in to at some point. But it's clearly not in-scope for this PR.

[Bigfoot71]

@Bigfoot71 Can you test this out?

I was able to test it, no more issues with rlsw or ES2.

---

@raysan5 By the way, to test on desktop (via nvidia emulation), I had to pass an EGL_NONE terminated array for attrib_list in eglChooseConfig instead of NULL:

    const EGLint count_attribs[] = { EGL_NONE };
    if (!eglChooseConfig(platform.device, count_attribs, NULL, 0, &numConfigs))
    {
        TRACELOG(LOG_WARNING, "DISPLAY: Failed to get EGL config count: 0x%x", eglGetError());
        return -1;
    }

Otherwise it crashed on driver side, likely an nvidia bug, since NULL is supposed to be accepted according to the doc:

attrib_list: NULL, or a list of zero or more attributes terminated with
EGL_NONE. Contains elements from table in “Attribute Lists” except
for EGL_MAX_PBUFFER_WIDTH, EGL_MAX_PBUFFER_HEIGHT,
or EGL_MAX_PBUFFER_PIXELS.

Source: https://www.khronos.org/files/egl-1-4-quick-reference-card.pdf

Leaving this here just in case.

[Not-Nik]

could you take a look to build.zig to support the software renderer option on (at least) PLATFORM_DESKTOP_SDL, PLATFORM_DRM?

I don't think SDL is properly supported, because the Zig build script doesn't link against it. Additionally, several platforms are missing, which means the whole thing probably needs a thorough review, something I unfortunately don't have time for. Here's the diff for just adding support for DRM/Software GL:

diff --git a/build.zig b/build.zig
index ec254deb..1aedc58f 100644
--- a/build.zig
+++ b/build.zig
@@ -202,8 +202,10 @@ fn compileRaylib(b: *std.Build, target: std.Build.ResolvedTarget, optimize: std.
                     raylib.root_module.addCMacro("GRAPHICS_API_OPENGL_ES2", "");
                 }
 
-                raylib.root_module.linkSystemLibrary("EGL", .{});
-                raylib.root_module.linkSystemLibrary("gbm", .{});
+                if (options.opengl_version != .gl_soft) {
+                    raylib.root_module.linkSystemLibrary("EGL", .{});
+                    raylib.root_module.linkSystemLibrary("gbm", .{});
+                }
                 raylib.root_module.linkSystemLibrary("libdrm", .{ .use_pkg_config = .force });
 
                 raylib.root_module.addCMacro("PLATFORM_DRM", "");
@@ -416,6 +418,7 @@ pub const Options = struct {
 
 pub const OpenglVersion = enum {
     auto,
+    gl_soft,
     gl_1_1,
     gl_2_1,
     gl_3_3,
@@ -426,6 +429,7 @@ pub const OpenglVersion = enum {
     pub fn toCMacroStr(self: @This()) []const u8 {
         switch (self) {
             .auto => @panic("OpenglVersion.auto cannot be turned into a C macro string"),
+            .gl_soft => return "GRAPHICS_API_OPENGL_SOFTWARE",
             .gl_1_1 => return "GRAPHICS_API_OPENGL_11",
             .gl_2_1 => return "GRAPHICS_API_OPENGL_21",
             .gl_3_3 => return "GRAPHICS_API_OPENGL_33",

On another note, cmake/LibraryConfigurations.cmake includes an extra

if (${PLATFORM} MATCHES "Desktop")
    set(LIBS_PRIVATE ${LIBS_PRIVATE} glfw)
endif ()

at the end, which I suspect is not correct (Desktop systems without GLFW may fail to compile). c53dd8a fixed this, but was reverted, because of CI failures. The errors look like linking to GLFW includes some extra libraries that raylib depends on. In other words, GLFW links to libabc. raylib links to GLFW. So raylib also links to libabc¹. I believe raylib has some deep rooted linker issues in its build script, with extraneous linking requirements and confusing dependency trees, all of which I also don't have time to investigate.

Footnotes

1. There's to many edge cases to talk about here, but for the symbols these errors mention, this holds true. ↩

[raysan5]

OK, that's something I can look in to at some point. But it's clearly not in-scope for this PR.

@Peter0x44 Yeap, out of scope for this PR and it can be reviewed later on, probably after raylib 6.0 release.

By the way, to test on desktop (via nvidia emulation), I had to pass an EGL_NONE terminated array for attrib_list in eglChooseConfig instead of NULL

@Bigfoot71 Wow! Good catch! Not sure how to address this kind of hardware-dependant issue, does your approach of a EGL_NONE array work on all paltforms? It could be applied with a comment explaining this issue.

I believe raylib has some deep rooted linker issues in its build script, with extraneous linking requirements and confusing dependency trees, all of which I also don't have time to investigate.

That's a bit worrying, I did not maintain the CMake build system and many contributors added changes to that system, definitely it needs some full sanity review. I'm taking note.

[Bigfoot71]

Wow! Good catch! Not sure how to address this kind of hardware-dependant issue, does your approach of a EGL_NONE array work on all paltforms? It could be applied with a comment explaining this issue.

Both are standard according to the spec but since this only affects a very specific case (desktop nvidia + DRM), and the current code works fine on RPi, I'd leave it as-is. The fix is documented here if anyone ever hits it.