Re: [Dri-devel] reproducible VTK + DRI breakage
Am Dienstag, 11. März 2003 11:06 schrieb Keith Whitwell: Charl P. Botha wrote: On Tue, 2003-03-11 at 10:16, Keith Whitwell wrote: Charl P. Botha wrote: In anycase, if you have wxPython and VTK with working Python wrappings installed, please run the attached example. Manipulate the 3D cone in both windows and then close the one window. Manipulating the remaining 3D cone for a second or two should result in a drmCmdBuffer: -22 application crash. You'll be pleased to hear that I've now got access to a HT enabled box with which I can reproduce some or all of the problems you guys have been seeing with threaded apps. Hopefully there'll be some fixes soon. Hmmm, new toys to play with! Thanks for thinking about us. ;) Keith, your filp-1 patch completely killed the drmCmdBuffer: -22 bug on my box. I have not been able to reproduce it since with VTK or synthetic tests. Can you summarize the problems that remain? I'm seeing all manner of bad behaviour with glthreads - lots of GL_INVALID_OPERATION errors, lots of 'holds heavyweight lock' errors, the occasional lockup. It's a mess... Ack. VTK TaskParallelismWithPorts: all (inner) triangles of the isosurface are not (wrong) colored = R200_NO_TCL fix it VTK/bin ./TaskParallelism TaskParallelism: r200_vtxfmt.c:949: r200VtxFmtFlushVertices: Assertion `vb.context == ctx' failed. Abbruch (core dumped) !!! Screen corruption in some upper lines !!! Redraw fix it. VTK/bin ./TaskParallelism TaskParallelism: r200_vtxfmt.c:949: r200VtxFmtFlushVertices: Assertion `vb.context == ctx' failed. Abbruch (core dumped) Reading symbols from /usr/X11R6/lib/modules/dri/r200_dri.so...done. Loaded symbols for /usr/X11R6/lib/modules/dri/r200_dri.so #0 0x41427701 in kill () from /lib/libc.so.6 (gdb) bt #0 0x41427701 in kill () from /lib/libc.so.6 #1 0x412b589a in pthread_kill () from /lib/libpthread.so.0 #2 0x412b5d92 in raise () from /lib/libpthread.so.0 #3 0x41428a23 in abort () from /lib/libc.so.6 #4 0x414220ea in __assert_fail () from /lib/libc.so.6 #5 0x4188c845 in r200VtxFmtFlushVertices () from /usr/X11R6/lib/modules/dri/r200_dri.so #6 0x401b1950 in vtkOpenGLRenderWindow::SetPixelData () from /opt/VTK/V4.0/VTK/lib/libvtkRendering.so #7 0x40048d40 in vtkCompositeManager::Composite () from /opt/VTK/V4.0/VTK/lib/libvtkParallel.so #8 0x40047de9 in vtkCompositeManager::EndRender () from /opt/VTK/V4.0/VTK/lib/libvtkParallel.so #9 0x40046379 in vtkCompositeManagerEndRender () from /opt/VTK/V4.0/VTK/lib/libvtkParallel.so #10 0x410f7afd in vtkCallbackCommand::Execute () from /opt/VTK/V4.0/VTK/lib/libvtkCommon.so #11 0x4113c5ea in vtkSubjectHelper::InvokeEvent () from /opt/VTK/V4.0/VTK/lib/libvtkCommon.so #12 0x4113c962 in vtkObject::InvokeEvent () from /opt/VTK/V4.0/VTK/lib/libvtkCommon.so #13 0x4017ff11 in vtkRenderWindow::Render () from /opt/VTK/V4.0/VTK/lib/libvtkRendering.so #14 0x401bb3da in vtkXOpenGLRenderWindow::Render () from /opt/VTK/V4.0/VTK/lib/libvtkRendering.so #15 0x401a74de in vtkXRenderWindowInteractorCallback () from /opt/VTK/V4.0/VTK/lib/libvtkRendering.so #16 0x40d55f3e in XtDispatchEventToWidget () from /usr/X11R6/lib/libXt.so.6 #17 0x40d56832 in _XtDefaultDispatcher () from /usr/X11R6/lib/libXt.so.6 #18 0x40d56bb9 in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6 #19 0x401a6852 in vtkXRenderWindowInteractor::Start () from /opt/VTK/V4.0/VTK/lib/libvtkRendering.so #20 0x40047658 in vtkCompositeManager::StartInteractor () from /opt/VTK/V4.0/VTK/lib/libvtkParallel.so #21 0x08049670 in process () #22 0x4006e964 in vtkThreadedController::Start () from /opt/VTK/V4.0/VTK/lib/libvtkParallel.so #23 0x4006e7c0 in vtkThreadedController::vtkThreadedControllerStart () from /opt/VTK/V4.0/VTK/lib/libvtkParallel.so #24 0x41139be1 in vtkMultiThreader::SingleMethodExecute () from /opt/VTK/V4.0/VTK/lib/libvtkCommon.so #25 0x4006eb40 in vtkThreadedController::SingleMethodExecute () from /opt/VTK/V4.0/VTK/lib/libvtkParallel.so #26 0x08049716 in main () #27 0x414177d1 in __libc_start_main () from /lib/libc.so.6 (gdb) info registers eax0x0 0 ecx0x6 6 edx0x412c127c 1093407356 ebx0x14d2 5330 esp0xbfffe998 0xbfffe998 ebp0xbfffe9b4 0xbfffe9b4 esi0x14d2 5330 edi0x412ba8c0 1093380288 eip0x41427701 0x41427701 eflags 0x202514 cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x2b 43 gs 0x2b 43 fctrl 0x37f895 fstat 0x0 0 ftag 0x0 0 fiseg 0x0 0 fioff 0x0 0 foseg 0x1f80 8064 fooff 0x0 0 fop0x0 0 xmm0 0x xmm1 0x xmm2
Re: [Dri-devel] reproducible VTK + DRI breakage
Am Dienstag, 11. März 2003 18:29 schrieb Michel Dänzer: RADEON_NO_VTXFMT=1 NO, not for me. VTK/bin ./TaskParallelism Speicherschutzverletzung (core dumped) DRI CVS taken on 10.03.2003. -Dieter --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] reproducible VTK + DRI breakage
Am Mittwoch, 12. März 2003 16:42 schrieb Dieter Nützel: Am Dienstag, 11. März 2003 11:06 schrieb Keith Whitwell: Charl P. Botha wrote: On Tue, 2003-03-11 at 10:16, Keith Whitwell wrote: Charl P. Botha wrote: In anycase, if you have wxPython and VTK with working Python wrappings installed, please run the attached example. Manipulate the 3D cone in both windows and then close the one window. Manipulating the remaining 3D cone for a second or two should result in a drmCmdBuffer: -22 application crash. You'll be pleased to hear that I've now got access to a HT enabled box with which I can reproduce some or all of the problems you guys have been seeing with threaded apps. Hopefully there'll be some fixes soon. Hmmm, new toys to play with! Thanks for thinking about us. ;) Keith, your filp-1 patch completely killed the drmCmdBuffer: -22 bug on my box. I have not been able to reproduce it since with VTK or synthetic tests. Can you summarize the problems that remain? I'm seeing all manner of bad behaviour with glthreads - lots of GL_INVALID_OPERATION errors, lots of 'holds heavyweight lock' errors, the occasional lockup. It's a mess... Ack. VTK TaskParallelismWithPorts: all (inner) triangles of the isosurface are not (wrong) colored = R200_NO_TCL fix it VTK/bin ./TaskParallelism TaskParallelism: r200_vtxfmt.c:949: r200VtxFmtFlushVertices: Assertion `vb.context == ctx' failed. Abbruch (core dumped) !!! Screen corruption in some upper lines !!! Redraw fix it. VTK/bin ./TaskParallelism TaskParallelism: r200_vtxfmt.c:949: r200VtxFmtFlushVertices: Assertion `vb.context == ctx' failed. Abbruch (core dumped) Still there, even after latest pull (12.03.2003). -Dieter --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] reproducible VTK + DRI breakage
Charl P. Botha wrote: Dear list, I've attached a wxPython + VTK example (just the wxVTKRenderWindowInteractor.py slightly modified) to illustrate the drmCmdBuffer: -22 bug that I'm actually seeing. It seems my glthreads.c attempts were off the track. In anycase, if you have wxPython and VTK with working Python wrappings installed, please run the attached example. Manipulate the 3D cone in both windows and then close the one window. Manipulating the remaining 3D cone for a second or two should result in a drmCmdBuffer: -22 application crash. If anyone 1. can replicate this or 2. fix it ;) I would be most grateful. Thanks, Charl Charl (and Dieter), You'll be pleased to hear that I've now got access to a HT enabled box with which I can reproduce some or all of the problems you guys have been seeing with threaded apps. Hopefully there'll be some fixes soon. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] reproducible VTK + DRI breakage
On Tue, 2003-03-11 at 10:16, Keith Whitwell wrote: Charl P. Botha wrote: In anycase, if you have wxPython and VTK with working Python wrappings installed, please run the attached example. Manipulate the 3D cone in both windows and then close the one window. Manipulating the remaining 3D cone for a second or two should result in a drmCmdBuffer: -22 application crash. You'll be pleased to hear that I've now got access to a HT enabled box with which I can reproduce some or all of the problems you guys have been seeing with threaded apps. Hopefully there'll be some fixes soon. Hmmm, new toys to play with! Thanks for thinking about us. ;) Keith, your filp-1 patch completely killed the drmCmdBuffer: -22 bug on my box. I have not been able to reproduce it since with VTK or synthetic tests. Thanks again, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] reproducible VTK + DRI breakage
Charl P. Botha wrote: On Tue, 2003-03-11 at 10:16, Keith Whitwell wrote: Charl P. Botha wrote: In anycase, if you have wxPython and VTK with working Python wrappings installed, please run the attached example. Manipulate the 3D cone in both windows and then close the one window. Manipulating the remaining 3D cone for a second or two should result in a drmCmdBuffer: -22 application crash. You'll be pleased to hear that I've now got access to a HT enabled box with which I can reproduce some or all of the problems you guys have been seeing with threaded apps. Hopefully there'll be some fixes soon. Hmmm, new toys to play with! Thanks for thinking about us. ;) Keith, your filp-1 patch completely killed the drmCmdBuffer: -22 bug on my box. I have not been able to reproduce it since with VTK or synthetic tests. Can you summarize the problems that remain? I'm seeing all manner of bad behaviour with glthreads - lots of GL_INVALID_OPERATION errors, lots of 'holds heavyweight lock' errors, the occasional lockup. It's a mess... Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] reproducible VTK + DRI breakage
Keith Whitwell wrote: Charl P. Botha wrote: On Tue, 2003-03-11 at 10:16, Keith Whitwell wrote: Charl P. Botha wrote: In anycase, if you have wxPython and VTK with working Python wrappings installed, please run the attached example. Manipulate the 3D cone in both windows and then close the one window. Manipulating the remaining 3D cone for a second or two should result in a drmCmdBuffer: -22 application crash. You'll be pleased to hear that I've now got access to a HT enabled box with which I can reproduce some or all of the problems you guys have been seeing with threaded apps. Hopefully there'll be some fixes soon. Hmmm, new toys to play with! Thanks for thinking about us. ;) Keith, your filp-1 patch completely killed the drmCmdBuffer: -22 bug on my box. I have not been able to reproduce it since with VTK or synthetic tests. Can you summarize the problems that remain? I'm seeing all manner of bad behaviour with glthreads - lots of GL_INVALID_OPERATION errors, lots of 'holds heavyweight lock' errors, the occasional lockup. It's a mess... Ah, actually this was my fault. Missed an installation step on the new box... glthreads is running ok here, now. Which is good -- but can you still post a summary of outstanding issues. I don't have vtk installed, but will do so if necessary. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] reproducible VTK + DRI breakage
Keith, Do you want to try running two copies of the 'tunnel' demo ? Alan. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] reproducible VTK + DRI breakage
On Tue, 2003-03-11 at 12:44, Keith Whitwell wrote: Ah, actually this was my fault. Missed an installation step on the new box... glthreads is running ok here, now. Which is good -- but can you still post a summary of outstanding issues. I don't have vtk installed, but will do so if necessary. If we're talking only DRI with your filp-1 changes, I actually have no outstanding threading problems! I seem to recall Dieter having a test case with multiple glxgears and an ipers that broke badly, but he will probably bring that up again. On 4.3.0 however, the vtxfmt assert error (and application termination) seems to happen very often with applications with multiple glxcontexts. The problem seems to have been solved in current DRI CVS, but I haven't been able to track down the fixer/fix (I would love backporting this to 4.3.0). Thanks again, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] reproducible VTK + DRI breakage
On Die, 2003-03-11 at 13:51, Charl P. Botha wrote: On Tue, 2003-03-11 at 12:44, Keith Whitwell wrote: Ah, actually this was my fault. Missed an installation step on the new box... glthreads is running ok here, now. Which is good -- but can you still post a summary of outstanding issues. I don't have vtk installed, but will do so if necessary. If we're talking only DRI with your filp-1 changes, I actually have no outstanding threading problems! I seem to recall Dieter having a test case with multiple glxgears and an ipers that broke badly, but he will probably bring that up again. On 4.3.0 however, the vtxfmt assert error (and application termination) seems to happen very often with applications with multiple glxcontexts. The problem seems to have been solved in current DRI CVS, but I haven't been able to track down the fixer/fix (I would love backporting this to 4.3.0). This may be stating the obvious, but RADEON_NO_VTXFMT=1 should work around the problem, right? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] reproducible VTK + DRI breakage
On Die, 2003-03-11 at 18:37, Charl P. Botha wrote: On Tue, 2003-03-11 at 18:29, Michel Dänzer wrote: On Die, 2003-03-11 at 13:51, Charl P. Botha wrote: On 4.3.0 however, the vtxfmt assert error (and application termination) seems to happen very often with applications with multiple glxcontexts. The problem seems to have been solved in current DRI CVS, but I haven't been able to track down the fixer/fix (I would love backporting this to 4.3.0). This may be stating the obvious, but RADEON_NO_VTXFMT=1 should work around the problem, right? AFAICR (I don't have my laptop with me) it does. However, I would prefer to have this done The Right Way(tm). Sure, just pointing out that this isn't a showstopper until the fix is backported. Someone also sent me your radeon flushvertices patch that I still have to try on 4.3.0. I'd be surprised if that helped this. Keith probably fixed this, look for his post mesa-4-0-4-branch trunk commits. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] reproducible VTK + DRI breakage
Dear list,
I've attached a wxPython + VTK example (just the
wxVTKRenderWindowInteractor.py slightly modified) to illustrate the
drmCmdBuffer: -22 bug that I'm actually seeing. It seems my glthreads.c
attempts were off the track.
In anycase, if you have wxPython and VTK with working Python wrappings
installed, please run the attached example. Manipulate the 3D cone in both
windows and then close the one window. Manipulating the remaining 3D cone
for a second or two should result in a drmCmdBuffer: -22 application crash.
If anyone 1. can replicate this or 2. fix it ;) I would be most grateful.
Thanks,
Charl
--
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/
A VTK RenderWindowInteractor widget for wxPython. Note that wxPython
comes with its own wxVTKRenderWindow in wxPython.lib.vtk. Try both
and see which one works better for you.
Find wxPython info at http://wxPython.org
Created by Prabhu Ramachandran, April 2002
Based on wxVTKRenderWindow.py
Please see the example at the end of this file.
Creation:
wxVTKRenderWindowInteractor(parent, ID, stereo=0, [wx keywords]):
You should create a wxPySimpleApp() or some other wx**App before
creating the window.
Behaviour:
Uses __getattr__ to make the wxVTKRenderWindowInteractor behave just
like a vtkGenericRenderWindowInteractor.
# import usual libraries
import math, os, sys
from wxPython.wx import *
import vtk
# a few configuration items, see what works best on your system
# Use wxGLCanvas as base class instead of wxWindow.
# This is sometimes necessary under wxGTK or the image is blank.
# (in wxWindows 2.3.1 and earlier, the GLCanvas had scroll bars)
try:
WX_USE_GL_CANVAS
except NameError:
if wxPlatform == '__WXMSW__':
WX_USE_GLCANVAS = 0
else:
WX_USE_GLCANVAS = 1
# Keep capturing mouse after mouse is dragged out of window
# (in wxGTK 2.3.2 there is a bug that keeps this from working,
# but it is only relevant in wxGTK if there are multiple windows)
try:
WX_USE_X_CAPTURE
except NameError:
if wxPlatform == '__WXMSW__':
WX_USE_X_CAPTURE = 1
else:
WX_USE_X_CAPTURE = 0
# end of configuration items
if WX_USE_GLCANVAS:
from wxPython.glcanvas import *
baseClass = wxGLCanvas
else:
baseClass = wxWindow
class EventTimer(wxTimer):
def __init__(self, iren):
wxTimer.__init__(self)
self.iren = iren
def Notify(self):
self.iren.TimerEvent()
class wxVTKRenderWindowInteractor(baseClass):
A wxRenderWindow for wxPython.
Use GetRenderWindow() to get the vtkRenderWindow.
Create with the keyword stereo=1 in order to
generate a stereo-capable window.
def __init__(self, parent, ID, *args, **kw):
# private attributes
self.__OldFocus = None
self.__RenderWhenDisabled = 0
# First do special handling of some keywords:
# stereo, position, size, width, height, style
stereo = 0
if kw.has_key('stereo'):
if kw['stereo']:
stereo = 1
del kw['stereo']
position = wxDefaultPosition
if kw.has_key('position'):
position = kw['position']
del kw['position']
size = wxDefaultSize
if kw.has_key('size'):
size = kw['size']
del kw['size']
if kw.has_key('width') and kw.has_key('height'):
size = (kw['width'], kw['height'])
del kw['width']
del kw['height']
# wxWANTS_CHARS says to give us e.g. TAB
# wxNO_FULL_REPAINT_ON_RESIZE cuts down resize flicker under GTK
style = wxWANTS_CHARS | wxNO_FULL_REPAINT_ON_RESIZE
if kw.has_key('style'):
style = style | kw['style']
del kw['style']
# the enclosing frame must be shown under GTK or the windows
# don't connect together properly
l = []
p = parent
while p: # make a list of all parents
l.append(p)
p = p.GetParent()
l.reverse() # sort list into descending order
for p in l:
p.Show(1)
# initialize the wxWindow
baseClass.__init__(self, parent, ID, position, size, style)
# create the RenderWindow and initialize it
self._RenderWindow = vtk.vtkRenderWindow()
try:
self._RenderWindow.SetSize(size.width, size.height)
except AttributeError:
self._RenderWindow.SetSize(size[0], size[1])
if stereo:
self._RenderWindow.StereoCapableWindowOn()
self._RenderWindow.SetStereoTypeToCrystalEyes()
self.__Created = 0
# Tell the RenderWindow to render inside the wxWindow.
if self.GetHandle():
self.__Created = 1
self._RenderWindow.SetWindowInfo(str(self.GetHandle()))
