Hello,
I get the following assert when running the included 'cube' demo:
$ ./cube
GL renderer: [NULL]
GL vendor:[NULL]
GL version: [NULL]
GL shading language version: [NULL]
cube: /home/jenkins/workspace/opengles30-emulator-packaging-nightly/Arch/x64/OS/linux/gles/opengles30/src/gles30_system_fbo.cc:501: bool system_fbo_init(GLuint, _context_data*, bool): Assertion `depth_to_id != 0' failed.
Aborted (core dumped)
The backtrace is as follows:
#0 0x00007ffff67bcf77 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff67c05e8 in __GI_abort () at abort.c:90
#2 0x00007ffff67b5d43 in __assert_fail_base (fmt=0x7ffff690cf58 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7ffff7873c9d "depth_to_id != 0",
file=file@entry=0x7ffff7873b80 "/home/jenkins/workspace/opengles30-emulator-packaging-nightly/Arch/x64/OS/linux/gles/opengles30/src/gles30_system_fbo.cc",
line=line@entry=501,
function=function@entry=0x7ffff7873ce0 <system_fbo_init(unsigned int, _context_data*, bool)::__PRETTY_FUNCTION__> "bool system_fbo_init(GLuint, _context_data*, bool)")
at assert.c:92
#3 0x00007ffff67b5df2 in __GI___assert_fail (assertion=0x7ffff7873c9d "depth_to_id != 0",
file=0x7ffff7873b80 "/home/jenkins/workspace/opengles30-emulator-packaging-nightly/Arch/x64/OS/linux/gles/opengles30/src/gles30_system_fbo.cc", line=501,
function=0x7ffff7873ce0 <system_fbo_init(unsigned int, _context_data*, bool)::__PRETTY_FUNCTION__> "bool system_fbo_init(GLuint, _context_data*, bool)") at assert.c:101
#4 0x00007ffff777319a in system_fbo_init(unsigned int, _context_data*, bool) () from /usr/local/lib/libGLESv2.so.2
#5 0x00007ffff777892d in init_context_data_from_within_active_context(unsigned int, _context_data*) () from /usr/local/lib/libGLESv2.so.2
#6 0x00007ffff77a6e0b in context_data_storage_make_context_current () from /usr/local/lib/libGLESv2.so.2
#7 0x00007ffff77a3c02 in GLES3_MakeCurrent () from /usr/local/lib/libGLESv2.so.2
#8 0x00007ffff77a3c7d in GLES2_MakeCurrent () from /usr/local/lib/libGLESv2.so.2
#9 0x00007ffff7ba71bf in GLES2_MakeCurrent () from /usr/local/lib/libEGL.so.1
#10 0x00007ffff7ba9e23 in makeCurrent(void*, void*, void*, void*) () from /usr/local/lib/libEGL.so.1
#11 0x00007ffff7bae4af in eglMakeCurrent () from /usr/local/lib/libEGL.so.1
#12 0x000000000040223e in main (argc=1, argv=0x7fffffffdd38) at src/cube.cc:283
When using the libEGL.so.1 and libGLESv2.so.1 bundled with Mesa (LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/mesa-egl/ ./cube on my system) instead of those from the emulator, the example runs fine.
System specs:
uname -a: Linux huvuddator 3.11.0-18-generic #32-Ubuntu SMP Tue Feb 18 21:11:14 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Ubuntu 13.10
GeForce GT 430, NVIDIA driver version 319.32
The same problem also occurs on a different system with the following specs (where it also runs fine with the Mesa libs):
uname -a: Linux jp 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
GeForce GTX 660 Ti, NVIDIA driver version 304.108
Hi ulfalizer,
GL renderer: [NULL] suggests that your NVIDIA GL driver is not being used. Could you please try to run the example in a following way:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/nvidia-current #(or whatever directory your NVIDIA driver is located in)./cube
Hope that helps,
Jacek
That fixed it - thanks!
It seems a bit strange though, since the NVIDIA driver is apparently already in the dynamic linker's search path:
$ ldd cube
linux-vdso.so.1 => (0x00007fffebbfe000)
libEGL.so.1 => /usr/local/lib/libEGL.so.1 (0x00007fb7fce6c000)
libGLESv2.so.2 => /usr/local/lib/libGLESv2.so.2 (0x00007fb7fc99c000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007fb7fc666000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fb7fc362000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb7fc05e000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb7fbe47000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb7fba7f000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb7fb87b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb7fb65d000)
libGL.so.1 => /usr/lib/nvidia-319/libGL.so.1 (0x00007fb7fb32f000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb7fd0f7000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fb7fb111000)
libnvidia-tls.so.319.32 => /usr/lib/nvidia-319/tls/libnvidia-tls.so.319.32 (0x00007fb7faf0d000)
libnvidia-glcore.so.319.32 => /usr/lib/nvidia-319/libnvidia-glcore.so.319.32 (0x00007fb7f89b6000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007fb7f87a3000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007fb7f859f000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fb7f8399000)
Shouldn't the dlopen("libGL.so", ...) or similar that I assume is being done at runtime automatically use the same search path?
($ LD_LIBRARY_PATH=/usr/lib/nvidia-319 ldd cube has the same output as above by the way, though I realize it can still affect runtime stuff.)