Godot 2.0 does not run on Nvidia GeForce Go 7300 gfx card with nouveau drivers.

[freemanfromgodotengine]

Operating system or device:
Freshly installed Debian 8 Testing also OpenSusye Tumbleweed (rolling release).
Core2Duo 64-bit laptop, nvidia gfx card (described in laptop specs as Nvidia GeForce Go 7300) with Nouveau display driver (no proprietary drivers installed).

Issue description (what happened, and what was expected):
Clicking Godot's icon outputs "Segmentation fault" in terminal and Godot not starting at all. You can see the the windows blink for a split of the second and that's it.

Steps to reproduce:
Install Debian 8 Testing (or OpenSuse Tumbleweed)
Download Godot files from the official site.
Unpack the files into one directory.
Click Godot_v2.0.1_stable_x11.64 binary or run it from the console.

[akien-mga]

Could you get a gdb backtrace of the segfault?

Also, does the nouveau driver support OpenGL 2.1+ for your card? (gfxinfo | grep -i OpenGL should give the relevant info).

[akien-mga]

The binaries are compressed with upx (package upx-ucl in Debian I think), so you may try to uncompress them to see if it gives a difference.

I believe the syntax to uncompress is upx -d path/to/file.

[freemanfromgodotengine]

Binary that people can download is a release, so gdb gives only:

Reading symbols from ./Godot_v2.0.1_stable_x11.64...(no debugging symbols found)...done.

In pure Debian Testing I can't find gfxinfo tool.

[freemanfromgodotengine]

After decompressing the binary and running it, it still spits segmentation fault.

[akien-mga]

Even without debugging symbols, I think you should be able to get a backtrace, it will just lack line numbers when mentioning the functions that lead to the crash. Release binaries are compiled as release_debug, so they should contain some debug info.

[akien-mga]

In pure Debian Testing I can't find gfxinfo tool.

It's in mesa-utils: https://packages.debian.org/stretch/amd64/mesa-utils/filelist

[freemanfromgodotengine]

glxinfo | grep -i OpenGL
OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NV46
OpenGL version string: 2.1 Mesa 11.1.2
OpenGL shading language version string: 1.20
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 11.1.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
OpenGL ES profile extensions:

So it's OpenGL ES 2.0.

[akien-mga]

Ok, I'm not an expert on what exact GL API we need, but it looks like you're at the lower limit, so that might explain the issue. Did you have previous Godot versions running fine on this hardware with nouveau?

Also to confirm if it's driver-related, could you try to build from source (either the 2.0 branch or the master branch, it wouldn't matter much) and see if you get the same issue? You can compile with target=debug so that you can get more info from gdb if it still crashes.

[freemanfromgodotengine]

I do run Godot on this laptop but always with proprietary drivers, so I expect it's nouveau.
OK, I will compile Godot myself before installing proprietary drivers than.
Then I am going to install proprietary drivers and see if that helps.

[akien-mga]

This report page shows that some GL features seem not to be supported by Gallium on NV46 (as of mesa 10.5.4): http://feedback.wildfiregames.com/report/opengl/device/Gallium%200.4%20on%20NV46
Two of those (GL_ARB_framebuffer_object and GL_ARB_texture_rg) seem to be part of the OpenGL 2.1 specification, so that might be why it's failing.

[freemanfromgodotengine]

After running in gdb is shows only

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe54d6700 (LWP 21931)]
[New Thread 0x7fffe4cd5700 (LWP 21932)]
[New Thread 0x7fffe4c68700 (LWP 21933)]

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()

That's not really helpful, does it?
I probably do not know how to debug properly.
I just issued the run command in gdb.
After that backtrace shows

#0  0x0000000000000000 in ?? ()
#1  0x0000000000555efe in RasterizerGLES2::init (this=0x23e3020) at drivers/gles2/rasterizer_gles2.cpp:10855
#2  0x0000000001373f12 in VisualServerRaster::init (this=0x7fffe9519030) at servers/visual/visual_server_raster.cpp:7639
#3  0x00000000013a9445 in VisualServerWrapMT::init (this=0x7fffe94d8030) at servers/visual/visual_server_wrap_mt.cpp:156
#4  0x000000000040eb33 in OS_X11::initialize (this=0x7fffffffddd0, p_desired=..., p_video_driver=0, p_audio_driver=0) at platform/x11/os_x11.cpp:419
#5  0x000000000041c4e6 in Main::setup2 () at main/main.cpp:857
#6  0x000000000041b581 in Main::setup (execpath=0x7fffffffe521 "/home/me/Software/Github/godot/bin/godot.x11.tools.64", argc=0, argv=0x7fffffffe270, p_second_phase=true) at main/main.cpp:801
#7  0x000000000040c918 in main (argc=1, argv=0x7fffffffe268) at platform/x11/godot_x11.cpp:36

Can I do anything else?

[akien-mga]

The hint about RasterizerGLES2::init seems to confirm that it's an issue in the OpenGL support, it's probably that nouveau does not fully support OpenGL 2.1 features even though it claims to implement 2.1 for your hardware.

So I guess you're stuck with the proprietary drivers :/

[freemanfromgodotengine]

OK, thx for your help.
Proprietary it is.

[freemanfromgodotengine]

To close this issue I just add, that after installing proprietary drivers Godot works like it should.

[akien-mga]

Thanks for reporting back :)
I'll close the issue then, as sadly there's nothing that we can really fix here.

[imirkin]

While nouveau may have any number of bugs, even if it implemented 0 of the functionality of GL 2.1, that's not something you could tell easily from the application. You're probably expecting something very specific to work, which is not required by the spec, and it's failing.

For the recard, ARB_framebuffer_object and ARB_texture_rg are actually part of GL 3.0, not GL 2.1. NV4x should have all of the features of GL 2.1 supported, albeit with some nasty shortcomings that are pretty easy to hit. Those don't result in crashes though, just misrendering.

I don't see any indication in this bug that there's an issue with nouveau's GL implementation, however.

[akien-mga]

Thanks for the input @imirkin, I'll link it in the more general issue #1162 which is related to this one. Though #1162 is about not segfaulting when GL 2.1 features are missing, and this issue here seems to indicate that it crashes even though nouveau should support the necessary feature, so there's maybe a deeper issue in Godot's renderer code.

[imirkin]

And just to be clear, the nv30 driver (which implements GL support for nv3x and nv4x GPUs - the former are stuck on GL 1.5 due to lack of NPOT) is no work of perfection - it's entirely possible that features are misimplemented, and that crashes lurk within the driver. The nv50/nvc0 drivers are in much better shape wrt conformance.

However scanning through this bug, I just don't see any specific indication of something going wrong in nouveau. Not to say it's not :) But a "well, it works on nvidia" comment generally just implies the application was developed against the nvidia driver, not that some other driver is non-conformant.

[karolherbst]

GLEW only sets the glGenerateMipmap function pointer if GL_ARB_framebuffer_object is detected. So you should check if this extension is there before using the functions

[imirkin]

Perhaps worth noting is that nv4x does support EXT_framebuffer_object, which has a glGenerateMipmapEXT. The main distinction is that the ARB version allows attachments of different sizes. Probably a handful of other differences as well.

[freemanfromgodotengine]

For the record here is more relevant debug output:

(gdb) run
Starting program: /home/me/Software/Github/godot/bin/godot.x11.tools.64
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe54d6700 (LWP 1340)]
[New Thread 0x7fffe4cd5700 (LWP 1341)]
[New Thread 0x7fffe4c68700 (LWP 1342)]

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) frame 1
#1  0x0000000000555efe in RasterizerGLES2::init (this=0x23e3040)
    at drivers/gles2/rasterizer_gles2.cpp:10855
10855        glGenerateMipmap(GL_TEXTURE_2D);
(gdb) x glGenerateMipmap
0x7ffff6394f00 <glGenerateMipmapEXT>:    0xe1058b48
(gdb) 

[karolherbst]

sadly gdb only shows the entry point of the mesa library and not what glew has stored, they use strange symbol names.

[akien-mga]

Some interesting info about a potentially related issue in #686 (comment)

[imirkin]

I think it's different... there it's about glGenerateMipmap being buggy in some blob drivers, while here it's about you calling glGenerateMipmap when it's not supported (it requires GL_ARB_framebuffer_object or GL 3.0).

As an aside, your renderer is called "gles2", but from what I can tell it's creating regular desktop GL contexts (see platform/x11/context_gl_x11.cpp). If you really were creating a GLES context, even with gles2, you'd have glGenerateMipmap, glBindFramebuffer, etc. [But the GLEW that you're using would be none the wiser and fail pretty miserably - it also really expects a desktop context.]

[reduz]

The GLES2 driver will be rewritten in 3.0, so maybe we can manage to get it to work then

[freemanfromgodotengine]

@reduz I am glad to report, that the issue is gone. It happened somewhere between 2.1-stable and 2.1.3.
Godot 2.1-stable still quits on that laptop of mine with open-source nouveau nVidia drivers. Version 2.1.3 runs just fine.
Thank you! :)