[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mesa-users] OSMesa problems with proprietary NVIDIA 304 drivers on
Re: [Mesa-users] OSMesa problems with proprietary NVIDIA 304 drivers on Debian Jessie
Sat, 08 Aug 2015 16:58:56 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0
Hi Brian, thank you for your answer,
Am 16.05.2015 um 22:39 schrieb Brian Paul:
> On 05/16/2015 03:13 AM, Andreas Weber wrote:
>>>> 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.
What would be the preferred way to check in runtime, if the loaded
libGL.so is compatible with OSMesa.so?
Is it sufficient to look for "Mesa" in "OpenGL core profile version string"?
If I'm able to detect if a proprietary driver from Nvidia or AMD is
loaded, we can show an error and disable offscreen rendering with a hint
using "export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libGL.so" or install
nouveau driver for example.
|[Prev in Thread]
||[Next in Thread]|
- Re: [Mesa-users] OSMesa problems with proprietary NVIDIA 304 drivers on Debian Jessie,
Andreas Weber <=