Thread: [PyOpenGL-Users] PyOpenGL/PySide QML interaction bug
Brought to you by:
mcfletch
Menu
▾
▴
pyopengl-users
|
From: Henry G. <he...@ca...> - 2011-05-09 15:35:24
|
I've been using PyOpenGL in conjunction with PySide (the python Qt bindings) and QML (Qt's new declarative language). The idea is to have an OpenGL scene, with a declarative view on top presenting interface widgets. I describe it a little more here (with a picture): http://hgomersall.wordpress.com/2011/03/31/qml_with_opengl_using_python/ I had everything working well with my old laptop (Radeon x1400 graphics card with r300 driver, running Ubuntu 10.10). However, in moving to a new machine (necessitated by the death of the laptop), I've been experience an interesting bug, the source of which I am not sure about. The code that triggers the bug can be found here: https://github.com/hgomersall/Blog-Code/tree/master/qml_with_simplegl_bugtest I've attempted to pare the code down to be as simple as possible. The code is run by calling gl_simple.py. In its checked in state, the code will function using the workaround described below, but it is simple to trigger the bug. The program paints a red triangle on a black background with a few transparent QML widgets on top. Here is the problem: The GL commands are split between two classes in two different files: gl_simple.py and renderer_simple.py, containing the Renderer class (which is called from gl_simple.py). If "from OpenGL import GL" is included in any file in addition to gl_simple.py, then the program will hang and needs to be killed. The workaround used is to pass GL explicitly to Renderer and to store that within the class instance. This is how the code is made to work. In addition, there is a call to import numpy within gl_simple.py. Numpy is *not* used within my code in gl_simple.py, but if this import is removed then the program hangs. Numpy has to be imported *before* GL is imported - doing so after causes the hang. As mentioned, the bug was triggered by moving to a new machine. This is running Ubuntu 11.11 with a Radeon 4000 series card and the r600 driver. The same problem occurred on a laptop running 11.11 and using an Intel GMA X3100 graphics card. Is this a bug with primarily PyOpenGL or should I be getting on to PySide? Clearly PyOpenGL should handle imports and dependencies without breakages. Thanks, Henry Gomersall |
|
From: Henry G. <he...@ca...> - 2011-05-09 15:27:44
|
I've been using PyOpenGL in conjunction with PySide (the python Qt bindings) and QML (Qt's new declarative language). The idea is to have an OpenGL scene, with a declarative view on top presenting interface widgets. I describe it a little more here (with a picture): http://hgomersall.wordpress.com/2011/03/31/qml_with_opengl_using_python/ I had everything working well with my old laptop (Radeon x1400 graphics card with r300 driver, running Ubuntu 10.10). However, in moving to a new machine (necessitated by the death of the laptop), I've been experience an interesting bug, the source of which I am not sure about. The code that triggers the bug can be found here: https://github.com/hgomersall/Blog-Code/tree/master/qml_with_simplegl_bugtest I've attempted to pare the code down to be as simple as possible. The code is run by calling gl_simple.py. In its checked in state, the code will function using the workaround described below, but it is simple to trigger the bug. The program paints a red triangle on a black background with a few transparent QML widgets on top. Here is the problem: The GL commands are split between two classes in two different files: gl_simple.py and renderer_simple.py, containing the Renderer class (which is called from gl_simple.py). If "from OpenGL import GL" is included in any file in addition to gl_simple.py, then the program will hang and needs to be killed. The workaround used is to pass GL explicitly to Renderer and to store that within the class instance. This is how the code is made to work. In addition, there is a call to import numpy within gl_simple.py. Numpy is *not* used within my code in gl_simple.py, but if this import is removed then the program hangs. Numpy has to be imported *before* GL is imported - doing so after causes the hang. As mentioned, the bug was triggered by moving to a new machine. This is running Ubuntu 11.11 with a Radeon 4000 series card and the r600 driver. The same problem occurred on a laptop running 11.11 and using an Intel GMA X3100 graphics card. Is this a bug with primarily PyOpenGL or should I be getting on to PySide? Clearly PyOpenGL should handle imports and dependencies without breakages. Thanks, Henry Gomersall |
|
From: Mike C. F. <mcf...@vr...> - 2011-05-09 18:11:46
|
On 11-05-09 11:35 AM, Henry Gomersall wrote: ... > Is this a bug with primarily PyOpenGL or should I be getting on to > PySide? Clearly PyOpenGL should handle imports and dependencies without > breakages. I don't see the bug(s) with an Kubuntu Natty (11.04), Radeon HD 3650 (with the FireGL bindings). PyOpenGL doesn't have any internal threading operations, so the most likely culprit would be something in PySide keeping the rendering loop running. Other possible culprits might be code which is attempting to do cleanup that crashes when the references to GL or numpy go to None during interpreter shutdown; a raised exception may be preventing the finalization/destruction of the context. That might be in PyOpenGL or elsewhere, but I can't readily track it down without some traceback or the like. I suppose it would be possible that something is doing reference counting for the windows and winding up with a loop due to something being held by PyOpenGL, but that seems unlikely given the symptoms. We're likely looking at something low-level, as differences in hardware/drivers are causing the error to appear/disappear, but I don't see anything obviously wrong with what you're doing. I don't have any machines updated to 11.11 yet, so we might possibly be looking at an 11.11 regression, or a bug in the r600 driver? If it's easy for you, can you test with the FireGL (proprietary) driver or an 11.04 machine? Good luck, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
|
From: Henry G. <he...@ca...> - 2011-05-09 18:37:55
|
On Mon, 2011-05-09 at 14:11 -0400, Mike C. Fletcher wrote: > We're likely looking at something low-level, as differences in > hardware/drivers are causing the error to appear/disappear, but I > don't > see anything obviously wrong with what you're doing. I don't have any > machines updated to 11.11 yet, so we might possibly be looking at an > 11.11 regression, or a bug in the r600 driver? If it's easy for you, > can you test with the FireGL (proprietary) driver or an 11.04 machine? > Whoops, I meant 11.04 :) I'll try the code with the proprietary driver and report back. I tried to replicate the bug using the more usual method of directly controlling an instance of QQLWidget, but couldn't. Cheers, Henry |
|
From: Henry G. <he...@ca...> - 2011-05-10 12:17:11
|
On Mon, 2011-05-09 at 19:37 +0100, Henry Gomersall wrote: > I'll try the code with the proprietary driver and report back. > Right, so I've had more of a play. Using the proprietary fglrx driver, I have no problems (using the ATI HD4350 card), as expected from Mike's tests (btw, all tests are using Ubuntu 11.04). I've added another example test case to my github repository: https://github.com/hgomersall/Blog-Code/tree/master/qml_with_simplegl_bugtest This adds another two files called broken_wrapper.py and hd4350_working_wrapper.py. The external calls that are made in each case are identical and everything I know tells me the two wrappers should do exactly the same thing. The only difference is an extra function layer in hd4350_working_wrapper.py. The code that is run when either wrapper file is executed is superficially identical to the code that is run when gl_simple.py is executed. The outcomes however are quite different: 1) gl_simple.py executed: Everything works as expected on both the desktop ATI HD4350 (running r600 driver) and the laptop Intel GMA X3100 (a red triangle and some sliders). 2) broken_wrapper.py executed: Hangs with both the desktop and the laptop. 3) hd4350_working_wrapper.py executed: Runs as expected on the desktop ATI HD4350 machine, but hangs on the laptop. This is the first time if teased apart a difference between the laptop and the desktop. Does this suggest some kind of timing issue? The bug is starting to be pretty unpredictable and really needs to be sorted, so assistance is *much* appreciated. Thanks, Henry |
|
From: Mike C. F. <mcf...@vr...> - 2011-05-11 04:26:11
|
On 11-05-10 08:17 AM, Henry Gomersall wrote: ... > Right, so I've had more of a play. Using the proprietary fglrx driver, I > have no problems (using the ATI HD4350 card), as expected from Mike's > tests (btw, all tests are using Ubuntu 11.04). > > I've added another example test case to my github repository: > https://github.com/hgomersall/Blog-Code/tree/master/qml_with_simplegl_bugtest > > This adds another two files called broken_wrapper.py and > hd4350_working_wrapper.py. The external calls that are made in each case > are identical and everything I know tells me the two wrappers should do > exactly the same thing. The only difference is an extra function layer > in hd4350_working_wrapper.py. The code that is run when either wrapper > file is executed is superficially identical to the code that is run when > gl_simple.py is executed. The outcomes however are quite different: > > 1) gl_simple.py executed: Everything works as expected on both the > desktop ATI HD4350 (running r600 driver) and the laptop Intel GMA X3100 > (a red triangle and some sliders). > 2) broken_wrapper.py executed: Hangs with both the desktop and the > laptop. > 3) hd4350_working_wrapper.py executed: Runs as expected on the desktop > ATI HD4350 machine, but hangs on the laptop. > > This is the first time if teased apart a difference between the laptop > and the desktop. > > Does this suggest some kind of timing issue? The bug is starting to be > pretty unpredictable and really needs to be sorted, so assistance is > *much* appreciated. Yeah, its definitely beginning to look like some sort of timing or similar issue where the longer tear-down time of a few modules or something of that nature is causing some race condition in a thread or the like. I gather Qt is creating threads for e.g. your URL-based loading of the resource file? IIRC you did not see the same failure when using direct rendering of the widgets, so we might be seeing some tear-down problem in that thread? I see from google that there have been errors in PySide where image loading threads could cause the application to hang, it might be possible this is a similar issue, but likely more subtle in the trigger/race condition causing it. I can't test the code on my machine without the firegl driver (older radeon only has OpenGL 1.4 support with the free driver), so can't confirm behaviour on the OS driver. Afraid that's not likely much help, but good luck, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
|
From: Henry G. <he...@ca...> - 2011-05-11 15:39:13
|
On Wed, 2011-05-11 at 00:25 -0400, Mike C. Fletcher wrote: > I can't test the code on my machine without the firegl driver (older > radeon only has OpenGL 1.4 support with the free driver), so can't > confirm behaviour on the OS driver. > That's funny, my OpenGL version is 2.1 using the r600 driver which should be the same as you. In case you feeling super keen, I can trigger the bug using the software mesa driver (enabled with the environment variable LIBGL_ALWAYS_SOFTWARE=1). Anyway, I understand this is probably getting beyond the PyOpenGL list. I'll go and pester the PySide list (which it probably isn't either, PyQt4 bindings show the same bug). Thanks, Henry |
|
From: Henry G. <he...@ca...> - 2011-05-12 13:56:29
|
On Wed, 2011-05-11 at 00:25 -0400, Mike C. Fletcher wrote: > but good luck, Just to tidy up and conclude this thread, upgrading to git Mesa (well, actually to xedgers ppa, so it could be anything in there) has made the problem go away, so I conclude that it was a regression between 10.10 and 11.04. Although I'd love to have the time and motivation to track down the specific bug, I don't, so here's to hoping it stays fixed! All in all a bit of an anticlimax. Cheers, Henry |
Thanks for helping keep SourceForge clean.
X