Crashes when requested OpenGL context cannot be created #2155
Comments
|
Hi and welcome! Thanks for posting your first issue in the PyVista project! Someone from |
|
Can you run the following? Using import pyvista as pv
print(pv.Report(gpu=False)) |
|
My initial impression with this is that you need the We also provide some osmesa wheels here: https://github.com/pyvista/pyvista-wheels/tree/main/osmesa and https://wheels.pyvista.org/osmesa/ for you to try, though they may be missing some of the qt modules |
|
I'd recommend sticking with conda and trying their osmesa variant to see if that solves this initial issue with PyVista |
|
Hello @banesullivan, thanks for your comments!
Oh, yes, I'd tried that but forgot to mention. With the My main concern was that I'm getting a segfault if certain OpenGL features are not available. (In my case, lack of ES3) |
Concerning indeed. The gracefulness of that error handling is up to VTK directly in my opinion... though if someone has a the know-how to write a GL check method in PyVista, I'd support it 100% - its just a tough thing to robustly handle.
Hm, I wonder if that's because some qt module is missing in the osmesa conda-forge build variant? |
|
I'm curious. If you spin up a vanilla Python virtual environment and install PyVista and VTK from |
Do you mean with or without OSMesa? |
I did try to import the on my system: But I tried with @hoechenberger and it's possible to check for a specific extension with from OpenGL.GL import (glGetIntegerv, glGetStringi, GL_NUM_EXTENSIONS,
GL_EXTENSIONS)
from OpenGL.GLUT import glutInit, glutCreateWindow
glutInit()
wind = glutCreateWindow("Check OpenGL ES3")
num_extensions = glGetIntegerv(GL_NUM_EXTENSIONS, 0)
extensions = list()
for i in range(num_extensions.value):
current_ext = glGetStringi(GL_EXTENSIONS, i)
extensions.append(current_ext.decode("utf-8"))
extensions = [ext for ext in extensions if '_ES3' in ext] # <--- parse ES3 here
print(extensions) # return the list of supported OPENGL_ES3 extensionshttps://gist.github.com/GuillaumeFavelier/06dcae8677bb66181714d1285fbe8e61 |
|
AFAIK |
Thank you for the explanation! But ouch 😅 Do you know any alternative then? |
|
Afraid not, but you might try https://vtk.org/doc/nightly/html/classvtkOpenGLFramebufferObject.html#details. |
|
What I found in const char* vtkOpenGLRenderWindow::ReportCapabilities()
{
this->MakeCurrent();
const char* glVendor = (const char*)glGetString(GL_VENDOR);
const char* glRenderer = (const char*)glGetString(GL_RENDERER);
const char* glVersion = (const char*)glGetString(GL_VERSION);
std::ostringstream strm;
if (glVendor)
{
strm << "OpenGL vendor string: " << glVendor << endl;
}
if (glRenderer)
{
strm << "OpenGL renderer string: " << glRenderer << endl;
}
if (glVersion)
{
strm << "OpenGL version string: " << glVersion << endl;
}
strm << "OpenGL extensions: " << endl;
GLint n, i;
glGetIntegerv(GL_NUM_EXTENSIONS, &n);
for (i = 0; i < n; i++)
{
const char* ext = (const char*)glGetStringi(GL_EXTENSIONS, i);
strm << " " << ext << endl;
}
delete[] this->Capabilities;https://github.com/Kitware/VTK/blob/master/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx#L261-L293 So I made another gist: import vtk as _vtk
renderWindow = _vtk.vtkRenderWindow()
renderWindow.SetOffScreenRendering(True)
renderWindow.Render()
extension_name = "_ES3"
if renderWindow.SupportsOpenGL():
caps = renderWindow.ReportCapabilities()
caps = caps.split('\n')
else:
caps = ""
ext_supported = [ext for ext in caps if extension_name in ext]
print(ext_supported)https://gist.github.com/GuillaumeFavelier/02d7a51ef6aba3cae449bd33777d2c1d This is what I have on my system: Feel free to try it @hoechenberger |
|
@GuillaumeFavelier Unfortunately, this produces the same error as soon as |
|
This segfault-on-sys-info has been irking me for a while -- I think it's worth digging into a bit. @hoechenberger can you try this gist on the system that fails: https://gist.github.com/larsoner/05f13182d26b70ceb6c2df739cbb3edd I adapted it from If this works, I think it's worth implementing a cleaner variant as we have seen multiple users in MNE-Python complain about this segfault. It's not perfect, and it's not complete (e.g., doesn't triage based on |
|
@larsoner Thanks for looking into this, I can try out your script tomorrow CET and report back FWIW @GuillaumeFavelier and I had a look at this together again this Paris afternoon, and it appears that it might have something to do with the presence of an interactor (or, rather, the lack thereof). While a MWE with … basically every fancy OpenGL feature disabled still provokes the crash, even a complex scene like MNE's |
|
Indeed, as of now, I still have no clue why the MWE with |
Actually I get an … interesting error message: Traceback (most recent call last):
File "/home/rh265054/eric.py", line 33, in <module>
glx = CDLL('libGL.so')
File "/neurospin/meg/mne-python/dev/lib/python3.9/ctypes/__init__.py", line 374, in __init__
self._handle = _dlopen(self._name, mode)
OSError: libGL.so: cannot open shared object file: No such file or directory
( 3.406s) [main thread ] loguru.cpp:485 1| atexitboth when using X2go and when connecting via |
|
Can you try changing it to |
Right, this library does indeed exist! Getting a nice new message now… 😅 |
|
I suggest this StackOverflow answer for anyone still facing this issue. It worked like a charm for me: https://stackoverflow.com/a/71421355/8140182 |
Hello!
On a system with limited OpenGL support (specifically, in an X2go session without OpenGL core and ES3 profiles), PyVista (VTK?) doesn't gracefully handle this lack of advanced technologies and crashes.
To Reproduce
On a Linux system with the following
glxinfo |grep OpenGLoutput:(core and ES profiles missing), the following code snippets:
both result in:
According to the docs, depth peeling requires ES3, which isn't supported on this system.
I can reproduce this crash on the VTK level alone:
Expected behavior would be for things not to crash.
System Information:
Unfortunately, running this code leads to the same crash as reported above.
I'm using
pyvista0.7 withvtk9.1.0 fromconda-forge(theirqtbuild variant; see recipe)I verified that the installation itself is working in principle by running the above commands via X11 forwarding through SSH (
ssh -X), and everything works as expected.It should also be noted that rather complex 3D visualizations can be produced (tested with MNE-Python's Coregistration UI, which generates an interactive skull surface with numerous overlays) as long as I don't try to enable depth peeling (probably requesting other "advanced" features would produce the same issues; I'm just reporting here what I experienced so far :))
Any advice would be greatly appreciated!
Thanks,
Richard
cc @GuillaumeFavelier @larsoner @agramfort
The text was updated successfully, but these errors were encountered: