Mali OpenGLES3 emulator installation on Ubuntu

Hi lemontree,

To narrow down the problem could you please try to run mali-cube supplied with Mali OpenGL ES Emulator using LD_PRELOAD approach?

If it doesn't work, then there is probably a problem with environment configuration and that's why appCube doesn't work.

If mali-cube works, then could you please let us know - if possible - what part of appCube is causing the crash (e.g. creating rendering context with eglCreateContext())

Cheers,

Jacek

Hi lemontree,

To narrow down the problem could you please try to run mali-cube supplied with Mali OpenGL ES Emulator using LD_PRELOAD approach?

If it doesn't work, then there is probably a problem with environment configuration and that's why appCube doesn't work.

If mali-cube works, then could you please let us know - if possible - what part of appCube is causing the crash (e.g. creating rendering context with eglCreateContext())

Cheers,

Jacek

FATAL - EGL: (initialize 104) GLX returned Error base : a9, Event Base : 68

FATAL - EGL: GLX supports the following extensions: GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_video_sync GLX_SGI_swap_control GLX_EXT_swap_control GLX_EXT_swap_control_tear GLX_EXT_texture_from_pixmap GLX_EXT_buffer_age GLX_ARB_create_context GLX_ARB_create_context_profile GLX_EXT_create_context_es_profile GLX_EXT_create_context_es2_profile GLX_ARB_create_context_robustness GLX_ARB_multisample GLX_NV_float_buffer GLX_ARB_fbconfig_float GLX_EXT_framebuffer_sRGB GLX_NV_multisample_coverage GLX_ARB_get_proc_address

FATAL - GLES: (checkMissingVersions 824) Couldn't find symbol 'glGetQueryObjecti64v' in 'libGL.so' (required for version of GL)!

FATAL - GLES: (checkMissingExtensions 836) Couldn't find symbol 'glFramebufferTexture2DMultisampleEXT' in 'libGL.so' (required for extension of GL)!

FATAL - GLES: (checkMissingExtensions 836) Couldn't find symbol 'glGetInternalformativ' in 'libGL.so' (required for extension of GL)!

FATAL - GLES: (checkMissingVersions 824) Couldn't find symbol 'glQueryCounter' in 'libGL.so' (required for version of GL)!

FATAL - GLES: (checkMissingVersions 824) Couldn't find symbol 'glGetQueryObjectui64v' in 'libGL.so' (required for version of GL)!

FATAL - GLES: (initializeGLFunctionProxy 689) At least one GL33 function is unavailable - potential crash ahead.

GL renderer: [NULL]

GL vendor:[NULL]

GL version: [NULL]

GL shading language version: [NULL]

GL API Version: [0.0]

FATAL - GLES: (configureDepthStencilAttachments 242) Will use GL_DEPTH_COMPONENT24 for system FBO's depth+stencil attachment

FATAL - GLES: (configureColorAttachment 294) Using GL_RGB8 for color attachment

FATAL - GLES: (recreateSystemFBO 1027) An invalid framebuffer object was created!

FATAL - GLES: (init_context_data_from_within_active_context 105) Could not initialize system FBO!

Running: Mali OpenGL ES Emulator 1.4.0

glGetError() = 1281 (0x00000501) at line 27 of shader.cpp

This was the output that I got by:

1) copying mali-cube into a folder

2) copying all the content of the mali emulator's lib subfolder in the same folder

3) copying libMali-T600_r4p0-00rel0.so in the same folder

4) running from the command line the following script:

#!/bin/bash

export MY_BASE_FOLDER=/home/guido/Desktop/Libraries/OpenGLES/Mali/Mali_OpenGL_ES_Emulator-1.4.0-Linux-64bit

export MY_FOLDER=$MY_BASE_FOLDER/examples/cube

export LD_PRELOAD=$MY_FOLDER/libMaliEmulator.so.1.4.0:$MY_FOLDER/libcompiler_manager.so:$MY_FOLDER/liblog4cplus.so.1.1.2:$MY_FOLDER/libEGL.so.1.4.0:$MY_FOLDER/libGLESv2.so.2.0.0:$MY_FOLDER/libMali-T600_r4p0-00rel0.so:$LD_PRELOAD

export MALI_EMULATOR_COMPILER_MANAGER_PATH=$MY_FOLDER

$MY_FOLDER/mali-cube

echo Press any key to quit.

read key

(BTW: I believe that my "appCube" is the same program as "mali-cube" (its source code was included in a previous version of the Mali emulator, as far as I can remember).

So the difference seems to be that before I had:

glGetError() = 1281 (0x00000501) at line 63

and now:

glGetError() = 1281 (0x00000501) at line 27 of shader.cpp

I don't have the source of "shader.cpp", I just got a "shader.c" (and line 27 is not a gl call).

However I get your point: it could be that that's some wrong environment configuration.

It should be much easier to install the library to fix it, or just go ahead with the Mesa libraries (it's not a personal preference, it's just that installing them directly via Synaptic from the default Ubuntu repositories is simpler).

Thank you anyway

My last post here. I give up .

Just to tell that I've tried the 1.4.1 version without success. Here is my experience:

After unpacking the tgz package, if I launch the program without setting any environment variable, I get:

./mali-cube: error while loading shared libraries: libMaliEmulator.so.1: cannot open shared object file: No such file or directory

That's fine.

Then I add:

export MALI_EMULATOR_COMPILER_MANAGER_PATH=$MY_BASE_FOLDER/share/mali-compiler-manager

(MY_BASE_FOLDER is the folder where I extracted the tgz package)

From now on, if I set (assuming that I use: export MY_LIB_FOLDER=$MY_BASE_FOLDER/lib):

export LD_PRELOAD=$MY_LIB_FOLDER/libGLESv2.so:$MY_LIB_FOLDER/libMaliEmulator.so:$MY_LIB_FOLDER/liblog4cplus.so:$MY_LIB_FOLDER/libcompiler_manager.so:$MY_LIB_FOLDER/libEGL.so:$LD_PRELOAD

Or alternatively (and much concisely):

export LD_LIBRARY_PATH=$MY_LIB_FOLDER:$LD_LIBRARY_PATH

Well, I get the same errors as before (ending again with: glGetError() = 1281 (0x00000501) at line 27 of shader.cpp)

The funny thing is that if I just set:

export LD_PRELOAD=$MY_LIB_FOLDER/libMaliEmulator.so:$MY_LIB_FOLDER/liblog4cplus.so:$MY_LIB_FOLDER/libcompiler_manager.so:$LD_PRELOAD

(without adding the Mali libEGL.so and libGLESv2.so) then the program runs fine using the Mesa libraries.

That means that LD_PRELOAD manages somehow to provide linkage to "libMaliEmulator.so.1" and related libraries.

It's probably the Mali "libEGL.so" that is causing problems (FATAL - EGL: (initialize 104) GLX returned Error base : a9, Event Base : 68).

Maybe it's something wrong with my card (it can be), but I wonder when the program needs "libMali-T600_r4p0-00rel0.so": that library does not appear in "ldd mali-cube" outputs as far as I remember, and if I don't export MALI_EMULATOR_COMPILER_MANAGER_PATH, nothing seems to change (I've tried preloading it, but that is not working if ldd doesn't list it, I suppose).

However, as I've said at the beginning, I'm giving up.

Still, thank you again for all your time, support and patience!

Hello lemontree,

From the description  you've sent it looks like NVIDIA's GL driver library is not properly loaded by the emulator.

After downloading and unpacking the .tgz, you should be able to execute included mali-cube binary from within unpacked emulator directory with this command:

MALI_EMULATOR_COMPILER_MANAGER_PATH=./share/mali-compiler-manager/ LD_LIBRARY_PATH=/usr/lib/nvidia-331:./lib ./bin/mali-cube

The indication that your intended GL driver is properly picked by the emulator is the following output to the console:

GL renderer: [NVS 300/PCIe/SSE2]
GL vendor:[NVIDIA Corporation]
GL version: [3.3.0 NVIDIA 331.20]
GL shading language version: [3.30 NVIDIA via Cg compiler]
GL API Version: [3.3]

Any NULLs reported there indicate that no libGL.so is dlopen'ed properly.

I'll be happy knowing you don't give up (well, at least not yet) and let us know whether you can get these strings reported by using one-liner provided as above.

Hey! That seems to work !

I get the following output (typying the command line from the base emulator directory, not from its "bin" subfolder):

$-> MALI_EMULATOR_COMPILER_MANAGER_PATH=./share/mali-compiler-manager/ LD_LIBRARY_PATH=/usr/lib/nvidia-331:./lib ./bin/mali-cube

FATAL - EGL: (initialize 104) GLX returned Error base : a9, Event Base : 68

FATAL - EGL: GLX supports the following extensions: GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_video_sync GLX_SGI_swap_control GLX_EXT_swap_control GLX_EXT_swap_control_tear GLX_EXT_texture_from_pixmap GLX_EXT_buffer_age GLX_ARB_create_context GLX_ARB_create_context_profile GLX_EXT_create_context_es_profile GLX_EXT_create_context_es2_profile GLX_ARB_create_context_robustness GLX_ARB_multisample GLX_NV_float_buffer GLX_ARB_fbconfig_float GLX_EXT_framebuffer_sRGB GLX_NV_multisample_coverage GLX_ARB_get_proc_address

FATAL - GLES: (checkMissingExtensions 836) Couldn't find symbol 'glFramebufferTexture2DMultisampleEXT' in 'libGL.so' (required for extension of GL)!

GL renderer: [GeForce GT 120/PCIe/SSE2]

GL vendor:[NVIDIA Corporation]

GL version: [3.3.0 NVIDIA 331.38]

GL shading language version: [3.30 NVIDIA via Cg compiler]

GL API Version: [3.3]

FATAL - GLES: (configureDepthStencilAttachments 248) Will use GL_DEPTH_COMPONENT24 for system FBO's depth+stencil attachment

FATAL - GLES: (configureColorAttachment 300) Using GL_RGB8 for color attachment

Running: Mali OpenGL ES Emulator 1.4.1

I can tell it works because otherwise the last line should have been:

Running: Gallium 0.4 on llvmpipe (LLVM 3.4, 128 bits)

that (for some odd reasons ), means that the Mesa implementation is running.

So in short: my scripts were not working because I had to set the full path of my libGL.so explicitely in:

export LD_LIBRARY_PATH=/usr/lib/nvidia-331:$MY_LIB_FOLDER:$LD_LIBRARY_PATH

I tested a "LD_LIBRARY_PATH script" with line above and it works !

So I'm happy now... the only thing that still puzzles me a bit is that if I use the "LD_PRELOAD version" adding libGL.so like this:

export LD_PRELOAD=/usr/lib/nvidia-331/libGL.so:$MY_LIB_FOLDER/libGLESv2.so:$MY_LIB_FOLDER/libMaliEmulator.so:$MY_LIB_FOLDER/liblog4cplus.so:$MY_LIB_FOLDER/libcompiler_manager.so:$MY_LIB_FOLDER/libEGL.so:$LD_PRELOAD

the demo still runs but,... surprise with the line:

[...]
GL renderer: [NULL]
GL vendor:[NULL]
GL version: [NULL]
GL shading language version: [NULL]
GL API Version: [0.0]

[...]
Running: GeForce GT 120/PCIe/SSE2

What GLES implementation is this ? Isn't it just a GL renderer ?

PS. on a closer look all the NULLs probably mean that something wrong is happaning here...

Adding libGL.so to your LD_PRELOAD var (at least before libGLESv2.so) is probably going to break things as I imagine your application will find the libGL implementation of the bulk of the GL calls and will call them directly rather than through the emulator, which the "Running" line above seems to prove. LD_PRELOAD is pretty dangerous in this respect and I would recommend against its use, it is much simpler to guarantee the correct linkage by using the LD_LIBRARY_PATH mechanism. Glad to hear you got it working with the one liner.

Chris