[Octave-bug-tracker] [bug #47849] Documentation failing to build because of geometryimages.m

[Dan Sebald]

Follow-up Comment #6, bug #47849 (project octave):

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 


  OSMesaContext ctx = OSMesaCreateContextExt (OSMESA_RGBA, 16, 0, 0, NULL);


and


  if (! OSMesaMakeCurrent (ctx, buffer, GL_UNSIGNED_BYTE, Width, Height))


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:


  glGetIntegerv (GL_DEPTH_BITS, &z);


but I can put openGL command before it, such as:


  glEnable (GL_DEPTH_TEST);
  glClear (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);


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.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?47849>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/