bugGNU Octave - Bugs: bug #54396, Removing Opengl32.dll speeds up...

 
 

bug #54396: Removing Opengl32.dll speeds up plot navigation, but it prevents saving plots using saveas or print

Submitted by:  None
Submitted on:  Fri 27 Jul 2018 05:46:00 PM UTC  
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error
Status:  Fixed Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  4.4.0
Operating System:  Microsoft Windows

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Thu 23 Aug 2018 11:36:03 PM UTC, comment #50: 

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.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 23 Aug 2018 10:22:24 PM UTC, comment #49: 

I am seeing the same issue on Windows 10 with a recent default.
Zooming in to a range of about 100000 makes the line appear.

Same results also for the sine wave.

It's a bummer that the software renderers seem to be either slow or unreliable.

mesa 18.2 should be out within a few weeks. If we are lucky this might be fixed.

Markus Mützel <mmuetzel>
Project Member
Thu 23 Aug 2018 08:26:34 PM UTC, comment #48: 

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

Asa Packer <apacker>
Wed 08 Aug 2018 01:31:38 PM UTC, comment #47: 

Apparently it's something local to our company's setup.

Philip Nienhuis <philipnienhuis>
Project Member
Wed 08 Aug 2018 12:07:25 PM UTC, comment #46: 

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

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 08 Aug 2018 09:12:40 AM UTC, comment #45: 

Little wonder Dmitri, 4.4.1-rc2 still has the the (slow) opengl32.dll.
What happens if you rename bin/opengl32.dll to e.g., bin/__opengl32.dll ?

Philip Nienhuis <philipnienhuis>
Project Member
Tue 07 Aug 2018 09:33:03 PM UTC, comment #44: 

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.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 07 Aug 2018 07:55:48 PM UTC, comment #43: 

You mean, persuade the IT dept. to completely overthrow the entire company-wide IT architecture? You must be kidding :-)

Seriously, I and my colleagues have to make do with what the company offers to its employees, and my concern is that this virtualization is going to be the standard on more and more work environments, hitherto for more and more (potential) Octave users.
I can only access "my own" "powerbox" from a completely locked down basic standard virtual client w/o any special privileges. No way to get any outside SW installed there.

mstsc.exe is in a way my gateway to freedom on the two company boxes (a real one, as long as it lasts, and a virtual one in the cloud) where I do have some privileges.

Philip Nienhuis <philipnienhuis>
Project Member
Tue 07 Aug 2018 05:17:59 PM UTC, comment #42: 

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

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 07 Aug 2018 03:17:07 PM UTC, comment #41: 

Not yet reopening, but just reporting the story hasn't ended.

At work I use remote sessions using Microsoft's "mstsc.exe" program ("MS Terminal Server Client"), and when trying to plot something Octave crashes immediately (in the remote session).
Copying opengl32.dll into the bin/ subdirectory on the remote computer (could be a "real" tangible one but at another office, or a virtual session on a "persistent image" at the data center) makes Octave show graphics again.
(I copied the opengl32.dll from an older Octave installation from late June.)

Whether or not this is "upstream" I'm unsure. Yet it gets more important as many companies and institutions switch to remote virtual sessions running on thin clients (a tiny PC that can just convey mouse clicks and key presses and in return merely receives pixels to show).

I'll try to contact the guys who manage these network clients, but I have little hope that I'll get any further there.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 03 Aug 2018 07:04:42 AM UTC, comment #40: 

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.

Markus Mützel <mmuetzel>
Project Member
Thu 02 Aug 2018 10:06:05 AM UTC, comment #39: 

@JWE:
(sorry yesterday I tried at work, later on no time at home, just got back in the office)

Yes, after restarting Octave plotting/printing to pdf works fine. But it makes for quite some delay, I suppose Ghostscript takes its time.

Philip Nienhuis <philipnienhuis>
Project Member
Thu 02 Aug 2018 12:48:57 AM UTC, comment #38: 

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.

Anonymous
Wed 01 Aug 2018 01:33:36 PM UTC, comment #37: 

I noticed the ghostscript error when the installer started Octave but it seemed to work properly after I restarted.

Philip, is the error persistent for you, even after starting a new Octave session?

John W. Eaton <jwe>
Project Administrator
Wed 01 Aug 2018 01:08:14 PM UTC, comment #36: 

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).

Markus Mützel <mmuetzel>
Project Member
Wed 01 Aug 2018 10:13:13 AM UTC, comment #35: 

I'm not the OP, but on my box at work (w. Intel graphics) it makes a LOT of difference (much faster). Nice!

Printing is a bit different:

>> print -dpdf plotstuff.pdf
GPL Ghostscript 9.16: **** Could not open temporary file __MY_TMP_DIR__/gs_a05648
**** Unable to open the initial device, quitting.
error: gl2ps_renderer::draw: internal pipe error
>> error: parse error
error: called from
    __opengl_print__ at line 158 column 7
    print at line 561 column 14

... (all in a few seconds); while printing to .png works fine (and rapidly).

BTW as to the rc2:
Summary:
  PASS                            14995
  FAIL                                0
  XFAIL (reported bug)               36
  SKIP (missing feature)             54
  SKIP (run-time condition)           9

Philip Nienhuis <philipnienhuis>
Project Member
Tue 31 Jul 2018 07:54:25 PM UTC, comment #34: 

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.

John W. Eaton <jwe>
Project Administrator
Tue 31 Jul 2018 06:34:14 PM UTC, comment #33: 

I also tried something like X86_64 for the target name but it didn't work for me either.  I assumed you had found the magic combination of config options.  :-)

No worries about the changesets.  I pushed your latest patch.

John W. Eaton <jwe>
Project Administrator
Tue 31 Jul 2018 05:16:17 PM UTC, comment #32: 

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)

Markus Mützel <mmuetzel>
Project Member
Tue 31 Jul 2018 11:30:07 AM UTC, comment #31: 

OTOH, swapping those causes the build to fail for 64-bit Windows systems with this error:

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

So for now I'm just setting the target to X86 always.

John W. Eaton <jwe>
Project Administrator
Tue 31 Jul 2018 11:27:30 AM UTC, comment #30: 

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

John W. Eaton <jwe>
Project Administrator
Tue 31 Jul 2018 11:10:38 AM UTC, comment #29: 

I also found the interface of new buildbots less intuitive than the old one:

http://buildbot.octave.org:8010/#/builders/14/builds/85/steps/7/logs/stdio

Click on the name of the buildbot, then on build # etc...

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 31 Jul 2018 10:41:59 AM UTC, comment #28: 

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?

Markus Mützel <mmuetzel>
Project Member
Mon 30 Jul 2018 08:52:22 PM UTC, comment #27: 

Now that we can cross compile LLVM and mesa with LLVM for Windows, we should probably also enable the same for native mingw Windows builds.  I don't do builds that way though, so someone else will have to modify the cross rules and test.

John W. Eaton <jwe>
Project Administrator
Mon 30 Jul 2018 08:50:25 PM UTC, comment #26: 

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.

John W. Eaton <jwe>
Project Administrator
Mon 30 Jul 2018 08:44:49 PM UTC, comment #25: 

Thanks.
I never used MXE for native builds. So I don't know whether the dependency on mesa is still needed for native MXE Octave builds on Linux. But I guess it's not...

I'd say cross-building osmesa is not a priority.

Markus Mützel <mmuetzel>
Project Member
Mon 30 Jul 2018 08:37:47 PM UTC, comment #24: 

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?

John W. Eaton <jwe>
Project Administrator
Mon 30 Jul 2018 07:11:51 PM UTC, comment #23: 

And another changeset that enables ccache when compiling llvm.

(file #44662)

Markus Mützel <mmuetzel>
Project Member
Mon 30 Jul 2018 06:43:24 PM UTC, comment #22: 

@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)

Markus Mützel <mmuetzel>
Project Member
Mon 30 Jul 2018 06:14:51 PM UTC, comment #21: 

@Dmitri  Yes, the working desktop system has a discrete graphics card.  It is the Intel NUC8I7HVK with Radeon RX Vega M graphics.

@Markus Thank you.  Fingers crossed that the new dll will be faster!

-OP

Anonymous
Mon 30 Jul 2018 05:06:04 PM UTC, comment #20: 

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.

John W. Eaton <jwe>
Project Administrator
Mon 30 Jul 2018 04:39:11 PM UTC, comment #19: 

@jwe: Removing osmesa was thought to be temporary. But I'm realizing now that it is no longer needed.
However, with the current makefile it might be possible that scons is called without target (building for Windows with the default --enable-system-opengl).
Is mesa not built at all for that configuration? Or do we need to add some logic to prevent that?

@OP: If we are lucky, the new opengl32.dll will be faster than the  current one. But it won't use a dedicated GPU even if available.
It would be nice if we could enable and disable software rendering more easily (and maybe switch the defaults). But I'm pretty sure there already is an open bug report for that.

Markus Mützel <mmuetzel>
Project Member
Mon 30 Jul 2018 04:31:23 PM UTC, comment #18: 

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

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 30 Jul 2018 04:27:41 PM UTC, comment #17: 

OP here, sorry for the delay.  The machine is a Surface Book 2 with the newest drivers (no external or dedicated GPU).  I tried to save as SVG using the "system's" opengl32.dll file, but it still hangs indefinitely.  The plot opens up fine, and there is an SVG file with no data in the folder that is created.  Using this method does not cause gs.exe to appear in the task manager (understandably).

I was able to get a hold of a different desktop Windows 10 machine with the same version of Octave, and it does not have any issues in saving pdf, png, or svg plots with the same code using the system's dll file.

As a side note, on any Windows 10 machine I've used, the plot zoom/pan/maximize_winodow performance is so poor that a user pretty much has to delete/rename the packaged opengl32.dll.  This is even true on an 8th generation i7 chip at 3.1 GHz with a discrete GPU, just plotting 10 points.

Anonymous
Mon 30 Jul 2018 03:31:59 PM UTC, comment #16: 

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.

John W. Eaton <jwe>
Project Administrator
Mon 30 Jul 2018 04:13:49 AM UTC, comment #15: 

I got a little bit further with these changes:

diff -r e0dbadd553c6 src/mesa.mk
--- a/src/mesa.mk        Sun Jul 29 12:06:04 2018 +0200
+++ b/src/mesa.mk        Mon Jul 30 06:03:43 2018 +0200
@@ -2,8 +2,8 @@
# See index.html for further information.

PKG             := mesa
-$(PKG)_VERSION  := 17.2.1
-$(PKG)_CHECKSUM := 7429e74a0ef12ea9d60b41b2b852898b3da0b238
+$(PKG)_VERSION  := 18.0.5
+$(PKG)_CHECKSUM := 4f6f87d47336536b4c1864cd3e39e42bbc4ec158
$(PKG)_SUBDIR   := mesa-$($(PKG)_VERSION)
$(PKG)_FILE     := mesa-$($(PKG)_VERSION).tar.xz
$(PKG)_URL      := ftp://ftp.freedesktop.org/pub/mesa/$($(PKG)_FILE)
@@ -11,7 +11,7 @@
ifeq ($(MXE_WINDOWS_BUILD),yes)
   ifeq ($(USE_SYSTEM_OPENGL),no)
     $(PKG)_SCONS_OPENGL_OPTIONS := libgl-gdi
-    $(PKG)_DEPS += s2tc
+    $(PKG)_DEPS += llvm s2tc pthreads
   endif
else
   ifeq ($(USE_SYSTEM_OPENGL),yes)
@@ -44,7 +44,7 @@
     $(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)' && LLVM=$(HOST_PREFIX) LDFLAGS="-static -s -L$(HOST_LIBDIR)/gcc/$(TARGET)/$(native-gcc_VERSION)" scons platform=windows toolchain=crossmingw machine=$($(PKG)_MACHINE) verbose=1 build=release $($(PKG)_SCONS_OPENGL_OPTIONS)

     ## Do the scons config files have useful install targets?
     $(INSTALL) -d '$(3)$(HOST_INCDIR)/GL';
@@ -52,12 +52,6 @@
       $(INSTALL) -m 644 $$f '$(3)$(HOST_INCDIR)/GL'; \
     done

-    $(INSTALL) -d '$(3)$(HOST_LIBDIR)';
-    $(INSTALL) -m 644 '$(1)/build/windows-$($(PKG)_MACHINE)/gallium/targets/osmesa/libosmesa.a' '$(3)$(HOST_LIBDIR)/libOSMesa.a';
-
-    $(INSTALL) -d '$(3)$(HOST_BINDIR)';
-    $(INSTALL) -m 755 '$(1)/build/windows-$($(PKG)_MACHINE)/gallium/targets/osmesa/osmesa.dll' '$(3)$(HOST_BINDIR)/osmesa.dll';
-
     if [ -f '$(1)/build/windows-$($(PKG)_MACHINE)/gallium/targets/libgl-gdi/opengl32.dll' ]; then \
       $(INSTALL) -m 755 '$(1)/build/windows-$($(PKG)_MACHINE)/gallium/targets/libgl-gdi/opengl32.dll' '$(3)$(HOST_BINDIR)/opengl32.dll'; \
     fi

I (temporary#) removed osmesa to see whether I could get just llvmpipe to compile.

But it also failed with a link error (could not find pthread).
At least it detected llvm. I think LLVM has to be set to the correct path in the environment.
When I removed the static linking, I got different linker errors that were zlib related.
Maybe the built LLVM just isn't functional.

Markus Mützel <mmuetzel>
Project Member
Mon 30 Jul 2018 04:08:30 AM UTC, comment #14: 

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

https://wiki.qt.io/Cross_compiling_Mesa_for_Windows

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 30 Jul 2018 03:40:51 AM UTC, comment #13: 

The latest version of mesa failed with similar errors.  Maybe we need to try LLVM 3.3 for mesa?

John W. Eaton <jwe>
Project Administrator
Mon 30 Jul 2018 03:29:16 AM UTC, comment #12: 

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?

John W. Eaton <jwe>
Project Administrator
Mon 30 Jul 2018 02:59:13 AM UTC, comment #11: 

Markus:  Thanks for the patch.  I struggled and failed with LLVM 5.0.0.  I'm trying a build now with your changes.

You can also try building the mesa package now that you have llvm built.  The Linux builds seem to use llvm if it is available.  But the configuration is handled differently (autoconf for Linux vs scons for Windows) so I don't know whether it will just work, or require some additional changes to the configuration.

John W. Eaton <jwe>
Project Administrator
Sun 29 Jul 2018 10:12:43 AM UTC, comment #10: 

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)

Markus Mützel <mmuetzel>
Project Member
Sat 28 Jul 2018 09:45:54 PM UTC, comment #9: 

OK. In any case 6.0.1 seems to be working on linux.
I am also wondering if you are building mesa-demos?
Having glxinfo and glxgears would be helpful for debugging some
of those issues...

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 28 Jul 2018 09:30:45 PM UTC, comment #8: 

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.

Markus Mützel <mmuetzel>
Project Member
Sat 28 Jul 2018 09:25:22 PM UTC, comment #7: 

FWIW -- FEdora has llvm 6.0.1

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 28 Jul 2018 09:04:47 PM UTC, comment #6: 

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)

Markus Mützel <mmuetzel>
Project Member
Sat 28 Jul 2018 03:42:07 PM UTC, comment #5: 

When using mxe-octave to build Octave for Windows, llvmpipe is not currently used because I don't think we have a working build of the llvm package.  Make that work, and I think we can enable llvmpipe for the mesa build.

John W. Eaton <jwe>
Project Administrator
Sat 28 Jul 2018 01:17:51 PM UTC, comment #4: 

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

Markus Mützel <mmuetzel>
Project Member
Sat 28 Jul 2018 12:51:28 PM UTC, comment #3: 

Which particular MESA driver does it use on windows?
llvmpipe or the older swrast?

With llvmpipe (on linux) I hardly notice any difference in interactive use.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 28 Jul 2018 10:34:27 AM UTC, comment #2: 

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.

Markus Mützel <mmuetzel>
Project Member
Fri 27 Jul 2018 05:51:29 PM UTC, comment #1: 

Does it work if you save/print to svg?
(this should eliminate gs from chain).

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 27 Jul 2018 05:46:00 PM UTC, original submission:  

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;

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #44665:  bug54396_remove_cmake_native.patch added by mmuetzel (796B - application/octet-stream)
file #44662:  bug54396_llvm_ccache.patch added by mmuetzel (2KiB - application/octet-stream)
file #44661:  bug54396_mesa_dependency.patch added by mmuetzel (3KiB - application/octet-stream)
file #44651:  bug54396_llvm6.patch added by mmuetzel (4KiB - application/octet-stream)
file #44647:  llvm.mk added by mmuetzel (2KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by johasixt
  • -email is unavailable- added by apacker (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-09-03 johasixt Carbon-Copy- => Added johasixt
    2018-08-03 mmuetzel StatusNone => Fixed
        Open/ClosedOpen => Closed
    2018-07-31 mmuetzel Attached File- => Added bug54396_remove_cmake_native.patch, #44665
    2018-07-30 mmuetzel Attached File- => Added bug54396_llvm_ccache.patch, #44662
    2018-07-30 mmuetzel Attached File- => Added bug54396_mesa_dependency.patch, #44661
    2018-07-29 mmuetzel Attached File- => Added bug54396_llvm6.patch, #44651
    2018-07-28 mmuetzel Attached File- => Added llvm.mk, #44647

    Back to the top


    Powered by Savane 3.5