Thu 05 May 2016 08:45:18 AM UTC, comment #6:
I'm just writing some notes here so that I can come back to some lines of thought...
It boils down to that osmesa context.
I see that other projects have had problems with Qt and OSMesa simultaneously:
https://cmake.org/Wiki/ParaView/ParaView_And_Mesa_3D_tmp
https://cmake.org/Wiki/ParaView/ParaView_And_Mesa_3D_tmp#ParaView_with_Offscreen_Mesa
The
and
routines do not fail. But OSMesa is sort of it's own openGL interface and not tied into the native graphics screen-rendering openGL...although the two eventually do interconnect when OSMesa has to do its rendering.
This routine fails:
but I can put openGL command before it, such as:
I can comment out the glGetIntegerv() calls and _osmesa_print_() will continue onto rendering as though everything is fine, open the EPS file then crash leaving the EPS file behind with 0 bytes. So, it isn't anything to do with calling a particular openGL function.
Instead, I'm wondering if nVidia driver is adhering to a strict definition of X11, and that is where the conflict lies. Remember, Qt ultimately is using X11 under the hood. I thought that maybe I could make the current X11 context non-current by calling this routine
https://www.opengl.org/sdk/docs/man2/xhtml/glXMakeContextCurrent.xml
with None, None and NULL, just as a means to test. However, I don't know what the Display * is. Qt probably has that information, but there's no way for us to get at it. Plus, it probably isn't good to remove an existing X11 context. The whole screen might freeze.
Anyway, so continuing with train of thought. Here might be an important clue as to why the nVidia driver (or more accurately an X11 compliant driver) doesn't like openGL/OSMesa commands without proper care:
https://www.opengl.org/documentation/specs/glx/glx1.4.pdf
In particular, on pages 7 and 8:
"
X has atomicity (between clients) and sequentiality (within a single client) requirements that limit the amount of parallelism achievable when interpreting the command streams. GLX relaxes these requirements. Sequentiality is still guaranteed within a command stream, but not between the X and the OpenGL command streams. It is possible, for example, that an X command issued by a single threaded client after an OpenGL command might be executed before that OpenGL command.
"
and further
"
Synchronization is in the hands of the client. It can be maintained with moderate cost with the judicious use of the
glFinish, glXWaitGL, glXWaitX, and XSync commands. OpenGL and X rendering can be done in parallel as long as the client does not preclude it with explicit synchronization calls. This is true even when the rendering is being done by the X server. Thus, a multi-threaded X server implementation may execute OpenGL rendering commands in parallel with other X requests.
"
I'll investigate this a bit further. The problem, of course, is that even if one does find a fix with an X11 synchronization function call, that isn't portable from the Qt perspective.
Another line to investigate is to see if it is possible to use the FLTK and QT rendering that works in visible mode and not have the graphics mapped into screen memory. Probably not, but if that were possible, then _osmesa_print_ could be restricted to the case when there is no Qt or FLTK running. If Qt is not running, then the X11/openGL threading conflict doesn't arise.. The least that could be done is to not use Qt for generating documentation, use FLTK.
|