GR3 error plotting isosurface in Jupyter notebook

[samuelpowell]

Executing a cell containing:

using GR
inline("png")
isosurface(rand(10,10,10))

Results in the error:

GR3 error (gr3.c, l. 153): init failed

Stacktrace:
 [1] _check_error() at /home/spowell/.julia/v0.6/GR/src/gr3.jl:70
 [2] plot_iso(::Array{Float64,3}) at /home/spowell/.julia/v0.6/GR/src/jlgr.jl:668
 [3] plot_data(::Bool) at /home/spowell/.julia/v0.6/GR/src/jlgr.jl:868
 [4] #isosurface#24(::Array{Any,1}, ::Function, ::Array{Float64,3}) at /home/spowell/.julia/v0.6/GR/src/GR.jl:2949
 [5] isosurface(::Array{Float64,3}) at /home/spowell/.julia/v0.6/GR/src/GR.jl:2949
 [6] include_string(::String, ::String) at ./loading.jl:515

Notebook server is running on an Ubuntu 16.04 machine with Julia 0.6.0, and GR.jl 0.24.0.

[jheinen]

Are the required OpenGL packages installed on this specific notebook server, e.g. libgl1-mesa-dev and libglu1-mesa-dev ? GR3 needs a software rasterizer.

[samuelpowell]

Yes, both libgl1-mesa-dev and libglu1-mesa-dev are installed.

[jheinen]

Could you please try to set the environment variable GALLIUM_DRIVER=softpipe before starting the notebook server?

[jheinen]

@FlorianRhiem : do you remember, where we changed this setting in our JupyterHub appliance?

[FlorianRhiem]

Setting the variable before loading GR3 (or any other OpenGL related library) should be enough.

In our JupyterHub installation, we are using "Gallium 0.4 on llvmpipe (LLVM 3.9, 128 bits)" as reported by GR3 and we do not enforce the Gallium driver. The issue we had with this is that Gallium and Julia may use differing, incompatible versions of LLVM, but currently our Julia uses LLVM 3.9 as well, so we can use the llvmpipe driver.

[samuelpowell]

After restarting my JupyterHub service I created a new notebook and tried:

ENV["GALLIUM_DRIVER"]="softpipe"
using GR
inline("png")
isosurface(rand(10,10,10))

I received the same error.

Since you are also using a JupyterHub based setup, can you recommend a good place to set this environment variable for each notebook server that JupyterHub spawns, if indeed you still think this might help?

[FlorianRhiem]

Please run the following code in a new (or freshly restarted) Julia notebook and post the output:

using GR
function log(msg::Cstring)
    println(unsafe_string(msg))
end
log_c = cfunction(log, Void, (Cstring,))
ccall((:gr3_setlogcallback, GR.libGR3), Void, (Ptr{Void},), log_c)
GR.gr3.init([])

Also, could you please use a terminal in JupyterHub to run glxinfo and post the output?

Thank you!

[samuelpowell]

The output is

gr3_initGL_GLX_();
Not connected to an X server!
GR3 error (gr3.c, l. 153): init failed

Stacktrace:
 [1] _check_error() at /home/spowell/.julia/v0.6/GR/src/gr3.jl:70
 [2] init(::Array{Any,1}) at /home/spowell/.julia/v0.6/GR/src/gr3.jl:76
 [3] include_string(::String, ::String) at ./loading.jl:515

[FlorianRhiem]

Okay, in that case I guess glxinfo also only returns an error about having no X server? GR3 uses GLX on Linux to create an OpenGL context, therefore it requires a connection to an X server.

What JupyterHub spawner are you using?

If you are using a Docker-based spawner, you will have no X server available by default. On our JupyterHub installation, we have used both the DockerSpawner and the SwarmSpawner successfully by running xvfb. The entrypoint of our notebook server image is:

ENTRYPOINT ["xvfb-run", "--server-args", "-screen 0 1920x1080x24",  "/opt/jupyterhub/bin/start.sh"]

[samuelpowell]

Thanks @FlorianRhiem. Indeed, glxinfo returns Error: unable to open display.

In retrospect it would have been worth mentioning that this is a headless server!

In my setup JupyterHub is a system service and the single user notebook servers are spawned using SudoSpawner. Do you think it would be better to run JupyterHub or the individual notebook servers under xvfb?

[FlorianRhiem]

Ah, that explains it. Yes, you need an X server for GLX and therefore for GR3, so running the notebook servers with xvfb should solve the issue.

[samuelpowell]

This machine has a few Teslas for CUDA, and I think that the Nvidia drivers are not playing well with xvfb/glx:

spowell@charlesegg:~$ xvfb-run --server-args='-screen 0 1024x768x24 -ac +extension GLX +render -noreset' glxinfo
name of display: :99
Xlib:  extension "GLX" missing on display ":99".
Xlib:  extension "GLX" missing on display ":99".
Xlib:  extension "GLX" missing on display ":99".
Xlib:  extension "GLX" missing on display ":99".
.
.
.

Thus I still have a little work to do. This is not a GR issue of course, so closing. Many thanks for your help @FlorianRhiem, @jheinen.

[aviks]

Can I ask, is there any chance this will change? The ability to run GR3 on headless servers seems like a useful thing. xvfb is not appropriate (or possible) in many situations.

I'll understand if the answer is no (I don't know much about the underlying tech)