octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #44478] test __osmesa_print__.cc-tst crashes w


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #44478] test __osmesa_print__.cc-tst crashes with Nvidia drivers
Date: Wed, 11 May 2016 08:20:03 +0000 (UTC)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0

Follow-up Comment #78, bug #44478 (project octave):

Could someone who better understands the rendering flow setup, thread-wise,
summarize the threads in which osmesa_print, gl2ps_render, screen display
happen?

I've experimented with trying to use the render-buffer extensions in place of
osMesa (had to link in GLEW) and I end up with a similar behavior for nVidia
OpenGL library, i.e., a call to any of the glXyzExt routines immediately seg
faults.

First, let me point out that this behavior, i.e., crashing for any of the
OpenGL functions, sounds like it may be typical of OpenGL with no current
context.  So, my guess is that contrary to the OSMesaMakeCurrent() routine
returning OK, the nVidia library routine may actually not be setting a current
context.

The reason I ask about threads is because:

1) The osmesa demos look like a single-threaded process.
2) We know that Qt only allows graphics in the single thread.
3) Octave appears to not be the one initializing the OpenGL interface.

Read this short description of the current context:

https://www.opengl.org/wiki/OpenGL_Context

It explains that multiple contexts can write to the same window (presumably
from different threads), but a context can be current in only one thread.

Perhaps the issue with nVidia OpenGL library is that some configuration needs
to be done to make the non-main Qt thread accept a context.  It could be that
the non-nVidia library isn't so stringent on separate thread configuration. 
The problem here, is that Qt is the code initializing the OpenGL environment. 
If Qt only allows graphics in the main thread, maybe it doesn't concern itself
with how OpenGL is configured in the other threads--then when Octave tries to
use OpenGL in the non-main Qt thread, OpenGL fails.

Could it be an extra step needs to be done to make nVidia's OpenGL function
properly in the thread that __osmesa_print__ is running in?  Does that make
sense?

https://www.opengl.org/wiki/Getting_Started#Initialization


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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