[GLMakie] only every 64th line segment is rendered on AMD integrated graphics

[imyxh]

Hello, I just noticed something wrong with my lines plots today. When I run the following simple test code in the REPL:

using GLMakie
fig = Figure()
ax = fig[1, 1] = Axis(fig)
xs = 0:0.01:5
lines!(xs, map(sin, xs))

This is the kind of output I get:

The lines drawn seem to only connect two points at a time, and only do so very very intermittently. I have noticed no problems with scatter or even linesegments, just lines.

Does anyone have any suggestions to debug this further? Help would be greatly appreciated. Thanks!

Edit: Julia 1.6.3, GLMakie 0.4.7, Wayland on Linux. CairoMakie does not have the same issue.

[ximonsson]

i am experiencing the same issue running the same setup but using x server instead of wayland on arch linux. also tried with julia 1.6.4 today and the issue persists.

i thought it might be a driver issue and have tried it on three different machines. the only one that it does not work on is the laptop with integrated amd graphics. other opengl applications like glxgears works fine though. funny is that i can see a very short flash of the lines and then they disapear.

maybe someone with similar hardware can confirm if it might be an isolated issue. output of lspci -v | grep -i vga:

03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Renoir (rev d1) (prog-if 00 [VGA controller])

i get the following failed tests when i run ] test GLMakie

Test Summary:                                               | Pass  Fail  Total
Reference Image Tests                                       |   50    17     67
  examples2d_27_Arrowsonhemisphere.png                      |          1      1
  short_tests_36.png                                        |          1      1
  short_tests_51.png                                        |    1            1
  examples2d_104_coloredtrianglewithpoly.png                |    1            1
  text_216_Textoffset.png                                   |    1            1
  short_tests_154_log10heatmap.png                          |    1            1
  attributes_16_font.png                                    |    1            1
  text_202_3Dscreenspaceannotations.png                     |          1      1
  short_tests_22.png                                        |    1            1
  attributes_26_isorange,isovalue.png                       |          1      1
  text_173_text_in_3d_axis.png                              |    1            1
  text_252_latexstrings.png                                 |    1            1
  short_tests_19.png                                        |    1            1
  attributes_50_shading.png                                 |    1            1
  attributes_3_align.png                                    |    1            1
  examples3d_6_ImageonGeometry(Moon).png                    |    1            1
  short_tests_119_heatmaps&surface.png                      |    1            1
  text_266_latexsimple.png                                  |    1            1
  short_tests_67.png                                        |    1            1
  text_80_single_strings_single_positions_justification.png |    1            1
  short_tests_23.png                                        |    1            1
  text_141_single_boundingboxes.png                         |    1            1
  short_tests_25.png                                        |    1            1
  short_tests_1.png                                         |          1      1
  examples2d_43_FEMpolygon2D.png                            |    1            1
  short_tests_33.png                                        |    1            1
  short_tests_35.png                                        |          1      1
  attributes_32_levels.png                                  |          1      1
  short_tests_21.png                                        |    1            1
  text_185_empty_lines.png                                  |    1            1
  short_tests_7.png                                         |    1            1
  examples2d_22_quiver.png                                  |    1            1
  text_19_dataspace.png                                     |    1            1
  short_tests_158_reverserangeheatmap.png                   |    1            1
  short_tests_40.png                                        |          1      1
  short_tests_70.png                                        |          1      1
  short_tests_13.png                                        |    1            1
  text_55_multi_strings_multi_positions.png                 |    1            1
  short_tests_42.png                                        |          1      1
  examples2d_11_polyandcolormap.png                         |    1            1
  short_tests_59.png                                        |    1            1
  short_tests_39.png                                        |          1      1
  short_tests_43.png                                        |    1            1
  short_tests_80_Unequalxandysizesinsurface.png             |          1      1
  short_tests_100_Matricesofdatainsurfaces.png              |          1      1
  text_113_multi_boundingboxes.png                          |    1            1
  short_tests_68.png                                        |    1            1
  examples2d_69_FEMmesh2D.png                               |    1            1
  short_tests_37.png                                        |          1      1
  examples2d_97_coloredtriangle.png                         |    1            1
  text_32_single_strings_single_positions.png               |    1            1
  attributes_9_fillrange.png                                |    1            1
  text_3_heatmap_with_labels.png                            |    1            1
  short_tests_49.png                                        |    1            1
  attributes_40_position.png                                |    1            1
  attributes_54_visible.png                                 |    1            1
  attributes_46_rotation.png                                |    1            1
  examples2d_36_image.png                                   |          1      1
  short_tests_5.png                                         |          1      1
  short_tests_20.png                                        |    1            1
  short_tests_3.png                                         |    1            1
  text_244_Log10text.png                                    |    1            1
  attributes_22_glowcolor,glowwidth.png                     |    1            1
  examples2d_5_Testheatmap+imageoverlap.png                 |    1            1
  short_tests_56.png                                        |    1            1
  short_tests_57.png                                        |    1            1
  short_tests_41.png                                        |          1      1
ERROR: LoadError: Some tests did not pass: 50 passed, 17 failed, 0 errored, 0 broken.
in expression starting at /home/ximon/.julia/packages/GLMakie/pFGSp/test/runtests.jl:21
ERROR: Package GLMakie errored during testing

[SimonDanisch]

Ah, wow...this seems to be again a driver issue:

Jeez, how can the drivers be so different...

[ffreyer]

Is this also an issue with the previous version?

[ximonsson]

tried v0.4.6, v0.4.5 and v0.3.4 and they all had the same issue. guess the drivers are to blame here.

[imyxh]

i thought it might be a driver issue and have tried it on three different machines. the only one that it does not work on is the laptop with integrated amd graphics. other opengl applications like glxgears works fine though. funny is that i can see a very short flash of the lines and then they disapear.

Aha! I am using the integrated graphics on an AMD Ryzen 5 2400G. And yes, I also noticed the flash.

[mo8it]

Makie v0.16.1
GLMakie v0.5.0

This version just came out two days ago and the issue is still not solved #1543.

I also use AMD integrated graphics.

Blaming the driver sounds too easy since I guess we here have different kernel versions. Any idea how to help to debug it?

My linux kernel version is 5.15.12

[SimonDanisch]

Blaming the driver sounds too easy since

Well, it only happens on AMD, so it must be a driver issue one way or the other...
It doesn't mean, that we can't fix it by writing the shader in a different way, but it does mean it will be hard to figure out, especially if I don't have access to the hardware.

[imyxh]

I guess my question is, how is lines using the driver that linesegments isn't? And are there other plot commands that we should test that are similar to lines?

Also, what driver do you suspect is at fault here? OpenGL? OpenCL? Vulkan? Sorry, not very familiar with the GLMakie codebase, but I would be happy for that to change!

[mo8it]

I am sorry, I am not trying to blame you @SimonDanisch . I would just like to help. Hardware access is difficult. I could run tests and provide you with the results if you want.

Should we open an issue for the kernel? The other two users are also on Linux, so it might be an issue with the Linux driver specifically.

[mo8it]

I guess my question is, how is lines using the driver that linesegments isn't? And are there other plot commands that we should test that are similar to lines?

Strokes from poly are also affected as shown in this issue #1543.

I can confirm that linesegments does work on my machine.

[mo8it]

lines([1, 2], [1, 2]) does also work fine. But lines([1, 2, 3], [1, 2, 3]) does only show the segment from (1, 1) to (2, 2).
The question is, what happens after the first segment in lines that breaks things?

linesegments([1, 2, 2, 3], [1, 2, 2, 3]) shows exactly the expected result of lines([1, 2, 3], [1, 2, 3]) without any problem.

[imyxh]

It's not just the first line segment that displays, as you can see in my original image. It seems to maybe be every 64th line segment? Or something close to that? (away from my computer)

[mo8it]

@imyxh you are right!

Example:

x = 1:200
lines(x, x)

This code shows only segments starting with the points (1, 1), (65, 65), (129, 129) etc.

[nchisholm]

Should we open an issue for the kernel? The other two users are also on Linux, so it might be an issue with the Linux driver specifically.

I can confirm that the bug does not affect Windows but does affect Linux for me. (I am dual booting my laptop with an AMD Ryzen 7 pro 4750u APU).

[mo8it]

I could open an issue on the kernel repo take a look at the instructions here https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html to report an issue, but what would I write there?

@SimonDanisch It would be awesome if you would provide us with some assumptions of what in the driver is not working, and which driver, as @imyxh asked :)

[imyxh]

I could open an issue on the kernel repo take a look at the instructions here https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html to report an issue, but what would I write there?

I feel like if there is indeed an upstream bug, it is likely it lies in mesa instead of the kernel? I have an apitrace here: https://0x0.st/oi3o.trace but it's very long and I have no idea how to interpret it.

[SimonDanisch]

So, I expect some math function to work slightly differently on AMDs linux driver....
The most likely place where this leads to problems is here:
https://github.com/JuliaPlots/Makie.jl/blob/master/GLMakie/assets/shader/lines.geom#L60

The input of that shader is a whats called lines_adjacency, which is pretty much:

points = ...# points of the line
geom_shader_output = map(Iterators.partition(points, 4)) do g_valid_vertex
   p1, p2, p3, p4 = g_valid_vertex
  ...
end

All the g_.*[] inputs are like this.

To debug this, you can just directly change lines.geom...After closing the window (important!) and re-running the plotting code, GLMakie should use the new shader!
So one could try e.g. setting isvalid[4] to bool[](true, true, true, true)

[mo8it]

I did what you said and changed isvalid[4] to bool[](true, true, true, true), but this did not change anything. I did close the window and rerun the command every time after changing the file btw.

Then I tried some other combinations of true and false. Two combinations did work:

• bool[](false, true, true, true)
• bool[](false, true, true, false)

They produce the expected lines! Even the stroke problem from issue #1543 is solved! The lines do not disappear after a moment (no flashing, see below).

If I set the first field to true, then I get the bad result with only every 64-th segment plotted. I do also see the expected lines for a moment (less than a second) after closing and rerunning. Then they disappear. This flashing is descried here #1460 (comment).

If I set the second and/or the third field to false, then I only see the coordinate system, no line segments, also not the 64-th ones.

Setting the fourth field to true or false does not change anything.

TL;DR: The problem is that the first field is set to true, but it has to be false.

Please give me further instructions to debug. I am happy to help ^^

[mauro3]

Same here, Arch-Linux/Wayland on AMD integrated graphics.

[SimonDanisch]

@mo8it oh, I didn't see this comment.
Great to see progress on this. Lets see, if this already gives me something to work with.

[hammerfunctor]

Same, ArchLinux/X11, driver version:

amdvlk 2022.Q1.3-1
lib32-amdvlk 2022.Q1.3-1
xf86-video-amdgpu 22.0.0-1

Makie version:

Makie v0.16.5
GLMakie v0.5.4

[SimonDanisch]

So I finally had a chance to try out an AMD onboard GPU on windows.

I can confirm that the bug does not affect Windows but does affect Linux for me

Damn, yeah I can confirm this. There goes the chance to debug this, I guess...

[mauro3]

Easy: just install Linux ;-)

[SimonDanisch]

:D

[tomchor]

Dropping by to say that I also have the issue (on AMD graphics using Manjaro). It looks like there's no workaround so far, correct?

Let me know if there's any diagnostics I can run to help!

[VarLad]

Issue does appear to be AMD only.
Of course, since we don't have GLFW BB for Wayalnd, NVIDIA + XWayland suffer with their own issues

@SimonDanisch What are the odds that we can shift to Rust's wgpu-rs library for Makie (via its C API) instead of GLFW? :D

[SimonDanisch]

Well if someone has time for it😂 The api of glfw is pretty thin, so easy to replace😉

[ArbitRandomUser]

The workaround I am using as of now is to use either llvmpipe or the zink (if vulkan capable) driver .
to use the software rasterizer llvmpipe start julia with environment variables

env LIBGL_ALWAYS_SOFTWARE=true GALLIUM_DRIVER=llvmpipe julia 

to use zink

env __GLX_VENDOR_LIBRARY_NAME=mesa MESA_LOADER_DRIVER_OVERRIDE=zink GALLIUM_DRIVER=zink julia 

more details ...
https://wiki.archlinux.org/title/OpenGL#Switching_between_drivers

[VarLad]

@ArbitRandomUser Darn, I totally forgot about Zink. Nice find! 😄

[VarLad]

@SimonDanisch Reminds me, I visually see the full line at the very beginning for a moment, but it gets shrinked to a small line the next instant. That happens every time I run lines(1:10, 1:10)
Does that tell you something? Thought it might help.

[VarLad]

Caught it in a screenshot too. It changes to the incorrect plot in a moment, but the correct plot is there initially :D

[felixcremer]

When I am using GLMakie inside of a Jupyter Notebook, the first plot that I do after starting Julia is displayed correctly, but the second plot shows only every 64th line segment. Even just displaying the current figure for a second time only shows every 64th line segment.
This might be similar to the flickering.

@SimonDanisch maybe we can sit down together next week and have a short glance at this problem?

[felixcremer]

I sat down with Simon and tried to debug this on Julia 1.9 and Makie 0.19.1 and GLMakie 0.8.1.
On the first plot after starting Julia the lines are shown at first and you can get them to show the strange behaviour by doing the following steps:

julia> GLMakie.closeall()

julia> f, ax, pl = lines(rand(100)); s=display(f)
GLMakie.Screen(...)

julia> GLMakie.render_frame(s)

julia> GLFW.SwapBuffers(s.glscreen)

even if you close the window it keeps being broken on the next plot until you call
GLMakie.closeall().

[SimonDanisch]

I created an MWE repository: https://github.com/SimonDanisch/AMDMWE.jl
Right now, this does NOT reproduce the issue, but should use almost the same code as GLMakie.
The biggest difference now is the renderloop + renderpasses, which should help at least to narrow the problem down.

[felixcremer]

For me this issue is closed on julia version 1.8.5 and GLMakie version 0.8.3 and newer combinations I tried.
I have no idea what exactly changed, because I have also the feeling that it also works on the versions which failed two month ago.

[ffreyer]

#2666 changed a lot about lines, though I don't know if it fixed this issue. That has been merged in 0.8.3 if I'm not mistaken.

[tomchor]

Can confirm this issue is solved for me on Linux using GLMakie v0.8.4 and Julia 1.8.5.

[SimonDanisch]

Lets close it then for now^^ Would be really great if this finally "just worked"

[bjarthur]

@SimonDanisch What are the odds that we can shift to Rust's wgpu-rs library for Makie (via its C API) instead of GLFW? :D

Well if someone has time for it😂 The api of glfw is pretty thin, so easy to replace😉

i just heard of wgpu for the first time this morning. described as the successor to both opengl and webgl here. seems like long-term at some point makie will need to be refactored.

[bjarthur]

follow up question-- would refactoring to use wgpu provide a path to unify the GLMakie and WGLMakie backends?

[asinghvi17]

Seems they have a C API and some Julia wrappers already, so it's definitely feasible. But that's just for the desktop implementation, I'm not sure if that interface extends to WebGL.

[SimonDanisch]

Honestly, i wouldn't bet any horses on this.
Vulkan promised something similar, and Apple & NVidia killed it...
WGPU promises the same, but is very far away from any mainstream adaptation, so very hard to tell.
I don't really see how we even would share code between WGPU on the browser and the WGPU C api besides re-using the same shaders, which isn't currently the main pain point.

[bjarthur]

WGPU ... is very far away from any mainstream adaptation

i'm not so sure about this. in january of this year it proceeded to the stage of "candidate recommendation draft" at W3C. https://www.w3.org/standards/history/webgpu

worth noting too that apple has deprecated opengl as of v4.1. there appears to be no firm date as to when they'll sunset it entirely though.

[SimonDanisch]

Well, that's what I mean exactly ;) Adaptation for Graphics API are notoriously slow, for Vulcan it took at least 5-9 years from first draft/demos/support to being somewhat certain that it works on 90%+ of hardware (note Vulkan was released 2016, and adaptation is still somewhat shaky).
On top of it, the big question is who will pay for such a large refactor. It's not something someone can do on the side, and it may easily take 2-6 months of full time work, so if anyone is interested in this, I guess the main thing to focus on would be figuring out how to finance something like this ;)
That said, of course little proof of concepts will pave the way, so would certainly be interesting if someone has time to setup first little cross platform demos in Julia with it.
That might at some point be the trigger to seriously consider it.