I have seen disappearing lines before on computers with Intel graphics. Setting linewidth to 1 or higher usually fixed the issue. llvmpipe mesa driver usually gives me slightly thicker
lines than what I get with any hardware-accelerated driver
(intel, amd, nvidia).

Dmitri.
--

Hello,

Yesterday, I posted bug #54554 about an issue I am having with 4.4.1 that is somehow related to Opengl32.dll (issue goes away if I rename the Opengl32.dll shipped with Octave).  I was asked to post here to see if someone else can repro my problem.  Easiest repro for me is to do

plot(zeros(1,1000000))

This gives me an empty plot window with no visible line.  This works fine in 4.4.0.

For more details see my original post in bug #54554.

Thanks!

Asa

-rc2 has a software llvmpipe opengl driver which is fairly fast.

Dmitri.
--

I installed 4.4.1-rc2 (from alpha.gnu.org) on Win10 and can run/plo/print locally and remotely from either linux or Win7
(using mstsc on windows) w/o problems.

FWIW.

Dmitri.
--

Could you try a different client? My current favorite is (x)freerdp: http://www.freerdp.com/

Dmitri.
--

GhostScript being slow is a different issue (that might be solved if the changes in bug #52193 should be applied).

Closing this bug as fixed.

OP here.  I have good news and bad news.  The bad news is that my IT department won't let me install the alpha candidate on my original machine.  Something about unsigned publishers.

The good news is that I was able to install it on my intel NUC system running Windows 10 and the plot zoom/pan performance has improved by orders of magnitude.  It is absolutely phenomenal.  No issues in plotting to pdf with this new installation as-is.  Based on this performance improvement, there is no need to remove or delete the packaged opengl32.dll file.  Very happy with these changes and I hope they make the final release.  Hopefully the issues reported by Philip can be resolved.

Installed the rc2 on my Windows 10 work computer. The llvmpipe driver seems to be loaded and panning "sombrero" works smoothly:

>> __opengl_info__
   version: 3.1 Mesa 18.1.5
    vendor: VMware, Inc.
  renderer: llvmpipe (LLVM 6.0, 256 bits)

But I never really noticed performance issues of the scale the OP described even with the older opengl32.dll.

Also printing sombrero to pdf or png works fine (no Ghostscript errors here).

A new release candidate (source and Windows binaries) is now available.  Here's a direct link for the Windows installer:

http://alpha.gnu.org/gnu/octave/octave-4.4.1-rc2-w64-installer.exe

It would be helpful if the original reporter could try this and say whether the performance is better now and whether printing works.

Sorry for the messy changesets and thanks for cleaning them up.

I can't find the source any more that made me believe "X86_64" was a valid target. It's a lot of trial and error. :-)

I also forgot to add removing the cmake native toolchain stamp file with the "clean" target which bit me today. Please see the attached changeset.

(file #44665)

There is no access to the log files of the individual packages built with mxe-octave.  Those builds are on my systems and I can send them to you if you need them.

The llvm build error is:

 llvm-build: error: invalid target to enable: 'X86_64' (not in project)

I pushed this change:

http://hg.octave.org/mxe-octave/rev/12dff80041be

Buildbots are erroring when building LLVM for 32bit Windows targets (which I never tested).
Is there I way to access the build logs of the buildbots?

Mesa is needed for the Linux builds that I do with mxe-octave so I can control almost all of the dependencies and only rely on a minimal set of system libraries.

Markus: I pushed those changes.  Thanks.

I think it is correct to only depend on mesa when not using the system opengl libraries.

Or did you mean to ask about building osmesa?

@jwe: I don't know if it is valid syntax to call scons without target. Since Octave no longer depends on osmesa the attached changeset should avoid that situation.

Or would it be better to still depend on mesa for non-Windows targets?

(file #44661)

I tested on a system running Windows 7 in a virtualbox VM running remotely, displaying the desktop across a Gb network and the performance seems good to me.  Printing to a file also works.  The _opengl_info_ function reports llvmpipe.

I could probably restore osmesa as a target in case someone wants to have the library for some external package.  But even if it is present, there is no use of it in Octave's current development sources.

Do you know if the working desktop system has a discrete graphics card, or just an integrated Intel's?

Dmitri.
--

Markus:

I pushed your changes for llvm and something similar to your
changes for mesa:

http://hg.octave.org/mxe-octave/rev/f6f934903cd2
http://hg.octave.org/mxe-octave/rev/a50783d698b2

Now I'm able to cross compile llvm and mesa with llvm for Windows.  I'm building an installer now so I can test it.

I'll try to make a new 4.4.1 release candidate and Windows binaries in the next couple of days.

Here is some info about compiling Mesa for Windows (for Qt):

https://wiki.qt.io/Cross_compiling_Mesa_for_Windows

Dmitri.
--

I needed the following changes to enable llvm for the Windows build of the mesa package:

diff --git a/src/mesa.mk b/src/mesa.mk
--- a/src/mesa.mk
+++ b/src/mesa.mk
@@ -7,11 +7,10 @@ PKG             := mesa
 $(PKG)_SUBDIR   := mesa-$($(PKG)_VERSION)
 $(PKG)_FILE     := mesa-$($(PKG)_VERSION).tar.xz
 $(PKG)_URL      := ftp://ftp.freedesktop.org/pub/mesa/$($(PKG)_FILE)
-$(PKG)_DEPS     := build-mako expat zlib
+$(PKG)_DEPS     := build-mako expat zlib llvm s2tc
 ifeq ($(MXE_WINDOWS_BUILD),yes)
   ifeq ($(USE_SYSTEM_OPENGL),no)
     $(PKG)_SCONS_OPENGL_OPTIONS := libgl-gdi
-    $(PKG)_DEPS += s2tc
   endif
 else
   ifeq ($(USE_SYSTEM_OPENGL),yes)
@@ -28,7 +27,6 @@ else
     ifeq ($(USE_SYSTEM_X11_LIBS),no)
       $(PKG)_DEPS += dri2proto glproto libdrm libxshmfence x11 xdamage xext xfixes
     endif
-    $(PKG)_DEPS += llvm s2tc
   endif
 endif

@@ -44,7 +42,7 @@ ifeq ($(MXE_WINDOWS_BUILD),yes)
     $(PKG)_MACHINE := x86
   endif
   define $(PKG)_BUILD
-    cd '$(1)' && scons platform=windows toolchain=crossmingw machine=$($(PKG)_MACHINE) verbose=1 build=release osmesa $($(PKG)_SCONS_OPENGL_OPTIONS)
+    cd '$(1)' && scons platform=windows toolchain=crossmingw machine=$($(PKG)_MACHINE) verbose=1 build=release llvm=True osmesa $($(PKG)_SCONS_OPENGL_OPTIONS)

     ## Do the scons config files have useful install targets?
     $(INSTALL) -d '$(3)$(HOST_INCDIR)/GL';

The real change here is to add llvm=True to the scons command.

But then it failed with the following messages:

In file included from src/gallium/auxiliary/gallivm/lp_bld_type.h:42:0,
                 from src/gallium/drivers/llvmpipe/lp_bld_alpha.c:37:
src/gallium/auxiliary/gallivm/lp_bld.h:54:2: error: #error "HAVE_LLVM should be set with LLVM's version number, e.g. (0x0207 for 2.7)"
 #error "HAVE_LLVM should be set with LLVM's version number, e.g. (0x0207 for 2.7)"
  ^~~~~
src/gallium/auxiliary/gallivm/lp_bld.h:57:2: error: #error "LLVM 3.3 or newer required"
 #error "LLVM 3.3 or newer required"
  ^~~~~
In file included from src/gallium/auxiliary/gallivm/lp_bld_init.h:36:0,
                 from src/gallium/auxiliary/gallivm/lp_bld_const.h:42,
                 from src/gallium/drivers/llvmpipe/lp_bld_alpha.c:38:
/scratch/build/mxe-octave-w32/usr/i686-w64-mingw32/include/llvm-c/ExecutionEngine.h:42:46: error: conflicting types for 'LLVMMCJITMemoryManagerRef'
 typedef struct LLVMOpaqueMCJITMemoryManager *LLVMMCJITMemoryManagerRef;
                                              ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from src/gallium/auxiliary/gallivm/lp_bld_type.h:42:0,
                 from src/gallium/drivers/llvmpipe/lp_bld_alpha.c:37:
src/gallium/auxiliary/gallivm/lp_bld.h:65:15: note: previous declaration of 'LLVMMCJITMemoryManagerRef' was here
 typedef void *LLVMMCJITMemoryManagerRef;
               ^~~~~~~~~~~~~~~~~~~~~~~~~

So maybe this version isn't suitable?  Or is there a newer verions of mesa that will work with llvm 6?

Finally managed to get LLVM 6.0.1 to cross-compile. See the attached changeset.
This should also be a lot closer to what would currently be built for the native MXE-builds.

If Fedora can compile llvmpipe with that version, we should also be able to do it. Hopefully :-)

What would be the next step?

(file #44651)

IIRC, it was mentioned in the discussion about the JIT compiler that LLVM was notorious for introducing breaking changes between versions. So I wanted to stick with a version that probably works according to the documentation.

The mesa page recommends LLVM 3.4. So I tried to build version 3.4.2 in the hope that dot-versions don't contain any breaking changes.

With the attached make file LLVM successfully compiles for me with MXE-Octave with "make download-llvm" and "make build-only-llvm". But I don't know whether it is functional or whether it is complete enough for llvmpipe. It might also break the Linux native builds since I downgraded the version without changing those rules.

The make commands are inspired by [1].

[1]: https://github.com/mxe/mxe/blob/master/src/llvm.mk

(file #44647)

I think we are building opengl32.dll with "mesa.mk" in MXE Octave. It contains the following configure options:

    $(PKG)_CONFIGURE_OPENGL_OPTIONS := \
      --enable-opengl --enable-egl --enable-gles1 --enable-gles2 \
      --with-gallium-drivers="swrast" --with-dri-drivers="" \
      --with-platforms="x11"

Does that mean we are building the older swrast driver?

The mesa docs [1] say to use the following switches to build the Gallium llvmpipe driver (for a Linux target):

  ./configure --enable-glx=gallium-xlib --with-gallium-drivers=swrast --disable-dri --disable-gbm --disable-egl
  make

To be honest, I don't know all the intricacies to make any further comments.

[1]: https://www.mesa3d.org/llvmpipe.html

Do you use the latest drivers for your graphics card hardware? The printing issues might be fixed with newer drivers...

The issue that you are seeing with hardware rendering is one of the reasons why Octave started shipping the MESA opengl32 library.
If the drivers of your graphics card don't work for certain features, unfortunately you'd have to resort to the opengl32.dll with CPU rendering that is shipped with Octave if you like to use these features anyway. As that library doesn't use your graphics card hardware, it might be considerably slower. Especially when rendering more complex scenes (like many points or lines,...).

If your hardware (or system?) opengl32 library doesn't play well with ghostscript, you might be able to stick to file formats that don't need ghostscript (like svg as Dmitri pointed out). And use other programs to convert to the correct file format from there.

In newer versions of Octave, opengl32.dll was shipped with Octave for software rendering, whereas earlier versions used the system's opengl32.dll.  The version shipped with Octave causes a huge performance hit when zooming, panning, or making a plot full screen.  For example it takes 10 seconds to zoom in on an area with modern hardware.  The plot screen seems to hang.  This is documented in bug #53845 and the workaround was to delete or rename opengl32.dll in the Octave bin file, this dramatically improves performance.

The problem now is when using the system's opengl32.dll, plots do not seem to save.  Octave hangs indefinitely and must be force closed through the task manager.  "gs.exe" must also be closed in the task manager.

For example, the code below runs just fine with the shipped version of opengl32.dll, but not with the system's.  However if you use the shipped version of opengl32.dll navigating plots is unbearably slow.  This code has been tried also with the "saveas" function with the same results.  It also crashes if producing 'png' plots in the same fashion.

figure(1);
x=1:10;
y=x.^2;
plot(x,y);
print -dpdf plotstuff.pdf;