linking a slim liboctave without OpenGL or Nvidia stuff

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

linking a slim liboctave without OpenGL or Nvidia stuff

Andreas Weber-6
Dear all,

is it feasible to compile and link a separate slim liboctave without
OpenGL and other stuff which might influence libosmesa?
Just enough to hgload a figure and print it.

My idea is to create a standalone helper program (lets call it oct_print
for now) which links osmesa but not the Nvidia or AMD libgl or other
non-mesa libs)

If someone wants to offscreen print a figure, print would then "hgsave"
the figure and call oct_print which loads (or reads from stdin) the
saved figure and uses the opengl-renderer, gl2ps (+ghostscript) and
osmesa to create the plot.

This would solve the NVIDIA libGl vs. OSMesa problematic and I also like
the idea to have an intermediate plot exchange format.

But I'm currently lost with autotools/libtool and would need some tips
how to create a slim liboctave (+libinterp?)


-- Andy


Reply | Threaded
Open this post in threaded view
|

Re: linking a slim liboctave without OpenGL or Nvidia stuff

Daniel Sebald
On 12/21/2017 11:48 PM, Andreas Weber wrote:
> Dear all,
>
> is it feasible to compile and link a separate slim liboctave without
> OpenGL and other stuff which might influence libosmesa?
> Just enough to hgload a figure and print it.
>
> My idea is to create a standalone helper program (lets call it oct_print
> for now) which links osmesa but not the Nvidia or AMD libgl or other
> non-mesa libs)

Andy, I looked at some osmesa-related stuff quite some time ago, so I
have forgotten exactly how it interacts with the program, but doesn't
osmesa need some type of non-mesa, OpenGL driver to function?


> If someone wants to offscreen print a figure, print would then "hgsave"
> the figure and call oct_print which loads (or reads from stdin) the
> saved figure and uses the opengl-renderer, gl2ps (+ghostscript) and
> osmesa to create the plot.
>
> This would solve the NVIDIA libGl vs. OSMesa problematic and I also like
> the idea to have an intermediate plot exchange format.

There was a small discussion within a bigger discussion here

http://lists.gnu.org/archive/html/octave-maintainers/2017-11/msg00133.html

that illustrates how pre-loading a generic driver (as opposed to using
the configured, custom Nvidia driver) can work with osmesa... at least
for the build process.  E.g.,

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libGL.so make

To me, that's actually a significant accomplishment because it means not
having to configure OSMesa from the build.

Of course, this requires the user to be cognizant of this solution, and
it also requires that the user is on a system that has both the
graphics-card-specific custom driver and some generic driver hanging
around.  The latter might be fairly common, as I doubt people who
install linux (which initially boots with a generic graphics driver)
then their custom graphics driver will set about removing drivers they
think are no longer needed (too much work).  The former (i.e., user
remembering the LD_PRELOAD method) isn't so common.

But here's the good news, as I see it.  The problem that Nvidia users
have right now is building Octave.  After the main program compile and
link, the build process sets about compiling the manual using OSMesa
off-screen printing.  However, that keeps failing repeatedly with every
new "make".  My thought was that in the make/build Makefile command
which builds the manual it could first search for the generic driver and
pre-load that, i.e.,

1) Find some generic driver (how, I don't know but I'm sure the
"configure" script would have some good examples of how to look for
files), e.g.,

   GENERIC_GRAPHICS_DRIVER = /usr/lib/x86_64-linux-gnu/libGL.so

2) Preload for the desired octave executable,

   LD_PRELOAD=GENERIC_GRAPHICS_DRIVER octave-cli


> But I'm currently lost with autotools/libtool and would need some tips
> how to create a slim liboctave (+libinterp?)

Rather than build a whole new octave, maybe experiment with the ideas
above to see if you can generate an off-screen plot without Nvidia.  If
so, then how about writing a short bash-script that does pretty much the
same as described above?  That is

mycomp $ ./octave-print some_hgsave_fig

runs a script that internally searches for a generic driver, preloads
it, and does what you described.  In fact, if you got such a thing
working, that script could be used in the Makefile command that
generates the Octave manual rather than have the searching done internal
to the Makefile.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: linking a slim liboctave without OpenGL or Nvidia stuff

Andreas Weber-6
Hi Daniel, sorry for the late answer

Am 22.12.2017 um 11:30 schrieb Daniel J Sebald:

> On 12/21/2017 11:48 PM, Andreas Weber wrote:
>> Dear all,
>>
>> is it feasible to compile and link a separate slim liboctave without
>> OpenGL and other stuff which might influence libosmesa?
>> Just enough to hgload a figure and print it.
>>
>> My idea is to create a standalone helper program (lets call it oct_print
>> for now) which links osmesa but not the Nvidia or AMD libgl or other
>> non-mesa libs)
>
> Andy, I looked at some osmesa-related stuff quite some time ago, so I
> have forgotten exactly how it interacts with the program, but doesn't
> osmesa need some type of non-mesa, OpenGL driver to function?

As far as I understand the OSMesa architecture it provides the same
symbols like libGL would do so linking agains libosmesad is sufficient.

> LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libGL.so make

I know we are using this trick and suggest it since OSMesa was added in
2015 especially for Nvidia users but I always thought it's a dirty
workaround. I don't think the speed penalty using this for the onscreen
OpenGL rendering with FLTK or Qt would be dramatically.

> Rather than build a whole new octave, maybe experiment with the ideas
> above to see if you can generate an off-screen plot without Nvidia.

As I've found out the last two days the check for a valid X11 display is
deeply anchored in Octave core, the gtk-manager, __init_fltk__ and so on
so that real offscreen printing on a headless server seems much more
unrealistic than I've thought before.

-- Andy

Reply | Threaded
Open this post in threaded view
|

Re: linking a slim liboctave without OpenGL or Nvidia stuff

Dmitri A. Sergatskov
On Mon, Dec 25, 2017 at 1:40 PM, Andreas Weber <[hidden email]> wrote:

As I've found out the last two days the check for a valid X11 display is
deeply anchored in Octave core, the gtk-manager, __init_fltk__ and so on
so that real offscreen printing on a headless server seems much more
unrealistic than I've thought before.

​You can print on headless server by running octave through xvfb.

​E.g.:
xvfb-run -a -s '-screen 0 640x480x24' octave


 

-- Andy


​Dmitri.
--

Reply | Threaded
Open this post in threaded view
|

Re: linking a slim liboctave without OpenGL or Nvidia stuff

Andreas Weber-6
Am 25.12.2017 um 21:04 schrieb Dmitri A. Sergatskov:
> ​You can print on headless server by running octave through xvfb.

yes sure. When I was writing the above I thought "I have to add a phrase
expressing 'without using Xvfb'" but then forget to actally write it, sorry.

-- Andy