[Mesa-users] OSMesa problems with proprietary NVIDIA 304 drivers on Debian Jessie
Brian Paul
brianp at vmware.com
Sat May 16 13:39:37 PDT 2015
On 05/16/2015 03:13 AM, Andreas Weber wrote:
> Hi Brian, thank you for your answer.
>
> On 15.05.2015 16:35, Brian Paul wrote:
>> On 05/14/2015 03:13 PM, Andreas Weber wrote:
>>> Dear users and maintainers,
>>>
>>> we want to use OSMesa for offscreen rendering in the upcoming GNU Octave
>>> 4.0 release. Unfortunately I'm facing some unecpected problems when
>>> using proprietary NVIDIA 304 legacy drivers (it works fine if switching
>>> to nouveau or on machines with AMD or Intel GPU).
>>
>> Just to be clear, OSMesa does not work with nvidia's driver/hardware (or
>> any other GPU). The OSMesa interface only works with software rendering
>> (swrast, softpipe, llvmpipe). If you want to do offscreen rendering
>> with a hardware GPU, the easiest approach is to use framebuffer objects.
>
> I would like to be able to render OpenGL to a bitmap or, using gl2ps, to
> PostScript without needing a X display or even a hardware GPU (aka
> headless server).
>
> I'm not familiar with the Mesa or OpenGL internals so my question might
> sound naive but how can I force a program to use swrast, softpipe or
> llvmpipe? I tired setting LIBGL_ALWAYS_SOFTWARE=1 but apparently this
> doesn't work if the Nvidia drivers are installed. And why does osdemo
> work even if Nvidia drivers are installed but Octave not? Some compile
> or linker flags?
People that try to have Mesa and nvidia's drivers coexist on one system
often run into problems. Both provide a libGL.so and they're totally
different implementations.
For Mesa, if you build with something like:
./autogen.sh --enable-xlib-glx --disable-driglx-direct --disable-dri
--enable-gallium-osmesa --with-gallium-drivers=swrast
You'll get a Mesa libGL.so and OSMesa.so that you can link your OSMesa
application with. You'll get software rendering, either softpipe (slow)
or llvmpipe (fast, if you have LLVM installed). I would recommend not
doing 'make install' because you may clobber your nvidia driver. You
could install it to /usr/local/ if you add a --prefix option to the
autogen.sh command.
LIBGL_ALWAYS_SOFTWARE is only recognized by Mesa's DRI build of libGL
(which is not what you're using here).
>
>>> The problem is that the generated image is almost black and values
>>> queried with glGetIntegerv contains arbitray values, for example
>>> ...
>> My guess is you're calling glGetIntegerv() without having a current
>> rendering context. The values you're getting are probably the
>> uninitialized values of z, s, ar, etc.
>
> Yes, you are right this was the reason. I though if OSMesaContext and
> OSMesaCreateContextExt return without error I can assume that there is a
> current rendering context.
That should be the case, assuming that you've linked with Mesa's
libGL.so and not nvidia's. When you build your app, you probably need
to link with a -L option that specifies the directory where Mesa's
libraries live (like /usr/local/lib, if you use --prefix as I mentioned
above). And at runtime you, may also need to set LD_LIBRARY_PATH.
-Brian
More information about the mesa-users
mailing list