Bug 564 - X11GLXDrawableFactory - Could not initialize shared resources for :0 due to NullPointerException
Summary: X11GLXDrawableFactory - Could not initialize shared resources for :0 due to N...
Alias: None
Product: Jogl
Classification: JogAmp
Component: x11 (show other bugs)
Version: 2
Hardware: pc_x86_64 linux
: --- normal
Assignee: Sven Gothel
Depends on:
Reported: 2012-03-13 20:58 CET by Martin von Gagern
Modified: 2012-03-24 01:38 CET (History)
1 user (show)

See Also:
Type: ---
SCM Refs:
7a40768455342ab2d1d43bf435baa42a8ccaf917 42c461a157bbcf9e7268b171a7593c2b3ae6a173
Workaround: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Martin von Gagern 2012-03-13 20:58:16 CET
Using jogl-2.0rc5 (the latest version available, as far as I understand it), I get an exception initializing things. I first encountered this in a local application with relaxed security constraints, but could reproduce it as well in my browser using the Gears demo applet.

javax.media.opengl.GLException: X11GLXDrawableFactory - Could not initialize shared resources for :0
	at jogamp.opengl.x11.glx.X11GLXDrawableFactory$SharedResourceImplementation.createSharedResource(X11GLXDrawableFactory.java:267)
	at jogamp.opengl.SharedResourceRunner.run(SharedResourceRunner.java:261)
	at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.NullPointerException
	at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:419)
	at jogamp.opengl.x11.glx.X11GLXDrawableFactory$SharedResourceImplementation.createSharedResource(X11GLXDrawableFactory.java:246)
	... 2 more
#### Java Web Start Error:
#### Profile GL_DEFAULT is not available on X11GraphicsDevice[type X11, connection :0, unitID 0, handle 0x0], but: []

Sounds to me as if this shouldn't happen this way. A null pointer might be an indication of a problem, but if so, I'd hope for the relevant code to check that condition and throw some more informative exception. So I doubt that it's an external problem here. After all, the Gears applet doens't require any exotic capabilities, does it? I used to have older versions of jogl working fine, so my graphics setup should work well enough.
Comment 1 Julien Gouesse 2012-03-15 22:50:31 CET

Do you reproduce this bug with the latest autobuild (JOGL build 699)?

Please tell me more about your hardware, I don't reproduce this bug on Cent OS 5.3 with an Intel 64 bits microprocessor and a graphics card NVIDIA Quadro FX.
Comment 2 Julien Gouesse 2012-03-15 22:51:51 CET
Using GLProfile.getMaxFixedFunc(true) instead of GLProfile.getDefault() might work.
Comment 3 Sven Gothel 2012-03-18 13:53:15 CET
I am on it - thx.

'misio-it' reported the same NPE/GLProfile missing:
   - GL_RENDERER  Mesa DRI Intel(R) 945GM x86/MMX/SSE2
   - GL_VERSION 1.4 Mesa 8.0.1
  -  GL_VENDOR Tungsten Graphics, Inc
Comment 4 Sven Gothel 2012-03-18 15:46:24 CET
The following configuration have passed, hence it's highly probably related to
Mesa 8.0.1 and it's OpenGL 3.0 enabled glXCreateContextAttribsARB

GL_VENDOR      Tungsten Graphics, Inc
GL_RENDERER    Mesa DRI Intel(R) Sandybridge Desktop 
GL_VERSION     2.1 Mesa 7.11

GL_VENDOR      Mesa Project
GL_RENDERER    Software Rasterizer
GL_VERSION     2.1 Mesa 7.11.2
Comment 5 Martin von Gagern 2012-03-18 19:23:57 CET
I haven't had time to test this with local access to the hardware where I first encountered this, but I can confirm this is Mesa 8.0.1 as well.

OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NV84
OpenGL version string: 2.1 Mesa 8.0.1

Will try to check this getMaxFixedFunc tomorrow.
Comment 6 Sven Gothel 2012-03-18 22:36:14 CET

    Fix bug 564 (X11 Mesa 8.0.1 GL 3.0 w/o GLX_ARB_create_context)

    X11/Mesa 8.0.1 offers a GL 3.0 context w/o
    having the GLX_ARB_create_context extension available
    (even though the func-ptr glXCreateContextAttribsARB is not null).

    We assumed that if no GLContext device availability is set,
    it can be only GL 2.0 or ES1/ES2.

    Fix: Relaxed these (false) constrains and map the created context
         reflecting using it's actual attributes.
Comment 7 Julien Gouesse 2012-03-19 23:47:14 CET
Zeno said that the latest fix isn't enough, he provided another one:
Comment 8 Sven Gothel 2012-03-20 12:45:06 CET
Thanks to Zeno's report and analysis, here is the 2nd bug fix 
regarding a 'broken' ARB_create_context impl:


    Fix bug 564 - part 2 (X11 Mesa 8.0.1 GL 3.0 w/ failing GLX_ARB_create_context)
    Tolerate a buggy ARB createContext impl (always failing to create a context).
    Now we only reset the GLContext state and
    set the context/device availability flag if ARB create context actually was successful.
    Otherwise the fallback 'old' context is being used w/o having it's context state cleared
    and context/device availability is set later on.
    This makes the general use of ARB_create_context more stable.
    Minor changes:
    - Non compatibility fallback: Try forward context instead.
    - Limit ARB context 'seeking' to >= OpenGL 2.0
Comment 9 Julien Gouesse 2012-03-20 15:22:28 CET
(In reply to comment #8)
>     Minor changes:
>     - Non compatibility fallback: Try forward context instead.
>     - Limit ARB context 'seeking' to >= OpenGL 2.0

Why limiting ARB context seeking to >= OpenGL 2.0? Sorry for my silly question.
Comment 10 Sven Gothel 2012-03-24 01:38:16 CET
(In reply to comment #9)
> (In reply to comment #8)
> >     Minor changes:
> > 
> >     - Non compatibility fallback: Try forward context instead.
> >     - Limit ARB context 'seeking' to >= OpenGL 2.0
> Why limiting ARB context seeking to >= OpenGL 2.0? Sorry for my silly question.

B/c the ARB createContextAttribARB method was introduced with GL 3.1.
If available we can assume GL 2.1 (at least 2.0) is implemented or it just doesn't work (Mesa8).

Traversing all down to GL 1.1 is sort of futile here,
nevertheless GL 1.1 will be caught via the tradition createContext method.