mxe-octave status

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

mxe-octave status

John W. Eaton
Administrator
With current Octave and mxe-octave the default-octave target works forme
when doing builds for native GNU systems and cross compiling for
Windows-64 with either qt4 or qt5.  I'm also building libGL from the
Mesa package for consistent software rendering (more about that below).
Here are the configurations I'm using:

Options common to all builds:

   --with-pkg-dir=/a/common/dir/for/source/downloads
   --with-ccache
   --enable-octave=default
   --enable-binary-packages
   --enable-devel-tools
   --disable-system-opengl

Windows builds (the common options above, plus):

   --enable-windows-64

GNU systems (the common options above, plus):

   --enable-native-build
   --enable-lib64-directory
   --enable-pic-flag
   --disable-system-x11-libs
   --disable-system-fontconfig
   --disable-system-gcc
   gnu-linux

and then choosing qt4 or qt5 with either --disable-qt5 or --enable-qt5.

For the native GNU builds, I'm able to build LLVM and Mesa can use that
to generate the llvmpipe version of the swrast OpenGL driver and
performance seems good.  For Windows, I haven't figured out how to build
a version of LLVM, so it uses a different and apparently slower
implementation of swrast.  It still works, but not as smoothly.

Also for the GNU builds, we are now able to build and include in the tar
file nearly everything that is needed to run Octave.  Installing and
running a copy and then using lsof to examine the list of open files, I
see only the following open outside of Octave's installation directory
tree (using qt5):

   /lib/x86_64-linux-gnu/ld-2.24.so
   /lib/x86_64-linux-gnu/libc-2.24.so
   /lib/x86_64-linux-gnu/libdl-2.24.so
   /lib/x86_64-linux-gnu/libm-2.24.so
   /lib/x86_64-linux-gnu/libnsl-2.24.so
   /lib/x86_64-linux-gnu/libnss_compat-2.24.so
   /lib/x86_64-linux-gnu/libnss_files-2.24.so
   /lib/x86_64-linux-gnu/libnss_nis-2.24.so
   /lib/x86_64-linux-gnu/libpthread-2.24.so
   /lib/x86_64-linux-gnu/librt-2.24.so
   /lib/x86_64-linux-gnu/libudev.so.1.6.6
   /lib/x86_64-linux-gnu/libutil-2.24.so

   /usr/lib/locale/locale-archive

   /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache

   /usr/share/fonts/truetype/croscore/Cousine-Regular.ttf
   /usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf
   /usr/share/fonts/truetype/dejavu/DejaVuSansMono-Bold.ttf
   /usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf
   /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf

On Windows systems with qt4, I'm able to move aside the mesa version of
opengl32.dll and use the Windows OpenGL library (confirming with
__opengl_info__).  But with qt5, doing that causes Octave to freeze.  I
assume it's a segfault, but I haven't been successful with any attempt
at debugging.

There are a few optional packages that we are currently not using, or
that we are not building separately (Qt provides them), but that we
could use or build separately.  These include libjbig, icu,
double_conversion, and libproxy.  I could use some help creating
makefile fragments for these packages.

I could also use some help with building LLVM on Windows systems if
anyone has a clue.  Preferably version 5, which we are currently
successfully building on GNU systems.

Any help would be much appreciated.

Thanks,

jwe

Reply | Threaded
Open this post in threaded view
|

Re: mxe-octave status

PhilipNienhuis
John W. Eaton wrote

> With current Octave and mxe-octave the default-octave target works forme
> when doing builds for native GNU systems and cross compiling for
> Windows-64 with either qt4 or qt5.  I'm also building libGL from the
> Mesa package for consistent software rendering (more about that below).
> Here are the configurations I'm using:
>
> Options common to all builds:
>
>    --with-pkg-dir=/a/common/dir/for/source/downloads
>    --with-ccache
>    --enable-octave=default
>    --enable-binary-packages
>    --enable-devel-tools
>    --disable-system-opengl
>
> Windows builds (the common options above, plus):
>
>    --enable-windows-64
>
> :
> <snip>
> :
>
> On Windows systems with qt4, I'm able to move aside the mesa version of
> opengl32.dll and use the Windows OpenGL library (confirming with
> __opengl_info__).  But with qt5, doing that causes Octave to freeze.  I
> assume it's a segfault, but I haven't been successful with any attempt
> at debugging.

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.
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? until
recently I never encountered problems using graphics functions in Octave on
that older HW at work.

Maybe it is of some comfort that Matlab on that same older Intel & virtual
HW automatically disables opengl hardware rendering and falls back to
software rendering. I suppose Matlab just checks if OpenGL >= 2.1 (minimum
version), its docs say best performance requires OpenGL 3.3.0.

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.

Philip



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: mxe-octave status

John W. Eaton
Administrator
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?  How did you configure mxe-octave?  Did you
use --disable-system-opengl when configuring mxe-octave?  Do you have
opengl32.dll in the bin directory alongside octave-gui.exe?
Are you using the mesa software renderer provided by the mesa
opengl32.dll or the accelerated hardware renderer?

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

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

jwe

Reply | Threaded
Open this post in threaded view
|

RE: mxe-octave status

JohnD
In reply to this post by John W. Eaton
>
> Message: 1
> Date: Thu, 19 Oct 2017 17:07:05 -0400
> From: "John W. Eaton" <[hidden email]>
> To: Octave Maintainers List <[hidden email]>
> Cc: [hidden email]
> Subject: mxe-octave status
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> With current Octave and mxe-octave the default-octave target works forme
> when doing builds for native GNU systems and cross compiling for
> Windows-64 with either qt4 or qt5.  I'm also building libGL from the Mesa
> package for consistent software rendering (more about that below).
> Here are the configurations I'm using:
>
> Options common to all builds:
>
>    --with-pkg-dir=/a/common/dir/for/source/downloads
>    --with-ccache
>    --enable-octave=default
>    --enable-binary-packages
>    --enable-devel-tools
>    --disable-system-opengl
>
> Windows builds (the common options above, plus):
>
>    --enable-windows-64
>
> GNU systems (the common options above, plus):
>
>    --enable-native-build
>    --enable-lib64-directory
>    --enable-pic-flag
>    --disable-system-x11-libs
>    --disable-system-fontconfig
>    --disable-system-gcc
>    gnu-linux
>
> and then choosing qt4 or qt5 with either --disable-qt5 or --enable-qt5.
>
> For the native GNU builds, I'm able to build LLVM and Mesa can use that to
> generate the llvmpipe version of the swrast OpenGL driver and performance
> seems good.  For Windows, I haven't figured out how to build a version of
> LLVM, so it uses a different and apparently slower implementation of
swrast.  It
> still works, but not as smoothly.
>
> Also for the GNU builds, we are now able to build and include in the tar
file
> nearly everything that is needed to run Octave.  Installing and running a
copy
> and then using lsof to examine the list of open files, I see only the
following

> open outside of Octave's installation directory tree (using qt5):
>
>    /lib/x86_64-linux-gnu/ld-2.24.so
>    /lib/x86_64-linux-gnu/libc-2.24.so
>    /lib/x86_64-linux-gnu/libdl-2.24.so
>    /lib/x86_64-linux-gnu/libm-2.24.so
>    /lib/x86_64-linux-gnu/libnsl-2.24.so
>    /lib/x86_64-linux-gnu/libnss_compat-2.24.so
>    /lib/x86_64-linux-gnu/libnss_files-2.24.so
>    /lib/x86_64-linux-gnu/libnss_nis-2.24.so
>    /lib/x86_64-linux-gnu/libpthread-2.24.so
>    /lib/x86_64-linux-gnu/librt-2.24.so
>    /lib/x86_64-linux-gnu/libudev.so.1.6.6
>    /lib/x86_64-linux-gnu/libutil-2.24.so
>
>    /usr/lib/locale/locale-archive
>
>    /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache
>
>    /usr/share/fonts/truetype/croscore/Cousine-Regular.ttf
>    /usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf
>    /usr/share/fonts/truetype/dejavu/DejaVuSansMono-Bold.ttf
>    /usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf
>    /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
>
> On Windows systems with qt4, I'm able to move aside the mesa version of
> opengl32.dll and use the Windows OpenGL library (confirming with
> __opengl_info__).  But with qt5, doing that causes Octave to freeze.  I
assume
> it's a segfault, but I haven't been successful with any attempt at
debugging.
>
> There are a few optional packages that we are currently not using, or that
we
> are not building separately (Qt provides them), but that we could use or
build
> separately.  These include libjbig, icu, double_conversion, and libproxy.
I could
> use some help creating makefile fragments for these packages.
>
> I could also use some help with building LLVM on Windows systems if anyone
> has a clue.  Preferably version 5, which we are currently successfully
building
> on GNU systems.
>
> Any help would be much appreciated.
>
> Thanks,
>
> jwe
>


I should have some time in about 2 weeks to help out if no one else has
gotten to it first.


JD


Reply | Threaded
Open this post in threaded view
|

Re: mxe-octave status

PhilipNienhuis
In reply to this post by John W. Eaton
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

Reply | Threaded
Open this post in threaded view
|

Re: mxe-octave status

John W. Eaton
Administrator
On 10/20/2017 02:06 PM, Philip Nienhuis wrote:

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

You have to configure with --disable-system-opengl to build and use the
mesa version of the opengl32.dll library.

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

Yes.

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

There was a recent change to use QOpenGLWidget instead of the deprecated
QGLWidget.  Maybe that's the reason for the crash.  It improved things
for me on GNU systems, but maybe there is a problem with Windows
systems, or maybe we are not using it properly.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: mxe-octave status

PhilipNienhuis
John W. Eaton wrote:

> On 10/20/2017 02:06 PM, Philip Nienhuis wrote:
>
>>> 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.
>
> You have to configure with --disable-system-opengl to build and use the
> mesa version of the opengl32.dll library.

Ah, I see I misunderstood; you mean that mesa version provokes a segfault.
(Sorry for not following the whole issue in detail - which relates to
not having hit the issue with older system opengl32.dll libs yet.)

If I configure & build with --disable-system-opengl, install & then
remove opengl32.dll from the mxe-octave/bin/ subdir, would Octave fall
back to the system version in C:\Windows\system32 ? or is the mxe-octave
version statically linked to graphics libraries?
I'll just try it out this weekend.

<snip>

>> 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)
>
> There was a recent change to use QOpenGLWidget instead of the deprecated
> QGLWidget.  Maybe that's the reason for the crash.  It improved things
> for me on GNU systems, but maybe there is a problem with Windows
> systems, or maybe we are not using it properly.

(On this web page:
http://doc.qt.io/qt-5/windows-requirements.html
under "Dynamically Loading Graphics Drivers" I saw something about
dynamically loading opengl implementations. Would that be of any help here?)

Philip

Reply | Threaded
Open this post in threaded view
|

Re: mxe-octave status

John W. Eaton
Administrator
On 10/20/2017 04:28 PM, Philip Nienhuis wrote:

> Ah, I see I misunderstood; you mean that mesa version provokes a segfault.
> (Sorry for not following the whole issue in detail - which relates to
> not having hit the issue with older system opengl32.dll libs yet.)

No, the mesa version works fine for me.  It's when I've built the qt5
version with mesa and then I attempt to use the system opengl32.dll
instead.  As far as I know, this should work since the API should be the
same.  It's supposed to be a "drop-in replacement"

However, I haven't tried to build without the mesa opengl implementation
and see whether that works.

> If I configure & build with --disable-system-opengl, install & then
> remove opengl32.dll from the mxe-octave/bin/ subdir, would Octave fall
> back to the system version in C:\Windows\system32 ?

Yes, if you restart Octave, it should dynamically link to whatever
opengl32.dll is in the same directory with the .exe file or the first
one found in the PATH.

And this DOES work for me when using qt4, so it seems most likely that
the Qt5 widget doesn't work with my system opengl library, or that I'm
using QOpenGLWidget incorrectly.

> or is the mxe-octave
> version statically linked to graphics libraries?
> I'll just try it out this weekend.

No, it's not statically linked.  It's using the DLL (dynamic linking).

> (On this web page:
> http://doc.qt.io/qt-5/windows-requirements.html
> under "Dynamically Loading Graphics Drivers" I saw something about
> dynamically loading opengl implementations. Would that be of any help
> here?)

Possibly, but I don't think we need to do that.  Just choosing one
implementation at startup should be sufficient.  We don't need to
attempt to use multiple implementations simultaneously or swap between them.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: mxe-octave status

John W. Eaton
Administrator
On 10/20/2017 06:00 PM, John W. Eaton wrote:

> On 10/20/2017 04:28 PM, Philip Nienhuis wrote:
>
>> Ah, I see I misunderstood; you mean that mesa version provokes a
>> segfault.
>> (Sorry for not following the whole issue in detail - which relates to
>> not having hit the issue with older system opengl32.dll libs yet.)
>
> No, the mesa version works fine for me.  It's when I've built the qt5
> version with mesa and then I attempt to use the system opengl32.dll
> instead.  As far as I know, this should work since the API should be the
> same.  It's supposed to be a "drop-in replacement"

It looks like the problem that I've experienced is due to the system
opengl implementation that I have with a Windows 7 installation inside
virtualbox.  When I tried the same Octave installer on a Windows 10
system running on real hardware with Intel graphics, it worked fine with
the system opengl and the mesa version.

This is the info I get from __opengl_info__ on the virtual box system
(using Octave 4.2.1):

   version    = 1.1.0
   vendor     = Microsoft Corporation
   renderer   = GDI Generic
   extensions =
     GL_WIN_swap_hint
     GL_EXT_bgra
     GL_EXT_paletted_texture

so maybe this is insufficient for the qt5 QOpenGLWidget?  Or there is
just a bug that could be fixed.  Either way, it appears that with the
mesa opengl32.dll we now have a way to too avoid these problems.

I don't know that we need to detect and repair the problem
automatically, but we should probably at least have a configuration
option that arranges for Octave to use the mesa opengl library to do
software rendering.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: mxe-octave status

PhilipNienhuis
John W. Eaton wrote:

> On 10/20/2017 06:00 PM, John W. Eaton wrote:
>> On 10/20/2017 04:28 PM, Philip Nienhuis wrote:
>>
>>> Ah, I see I misunderstood; you mean that mesa version provokes a
>>> segfault.
>>> (Sorry for not following the whole issue in detail - which relates to
>>> not having hit the issue with older system opengl32.dll libs yet.)
>>
>> No, the mesa version works fine for me.  It's when I've built the qt5
>> version with mesa and then I attempt to use the system opengl32.dll
>> instead.  As far as I know, this should work since the API should be
>> the same.  It's supposed to be a "drop-in replacement"
>
> It looks like the problem that I've experienced is due to the system
> opengl implementation that I have with a Windows 7 installation inside
> virtualbox.  When I tried the same Octave installer on a Windows 10
> system running on real hardware with Intel graphics, it worked fine with
> the system opengl and the mesa version.
>
> This is the info I get from __opengl_info__ on the virtual box system
> (using Octave 4.2.1):
>
>   version    = 1.1.0
>   vendor     = Microsoft Corporation
>   renderer   = GDI Generic
>   extensions =
>     GL_WIN_swap_hint
>     GL_EXT_bgra
>     GL_EXT_paletted_texture

That looks just like the info I got on my (older) PCs at work (using an
Octave-4.3.0+ from early September) that run Windows 7 Enterprise 64bit.

On those PCs newest Octave-4.3.0+ crashes when invoking graphics functions.

In fact this is the basic Windows-supplied software renderer. It is
often used by default with older Intel graphics HW. Reading up about
this I get to vaguely suspect that several bug reports we have about
failing graphics on Intel HW, are in fact related to this default
Windows renderer.
Maybe if the mesa-based opengl32.dll does a better job, (some of) those
old bugs might be solved as well. (yes, speculation)

> so maybe this is insufficient for the qt5 QOpenGLWidget?  Or there is
> just a bug that could be fixed.  Either way, it appears that with the
> mesa opengl32.dll we now have a way to too avoid these problems.

It appears your situation is similar to mine. On my newer systems OpenGL
is probably at 3.3.0 (anyway high enough), while on older systems OpenGL
is too old or is provided by the default Windows driver; it's on those
older systems where problems occur.

> I don't know that we need to detect and repair the problem
> automatically, but we should probably at least have a configuration
> option that arranges for Octave to use the mesa opengl library to do
> software rendering.

Maybe some tool in NSIS can detect the OpenGL version? Or "we" (I can't,
sorry) can build one ourselves and try to use it in the installer. More
info here:
https://stackoverflow.com/questions/126028/how-to-write-an-installer-that-checks-for-opengl-support

Philip

Reply | Threaded
Open this post in threaded view
|

Re: mxe-octave status

PhilipNienhuis
Philip Nienhuis wrote:

> John W. Eaton wrote:
>> On 10/20/2017 06:00 PM, John W. Eaton wrote:
>>> On 10/20/2017 04:28 PM, Philip Nienhuis wrote:
>>>
>>>> Ah, I see I misunderstood; you mean that mesa version provokes a
>>>> segfault.
>>>> (Sorry for not following the whole issue in detail - which relates to
>>>> not having hit the issue with older system opengl32.dll libs yet.)
>>>
>>> No, the mesa version works fine for me.  It's when I've built the qt5
>>> version with mesa and then I attempt to use the system opengl32.dll
>>> instead.  As far as I know, this should work since the API should be
>>> the same.  It's supposed to be a "drop-in replacement"

Results with a --disable-system-opengl32 mxe-octave build:

I can confirm the crash on a PC with older Intel card (with the default
Windows opengl32.dll) when removing / renaming the Octave-supplied
(mesa-)opengl32.dll. Octave works fine there with the mesa-openg32.dll

On any system, __opengl_info__ doesn't work the first time. But the
second time, or after having made a simple "plot (1:10)",
__opengl_info__ does work.
So apparently there's some initialization issue. It doesn't matter which
opengl32.dll (Octave, system) is in use.

Earlier builds (octave & mxe-octave hg-id's) had the same issue; when
running __run_test_suite__ I usually got a FAIL for __opengl_info__ but
afterwards, "test __opengl_info__" worked.

Philip

Reply | Threaded
Open this post in threaded view
|

Re: mxe-octave status

John W. Eaton
Administrator
On 10/21/2017 04:58 PM, Philip Nienhuis wrote:

> Results with a --disable-system-opengl32 mxe-octave build:
>
> I can confirm the crash on a PC with older Intel card (with the default
> Windows opengl32.dll) when removing / renaming the Octave-supplied
> (mesa-)opengl32.dll. Octave works fine there with the mesa-openg32.dll

OK, thanks for testing.

I think we now have a good way to provide OpenGL based graphics when the
OpenGL implementation provided by the system causes trouble.  Getting
LLVM to build for Windows so we can have the llvmpipe renderer will
improve performance, but at least it works now.

> On any system, __opengl_info__ doesn't work the first time. But the
> second time, or after having made a simple "plot (1:10)",
> __opengl_info__ does work.
> So apparently there's some initialization issue. It doesn't matter which
> opengl32.dll (Octave, system) is in use.
>
> Earlier builds (octave & mxe-octave hg-id's) had the same issue; when
> running __run_test_suite__ I usually got a FAIL for __opengl_info__ but
> afterwards, "test __opengl_info__" worked.

__opengl_info__ requires an opengl context.  If one is not already
available, then it tries to create one.  There is a 0.1 second delay
between creating a figure and inquiring about the opengl capabilities.
Does increasing that delay help to avoid the failure on your system?

jwe

Reply | Threaded
Open this post in threaded view
|

Re: mxe-octave status

PhilipNienhuis
John W. Eaton wrote:
> On 10/21/2017 04:58 PM, Philip Nienhuis wrote:

<snip>

>> On any system, __opengl_info__ doesn't work the first time. But the
>> second time, or after having made a simple "plot (1:10)",
>> __opengl_info__ does work.
>> So apparently there's some initialization issue. It doesn't matter
>> which opengl32.dll (Octave, system) is in use.
>>
>> Earlier builds (octave & mxe-octave hg-id's) had the same issue; when
>> running __run_test_suite__ I usually got a FAIL for __opengl_info__
>> but afterwards, "test __opengl_info__" worked.
>
> __opengl_info__ requires an opengl context.  If one is not already
> available, then it tries to create one.  There is a 0.1 second delay
> between creating a figure and inquiring about the opengl capabilities.
> Does increasing that delay help to avoid the failure on your system?

Ah...

Well, on my relatively fast core i5 desktop a delay of 0.25 sec. seems
to reliably allow __opengl_info__ to succeed.
On my much slower core i5 laptop 0.2 sec. suffices. So, slower =>
shorter delay.

It does make a difference whether Octave was already running; I suppose
all kind of disk cache and memory cache things interfere.
The first time octave has been started after booting, __opengl_info__
usually responds fine. But a second start of Octave need a longer delay.

Philip

Reply | Threaded
Open this post in threaded view
|

Re: mxe-octave status

PrasannaKumar Muralidharan
In reply to this post by John W. Eaton


On 22-Oct-2017 2:39 AM, "John W. Eaton" <[hidden email]> wrote:
On 10/21/2017 04:58 PM, Philip Nienhuis wrote:

Results with a --disable-system-opengl32 mxe-octave build:

I can confirm the crash on a PC with older Intel card (with the default Windows opengl32.dll) when removing / renaming the Octave-supplied (mesa-)opengl32.dll. Octave works fine there with the mesa-openg32.dll

OK, thanks for testing.

I think we now have a good way to provide OpenGL based graphics when the OpenGL implementation provided by the system causes trouble.  Getting LLVM to build for Windows so we can have the llvmpipe renderer will improve performance, but at least it works now.

I am wondering whether angle library can be used in windows. Angle library translates opengl calls to directx calls. Qt and Chromium are prominent users of angle.



On any system, __opengl_info__ doesn't work the first time. But the second time, or after having made a simple "plot (1:10)", __opengl_info__ does work.
So apparently there's some initialization issue. It doesn't matter which opengl32.dll (Octave, system) is in use.

Earlier builds (octave & mxe-octave hg-id's) had the same issue; when running __run_test_suite__ I usually got a FAIL for __opengl_info__ but afterwards, "test __opengl_info__" worked.

__opengl_info__ requires an opengl context.  If one is not already available, then it tries to create one.  There is a 0.1 second delay between creating a figure and inquiring about the opengl capabilities. Does increasing that delay help to avoid the failure on your system?

jwe

Regards,
PrasannaKumar
Reply | Threaded
Open this post in threaded view
|

Re: mxe-octave status

PhilipNienhuis
PrasannaKumar Muralidharan wrote:

>
>
> On 22-Oct-2017 2:39 AM, "John W. Eaton" <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 10/21/2017 04:58 PM, Philip Nienhuis wrote:
>
>         Results with a --disable-system-opengl32 mxe-octave build:
>
>         I can confirm the crash on a PC with older Intel card (with the
>         default Windows opengl32.dll) when removing / renaming the
>         Octave-supplied (mesa-)opengl32.dll. Octave works fine there
>         with the mesa-openg32.dll
>
>
>     OK, thanks for testing.
>
>     I think we now have a good way to provide OpenGL based graphics when
>     the OpenGL implementation provided by the system causes trouble.
>     Getting LLVM to build for Windows so we can have the llvmpipe
>     renderer will improve performance, but at least it works now.
>
>
> I am wondering whether angle library can be used in windows. Angle
> library translates opengl calls to directx calls. Qt and Chromium are
> prominent users of angle.

Yeah I read about angle as it was mentioned in one of the links I
reported in my earlier posts in this thread.
Someone will have to dive into it; it'll introduce yet additional
dependencies while the windows installer is already so big. And maybe
there are license issues? As regards GPL, DirectX/Direct3D is a "system
library" I suppose. But we'd have to avoid the proprietary SDK stuff.

Anyway a good idea to keep angle in mind, thanks.

P.

Reply | Threaded
Open this post in threaded view
|

Re: mxe-octave status

PhilipNienhuis
In reply to this post by PhilipNienhuis
PhilipNienhuis wrote

> John W. Eaton wrote:
>> On 10/20/2017 06:00 PM, John W. Eaton wrote:
>>> On 10/20/2017 04:28 PM, Philip Nienhuis wrote:
>>>
>>>> Ah, I see I misunderstood; you mean that mesa version provokes a
>>>> segfault.
>>>> (Sorry for not following the whole issue in detail - which relates to
>>>> not having hit the issue with older system opengl32.dll libs yet.)
>>>
>>> No, the mesa version works fine for me.  It's when I've built the qt5
>>> version with mesa and then I attempt to use the system opengl32.dll
>>> instead.  As far as I know, this should work since the API should be
>>> the same.  It's supposed to be a "drop-in replacement"
>>
>> It looks like the problem that I've experienced is due to the system
>> opengl implementation that I have with a Windows 7 installation inside
>> virtualbox.  When I tried the same Octave installer on a Windows 10
>> system running on real hardware with Intel graphics, it worked fine with
>> the system opengl and the mesa version.
>>
>> This is the info I get from __opengl_info__ on the virtual box system
>> (using Octave 4.2.1):
>>
>>   version    = 1.1.0
>>   vendor     = Microsoft Corporation
>>   renderer   = GDI Generic
>>   extensions =
>>     GL_WIN_swap_hint
>>     GL_EXT_bgra
>>     GL_EXT_paletted_texture
>
> That looks just like the info I got on my (older) PCs at work (using an
> Octave-4.3.0+ from early September) that run Windows 7 Enterprise 64bit.
>
> On those PCs newest Octave-4.3.0+ crashes when invoking graphics
> functions.
>
> In fact this is the basic Windows-supplied software renderer. It is
> often used by default with older Intel graphics HW. Reading up about
> this I get to vaguely suspect that several bug reports we have about
> failing graphics on Intel HW, are in fact related to this default
> Windows renderer.
> Maybe if the mesa-based opengl32.dll does a better job, (some of) those
> old bugs might be solved as well. (yes, speculation)

Indeed, e.g. bug #47337 is solved with the mesa-based opengl32.dll. Nice!
Switching back to the system driver (at opengl v. 3.3.0) brings back the
bug.

So maybe my suggestion in other posts here to test for up-to-date system
opengl32.dll and switch to that during installation needs more thought.

Philip




--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: mxe-octave status

PrasannaKumar Muralidharan
In reply to this post by PhilipNienhuis
On 22 October 2017 at 15:16, Philip Nienhuis <[hidden email]> wrote:

> PrasannaKumar Muralidharan wrote:
>>
>>
>>
>> On 22-Oct-2017 2:39 AM, "John W. Eaton" <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     On 10/21/2017 04:58 PM, Philip Nienhuis wrote:
>>
>>         Results with a --disable-system-opengl32 mxe-octave build:
>>
>>         I can confirm the crash on a PC with older Intel card (with the
>>         default Windows opengl32.dll) when removing / renaming the
>>         Octave-supplied (mesa-)opengl32.dll. Octave works fine there
>>         with the mesa-openg32.dll
>>
>>
>>     OK, thanks for testing.
>>
>>     I think we now have a good way to provide OpenGL based graphics when
>>     the OpenGL implementation provided by the system causes trouble.
>>     Getting LLVM to build for Windows so we can have the llvmpipe
>>     renderer will improve performance, but at least it works now.
>>
>>
>> I am wondering whether angle library can be used in windows. Angle
>> library translates opengl calls to directx calls. Qt and Chromium are
>> prominent users of angle.
>
>
> Yeah I read about angle as it was mentioned in one of the links I reported
> in my earlier posts in this thread.
> Someone will have to dive into it; it'll introduce yet additional
> dependencies while the windows installer is already so big. And maybe there

It will remove the mesa and llvm from Installer (if it is there). So I
think that size may reduce actually.

According to https://chromium.googlesource.com/angle/angle/+/master/doc/DevSetup.md
adding angle support seems to be easy.

> are license issues? As regards GPL, DirectX/Direct3D is a "system library" I
> suppose. But we'd have to avoid the proprietary SDK stuff.

I do not have any idea on license issues. I don't know if proprietary
SDK is required to use angle.

> Anyway a good idea to keep angle in mind, thanks.
>
> P.

Regards,
PrasannaKumar

Reply | Threaded
Open this post in threaded view
|

Re: mxe-octave status

PhilipNienhuis
PrasannaKumar Muralidharan wrote:

> On 22 October 2017 at 15:16, Philip Nienhuis <[hidden email]> wrote:
>> PrasannaKumar Muralidharan wrote:
>>>
>>>
>>>
>>> On 22-Oct-2017 2:39 AM, "John W. Eaton" <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>>     On 10/21/2017 04:58 PM, Philip Nienhuis wrote:
>>>
>>>         Results with a --disable-system-opengl32 mxe-octave build:
>>>
>>>         I can confirm the crash on a PC with older Intel card (with the
>>>         default Windows opengl32.dll) when removing / renaming the
>>>         Octave-supplied (mesa-)opengl32.dll. Octave works fine there
>>>         with the mesa-openg32.dll
>>>
>>>
>>>     OK, thanks for testing.
>>>
>>>     I think we now have a good way to provide OpenGL based graphics when
>>>     the OpenGL implementation provided by the system causes trouble.
>>>     Getting LLVM to build for Windows so we can have the llvmpipe
>>>     renderer will improve performance, but at least it works now.
>>>
>>>
>>> I am wondering whether angle library can be used in windows. Angle
>>> library translates opengl calls to directx calls. Qt and Chromium are
>>> prominent users of angle.
>>
>>
>> Yeah I read about angle as it was mentioned in one of the links I reported
>> in my earlier posts in this thread.
>> Someone will have to dive into it; it'll introduce yet additional
>> dependencies while the windows installer is already so big. And maybe there
>
> It will remove the mesa and llvm from Installer (if it is there). So I
> think that size may reduce actually.
>
> According to https://chromium.googlesource.com/angle/angle/+/master/doc/DevSetup.md
> adding angle support seems to be easy.
>
>> are license issues? As regards GPL, DirectX/Direct3D is a "system library" I
>> suppose. But we'd have to avoid the proprietary SDK stuff.
>
> I do not have any idea on license issues. I don't know if proprietary
> SDK is required to use angle.

The page you refer to lists a.o., Visual Studio which is a proprietary
build environment.

There are some links to MinGW builds (e.g.,
https://groups.google.com/forum/#!msg/angleproject/SQTAjUNqIZ4/IOmHlFY-BAAJ)
and
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-angleproject-git 
but that doesn't look easy.

Philip

Reply | Threaded
Open this post in threaded view
|

Re: mxe-octave status

PrasannaKumar Muralidharan
On 24 October 2017 at 00:52, Philip Nienhuis <[hidden email]> wrote:

> PrasannaKumar Muralidharan wrote:
>>
>> On 22 October 2017 at 15:16, Philip Nienhuis <[hidden email]>
>> wrote:
>>>
>>> PrasannaKumar Muralidharan wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On 22-Oct-2017 2:39 AM, "John W. Eaton" <[hidden email]
>>>> <mailto:[hidden email]>> wrote:
>>>>
>>>>     On 10/21/2017 04:58 PM, Philip Nienhuis wrote:
>>>>
>>>>         Results with a --disable-system-opengl32 mxe-octave build:
>>>>
>>>>         I can confirm the crash on a PC with older Intel card (with the
>>>>         default Windows opengl32.dll) when removing / renaming the
>>>>         Octave-supplied (mesa-)opengl32.dll. Octave works fine there
>>>>         with the mesa-openg32.dll
>>>>
>>>>
>>>>     OK, thanks for testing.
>>>>
>>>>     I think we now have a good way to provide OpenGL based graphics when
>>>>     the OpenGL implementation provided by the system causes trouble.
>>>>     Getting LLVM to build for Windows so we can have the llvmpipe
>>>>     renderer will improve performance, but at least it works now.
>>>>
>>>>
>>>> I am wondering whether angle library can be used in windows. Angle
>>>> library translates opengl calls to directx calls. Qt and Chromium are
>>>> prominent users of angle.
>>>
>>>
>>>
>>> Yeah I read about angle as it was mentioned in one of the links I
>>> reported
>>> in my earlier posts in this thread.
>>> Someone will have to dive into it; it'll introduce yet additional
>>> dependencies while the windows installer is already so big. And maybe
>>> there
>>
>>
>> It will remove the mesa and llvm from Installer (if it is there). So I
>> think that size may reduce actually.
>>
>> According to
>> https://chromium.googlesource.com/angle/angle/+/master/doc/DevSetup.md
>> adding angle support seems to be easy.
>>
>>> are license issues? As regards GPL, DirectX/Direct3D is a "system
>>> library" I
>>> suppose. But we'd have to avoid the proprietary SDK stuff.
>>
>>
>> I do not have any idea on license issues. I don't know if proprietary
>> SDK is required to use angle.
>
>
> The page you refer to lists a.o., Visual Studio which is a proprietary build
> environment.
>
> There are some links to MinGW builds (e.g.,
> https://groups.google.com/forum/#!msg/angleproject/SQTAjUNqIZ4/IOmHlFY-BAAJ)
> and
> https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-angleproject-git
> but that doesn't look easy.
>
> Philip

There are ways to build angle in Linux I think. Thanks for the info.

Thanks,
PrasannaKumar