[Octave-bug-tracker] [bug #44478] test __osmesa_print__.cc-tst crashes with Nvidia drivers

[Dan Sebald]

Follow-up Comment #117, bug #44478 (project octave):

I don't know what the status of the Nvidia/OSMesa/swrast situation is.  Years
ago I built OSMesa and the OpenGL stuff from scratch, was able to make
changes, submit bug reports to the maintainers of the various drivers, etc.  I
don't want to dig that deep again.

But the problem still seems to be an issue on my relatively up-to-date Mint,
in particular the build process.  Perhaps there are some build work-arounds
that avoid OSMesa and the issue altogether.  I'm happy to use that, but I
suspect that generally speaking users who are just compiling won't like doing
too much special.

With that in mind, and particular to address the issue raised in

https://savannah.gnu.org/bugs/?func=detailitem&item_id=44478#comment112

I've written a little bash script called "octave-olp" that is analogous to
"octave-cli" but it does a few things:

1) Main issue: searches for the possibility that an Nvidia driver is active,
and if there is a possibility octave-olp will search for an alternative
generic driver to pre-load.  Since octave-olp is intended for off-line
printing, what does it matter if the spiffy Nvidia driver is used?  I do see
some figures in octave.pdf for voronoi (Figure 30.1) so it must be work (and I
did a full rebuild with just the "configure" sans any preload on my part).

2) I'll make this a second point for importance: I've confirmed that Nvidia
driver and generic driver are found on my system.  That is, I wondered if the
system utility I'm using will only recognize the generic driver if the generic
driver had been used prior (i.e., it only finds "installed" libraries). 
Perhaps it is because at power up the OS loads the generic driver before even
knowing details about the graphics hardware and a custom driver; then the
library remains resident in the proper tables.  On the other hand, maybe there
is an issue on systems that don't use any sort of generic driver at power-up. 
That would be the fly in the ointment here, i.e., there is a generic driver
present but it isn't found because it wasn't used prior.  I left some
commented-out alternative OS utilities in the script file in case there is an
issue.

3) This may not be a solution for Mac X OS (or windows).  Does the Nvidia
driver problem exist for those systems?  Hmm, that has got me thinking.  I've
placed "octave-olp" in the "figure-generating-commands", but if Windows can't
run octave-olp, then what?  Is it possible to make a script that looks like
bash on Unix and some other kind of fall-through script file on Windows?

4) Systems for which there is no Nvidia driver present, or for systems where
there is no generic driver present, either there is no pre-load (former) or
the loaded $GRAPHICS_LIB is empty "".  In both cases, the fall-back should be
just like running "octave-cli --norc --silent --no-history" with the
additional inputs.

5) The octave-olp is meant to work in both the build environment and the
installed environment.  (See top of the bash script.)  If I run octave-olp
after the fact and try plotting some figure, I see


linux@ ~ $ octave-olp
octave:1> plot(1:50)
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
octave:2> 


Oh well, that's the way it goes.

As far as I'm concerned, this approach is a good enough solution if the online
print works.  It solves the Nvidia driver build problem and at least gives a
quick path for Nvidia users to create off-line figures.  I don't know what
else beyond that one could expect from Octave.

(file #42760)
    _______________________________________________________

Additional Item Attachment:

File name: octave-nvidia_octave-olp_utility_djs2017dec29.patch Size:4 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?44478>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/