Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GLMakie doesn't build on Fedora #614

Closed
DevJac opened this issue May 28, 2020 · 25 comments
Closed

GLMakie doesn't build on Fedora #614

DevJac opened this issue May 28, 2020 · 25 comments
Labels
GLMakie This relates to GLMakie.jl, the OpenGL backend for Makie.

Comments

@DevJac
Copy link

DevJac commented May 28, 2020

I can't get GLMakie to build on Fedora 32, even though I believe I have all the required libraries installed.

I'm going to dump a bunch of console output below, but I'll give a quick overview here first. Below you can find the output of ]build GLMakie, the contents of /usr/lib64/dri, and some output from glxinfo -B:

(@v1.4) pkg> build GLMakie
   Building ModernGL → `~/.julia/packages/ModernGL/rVuW2/deps/build.log`
   Building GLMakie ─→ `~/.julia/packages/GLMakie/S9Zib/deps/build.log`
┌ Error: Error building `GLMakie`: 
│ libGL error: MESA-LOADER: failed to open iris (search paths /usr/lib64/dri)
│ libGL error: failed to load driver: iris
│ libGL error: MESA-LOADER: failed to open swrast (search paths /usr/lib64/dri)
│ libGL error: failed to load driver: swrast
│ init error of GLFW
│ ERROR: LoadError: OpenGL/GLFW wasn't installed correctly. This likely means,
│ you don't have an OpenGL capable Graphic Card,
│ you don't have the newest video driver installed,
│ or the GLFW build failed. If you're on linux and `]build` GLFW failed,
│ try manually adding `sudo apt-get install libglfw3` and then `]build GLMakie`.
│ If you're on a headless server, you still need to install x-server and
│ proper GPU drivers. You can take inspiration from this article
│ on how to get Makie running on a headless system:
│ https://nextjournal.com/sdanisch/makie-1.0
│ If you don't have a GPU, there is also a Cairo software backend
│ for Makie which you can use:
│ https://github.com/JuliaPlots/CairoMakie.jl.
│ Please check the below error and open an issue at:
│ https://github.com/JuliaPlots/GLMakie.jl.
│ After you fixed your OpenGL install, please run `]build GLMakie` again!
│ GLMakie will still load, but will be disabled as a default backend for Makie
│ 
│ Stacktrace:
│  [1] error(::String) at ./error.jl:33
│  [2] top-level scope at /home/devjac/.julia/packages/GLMakie/S9Zib/deps/build.jl:63
│  [3] include(::String) at ./client.jl:439
│  [4] top-level scope at none:5
│ in expression starting at /home/devjac/.julia/packages/GLMakie/S9Zib/deps/build.jl:31
│ caused by [exception 1]
│ GLFWError (VERSION_UNAVAILABLE): GLX: Failed to create context: GLXBadFBConfig
│ Stacktrace:
│  [1] _ErrorCallbackWrapper(::Int32, ::Cstring) at /home/devjac/.julia/packages/GLFW/g1nX6/src/callback.jl:43
│  [2] CreateWindow(::Int64, ::Int64, ::String, ::GLFW.Monitor, ::GLFW.Window) at /home/devjac/.julia/packages/GLFW/g1nX6/src/glfw3.jl:487
│  [3] GLFW.Window(; name::String, resolution::Tuple{Int64,Int64}, debugging::Bool, major::Int64, minor::Int64, windowhints::Array{Tuple{UInt32,Int64},1}, contexthints::Array{Tuple{UInt32,Integer},1}, visible::Bool, focus::Bool, fullscreen::Bool, monitor::Nothing, share::GLFW.Window) at /home/devjac/.julia/packages/GLFW/g1nX6/src/glfw3.jl:338
│  [4] top-level scope at /home/devjac/.julia/packages/GLMakie/S9Zib/deps/build.jl:34
│  [5] include(::String) at ./client.jl:439
│  [6] top-level scope at none:5
└ @ Pkg.Operations /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.4/Pkg/src/Operations.jl:899
➜  dri pwd 
/usr/lib64/dri
➜  dri ls -l
total 259628
-rwxr-xr-x. 5 root root 12658936 May 14 13:36 i915_dri.so*
-rwxr-xr-x. 5 root root 12658936 May 14 13:36 i965_dri.so*
-rwxr-xr-x. 9 root root 19564096 May 14 13:36 iris_dri.so*
-rwxr-xr-x. 9 root root 19564096 May 14 13:36 kms_swrast_dri.so*
-rwxr-xr-x. 9 root root 19564096 May 14 13:36 nouveau_dri.so*
-rwxr-xr-x. 3 root root  8815984 May 14 13:36 nouveau_drv_video.so*
-rwxr-xr-x. 5 root root 12658936 May 14 13:36 nouveau_vieux_dri.so*
-rwxr-xr-x. 5 root root 12658936 May 14 13:36 r200_dri.so*
-rwxr-xr-x. 9 root root 19564096 May 14 13:36 r300_dri.so*
-rwxr-xr-x. 9 root root 19564096 May 14 13:36 r600_dri.so*
-rwxr-xr-x. 3 root root  8815984 May 14 13:36 r600_drv_video.so*
-rwxr-xr-x. 5 root root 12658936 May 14 13:36 radeon_dri.so*
-rwxr-xr-x. 9 root root 19564096 May 14 13:36 radeonsi_dri.so*
-rwxr-xr-x. 3 root root  8815984 May 14 13:36 radeonsi_drv_video.so*
-rwxr-xr-x. 9 root root 19564096 May 14 13:36 swrast_dri.so*
-rwxr-xr-x. 9 root root 19564096 May 14 13:36 virtio_gpu_dri.so*
-rwxr-xr-x. 9 root root 19564096 May 14 13:36 vmwgfx_dri.so*
➜  cairo_experiment glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel (0x8086)
    Device: Mesa Intel(R) UHD Graphics 620 (KBL GT2) (0x5917)
    Version: 20.0.7
    Accelerated: yes
    Video memory: 3072MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.6
    Max compat profile version: 4.6
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) UHD Graphics 620 (KBL GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.0.7
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.6 (Compatibility Profile) Mesa 20.0.7
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.0.7
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
@asinghvi17 asinghvi17 added the GLMakie This relates to GLMakie.jl, the OpenGL backend for Makie. label May 28, 2020
@DevJac
Copy link
Author

DevJac commented May 28, 2020

I found a workaround. See https://www.reddit.com/r/archlinux/comments/g3u729/mesa_issues/

Specifically setting MESA_LOADER_DRIVER_OVERRIDE=i965 solved the problem and GLMake was able to build. That is, I created an environment variable MESA_LOADER_DRIVER_OVERRIDE and set it to i965.

I do not know if this is a GLMake bug or not, but GLMake is the only program I have had troubles with.

@DevJac
Copy link
Author

DevJac commented May 28, 2020

Although the above was able to get GLMakie to build, I ended up getting an assertion error when actually trying to use Makie:

julia> using Makie

julia> x = rand(10);

julia> y = rand(10);

julia> colors = rand(10);

julia> scene = scatter(x, y, color = colors)
Error showing value of type Scene:
ERROR: AssertionError: status == GL_FRAMEBUFFER_COMPLETE
Stacktrace:
 [1] GLMakie.GLFramebuffer(::Tuple{Int64,Int64}) at /home/devjac/.julia/packages/GLMakie/wpJsD/src/glwindow.jl:188
 [2] GLMakie.Screen(; resolution::Tuple{Int64,Int64}, visible::Bool, title::String, kw_args::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}) at /home/devjac/.julia/packages/GLMakie/wpJsD/src/screen.jl:316
 [3] Screen at /home/devjac/.julia/packages/GLMakie/wpJsD/src/screen.jl:275 [inlined]
 [4] global_gl_screen at /home/devjac/.julia/packages/GLMakie/wpJsD/src/screen.jl:346 [inlined]
 [5] global_gl_screen(::Tuple{Int64,Int64}, ::Bool, ::Int64) at /home/devjac/.julia/packages/GLMakie/wpJsD/src/screen.jl:356
 [6] global_gl_screen at /home/devjac/.julia/packages/GLMakie/wpJsD/src/screen.jl:355 [inlined]
 [7] backend_display at /home/devjac/.julia/packages/GLMakie/wpJsD/src/gl_backend.jl:57 [inlined]
 [8] display(::AbstractPlotting.PlotDisplay, ::Scene) at /home/devjac/.julia/packages/AbstractPlotting/erm8R/src/display.jl:45
 [9] display(::Any) at ./multimedia.jl:323
 [10] #invokelatest#1 at ./essentials.jl:712 [inlined]
 [11] invokelatest at ./essentials.jl:711 [inlined]
 [12] print_response(::IO, ::Any, ::Bool, ::Bool, ::Any) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.4/REPL/src/REPL.jl:161
 [13] print_response(::REPL.AbstractREPL, ::Any, ::Bool, ::Bool) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.4/REPL/src/REPL.jl:146
 [14] (::REPL.var"#do_respond#38"{Bool,REPL.var"#48#57"{REPL.LineEditREPL,REPL.REPLHistoryProvider},REPL.LineEditREPL,REPL.LineEdit.Prompt})(::Any, ::Any, ::Any) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.4/REPL/src/REPL.jl:729
 [15] #invokelatest#1 at ./essentials.jl:712 [inlined]
 [16] invokelatest at ./essentials.jl:711 [inlined]
 [17] run_interface(::REPL.Terminals.TextTerminal, ::REPL.LineEdit.ModalInterface, ::REPL.LineEdit.MIState) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.4/REPL/src/LineEdit.jl:2354
 [18] run_frontend(::REPL.LineEditREPL, ::REPL.REPLBackendRef) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.4/REPL/src/REPL.jl:1055
 [19] run_repl(::REPL.AbstractREPL, ::Any) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.4/REPL/src/REPL.jl:206
 [20] (::Base.var"#764#766"{Bool,Bool,Bool,Bool})(::Module) at ./client.jl:383
 [21] #invokelatest#1 at ./essentials.jl:712 [inlined]
 [22] invokelatest at ./essentials.jl:711 [inlined]
 [23] run_main_repl(::Bool, ::Bool, ::Bool, ::Bool, ::Bool) at ./client.jl:367
 [24] exec_options(::Base.JLOptions) at ./client.jl:305
 [25] _start() at ./client.jl:484

@SimonDanisch
Copy link
Member

ERROR: AssertionError: status == GL_FRAMEBUFFER_COMPLETE

Amazing :-O You must have pretty broken drivers....
You may be running into:
JuliaGL/GLFW.jl#198

@DevJac
Copy link
Author

DevJac commented May 28, 2020

Thank you. The suggestion at JuliaGL/GLFW.jl#198 solved my problem. Specifically:

Delete julia-1.3.0/lib/julia/libstdc++.so.6
Find the system libstdc++ with whereis libstdc++
Link that location to julia-1.3.0/lib/julia-libstdc++.so.6 using ln.

The whereis command didn't work for me, but I found the file at /lib/libstdc++.so.6, created the symlink, and then Makie was able to render graphs.

This issue can be close as far as I'm concerned. Although again, Makie is the only software I have had this problem with.

Thanks for the help.

@SimonDanisch
Copy link
Member

That's because of the way Julia & BinaryBuilder interact with the driver -.- So, it can only get fixed in Julia, not in Makie :(

@benkj
Copy link

benkj commented Jun 4, 2020

I get the same error after running the example code on debian testing

using AbstractPlotting
r = range(-3, stop = 3, length = 100)
me = [((1 ./ x).^2 + (1 ./ y).^2 + (1 ./ z).^2) for x=r, y=r, z=r]
me2 = me .* (abs.(me) .> 1.5)
sc= contour(me2, colormap = :Set2)

Error showing value of type Scene:
ERROR: AssertionError: status == GL_FRAMEBUFFER_COMPLETE
Stacktrace:
 [1] GLMakie.GLFramebuffer(::Tuple{Int64,Int64}) at /home/benkj/.julia/packages/GLMakie/wpJsD/src/glwindow.jl:188
 [2] GLMakie.Screen(; resolution::Tuple{Int64,Int64}, visible::Bool, title::String, kw_args::Base.Iterators.Pairs{Union{},Unio
n{},Tuple{},NamedTuple{(),Tuple{}}}) at /home/benkj/.julia/packages/GLMakie/wpJsD/src/screen.jl:316
 [3] Screen at /home/benkj/.julia/packages/GLMakie/wpJsD/src/screen.jl:275 [inlined]
 [4] global_gl_screen at /home/benkj/.julia/packages/GLMakie/wpJsD/src/screen.jl:346 [inlined]
 [5] global_gl_screen(::Tuple{Int64,Int64}, ::Bool, ::Int64) at /home/benkj/.julia/packages/GLMakie/wpJsD/src/screen.jl:356
 [6] global_gl_screen at /home/benkj/.julia/packages/GLMakie/wpJsD/src/screen.jl:355 [inlined]
 [7] backend_display at /home/benkj/.julia/packages/GLMakie/wpJsD/src/gl_backend.jl:57 [inlined]
 [8] display(::AbstractPlotting.PlotDisplay, ::Scene) at /home/benkj/.julia/packages/AbstractPlotting/q9DyS/src/display.jl:45
 [9] display(::Any) at ./multimedia.jl:323
 [10] #invokelatest#1 at ./essentials.jl:712 [inlined]
 [11] invokelatest at ./essentials.jl:711 [inlined]
 [12] print_response(::IO, ::Any, ::Bool, ::Bool, ::Any) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v
1.4/REPL/src/REPL.jl:161
 [13] print_response(::REPL.AbstractREPL, ::Any, ::Bool, ::Bool) at /buildworker/worker/package_linux64/build/usr/share/julia/
stdlib/v1.4/REPL/src/REPL.jl:146
 [14] (::REPL.var"#do_respond#38"{Bool,REPL.var"#48#57"{REPL.LineEditREPL,REPL.REPLHistoryProvider},REPL.LineEditREPL,REPL.Lin
eEdit.Prompt})(::Any, ::Any, ::Any) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.4/REPL/src/REPL.jl:
729
 [15] #invokelatest#1 at ./essentials.jl:712 [inlined]
 [16] invokelatest at ./essentials.jl:711 [inlined]
 [17] run_interface(::REPL.Terminals.TextTerminal, ::REPL.LineEdit.ModalInterface, ::REPL.LineEdit.MIState) at /buildworker/wo
rker/package_linux64/build/usr/share/julia/stdlib/v1.4/REPL/src/LineEdit.jl:2354
 [18] run_frontend(::REPL.LineEditREPL, ::REPL.REPLBackendRef) at /buildworker/worker/package_linux64/build/usr/share/julia/st
dlib/v1.4/REPL/src/REPL.jl:1055
 [19] run_repl(::REPL.AbstractREPL, ::Any) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.4/REPL/src/R
EPL.jl:206
 [20] (::Base.var"#764#766"{Bool,Bool,Bool,Bool})(::Module) at ./client.jl:383
 [21] #invokelatest#1 at ./essentials.jl:712 [inlined]
 [22] invokelatest at ./essentials.jl:711 [inlined]
 [23] run_main_repl(::Bool, ::Bool, ::Bool, ::Bool, ::Bool) at ./client.jl:367
 [24] exec_options(::Base.JLOptions) at ./client.jl:305
 [25] _start() at ./client.jl:484

The suggested fix of copying libstdc++ doesn't work for me. I tried to do that, delete the entire .julia/* and reinstall everything (a bit too drastic), but it still provides the same errors

@benkj
Copy link

benkj commented Jun 4, 2020

I did a bit of debugging and found that I get GL_FRAMEBUFFER_UNSUPPORTED as output

@benkj
Copy link

benkj commented Jun 4, 2020

I don't have any experience with OpenGL, but I see that I'm able to run all the examples from GLFW.jl in a fresh julia REPL. However, if I run the above Makie code first and then try to run the examples from GLFW, then no window is created... quite weird!

@SimonDanisch
Copy link
Member

So you did try the fixes from the issue?

@benkj
Copy link

benkj commented Jun 4, 2020 via email

@KajWiik
Copy link

KajWiik commented Jun 28, 2020

Bump...

I have exactly the same problem: ERROR: AssertionError: status == GL_FRAMEBUFFER_COMPLETE, tried the library fix, GLFW examples work. I'd really like to use Makie for a real data editing task...

@KajWiik
Copy link

KajWiik commented Jun 28, 2020

Bump...

I have exactly the same problem: ERROR: AssertionError: status == GL_FRAMEBUFFER_COMPLETE, tried the library fix, GLFW examples work. I'd really like to use Makie for a real data editing task...

This proved to be a local driver issue: old laptop with Nvidia card that has no valid drivers anymore, only nouveau..

@benkj
Copy link

benkj commented Jun 28, 2020 via email

@malevra
Copy link

malevra commented Jul 17, 2020

Got the same with an Iris GPU on a laptop (Intel® Iris(R) Pro Graphics P5200 (HSW GT3) ) and Ubuntu after upgrade from 19.10 to 20.04. Tried renaming libstdc++, no change. It worked before. I set some additional assertions for glCheckFramebufferStatus(GL_FRAMEBUFFER) after each attach_framebuffer() and found that attaching the normal buffer was the problem for me:

attach_framebuffer(normal_buffer, GL_COLOR_ATTACHMENT3)

commenting out just this line in glwindow.jl seems to have worked for me (for simple plots), but no idea if the normal buffer is used in GLMakie somewhere.

Would it make sense to check for GPU capabilities and have some form of simple backup? Or just expect a set of minimal things to work? At least for me it would be nice to have a meaningful error message ("feature GL_XYZ not supported on GPU")

@ffreyer
Copy link
Collaborator

ffreyer commented Jul 17, 2020

The normal buffer is just used for SSAO. It should be fine to disable that.

@SimonDanisch
Copy link
Member

Would it make sense to check for GPU capabilities and have some form of simple backup?

I'm 95% sure, that this should be supported on an iris GPU and only happens due to bad drivers - would need a bit more investigation, but nothing about that framebuffer looks like it could only be supported on a subset of GPUs.

@ffreyer
Copy link
Collaborator

ffreyer commented Jul 17, 2020

Do you still get an error if you change Vec3f0 to Vec4f0 in these two lines?
https://github.com/JuliaPlots/GLMakie.jl/blob/77856e191bbcbc836a9f784473f30e4f96666db1/src/glwindow.jl#L38
https://github.com/JuliaPlots/GLMakie.jl/blob/77856e191bbcbc836a9f784473f30e4f96666db1/src/glwindow.jl#L164

@malevra
Copy link

malevra commented Jul 17, 2020

Thanks. If I can do anything to clear it up, I could try. BTW, I think I misremembered when it really happened. I now think it appeared after updating from julia 1.4.1 to 1.4.2 on Ubuntu 19.10. I then tried updating Ubuntu to 20.04 to no avail (also reinstalling julia, even 1.4.1). Was the framebuffer introduced between 1.4.1 and 1.4.2?

@ffreyer
Copy link
Collaborator

ffreyer commented Jul 17, 2020

The additional framebuffers came with https://github.com/JuliaPlots/GLMakie.jl/releases/tag/v0.1.5

@malevra
Copy link

malevra commented Jul 17, 2020

@SimonDanisch
Copy link
Member

Do you still get an error if you change Vec3f0 to Vec4f0 in these two lines?

That'd have been my only guess as well ;)

Yes that worked, no error anymore. Thanks!

Not sure if I should be happy about that actually working :D But I guess it doesn't hurt that much, to make vec4 the default here...

@Sov-trotter
Copy link
Contributor

Sov-trotter commented Jul 17, 2020

So I was following this issue, since I had similar problems(Ubuntu 19.04, AMD Radeon 530).

Do you still get an error if you change Vec3f0 to Vec4f0 in these two lines?
https://github.com/JuliaPlots/GLMakie.jl/blob/77856e191bbcbc836a9f784473f30e4f96666db1/src/glwindow.jl#L38
https://github.com/JuliaPlots/GLMakie.jl/blob/77856e191bbcbc836a9f784473f30e4f96666db1/src/glwindow.jl#L164

This worked!

@ffreyer
Copy link
Collaborator

ffreyer commented Jul 17, 2020

Do you still get an error if you change Vec3f0 to Vec4f0 in these two lines?

That'd have been my only guess as well ;)

Yes that worked, no error anymore. Thanks!

Not sure if I should be happy about that actually working :D But I guess it doesn't hurt that much, to make vec4 the default here...

Yea, not really ideal. Maybe we could check if vec3 works and switch to vec4 if necessary? Or we could merge the normal_buffer and the occlusion buffer to avoid wasting memory?

@ffreyer
Copy link
Collaborator

ffreyer commented Jul 17, 2020

Maybe we could check if vec3 works and switch to vec4 if necessary?

That would be easy to do with JuliaPlots/GLMakie.jl#107.

@Kryohi
Copy link

Kryohi commented Jul 26, 2020

Do you still get an error if you change Vec3f0 to Vec4f0 in these two lines?
https://github.com/JuliaPlots/GLMakie.jl/blob/77856e191bbcbc836a9f784473f30e4f96666db1/src/glwindow.jl#L38
https://github.com/JuliaPlots/GLMakie.jl/blob/77856e191bbcbc836a9f784473f30e4f96666db1/src/glwindow.jl#L164

Had the same issue on a i5-5200u machine (Broadwell Gen8 graphics with fully updated Linux drivers).
Can confirm this solves the problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
GLMakie This relates to GLMakie.jl, the OpenGL backend for Makie.
Projects
None yet
Development

No branches or pull requests

9 participants