|
From: | John W. Eaton |
Subject: | Re: the nvidia/osmesa dilema |
Date: | Thu, 5 May 2016 16:39:03 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 |
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. 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).
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.
jwe
[Prev in Thread] | Current Thread | [Next in Thread] |