Re: OSMesa problems with proprietary NVIDIA 304 drivers on Debian Jessie

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

_______________________________________________
mesa-users mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-users