octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mesa-users] OSMesa problems with proprietary NVIDIA 304 drivers on


From: Brian Paul
Subject: Re: [Mesa-users] OSMesa problems with proprietary NVIDIA 304 drivers on Debian Jessie
Date: Sat, 16 May 2015 14:39:37 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]