glew and OpenGL Core profile (affects mostly mesa)

[ChristophHaag]

This would also fix #1531

Many people seem to have problems with glew and the OpenGL Core Profile, mainly because of this bug: http://sourceforge.net/p/glew/bugs/120/

Other projects like RBDoom3BFG include a fixed copy of glew, but in this case I appplied e.g. http://sourceforge.net/p/glew/patches/40/ to my system glew installation to get it to work.

Then, with a fixed glew, glewExperimental = GL_TRUE; can be completely removed.

Next it is segfaulting in stk-code/src/graphics/stkscenemanager.cpp:712 when selecting Single Player game. This is

711     if (irr_driver->hasBufferStorageExtension())
712         glMemoryBarrier(GL_CLIENT_MAPPED_BUFFER_BARRIER_BIT);

I really don't know, if this ought to be supported. Here is the spec to the extension: https://www.opengl.org/registry/specs/ARB/buffer_storage.txt
Here it says the specific function is in Core since 4.2: http://www.opengl.org/wiki/GLAPI/glMemoryBarrier

Maybe someone else who knows this better can say if this is a driver bug or a glew bug or if an additional check in stk is needed.

Anyway, commenting out these two lines (I know) yields a working game. But there are a lot of OpenGL errors. Here is a xz compressed log (because it's 33 megabyte) of starting a game, driving for a few seconds and then quitting the game: http://haagch.frickel.club/files/stk-err.log.xz

Note: This is on the second lowest graphical preset. If I change to the highest, I run into the assertion at stk-code/src/graphics/glwrap.cpp, line 350 when going to the single player menu option: assert(result == GL_FRAMEBUFFER_COMPLETE_EXT);. But I can just comment that out too and the game will still "sorta" work.

So the mesa opengl support is kinda broken at the moment and I believe it is mostly due to glew.

Sorry, if I made any mistakes here, being kinda tired.

[vlj]

I went the linux macro route because I would prefer not to embed libglew in stk code.
Of course libglew is not a fast evolving lib (a new version each year when a new GL revision is introduced) so it's a matter of taste.

For the others crashes I assumed maybe too fast that where buffer storage extension is supported so is memory barrier functions (which are included in some image load/store extension iirc). While whithout MemoryBarrier it may work it can also introduce some race condition.

For GL_FRAMEBUFFER_COMPLETE_EXT you need this patch on top of mesa 10.4 :
http://lists.freedesktop.org/archives/mesa-dev/2014-September/067645.html
otherwise you need to disable shadow/GI

[ChristophHaag]

Thanks for the info for the patch.

I had a few further looks:

The line #extension GL_ARB_bindless_texture : disable in a shader produces this warning on mesa:

[warn   ] GLWrap: OpenGL debug callback - SHADER_COMPILER
[warn   ] GLWrap:     Error type : OTHER
[warn   ] GLWrap:     Severity : HIGH
[warn   ] GLWrap:     Message : 0:2(12): warning: extension `GL_ARB_bindless_texture' unsupported in vertex shader

I have also looked where a few of the other OpenGL warnings come from:
stk-code/lib/irrlicht/source/Irrlicht/COpenGLExtensionHandler.cpp:340
stk-code/lib/irrlicht/source/Irrlicht/COpenGLDriver.cpp:1030
stk-code/lib/irrlicht/source/Irrlicht/COpenGLDriver.cpp:2534
etc.
These are calls to the legacy functions.
I guess this has to wait for the irrlicht engine 1.9 with core context support anyway.
Sorry for the noise.

"Not fast evolving" is kind of an euphemism for not fixing at least the most glaring and easily fixable bug for 4+ years of using glGetString(GL_EXTENSIONS) in a core context. But that's none of my business.

[konstin]

FYI: As STK uses a heavily altered version of irrlicht, it might not be possible to just switch to 1.9 . According to vlj, the warnings flooding the terminal are triggered by irrlicht, so this could be hard to get rid of that.

[hiker]

I originally suggested to include glew with stk. If there is a patch to be applied in order for STK to work, we can do it in our local copy. Additionally it solves the issue of other people not being able to find a new enough libglew version for their distribution (e.g. we have one artist who now can't even compile stk anymore since glew 1.10 is not easily available as a package, and we can't really expect everyone to compile their own). Afaik it should be pretty straight forward to compile it, so including it shouldn't be much of a problem.

And yes, I think we are 'too far away' from irrlicht trunk to be able to merge this in.

[vlj]

We can embed libglew but I think we should wait to see which other distro are affected. Fedora 21 is around the corner and given the nature of the distribution users are strongly encouraged to upgrade to the latest Fedora revision when it is released. That's different for instance for Ubuntu (which has 1.10 afaik) or openSUSE.

[konstin]

libglew1.10 is included with Ubuntu 14.04, but the still supported Ubuntu 12.04 only libglew1.5 . Having a copy of glew in stk-code will also make it easier to debug because everyone will have the same version.

[hiker]

I have integrated glew into our sources now. Vlj, can you apply the patch, you know better what exactly needs to be done and tested.

[vlj]

Can someone try it with mesa to confirm it's working ?

[vlj]

Looks like this patch break hd2000 on linux

[vlj]

Patches reverted