Bug 1403 - Could not initialize shared resources for EGLGraphicsDevice
Summary: Could not initialize shared resources for EGLGraphicsDevice
Status: RESOLVED WORKSFORME
Alias: None
Product: Jogl
Classification: JogAmp
Component: core (show other bugs)
Version: 2.4.0
Hardware: pc_x86_64 linux
: P4 major
Assignee: Sven Gothel
URL:
Depends on:
Blocks:
 
Reported: 2019-11-29 01:45 CET by James Foster
Modified: 2020-01-01 17:30 CET (History)
1 user (show)

See Also:
Type: DEFECT
SCM Refs:
Workaround: ---


Attachments
test log (23.45 KB, text/plain)
2019-11-29 01:45 CET, James Foster
Details
test with LIBGL_ALWAYS_SOFTWARE=true (22.43 KB, text/plain)
2019-11-29 04:10 CET, James Foster
Details
jogl-2.4.0-rc-20191231-test-default on Ubuntu 18.04 (61.17 KB, text/plain)
2020-01-01 17:27 CET, Sven Gothel
Details
jogl-2.4.0-rc-20191231-test-noegles2 on Ubuntu 18.04 (60.54 KB, text/plain)
2020-01-01 17:28 CET, Sven Gothel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description James Foster 2019-11-29 01:45:16 CET
Created attachment 826 [details]
test log

I am running JOGL on Ubuntu 18.04.3 in a VMware Fusion guest on macOS 10.15.1 and have an error that is reproduced using test.sh. With 2.3 I get the problem described at https://stackoverflow.com/questions/59082419/learning-opengl-in-java-why-does-glisframebuffer-return-false. With 2.4 I get an error just running the test (see attached).
Comment 1 Sven Gothel 2019-11-29 01:59:05 CET
(In reply to James Foster from comment #0)
> Created attachment 826 [details]
> test log
> 
> I am running JOGL on Ubuntu 18.04.3 in a VMware Fusion guest on macOS
> 10.15.1 and have an error that is reproduced using test.sh. With 2.3 I get
> the problem described at
> https://stackoverflow.com/questions/59082419/learning-opengl-in-java-why-
> does-glisframebuffer-return-false. With 2.4 I get an error just running the
> test (see attached).

The JOGL 2.4 test result is actually positive.

Caught handled GLException: EGLGLXDrawableFactory - Could not initialize shared resources for EGLGraphicsDevice[type .egl, v0.0.0, connection localhost:10.0, unitID 0, handle 0x0, owner true, ResourceToolkitLock[obj 0x6002f1c1, isOwner true, <6ec503b1, 6afa9ab1>[count 1, qsz 0, owner <main-SharedResourceRunner>]]] on thread main-SharedResourceRunner

Caused[0] by GLException: Failed to created/initialize EGL display incl. fallback default: native 0x0, error 0x3008/0x3003 on thread main-SharedResourceRunner

This is an informal notification that EGL, even though available,
was not able to initialize the EGLDisplay.

Otherwise, the X11 GLX support is working for you, giving you GL 1.4 support.

GL Profile     GLProfile[GL2/GL2.hw]
GL Version     1.4 (Compat profile, compat[], FBO, hardware) - 1.4 (2.1 NVIDIA-14.0.31 355.11.11.10.10.143) [GL 1.4.0, vendor 2.1.0 ((2.1 NVIDIA-14.0.31 355.11.11.10.10.143))]
Quirks         [NoSurfacelessCtx]
Impl. class    jogamp.opengl.gl4.GL4bcImpl
GL_VENDOR      NVIDIA Corporation
GL_RENDERER    NVIDIA GeForce GTX 660M OpenGL Engine
GL_VERSION     1.4 (2.1 NVIDIA-14.0.31 355.11.11.10.10.143)
GLSL           false, has-compiler-func: true
GL FBO: basic true, full false
GL_EXTENSIONS  60
GLX_EXTENSIONS 32

^^^ probably a VMWare emulated graphics card!!
+++

If you desire more GL functionality like GL >= 3.1
for shader development and EGL/ES as well,
feel free to set the environment variable:

export LIBGL_ALWAYS_SOFTWARE=true

which should force Mesa3D (the underlying GL implementation) 
to use the software driver.

Please reply with your results and you may set the status to resolved or invalid or worksforme.
Comment 2 James Foster 2019-11-29 04:10:14 CET
Created attachment 827 [details]
test with LIBGL_ALWAYS_SOFTWARE=true

Here is the test output with LIBGL_ALWAYS_SOFTWARE=true. Should I see any difference? The error still occurs and the GL Version still shows as 1.4.

Also, is there a way to disable EGL so as to avoid the error? (And, what features are we missing by not supporting EGL?)
Comment 3 Sven Gothel 2020-01-01 17:13:56 CET
JogAmp 2.4.0-rc-20191231 
https://jogamp.org/deployment/archive/master/gluegen_921-joal_647-jogl_1485-jocl_1128/

As shown <http://forum.jogamp.org/JogAmp-2-4-0-rc-20191231-tp4040215p4040219.html>

Some manual bring-up tests, trying to answer
some of the latest reported 'doesn't work' posts.

Latest build does work on OpenJDK 8 - 14
and Ubuntu 18 - 19.

~Sven

+++

Build 2.4.0-rc-20191231 gluegen_921-joal_647-jogl_1485-jocl_1128
1) java -jar jogamp-fat.jar
2) java -jar jogamp-fat-test.jar
3) cd jogamp-all-platforms/ && sh etc/test.sh

- Debian 10          amd64 native   OK
    - OpenJDK 8                     OK
    - OpenJDK 11 (default)          OK

- Ubuntu 18.04.3 LTS amd64 kvm-qemu OK
    - OpenJDK 11 (default)          OK

- Ubuntu 19.10       amd64 kvm-qemu OK
    - OpenJDK 11 (default)          OK
    - OpenJDK 14                    OK

- Raspbian 10      armv6hf raspi3b+ OK
    - OpenJDK 11 (default)          OK
    - DRM/GBM                       OK
    -- Test (1) fails, no AWT
    - Mesa X11                      ??
    -- should work

- Raspbian 10      armv6hf raspi4   OK
    - OpenJDK 11 (default)          OK
    - DRM/GBM                       OK
    -- Test (1) fails, no AWT
    - Mesa X11                      ??
    -- should work
Comment 4 Sven Gothel 2020-01-01 17:20:30 CET
Even w/ disabled EGL and GLES2 native libraries on Ubuntu 18.04, see below,
the bring-up tests succeed well.

   43  cd /usr/lib/x86_64-linux-gnu/
   44  ls -la libEGL* libGLESv2.so.2*
   45  mkdir nope
   46  mv libEGL* libGLESv2.so.2* nope

Thereby closing this issue for now as in 'works for me',
but we can continue the debate here of course.
Comment 5 Sven Gothel 2020-01-01 17:27:38 CET
Created attachment 833 [details]
jogl-2.4.0-rc-20191231-test-default on Ubuntu 18.04
Comment 6 Sven Gothel 2020-01-01 17:28:21 CET
Created attachment 834 [details]
jogl-2.4.0-rc-20191231-test-noegles2 on Ubuntu 18.04
Comment 7 Sven Gothel 2020-01-01 17:30:23 CET
Notable here, I ran Ubuntu 18.04 amd64 via virtualization using
a GNU/Linux Debian 10 amd64 host and 
KVM/qemu virtualization.

The GPU Rendering is all done in software, as no hardware acceleration is supported w/ said virtualization.