Re: the nvidia/osmesa dilema

[Daniel J Sebald]

On 05/05/2016 03:39 PM, John W. Eaton wrote:
> On 05/05/2016 05:34 AM, Daniel J Sebald wrote:
> > On 05/04/2016 02:15 PM, John W. Eaton wrote:
> > > Umm, I wonder if the issue discussed here is the same as our problem:
> > > https://sourceforge.net/p/mesa3d/mailman/message/24581439/
> >
> > It sounds like the same problem, but the solution they have doesn't seem
> > very robust.
> >
> >
> > > tl;dr:  As I understand it, mixing OpenGL and OSMesa calls requires some
> > > care to ensure that you are only calling the functions from the OSMesa
> > > library when the OSMesa gl context is active.  It doesn't appear that we
> > > are doing this correctly.  I guess somehow it works with some OpenGL
> > > library implementations but not the Nvidia one (at least).
> >
> > Not sure.  My impression is that OSMesa is somewhat tied into OSMesa,
> > development wise, so it should mesh pretty well.
>
> I'm pretty sure the problem is that nvidia supplies its own version of
> libGL.  Other vendors apparently don't do that.
>
> So if you set up an OSMesa context and make it active and then call some
> gl* routines, you end up calling functions from nvidia's libGL and I
> would assume that it doesn't know anything about the OSMesa context.

Does FLTK use the Mesa OpenGL?  __osmesa_print__ doesn't crash with the 
glXYZ routines in that case.  (It crash when rendering on my system 
though because of that OSMesa >= 9.0 bug... how could a bad bug like 
that be in this software for so long?  Is there a way to circumvent 
that?)  Or is nVidia openGL not active in the thread when Qt is not used?


>   So
> that's why people see things like blank/black images and random values
> coming back from glGetIntegerv.  It also explains why doing things like
> setting LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libGL.so before running
> Octave avoids the problem (because it prevents the nvidia ligGL from
> being loaded).

For what it's worth, here's the result I get from that:

sebald@ ~/octave/octave/octave $ 
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libGL.so 
/usr/local/src/octave/octave/build1/run-octave --no-gui --silent
> > graphics_toolkit ('qt')
> > figure visible off
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has 
not been called
[xcb] Aborting, sorry about that.
octave-gui: ../../src/xcb_io.c:274: poll_for_event: Assertion 
`!xcb_xlib_threads_sequence_lost' failed.
panic: Aborted -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
Aborted

It could be that I don't have the swrast driver installed.  I can't find 
it in any of the Linux Mint libdrm packages.  Perhaps they chose to 
leave that one out because it might be deprecated.  I don't know if it 
pays for me to build swrast again.  (It was a lot of work last time I 
did it, but at least I wrote down the steps I took.)


> There is a way to build OSMesa with mangled symbols, so you can have
> both OSMesa functions and OpenGL functions linked in the same binary and
> not conflict with one another.  But then you somehow have to ensure that
> you are only calling functions from OSMesa when an OSMesa context is
> active.  I was looking at ways of doing that when I realized that
> Octave's opengl_renderer class (defined in gl-render.cc) also calls
> functions from libGLU, and that is linked with libGL, so as far as I can
> tell, you'd end up back in the same situation, calling functions from
> nvidia's libGL when you don't want to do that.

I'm looking at the NVIDIA X Server Settings app that comes when the 
nVidia driver is installed.  There is a section on OpenGL but no 
settings of interest.  There's also a section on OpenGL/GLX.  One of the 
items in that list is

GL_EXT_framebuffer_object

This is support for rendering to frame buffers outside the window system 
provided frame buffers, dubbed "renderbuffer".  The intention is 
off-screen rendering:

https://www.opengl.org/discussion_boards/showthread.php/125898-Off-screen-rendering-in-Qt-OpenGL

http://oss.sgi.com/projects/ogl-sample/registry/EXT/framebuffer_object.txt

One of the developers was from nVidia, so I would hope that extension 
would work for folks with nVidia cards.  Whether this extension 
GL_EXT_framebuffer_object is ubiquitous to Linux/Windows/your-video-card 
is beyond my narrow scope of OpenGL knowledge.  But, maybe that is an 
alternative to OSMesa.

Dan