Re: mxe-octave status

[Philip Nienhuis]

John W. Eaton wrote:
> On 10/20/2017 05:32 AM, PhilipNienhuis wrote:
>
> > FWIW, in latest Octave 4.3.0+ built with qt5 and up-to-date mxe-octave
> > incl.
> > your mesa patches, _opengl_info__ runs fine & relatively fast with NVidia
> > graphics hardware en newer Intel hardware (all with OpenGL v. 3.3.0)
> > on my
> > Windows boxes at home.
>
> What HG ID for mxe-octave?

ce435b70fd94  (Rik)  quadl.m: Return single ....

> How did you configure mxe-octave?

--enable-octave=default
--enable-windows-64
--enable-binary-packages
--enable-devel-tools
and that's it.

> Did you
> use --disable-system-opengl when configuring mxe-octave?

No.

> Do you have
> opengl32.dll in the bin directory alongside octave-gui.exe?

No.

> Are you using the mesa software renderer provided by the mesa
> opengl32.dll or the accelerated hardware renderer?

How can I assess that?

On my home desktop:

> > __opengl_info__
   version: 3.3.0
    vendor: NVIDIA Corporation
  renderer: GeForce 210/PCIe/SSE2
extensions:
  GL_ARB_arrays_of_arrays
  GL_ARB_base_instance
  :
  :
  <and lots of other info.>

Similar on my laptop with Intel HD4000 graphics (also version 3.3.0).

> > At work, with older Intel HW and with virtualized sessions ("VMWare
> > VGA 3D"
> > graphics adapter), that same Octave build only freezes the first time
> > when
> > invoking __opengl_info__ or any plot function, after that my Windows
> > installations issue messages that they detected problems with Octave and
> > have automatically applied "compatibility settings" to it. To no avail as
> > the next time graphics functions are invoked Octave just crashes
> > immediately
> > - indeed a segfault AFAICS.
> > Do I suppose correctly those crashes are due to the mesa patches?
>
> I don't know, because I don't understand exactly what it is you are
> doing.  Are you using the opengl32.dll that is in the bin directory
> along with Octave, or are you using the opegl32.dll provided by the
> operating system or hardware vendor?

As it isn't present in the octave bin/ subdir, I suppose the one in 
C:\Windows\System32 is invoked.

I tried an mxe-octave qt5 binary from Sep. 2 (fully up-to-date at that 
time) on my work PC and there plotting and _opengl_info__ provoked no 
crash. So the changes provoking the crash must be from after that date.
(I think __opengl_info__'s output indicate software rendering? I saw 
"Microsoft GDI" and version 1.1.0 in its output and only 2 or 3 struct 
fields)


Just for info:

I have a fairly "plain vanilla" mxe-octave, with a few local mods to:

src/of-mapping, and
src/of-io, as I maintain those packages and usually run bleeding edge 
versions of them;

tools/makeinst_script.sh, to put shortcuts elsewhere than in the root of 
the Start Menu, and to install Octave in C:\Programs\Octave rather than 
in C:\Octave

/Makefile, to avoid of-database to be built (that currently breaks in 
the mxe-octave builds);

/binary-dist-files.mk, to:
* avoid appending $(VERSION) to the octave subdir name in dist/,
* copy an adapted octave-packages file to the dist/octave/share/octave 
subdir,
both allowing me to run Octave incl. OF-packages from that dist/octave/ 
when on Windows, w/o requiring to:
- always build the installer itself (saves ~15 mins.),
- copy it over and install it in Windows (another 10 mins.), and
- adapt the path to octave.vbs (hence avoiding $(VERSION) )
by just having a persistent shortcut in Windows to octave.vbs in
.../mxe-octave/dist/octave/ on my Linux /home drive (mounted using ext2fsd).

I hope this is all clear enough :-)

> > Could Octave be learned the same trick? that is, disabling hardware
> > OpenGL
> > if it finds "non-compatible graphics HW" ? Probably be too much
> > trouble if
> > that would only be required for Windows.
>
> That's exactly the point of building and providing our own mesa
> opengl32.dll, to avoid the hardware problems by doing software rendering
> instead.  But we are not currently attempting to detect configurations
> that might have problems and automatically choose between the mesa DLL
> and the one provided by the system.

That's what I figured.

From what I can see, OpenGL 3.3.0 seems to be safe with regard to 
hardware-based rendering on Windows.

Thanks,

Philip