should check GPU capabilities and exit gracefully

[adolson]

I think Godot should somehow check if the system can handle GLES2 or not, and instead of aborting or failing, present a meaningful error message to the user about their drivers not supporting GLES2. "Your computer does not appear to currently support GLES2, which is required to run this program. New drivers or hardware upgrade is required." Something along those lines.

I am not sure what this would take to do, but there must be some way to do it in the code.

This is specifically for Windows users who seem to always have crappy GPUs and crappy drivers, but ideally the checks would be on all platforms.

[the-mech]

+1

[SuperUserNameMan]

+10

[hurikhan]

+1

[reduz]

i wrote that code in context_gl_win.cpp but it generally crashes due to
some unimplemented function in windows due to shitty driver
I wish i could exactly find out why

On Sat, Jan 17, 2015 at 2:56 PM, MSC [email protected] wrote:

+1

—
Reply to this email directly or view it on GitHub
#1162 (comment).

[akien-mga]

Setting this as high priority for now as it would be a very useful feature. We get tons of reports of crashes due to people having very old Intel IGPs or whatnot that do not support GLES2.

[akien-mga]

Ok I guess I've referenced enough crashes to underline my above "tons", I'll stop digging through the archives :D

[Heybye44]

+1 Why does Godot magically work on Ubuntu but not on Windows?

[akien-mga]

Any idea on how this could be implemented @reduz?

[techtonik]

i wrote that code in context_gl_win.cpp but it generally crashes due to some unimplemented function in windows

Why not use dynamic linking then? It will be obvious which function is missing. I believe that https://github.com/p3/regal does this.

[reduz]

I already did detection and attempt to show a message, but it seems to
still not work.
As I don' t have any unsupported hardware, I can' t see why it crashes and
thus, can' t fix it.
PRs welcome.

On Tue, Feb 2, 2016 at 12:11 PM, anatoly techtonik <[email protected]

wrote:

i wrote that code in context_gl_win.cpp but it generally crashes due to
some unimplemented function in windows

Why not use dynamic linking then? It will be obvious which function is
missing. I believe that https://github.com/p3/regal does this.

—
Reply to this email directly or view it on GitHub
#1162 (comment).

[akien-mga]

If someone with an old GPU could try to run Godot through gdb on Linux, it might be quite helpful then. The Windows "problem signature" debug info seems quite pointless :/

[techtonik]

I am not doing C++ at all. Only Python, so I am a user. Tell me what to run and I may get the info.

[akien-mga]

Tell me what to run and I may get the info.

I have no clue about how to run stuff through a debugger on Windows, but I think it's non trivial for people who don't have much experience compiling stuff on Windows. That's why I suggested for someone to try to debug with GDB on Linux, as it's very easy to use:

$ gdb /path/to/godot/binary // if possible self-compiled in debug mode, to have more info
-> run
// see that it segfaults in the terminal
-> bt

and copy the output of this bt (backtrace) command to this bug report.

[akien-mga]

Of course it could be that the problem is Windows-specific, so debugging on Linux would be pointless, but I believe Linux users also had segfaults that were not caught to tell the user that their hardware does not support OpenGL(ES) 2.1.

[techtonik]

Beta 2.0 fails on to run on my Linux, but it seems unrelated to graphics card - #3557

[akien-mga]

Hehe you're a lucky one to run into all the known issues we have in corner cases :)

[techtonik]

I guess I just have a "complaining talent" and a GitHub account. =)

[punto-]

Well that's the point of angle, it uses direct 3d instead of opengl :p

On 15 February 2016 at 18:57, anatoly techtonik [email protected]
wrote:

In file included from drivers\angle/common/angleutils.h:12:0,
from drivers\angle\common\angleutils.cpp:7:
drivers\angle/common/platform.h:62:28: fatal error: d3d11_1.h: No such file or directory

include <d3d11_1.h>

                        ^

Fullstop?

—
Reply to this email directly or view it on GitHub
#1162 (comment).

[techtonik]

ANGLE has two backends - older one uses DirectX 9. I am downloading newer MinGW with DirectX 11 headers right now.

[punto-]

the context is created in platform/windows/gl_context_egl_angle.cpp, I
think there was a parameter there to choose the backend.. I think the
problem is in that file, there might be a way to detect what parameters are
best for the system..

On 16 February 2016 at 05:51, anatoly techtonik [email protected]
wrote:

ANGLE has two backends - older one uses DirectX 9. I am downloading newer
MinGW with DirectX 11 headers right now.

—
Reply to this email directly or view it on GitHub
#1162 (comment).

[techtonik]

Lots of errors with newer gcc 5.3.0, for example:

In file included from drivers\angle\common\angleutils.cpp:7:0:
drivers\angle/common/angleutils.h:29:21: warning: defaulted and deleted functions only available with -std=c++11 or -std=gnu++11
     NonCopyable() = default;
                     ^
...

[akien-mga]

You need to add -std=c++11 to the C++ flags I guess.
e.g. add this line after: https://github.com/punto-/godot/blob/angle/drivers/angle/SCsub#L276

env_angle.Append(CCFLAGS=['-std=c++11'])

Not sure if the syntax would work for MSVC though, but with MinGW it should be ok.

[techtonik]

drivers\angle\libANGLE\renderer\d3d\d3d11\win32\NativeWindow.cpp:15:19: fatal error:
dcomp.h: No such file or directory
compilation terminated.

Need to wait for new MinGW release.

[akien-mga]

Maybe the discussion about ANGLE should be moved to a separate issue, keeping this one for "tell the user that their hardware is old and unsupported before crashing"?

[punto-]

yeah I agree

On 17 February 2016 at 13:25, Rémi Verschelde [email protected]
wrote:

Maybe the discussion about ANGLE should be moved to a separate issue,
keeping this one for "tell the user that their hardware is old and
unsupported before crashing"?

—
Reply to this email directly or view it on GitHub
#1162 (comment).

[techtonik]

#3634 is the ANGLE issue. #3694 is PR for getting more information when loading engine.

[chandujr]

@Heybye44

Why does Godot magically work on Ubuntu but not on Windows?

Yes! I would like to know the reason too. It works when I tested with Xubuntu but not on any of Windows editions.

[adolson]

^^

It's not about the OS, it's about the drivers. In general, GL drivers are neglected on Windows in comparison to Linux, thanks to Direct3D. A lot of older-ish GPUs end up with a minimal GL 1.5 implementation on newer versions of Windows.

[WinnerEX]

@adolson

A lot of older-ish GPUs end up with a minimal GL 1.5 implementation on newer versions of Windows.

So when will earlier OpenGL versions be supported in Godot? Is there an absolute explicit necessity to rely on 2.0+? It's not like backwards-compatibility doesn't exist, so a more capable device isn't going to fail at rendering an earlier iteration of OpenGL. Are there features of the visual editor itself built around GLES2 which couldn't be scaled back to use GL1.4 in lieu? I mean, most later GL features are for 3D rendering anyway, which are needless when coming from the perspective of intending to create a 2D game with Godot.

[akien-mga]

@WinnerEX That won't happen. Being compatible with GL 1.4 would mean giving up many interesting features that are used for both 2D and 3D; and at the other end of the spectrum we have people who can't wait any longer for GL 3+ support or even Vulkan. You can safely consider Godot as a GL 2.1+ engine; if that's not what you want, there are plenty of other engines that might have lower GL restrictions (e.g. OGRE 1.9, or SDL 2.0).

The topic here is that Godot should give a proper error when the required GL 2.1+ features are not available instead of crashing; there is no intent to rewrite a GLES1 renderer. For Windows users there might be some hope if ANGLE is integrated for GL emulation via Direct3D, but there won't be a downgrade of the GLES2 renderer.

[akien-mga]

Back to the topic: @reduz, I thought that it might be possible to reproduce the crash even on GL 2.1 capable hardware by trying to load Godot in a virtual machine without 2D and 3D acceleration. I'll give it a try asap to confirm, but that might help find out where it crashes, and how to bail out properly with a human-readable error message instead of segfaulting.

[akien-mga]

I thought that it might be possible to reproduce the crash even on GL 2.1 capable hardware by trying to load Godot in a virtual machine without 2D and 3D acceleration. I'll give it a try asap to confirm

Alright, looks like with VirtualBox 5 it's not easy as it now has a decent GL driver which supports up to OpenGL 3.0 xD.

[reduz]

opengl 3.0 is easier t detect, because you have to request a special conext
(I hopt)

On Mon, Jul 25, 2016 at 12:28 PM, Rémi Verschelde [email protected]
wrote:

I thought that it might be possible to reproduce the crash even on GL 2.1
capable hardware by trying to load Godot in a virtual machine without 2D
and 3D acceleration. I'll give it a try asap to confirm

Alright, looks like with VirtualBox 5 it's not easy as it now has a decent
GL driver which supports up to OpenGL 3.0 xD.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1162 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2_MK5iQA0RxLwv0FHu6po8ucVE8kks5qZNYlgaJpZM4DQoN3
.

[SuperUserNameMan]

I've just made a test on my old netbook with an incompatible crappy intel igp, under Windows.

At line 10791 of rasterizer_gles2.cpp, into RasterizerGLES2::init() i've added these few lines :

    if (!glewIsSupported("GL_VERSION_2_1")) {
        print_line(String("Your graphics card is crappy. It does not support Opengl 2.1. Now Godot is going to crash."));
    }

Godot still crashes, but it displays this error message into the console just before fainting.

I don't know how to tell Godot to cancel the rasterizer initialization ( RasterizerGLES2::init() does not return true/false, it's like if it has no choice but success or crash), neither i know how to tell Godot to quit properly.

Even if this compatibility test might not be 100% reliable, it could at least reduce the number of silent crash, and display a little system dialog box warning the user that it is going to crash and why.

[akien-mga]

Awesome find @SuperUserNameMan. I played around with it a bit and I confirm that it works (at least in my tests where I checked for if (glewIsSupported("GL_VERSION_2_1")) since my GPU supports it). We can use OS::alert() to display a blocking message box.

As you mentioned, the only missing part (and hardest one) is to then let Godot exit properly. I've had a quick look but it's way over my skillset to make Godot quit in the middle of its OS initialization.

Here's a diff of the proof of concept:

diff --git a/drivers/gles2/rasterizer_gles2.cpp b/drivers/gles2/rasterizer_gles2.cpp
index 4cd97a7..910d5bf 100644
--- a/drivers/gles2/rasterizer_gles2.cpp
+++ b/drivers/gles2/rasterizer_gles2.cpp
@@ -10788,8 +10788,14 @@ void RasterizerGLES2::init() {
        if (OS::get_singleton()->is_stdout_verbose()) {
                print_line(String("GLES2: Using GLEW ") + (const char*) glewGetString(GLEW_VERSION));
        }
-#endif

+       // Check for GL 2.1 compatibility, if not bail out
+       if (!glewIsSupported("GL_VERSION_2_1")) {
+               ERR_PRINT("Your system's graphic drivers seem not to support OpenGL 2.1 / GLES 2.0, sorry :(\nTry a drivers update, buy a new GPU or move to Linux; Godot will now exit.");
+               OS::get_singleton()->alert("Your system's graphic drivers seem not to support OpenGL 2.1 / GLES 2.0, sorry :(", "Insufficient OpenGL / GLES drivers");
+               // Now DIE! Or at least stop without segfault and memory leaks :)
+       }
+#endif

To be able to test for people with GL 2.1 support, just remove the ! in the if test.

It spawns this (blocking) message box on X11:

[akien-mga]

After discussing with @reduz, it appears that my above patch could be good enough as a first step; since the OS alert is blocking, we can tell people about the issue and warn them that Godot will crash :) Exiting cleanly would of course be better, but this intermediate solution is already nice to have.

[SuperUserNameMan]

to test under linux without changing the code and recompiling, i think you can set the environment variable MESA_GL_VERSION_OVERRIDE to 2.0 : http://www.mesa3d.org/envvars.html

IIRC, that's also how to proceeded to force MESA to allow black listed GPU to work with Godot.