Thu 26 Oct 2017 05:37:56 AM UTC, comment #17:
Also setting LIBGL_DRI3_DISABLE=1 seems to solve the problem for me.
Dmitri.
--
|
Wed 25 Oct 2017 07:06:05 PM UTC, comment #16:
Software driver works. My point is the axis thing seems to be
a bug that came and will probably disappear with the next mesa/kernel update (but something else will pop-up).
So the documentation (instructions for the users)
has to be more generic and not tied down to this particular bug.
I am more and more inclined to set this option as a default
and have a readme that instructs brave users to try a hardware
driver.
Dmitri.
--
|
Wed 25 Oct 2017 07:00:38 PM UTC, comment #15:
@Dmitri: In your case, does using LIBGL_ALWAYS_SOFTWARE fail as well? Is there no combination of HW or SW rendering that is working for you? That would be pretty bad.
|
Wed 25 Oct 2017 06:57:57 PM UTC, comment #14:
I think it has to be more generic. The thing with this bug is that i used to be able to plot and did not have the issue, and now i have (with 4.2.1). So it must be a mesa driver (or mesa/kernel combo); a new mesa driver will come along and things will change again...
Dmitri.
--
|
Wed 25 Oct 2017 06:52:26 PM UTC, comment #13:
I think the benchmarking is a useful piece of code to have. When it is fully ready it should become part of the compare_plot_demos.m script so that we can run this before each release to see if plotting or performance has suffered.
However, for this bug report, the issue is how to instruct a user on how to set LIBGL_ALWAYS_SOFTWARE if they find innacurate renderings. I changed the Category of this bug to Documentation. I don't know if the new documentation should be in the manual, maybe in Appendix D about Known Bugs? Or should it be on the wiki?
Seems like there should be a brief explanation of how Octave emits OpenGL instructions, but those instructions have to be interpreted by someone: 1) either a software library, or 2) directly by HW in a graphics card. Even though Octave emits valid OpenGL code, problems can arise if there are bugs in the implementation of either 1) or 2).
Then, ask the user to run the code
and see if the axes lines are visible. If they aren't, recommend using the environment variable to disable HW acceleration.
|
Wed 25 Oct 2017 01:36:37 PM UTC, comment #12:
If it may help I had mofified the plot demo scripts to be able to save and summarize timing data. It is in a very draft state but usable. The visible differences are:
- timing data are saves together with eventual error/warning message for each plot
- when compararing 2 states of Octave with html_compare_plot, a summary of timings and differences (based on image correlation) is emitted in an html page.
(file #42257)
|
Wed 25 Oct 2017 04:13:06 AM UTC, comment #11:
I run dump_plot_demos_1 with hardware and with software opengl.
Attached are the timings (first is screen plot time, the second is printing to png). This is on the affected machine.
I also included original diary1.log so one can figure out
which data corresponds to what demo. May be somebody can write a script to extract this data from this log file (I did it manually with search and replaced and do not feel like doing it again).
Surprisingly sometimes llvmpipe is faster than Hw-acceleration,
so on average Hw is about 2+ times faster.
I hope this is of some interest.
Dmitri.
p.s. Machine is amd fx-8350 with amd 6450 graphics card.
Fedora 26 / Mesa 17.2.2
--
(file #42250, file #42251, file #42252)
|
Tue 24 Oct 2017 04:03:44 PM UTC, comment #10:
I don't think it would be bad to set LIBGL_ALWAYS_SOFTWARE=1 permanently. You would be choosing software over hardware rendering on a permanent basis. The advantage is that the software-rendering engine is implementing the OpenGL specification more accurately than the hardware-rendering engine. The disadvantage would be performance. For most Octave plots, that shouldn't be a big deal, but if you have an application, maybe gaming or possibly CAD, that needs to draw a lot of polygons then it might be a problem. Of course, you could always arrange to either set LIBGL_ALWAYS_SOFTWARE only before running Octave. Or you could go the other way and unset the environment variable before running your graphics-intensive software.
|
Tue 24 Oct 2017 07:44:51 AM UTC, comment #9:
my results are basically identical to Dmitri's. How useful is it to set LIBGL_ALWAYS_SOFTWARE=1 permanently?
|
Mon 23 Oct 2017 11:40:31 PM UTC, comment #8:
I also noticed that turning grid on will show the axes.
Dmitri.
--
|
Mon 23 Oct 2017 11:14:41 PM UTC, comment #7:
@Muhali: Could you try the solution from comment #1?
It sure seems like this is a problem of the GL renderer (AMD in Dmitri's case), rather than Octave.
|
Mon 23 Oct 2017 11:00:23 PM UTC, comment #6:
Nothing changed.
I tried some demos. On busy plots (where it takes a while to make
all plots) I could see the axes being drawn and then they dissapear (on subsecuent replots). But not all of them, see e.g. attached.
Dmitri.
--
(file #42245)
|
Mon 23 Oct 2017 10:21:14 PM UTC, comment #5:
What happens if you do
My guess is you will still have a problem, but at least we can be sure that anti-aliasing is disabled.
|
Mon 23 Oct 2017 05:18:39 PM UTC, comment #4:
I also switched to Xorg from Wayland and it did NOT make a difference.
Dmitri.
--
|
Mon 23 Oct 2017 05:12:37 PM UTC, comment #3:
I had this issue with antialiasing (but not on this particular
computer). This is something else, but I think it is OS related
(new mesa, Wayland, Qt5)...
Attached is the screenshot of Plot(1:3) with
Dmitri.
--
(file #42239)
|
Mon 23 Oct 2017 04:56:44 PM UTC, comment #2:
Works for me. This is with Qt 5.6.1.
This could be a HW or SW issue since OpenGL is often hardware-accelerated (HW), but when it isn't the version of your software-rendering library can make a difference.
What happens if you change the linewidth from 0.5 to 1.0?
Also, what happens if you use the mouse to change the window size? Are there times when the lines are visible and times when they are not? That sometimes happens with fractional linewidths.
|
Mon 23 Oct 2017 03:55:27 PM UTC, comment #1:
I have this problem on one of my computers (amd graphics card; Fedora 26, Qt 5.7.1, Wayland). The problem gets "solved" by
setting LIBGL_ALWAYS_SOFTWARE. E.g.:
Dmitri.
--
|
Mon 23 Oct 2017 08:51:57 AM UTC, original submission:
by doing
plot([0 1])
I don't see the axis line, only the ticks in the plot window; printing works, however. This happens both with the stable and dev version, using Arch Linux. Figure is attached.
|