Advertise the GLES2 macro

[hissingshark]

Hi,

I've been building on the Vero4k (Amlogic s905x box running OSMC/debian).

My platform is GLESv2. I could only build by using -DEGL=On and an unadvertised macro -DGLES2=On. The readme and CMakeLists make no mention of this. I just found it when going through the source to debug. Might be worth a mention in those places to aid the unwary in future.

I hope that's helpful to you devs. Many thanks.

[loganmc10]

What happens if you build without -DGLES2=On? You shouldn't need that to get it working with GLES2, the Android version supports GLES2 without doing that.

[hissingshark]

echo $CFLAGS

-I/opt/vero3/include -L/opt/vero3/lib -O3 -march=armv8-a+crc -mtune=cortex-a53 -mfloat-abi=hard -mfpu=neon-fp-armv8 -funsafe-math-optimizations

cmake -DEGL=On -DMUPENPLUSAPI=On -DVEC4_OPT=On -DNEON_OPT=On -DCRC_ARMV8=On -DUSE_SYSTEM_LIBS=On ../../src/

-- The C compiler identification is GNU 6.3.0 -- The CXX compiler identification is GNU 6.3.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found ZLIB: /usr/lib/arm-linux-gnueabihf/libz.so (found version "1.2.8") -- Found PNG: /usr/lib/arm-linux-gnueabihf/libpng.so (found version "1.6.28") -- Found Freetype: /usr/lib/arm-linux-gnueabihf/libfreetype.so (found version "2.6.3") -- Configuring done -- Generating done -- Build files have been written to: /home/osmc/GLideN64/projects/cmake

make

Scanning dependencies of target osal [ 1%] Building C object osal/CMakeFiles/osal.dir/osal_files_unix.c.o [ 2%] Linking C static library libosal.a [ 2%] Built target osal Scanning dependencies of target GLideNHQ [ 2%] Building CXX object GLideNHQ/CMakeFiles/GLideNHQ.dir/TextureFilters.cpp.o In file included from /home/osmc/GLideN64/src/GLideNHQ/TextureFilters.h:34:0, from /home/osmc/GLideN64/src/GLideNHQ/TextureFilters.cpp:27: /home/osmc/GLideN64/src/GLideNHQ/TxInternal.h:62:20: fatal error: GL/gl.h: No such file or directory

include <GL/gl.h>

                ^

compilation terminated. GLideNHQ/CMakeFiles/GLideNHQ.dir/build.make:62: recipe for target 'GLideNHQ/CMakeFiles/GLideNHQ.dir/TextureFilters.cpp.o' failed make[2]: [GLideNHQ/CMakeFiles/GLideNHQ.dir/TextureFilters.cpp.o] Error 1 CMakeFiles/Makefile2:178: recipe for target 'GLideNHQ/CMakeFiles/GLideNHQ.dir/all' failed make[1]: [GLideNHQ/CMakeFiles/GLideNHQ.dir/all] Error 2 Makefile:83: recipe for target 'all' failed make: *** [all] Error 2

Don't know why it's trying to include gl.h when I'm building for EGL. That's why I went looking for include macros and found the GLES2 ones.

[fzurita]

You are right, that should not be getting included. The GLES2 macro should not be getting included anywhere because the code uses EGL, so this sounds like a mistake in the code.

[loganmc10]

I am working on fixing it. GLideNHQ still has direct references to OpenGL names/types. I am refactoring it to use the Graphics backend system instead, I'll submit a PR soon

[hissingshark]

I can confirm that this now building for me with -DEGL without including the -DGLES2. Good stuff, thank you.

However on actually testing the plugin it causes a segmentation fault. This I had hoped would be resolved by building the "proper way", but unfortunately not. I've tried gradually reducing the options I passed to cmake until I reached a minimum of cmake -DEGL=On -DMUPENPLUSAPI=On -DUSE_SYSTEM_LIBS=On -DCMAKE_BUILD_TYPE=Debug ../../src/, but no dice.

Any "classic causes" you are aware of?

[loganmc10]

You'll have to use gdb to produce a backtrace, it should tell you where the segfault is happening.

[hissingshark]

Thread 1 "mupen64plus" received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) bt

0 0x00000000 in ?? ()

1 0xd28c07d6 in opengl::GLInfo::init (this=this@entry=0xcb100) at /home/osmc/GLideN64/src/Graphics/OpenGLContext/opengl_GLInfo.cpp:13

2 0xd28bfa1e in opengl::ContextImpl::init (this=0xcb0c0) at /home/osmc/GLideN64/src/Graphics/OpenGLContext/opengl_ContextImpl.cpp:32

3 0xd28bbeac in graphics::Context::init (this=0xd2d6f608 ) at /home/osmc/GLideN64/src/Graphics/Context.cpp:21

4 0xd289f3be in DisplayWindow::start (this=0xd2d70990 <DisplayWindow::get()::video>) at /home/osmc/GLideN64/src/DisplayWindow.cpp:12

5 0xd28bba32 in PluginAPI::RomOpen (this=0xd2d6f600 <PluginAPI::get()::api>) at /home/osmc/GLideN64/src/common/CommonAPIImpl_common.cpp:206

6 0xd28edfdc in RomOpen () at /home/osmc/GLideN64/src/MupenPlusPluginAPI.cpp:15

7 0xf3868b44 in main_run () at ../../src/main/main.c:1342

8 0x0001297a in main (argc=, argv=) at ../../src/main.c:1024

[loganmc10]

This is happening because your OpenGL libraries are in a different spot than usual (it looks like /opt/vero3/lib)

If you look here:

https://github.com/gonetz/GLideN64/blob/master/src/Graphics/OpenGLContext/GLFunctions.cpp#L185-L189

https://github.com/gonetz/GLideN64/blob/master/src/Graphics/OpenGLContext/GLFunctions.cpp#L8

You can see what we've done for the Raspberry Pi and the ODroid. You'll need to submit PR that does a similar thing (don't forget to update CMakeLists.txt as well, you can see here for the commit that added ODroid support: https://github.com/gonetz/GLideN64/commit/cc3e1e63020c1e9d23c4e3a282ff7ed87f32444f#diff-8d00b77b579260ee0345a82be1c5fe6d)

[hissingshark]

Many thanks for the direction! Looks promising. I shall get on that.

[hissingshark]

Well that was easy enough. You were right about the required path and I now have a -DVERO4K option to give cmake, but alas there is a new seg fault as follows.

Thread 1 "mupen64plus" received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) bt

0 0x00000000 in ?? ()

1 0xd2bd3b08 in glsl::CombinerProgramBuilder::buildCombinerProgram (this=0xb97e8, _color=..., _alpha=..., _key=...) at /home/osmc/GLideN64/src/Graphics/OpenGLContext/GLSL/glsl_CombinerProgramBuilder.cpp:2242

2 0xd2ba0812 in Combiner_Compile (key=...) at /home/osmc/GLideN64/src/Combiner.cpp:268

3 0xd2ba0b52 in CombinerInfo::setCombine (this=this@entry=0xd2c6e808 <CombinerInfo::get()::info>, _mux=) at /home/osmc/GLideN64/src/Combiner.cpp:296

4 0xd2ba0cb0 in CombinerInfo::init (this=0xd2c6e808 <CombinerInfo::get()::info>) at /home/osmc/GLideN64/src/Combiner.cpp:108

5 0xd2ba0cec in Combiner_Init () at /home/osmc/GLideN64/src/Combiner.cpp:77

6 0xd2babb14 in GraphicsDrawer::_initData (this=this@entry=0xd3077a18 <DisplayWindow::get()::video+1096>) at /home/osmc/GLideN64/src/GraphicsDrawer.cpp:1714

7 0xd2ba2336 in DisplayWindow::start (this=0xd30775d0 <DisplayWindow::get()::video>) at /home/osmc/GLideN64/src/DisplayWindow.cpp:13

8 0xd2bc14d2 in PluginAPI::RomOpen (this=0xd3076240 <PluginAPI::get()::api>) at /home/osmc/GLideN64/src/common/CommonAPIImpl_common.cpp:206

9 0xd2bf3b84 in RomOpen () at /home/osmc/GLideN64/src/MupenPlusPluginAPI.cpp:15

10 0xf3b6fb44 in main_run () at ../../src/main/main.c:1342

11 0x0001297a in main (argc=, argv=) at ../../src/main.c:1024

[loganmc10]

Ok I know what the issue is but I'm not in front of my computer now, I can fix it tomorrow.

For now, if you look in your mupen64plus.cfg file for an option called "EnableShadersStorage" and set that to false, that should work around the issue for now

[fzurita]

I think that can be fixed by updating the compiler version. So make sure you are using the latest GCC or clang.

Edit: Actually, this is a different problem. It's crashing when calling a GL function.

glProgramParameteri is somehow not available for your device, which makes sense for GLES.

[loganmc10]

It's because glProgramParameteri isn't valid in GLES2, it's an optional hint to give the driver, so we just need to skip calling that in GLES2

[fzurita]

I'm surprised it's not crashing in Android for GLES2 devices.

[loganmc10]

Yeah I'm surprised as well, maybe they don't support shader storage? That function is mentioned in GL_ARB_get_program_binary but not GL_OES_get_program_binary

[loganmc10]

I'm surprised it works at all, the main function for the GLES2 version is supposed to be glGetProgramBinaryOES, not glGetProgramBinary, which is what we use

[fzurita]

This is probably returning false for most GLES2 devices. In his it must be returning true:

gfxContext.isSupported(SpecialFeatures::ShaderProgramBinary)

[loganmc10]

@hissingshark can you try this commit:

https://github.com/loganmc10/GLideN64/commit/eddfa190325438ce3c852df67df0fdf05d0cd8a0

You can apply if to your current system by downloading https://github.com/loganmc10/GLideN64/commit/eddfa190325438ce3c852df67df0fdf05d0cd8a0.patch

and then:

cd GLideN64
patch -p1 < eddfa190325438ce3c852df67df0fdf05d0cd8a0.patch

Or if you have some other system to test it out that is good too.

[hissingshark]

1. So EnableShadersStorage = False as applied to my custom build with -DVERO4K works (will just need configuring to go full screen 16:9 and to sort out the choppy audio). Thank you.

2. But the patched code (I assume we are meant to go back to the default EnableShadersStorage = True) gives a new seg fault:

Thread 1 "mupen64plus" received signal SIGSEGV, Segmentation fault. CombinerKey::CombinerKey (this=0xec6c8, _other=...) at /home/osmc/GLideN64/src/CombinerKey.cpp:29 29 m_key.mux = _other.m_key.mux; (gdb) bt

0 CombinerKey::CombinerKey (this=0xec6c8, _other=...) at /home/osmc/GLideN64/src/CombinerKey.cpp:29

1 0xd283bea6 in std::pair<CombinerKey const, graphics::CombinerProgram*>::pair<CombinerKey const&, 0u>(std::tuple<CombinerKey const&>&, std::tuple<>&, std::_Index_tuple<0u>, std::_Index_tuple<>) (

__tuple2=<synthetic pointer>empty std::tuple, __tuple1=..., this=<optimized out>) at /usr/include/c++/6/tuple:1590

2 std::pair<CombinerKey const, graphics::CombinerProgram*>::pair<CombinerKey const&>(std::piecewise_construct_t, std::tuple<CombinerKey const&>, std::tuple<>) (second=..., first=..., this=)

at /usr/include/c++/6/tuple:1579

3 __gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<CombinerKey const, graphics::CombinerProgram> > >::construct<std::pair<CombinerKey const, graphics::CombinerProgram>, std::piecewise_construct_t const&, std::tuple<CombinerKey const&>, std::tuple<> >(std::pair<CombinerKey const, graphics::CombinerProgram>, std::piecewise_construct_t const&, std::tuple<CombinerKey const&>&&, std::tuple<>&&) (this=, __p=)

at /usr/include/c++/6/ext/new_allocator.h:120

4 std::allocator_traits<std::allocator<std::_Rb_tree_node<std::pair<CombinerKey const, graphics::CombinerProgram> > > >::construct<std::pair<CombinerKey const, graphics::CombinerProgram>, std::piecewise_construct_t const&, std::tuple<CombinerKey const&>, std::tuple<> >(std::allocator<std::_Rb_tree_node<std::pair<CombinerKey const, graphics::CombinerProgram> > >&, std::pair<CombinerKey const, graphics::CombinerProgram>*, std::piecewise_construct_t const&, std::tuple<CombinerKey const&>&&, std::tuple<>&&) (a=..., p=) at /usr/include/c++/6/bits/alloc_traits.h:475

5 std::_Rb_tree<CombinerKey, std::pair<CombinerKey const, graphics::CombinerProgram>, std::_Select1st<std::pair<CombinerKey const, graphics::CombinerProgram> >, std::less, std::allocator<std::pair<CombinerKey const, graphics::CombinerProgram> > >::_M_construct_node<std::piecewise_construct_t const&, std::tuple<CombinerKey const&>, std::tuple<> >(std::_Rb_tree_node<std::pair<CombinerKey const, graphics::CombinerProgram> >*, std::piecewise_construct_t const&, std::tuple<CombinerKey const&>&&, std::tuple<>&&) (this=0xd2909818 <CombinerInfo::get()::info+16>, __node=0xec6b8) at /usr/include/c++/6/bits/stl_tree.h:543

6 std::_Rb_tree<CombinerKey, std::pair<CombinerKey const, graphics::CombinerProgram>, std::_Select1st<std::pair<CombinerKey const, graphics::CombinerProgram> >, std::less, std::allocator<std::pair<CombinerKey const, graphics::CombinerProgram*> > >::_M_create_node<std::piecewise_construct_t const&, std::tuple<CombinerKey const&>, std::tuple<> >(std::piecewise_construct_t const&, std::tuple<CombinerKey const&>&&, std::tuple<>&&) (

this=0xd2909818 <CombinerInfo::get()::info+16>) at /usr/include/c++/6/bits/stl_tree.h:560

7 std::_Rb_tree<CombinerKey, std::pair<CombinerKey const, graphics::CombinerProgram>, std::_Select1st<std::pair<CombinerKey const, graphics::CombinerProgram> >, std::less, std::allocator<std::pair<CombinerKey const, graphics::CombinerProgram> > >::_M_emplace_hint_unique<std::piecewise_construct_t const&, std::tuple<CombinerKey const&>, std::tuple<> >(std::_Rb_tree_const_iterator<std::pair<CombinerKey const, graphics::CombinerProgram> >, std::piecewise_construct_t const&, std::tuple<CombinerKey const&>&&, std::tuple<>&&) (this=this@entry=0xd2909818 <CombinerInfo::get()::info+16>, pos=pos@entry=

{first = {m_key = {{{aA1 = 5, sbA1 = 5, aRGB1 = 1, aA0 = 1, sbA0 = 6, aRGB0 = 2, mA1 = 2, saA1 = 3, sbRGB1 = 14, sbRGB0 = 6, mRGB1 = 5, saRGB1 = 3, mA0 = 1, saA0 = 7, mRGB0 = 0, saRGB0 = 5}, {muxs1 = 1852400237, muxs0 = 1917874789}, mux = 8237209498430300781}}}, second = 0x6172676f}, args#0=..., args#1=<unknown type in /home/osmc/GLideN64/projects/cmake/plugin/Debug/mupen64plus-video-GLideN64.so, CU 0x0, DIE 0xff2f>, __args#2=<unknown type in /home/osmc/GLideN64/projects/cmake/plugin/Debug/mupen64plus-video-GLideN64.so, CU 0x0, DIE 0x102aa>) at /usr/include/c++/6/bits/stl_tree.h:2196

8 0xd28786c6 in std::map<CombinerKey, graphics::CombinerProgram, std::less, std::allocator<std::pair<CombinerKey const, graphics::CombinerProgram> > >::operator[] (__k=..., this=0xd2909818 <CombinerInfo::get()::info+16>)

at /usr/include/c++/6/bits/stl_map.h:483

9 glsl::ShaderStorage::loadShadersStorage (this=this@entry=0xfffef1c8, _combiners=std::map with 0 elements) at /home/osmc/GLideN64/src/Graphics/OpenGLContext/GLSL/glsl_ShaderStorage.cpp:331

10 0xd2860b66 in opengl::ContextImpl::loadShadersStorage (this=0xc6650, _combiners=std::map with 0 elements) at /home/osmc/GLideN64/src/Graphics/OpenGLContext/opengl_ContextImpl.cpp:389

11 0xd283ba1c in CombinerInfo::_loadShadersStorage (this=this@entry=0xd2909808 <CombinerInfo::get()::info>) at /home/osmc/GLideN64/src/Combiner.cpp:349

12 0xd283bc4e in CombinerInfo::init (this=0xd2909808 <CombinerInfo::get()::info>) at /home/osmc/GLideN64/src/Combiner.cpp:99

13 0xd283bcec in Combiner_Init () at /home/osmc/GLideN64/src/Combiner.cpp:77

14 0xd2846b14 in GraphicsDrawer::_initData (this=this@entry=0xd2d12a18 <DisplayWindow::get()::video+1096>) at /home/osmc/GLideN64/src/GraphicsDrawer.cpp:1714

15 0xd283d336 in DisplayWindow::start (this=0xd2d125d0 <DisplayWindow::get()::video>) at /home/osmc/GLideN64/src/DisplayWindow.cpp:13

16 0xd285c4d2 in PluginAPI::RomOpen (this=0xd2d11240 <PluginAPI::get()::api>) at /home/osmc/GLideN64/src/common/CommonAPIImpl_common.cpp:206

17 0xd288ebcc in RomOpen () at /home/osmc/GLideN64/src/MupenPlusPluginAPI.cpp:15

18 0xf380ab44 in main_run () at ../../src/main/main.c:1342

19 0x0001297a in main (argc=, argv=) at ../../src/main.c:1024

FYI - I know I can just use the configuration fix going forward, but I'm happy to keep testing any patches you want to try to get that cleared.

[loganmc10]

Can you look inside ~/.cache/mupen64plus for a folder called shaders and delete that folder and then retry?

If it still crashes then I would just say shader storage doesn't work on your device. I would either disable shader storage using the VERO4K definition or disable it for GLES2 in general, depending on @fzurita's preference. I'd be surprised if it worked on any GLES2 devices before given the crash you saw on your device

[loganmc10]

Although that crash might just be related to your compiler, it looks kind of strange, @fzurita might have more insight

[fzurita]

Try using the latest GCC or clang. This looks very similar to a crash we had before when someone was using an older compiler.

[hissingshark]

Deleting the shader folder does let it run - BUT it must be deleted prior to each run otherwise it gives the seg fault I published above.

You know I was sure the patched build had worked when I tested it the first time but after that no dice so I thought I'd mixed up my builds or config!

My gcc is currently at 6.3 I believe.

[fzurita]

This last crash looks like a bug in the code. Not sure why it's happening though.

[gonetz]

@hissingshark Can it be closed?

[hissingshark]

I'm happy with respect to the original issue.

@fzurita

This last crash looks like a bug in the code. Not sure why it's happening though.

Does this need to be taken this elsewhere then? A new issue?

[gonetz]

@hissingshark If original issue is fixed, please close this ticket. If you have another issue to solve, please open new ticket. It is not good to solve several issues in one ticket: things quickly messed up.