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: Andreas Weber
Subject: Re: [Mesa-users] OSMesa problems with proprietary NVIDIA 304 drivers on Debian Jessie
Date: Sat, 16 May 2015 11:13:00 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0

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?

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.

-- Andy



reply via email to

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