EGL or GLESv2 support.

[psi29a]

Now that OSG-3.4 is in Debian and Ubuntu and they have it compiling and working on arm64/armhf, is there any way we can add better support for GLESv2 (or even EGL)?

For example here: https://launchpadlibrarian.net/28656329 ... ING.txt.gz

It looks like if we could do some #ifdef magic, we should be able to use header from libglesv1-mesa-dev instead of from libgl-mesa-dev. Perhaps this is something we can detect via cmake and set the proper #ifdef magic?

I managed to do some cross-compile using qemu as a backend, here is a silly-easy howto:
https://wiki.debian.org/Arm64Qemu

Any help?

[sandstranger]

d

[psi29a]

Thanks, but no, we need to be doing this the right way. This is on real Debian and Ubuntu armhf hardware. They've already filed a serious bug against 0.40 which might threaten its future in the Debian/Ubuntu.

https://bugs.debian.org/cgi-bin/bugrepo ... bug=838792

Unfortunately it is caused by osgQt, which Scrawl has stated is to be replaced. So the question is, when is it going to be replaced and if it will take awhile then is it better to fix this issue bellow?

Code: Select all

[  1%] Building CXX object components/CMakeFiles/components.dir/settings/settings.cpp.o
cd /«PKGBUILDDIR»/build/components && /usr/bin/c++   -DGLOBAL_CONFIG_PATH=\"/etc\" -DGLOBAL_DATA_PATH=\"/usr/share/games\" -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB -DTIXML_USE_STL -D__STDC_CONSTANT_MACROS -I/«PKGBUILDDIR»/. -isystem /usr/include/SDL2 -isystem /usr/include/MYGUI -isystem /usr/include/AL -isystem /usr/include/bullet -isystem /usr/include/qt4 -isystem /usr/include/qt4/QtOpenGL -isystem /usr/include/qt4/QtGui -isystem /usr/include/qt4/QtNetwork -isystem /usr/include/qt4/QtCore -I/«PKGBUILDDIR»/build/components  -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2  -Wall -Wextra -Wundef -Wno-unused-parameter -std=c++98 -pedantic -Wno-long-long -Wno-unused-but-set-parameter -O2 -g -DNDEBUG   -o CMakeFiles/components.dir/settings/settings.cpp.o -c /«PKGBUILDDIR»/components/settings/settings.cpp
In file included from /usr/include/osg/GL:113:0,
                 from /usr/include/osg/GLDefines:25,
                 from /usr/include/osg/GLExtensions:18,
                 from /usr/include/osg/State:18,
                 from /usr/include/osg/GraphicsContext:17,
                 from /usr/include/osgViewer/GraphicsWindow:17,
                 from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:19,
                 from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14:
/usr/include/GLES2/gl2.h:69:25: error: conflicting declaration 'typedef khronos_ssize_t GLsizeiptr'
 typedef khronos_ssize_t GLsizeiptr;
                         ^~~~~~~~~~
In file included from /usr/include/GL/gl.h:2055:0,
                 from /usr/include/qt4/QtOpenGL/qgl.h:88,
                 from /usr/include/qt4/QtOpenGL/QGLWidget:1,
                 from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:17,
                 from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14:
/usr/include/GL/glext.h:468:19: note: previous declaration as 'typedef ptrdiff_t GLsizeiptr'
 typedef ptrdiff_t GLsizeiptr;
                   ^~~~~~~~~~
In file included from /usr/include/osg/GL:113:0,
                 from /usr/include/osg/GLDefines:25,
                 from /usr/include/osg/GLExtensions:18,
                 from /usr/include/osg/State:18,
                 from /usr/include/osg/GraphicsContext:17,
                 from /usr/include/osgViewer/GraphicsWindow:17,
                 from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:19,
                 from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14:
/usr/include/GLES2/gl2.h:70:26: error: conflicting declaration 'typedef khronos_intptr_t GLintptr'
 typedef khronos_intptr_t GLintptr;
                          ^~~~~~~~
In file included from /usr/include/GL/gl.h:2055:0,
                 from /usr/include/qt4/QtOpenGL/qgl.h:88,
                 from /usr/include/qt4/QtOpenGL/QGLWidget:1,
                 from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:17,
                 from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14:
/usr/include/GL/glext.h:469:19: note: previous declaration as 'typedef ptrdiff_t GLintptr'
 typedef ptrdiff_t GLintptr;

[sandstranger]

d

[psi29a]

We're at OSG-3.4, which is the latest release. The problem is in the Qt's headers that include different GL headers than what we are using and clashing.

OSG-3.4 compiles just fine now on armhf, on both Debian and Ubuntu, but only with GLESv2 or EGL. They've disabled the normal libgl (GL) headers. They did this expresily to support the osgQt plugin for both Qt4 and Qt5.
https://anonscm.debian.org/cgit/pkg-osg ... an/control

freeglut3-dev [!armhf],
libgl1-mesa-dev [!armhf] | libgl-dev [!armhf],
libegl1-mesa-dev [armhf],
libgles2-mesa-dev [armhf],

This of course could be avoided if we ditched the osgQt plugin. However we still need some way to bind OSG renderer into the Qt context for openmw-cs, this might cause us to run into this problem again.

EGL notes, probably of use: http://android-dls.com/wiki/index.php?title=EGL_notes

[aesylwinn]

From what I understand, we have our own version of osgQt that we maintain here.

[psi29a]

From what I understand, we have our own version of osgQt that we maintain here.

Then it is there it needs to be solved then and not with OSG itself. We'll likely need to do some #ifdef magic in there.

[psi29a]

I did a bit more research with GLESv2 and OpenMW, and it turns out that we depend on a lot of variables defined in <GL/gl.h>, I can find them in GLESv1 and GLESv2 but for whatever reason, we still get this and I'm not sure why:

Code: Select all

In file included from /usr/include/osg/Uniform:23:0,
                 from /usr/include/osg/StateSet:20,
                 from /usr/include/osg/State:19,
                 from /usr/include/osg/GraphicsContext:17,
                 from /usr/include/osgViewer/GraphicsWindow:17,
                 from /opt/openmw-debian/extern/osgQt/GraphicsWindowQt:22,
                 from /opt/openmw-debian/extern/osgQt/GraphicsWindowQt.cpp:14:
/usr/include/osg/Array:566:22: error: ‘virtual void osg::ValueVisitor::apply(GLdouble&)’ cannot be overloaded
         virtual void apply(GLdouble&) {}
                      ^~~~~
/usr/include/osg/Array:565:22: error: with ‘virtual void osg::ValueVisitor::apply(GLfloat&)’
         virtual void apply(GLfloat&) {}
                      ^~~~~
/usr/include/osg/Array:620:22: error: ‘virtual void osg::ConstValueVisitor::apply(const GLdouble&)’ cannot be overloaded
         virtual void apply(const GLdouble&) {}
                      ^~~~~
/usr/include/osg/Array:619:22: error: with ‘virtual void osg::ConstValueVisitor::apply(const GLfloat&)’
         virtual void apply(const GLfloat&) {}
                      ^~~~~
qemu: Unsupported syscall: 384

@scrawl: Is there a way, that you know of, to re-write these in a way that is both GL and GLESv2 compatible? Is it something is doable or is this non-trivial?

[psi29a]

I've done some more hacking, I got everything to compile and link except for openmw-cs... so a partial win.

our openmw/extern/osgQt is still a problem.

I'm going to "weaponize" my patchset, and post it here for others to test. Technically armhf is a poor choice to run openmw-cs on anyway.

My idea is that for armhf environments, we disable the openmw-cs build.

@maqifrnswa: is this possible in debian?

[maqifrnswa]

I've done some more hacking, I got everything to compile and link except for openmw-cs... so a partial win.

our openmw/extern/osgQt is still a problem.

I'm going to "weaponize" my patchset, and post it here for others to test. Technically armhf is a poor choice to run openmw-cs on anyway.

My idea is that for armhf environments, we disable the openmw-cs build.

@maqifrnswa: is this possible in debian?

nice work bret! that looked hard...
Yes, we can explicitly not build for an architecture. In general, we'd want to make it build everywhere - but sometimes fixing openmw to work on a mainframe (or opencs on an SBC) doesn't make sense, so in that case it is ok to drop building for an architecture. For example, bitcoin algorithms were originally endian-specific, so there were rules to not build on certain architectures. Eventually, it was fixed, and the package was made available on all architectures.

Simply putting to not build on arm in the control file and requesting that the arm binaries be removed from unstable will be enough to reduce the bug from "important" to "normal" (or even wishlist). "Removals from testing, stable and oldstable"
https://wiki.debian.org/ftpmaster_Removals
Also, the acronym "ANAIS" (architecture not allowed in source) is used for this case.
This is how you request it:
https://bugs.debian.org/cgi-bin/bugrepo ... bug=813860