[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: the nvidia/osmesa dilema
From: |
Daniel J Sebald |
Subject: |
Re: the nvidia/osmesa dilema |
Date: |
Thu, 5 May 2016 04:34:07 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 |
On 05/04/2016 02:15 PM, John W. Eaton wrote:
Umm, I wonder if the issue discussed here is the same as our problem:
https://sourceforge.net/p/mesa3d/mailman/message/24581439/
It sounds like the same problem, but the solution they have doesn't seem
very robust.
tl;dr: As I understand it, mixing OpenGL and OSMesa calls requires some
care to ensure that you are only calling the functions from the OSMesa
library when the OSMesa gl context is active. It doesn't appear that we
are doing this correctly. I guess somehow it works with some OpenGL
library implementations but not the Nvidia one (at least).
Not sure. My impression is that OSMesa is somewhat tied into OSMesa,
development wise, so it should mesh pretty well.
After doing a bit of searching and reading, I'm thinking the issue is
that Qt (GUI) is using X11 and the nVidia driver might be adhering more
rigorously to the X11 standard than other drivers, in particular on the
matter of multiple threads. I wrote some notes about this here:
https://savannah.gnu.org/bugs/?47849#comment6
The quotes from GLX manual are perhaps helpful.
What hunk of software/driver is using what standard is mere guessing for
me, but here's a rundown on nVidia drivers for Linux:
https://wiki.gentoo.org/wiki/NVidia/nvidia-drivers
and even more, this bit
https://wiki.gentoo.org/wiki/NVidia/nvidia-drivers#Enable_OpenGL.2FOpenCL
makes me think that nVidia driver might be intentionally restricting an
application that tries to use openGL on its resources without being
configured properly.
If there were a way to use openGL rendering in non-visible plots pretty
much the same as visible plots but somehow the context memory simply
isn't mapped into the screen video memory, that would be the best
solution. Then __osmesa_print__ could be used for only the case where
there is no Qt toolkit or FLTK toolkit...and that could be the case used
for generating the documentation---hence no Qt/FLTK needed for docs.
Just __osmesa_print__.
Dan
- Re: the nvidia/osmesa dilema, (continued)
Re: the nvidia/osmesa dilema, John W. Eaton, 2016/05/04
Re: the nvidia/osmesa dilema, Daniel J Sebald, 2016/05/04
Documentation failing to build because of geometryimages in FLTK (was Re: the nvidia/osmesa dilema), Daniel J Sebald, 2016/05/04
Re: Documentation failing to build because of geometryimages in FLTK (was Re: the nvidia/osmesa dilema), Mike Miller, 2016/05/04
Re: Documentation failing to build because of geometryimages in FLTK (was Re: the nvidia/osmesa dilema), Daniel J Sebald, 2016/05/04
Re: Documentation failing to build because of geometryimages in FLTK (was Re: the nvidia/osmesa dilema), Daniel J Sebald, 2016/05/04
Re: the nvidia/osmesa dilema, Juan Pablo Carbajal, 2016/05/04