Re: [Xquartz-dev] Bug in displaying vtk objects
This is really better suited for xquartz-dev, so moving there...
The result for Valerie's vtk scripts is the same as with 2.3.3.2, with one exception: The "correct" vtk window from imagepluspoly.py now renders extremely slowly, it follows mouse movements with about 1 frame per second.
Whoa. it must be triggering something bad in our old libGL to be seeing such low performance.
There were some changes in 2.3.2, so I'd also try 2.3.1 and start stepping back towards 2.2.3 (which was pretty much what was in OSX 10.5.5) to see if any of those make a difference.
With 2.3.3.2 it is fluid, as are (with both 2.3.2 and 2.3.3.2) the "wrong" windows using gtk that do not show the volume object.
My configuration is similar to Valerie's, same Mbook pro, same GeForce 8600M GT graphics card. VTK is more up-to-date:
vtk: 5.4 (fink package vtk54-5.4.0-1)
but this doesn't seem to make a difference.
I just got back from my trip, so I'm going to try reproducing this. I'm a MacPorts guy, so I'm installing our vtk5 port right now. MP doesn't have a vtk-py port, so I'll need to put one together first assuming vtk5 builds alright here.
So it turns out the vtk-py stuff is in MacPorts' vtk5 port already, so I'm giving it a go. The two gtk scripts fail outright for me using MacPorts with either Mesa's libGL or our new hardware accelerated libGL. I see: The program 'gtkvtkdebug2.py' received an X Window System error. This probably reflects a bug in the program. The error was 'BadValue (integer parameter out of range for operation)'. (Details: serial 20 error_code 2 request_code 0 minor_code 3) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Here's the stack with our hw accelerated libGL: #0 0x0072e08c in gdk_x_error () #1 0x018e274c in _XError () #2 0x055adfa4 in __glXSendError (dpy=0x8af400, errorCode=2, resourceID=34, minorCode=3, coreX11error=true) at glx_error.c:59 #3 0x055809f4 in CreateContext (dpy=0x8af400, vis=0x7322e40, fbconfig=0x0, shareList=0x0, allowDirect=1, contextID=0, use_glx_1_3=0, renderType=0) at glxcmds.c:388 #4 0x05580b30 in glXCreateContext (dpy=0x8af400, vis=0x7322e40, shareList=0x0, allowDirect=1) at glxcmds.c:416 #5 0x0534a2b0 in vtkXOpenGLRenderWindow::CreateAWindow () #6 0x0534b6d4 in vtkXOpenGLRenderWindow::WindowInitialize () #7 0x0534b7f0 in vtkXOpenGLRenderWindow::Initialize () #8 0x0534bc88 in vtkXOpenGLRenderWindow::Start () #9 0x0523edc0 in vtkRenderWindow::DoStereoRender () #10 0x0523ed74 in vtkRenderWindow::DoFDRender () #11 0x0523e6f8 in vtkRenderWindow::DoAARender () #12 0x0523db58 in vtkRenderWindow::Render () #13 0x0534e9d0 in vtkXOpenGLRenderWindow::Render () #14 0x04f2e67c in PyvtkXOpenGLRenderWindow_Render () ... (gdb) frame 3 #3 0x055809f4 in CreateContext (dpy=0x8af400, vis=0x7322e40, fbconfig=0x0, shareList=0x0, allowDirect=1, contextID=0, use_glx_1_3=0, renderType=0) at glxcmds.c:388 388 __glXSendError(dpy, BadValue, vis->visualid, X_GLXCreateContext, (gdb) print mode $1 = (const __GLcontextModes *) 0x0 ^^^ This is why we're seeing an error. We couldn't get a valid mode for the requested visual id: (gdb) print vis->visualid $2 = 34 So we were told to use an invalid visual by vtkXOpenGLRenderWindow::CreateAWindow I'm curious how you guys are getting yours to render. Perhaps this is an issue that is fixed in fink's version of vtk. Can you set the LIBGL_DUMP_VISUALID environment variable? that should tell you which visual is being requested, and you can find out about that visual by running 'glxinfo -v'. --Jeremy
Jeremy Huddleston wrote:
This is really better suited for xquartz-dev, so moving there...
The result for Valerie's vtk scripts is the same as with 2.3.3.2, with one exception: The "correct" vtk window from imagepluspoly.py now renders extremely slowly, it follows mouse movements with about 1 frame per second.
Whoa. it must be triggering something bad in our old libGL to be seeing such low performance.
There were some changes in 2.3.2, so I'd also try 2.3.1 and start stepping back towards 2.2.3 (which was pretty much what was in OSX 10.5.5) to see if any of those make a difference.
I had noticed the same low performance with 2.3.2 but didn't think to mention it earlier.
With 2.3.3.2 it is fluid, as are (with both 2.3.2 and 2.3.3.2) the "wrong" windows using gtk that do not show the volume object.
My configuration is similar to Valerie's, same Mbook pro, same GeForce 8600M GT graphics card. VTK is more up-to-date:
vtk: 5.4 (fink package vtk54-5.4.0-1)
but this doesn't seem to make a difference.
I just got back from my trip, so I'm going to try reproducing this. I'm a MacPorts guy, so I'm installing our vtk5 port right now. MP doesn't have a vtk-py port, so I'll need to put one together first assuming vtk5 builds alright here.
Based on the recommendations from your earlier email in the X11 list, I tried setting LIBGL_DIAGNOSTIC=1 When I run (and then close) the script that gives the "correct" rendering, imagepluspoly.py, I get: initializing libGL in apple_init_glx DIAG: CGL major 1 minor 2 DIAG: apple_glx_create_context: ac 0x2bdf10 ac->context_obj 0x94a400 DIAG: apple_glx_drawable_create: new drawable 0x98f400 DIAG: create_surface: created a surface for drawable 0x600002 with uid 181 DIAG: surface_make_current: ac->context_obj 0x94a400 s->surface_id 5 DIAG: surface_make_current: drawable 0x600002 DIAG: MakeContextCurrent: error NO DIAG: surface_notify_handler: surface destroyed 181 DIAG: destroy_drawable_callback: 0x98f400 ->reference_count before -- 2 When I run the script that gives the "wrong" behavior, gtkvtkdebug.py, I get: initializing libGL in apple_init_glx DIAG: CGL major 1 minor 2 DIAG: apple_glx_create_context: ac 0x4f42810 ac->context_obj 0x9c7200 DIAG: apple_glx_drawable_create: new drawable 0xa08600 DIAG: create_surface: created a surface for drawable 0x60001e with uid 229 DIAG: surface_make_current: ac->context_obj 0x9c7200 s->surface_id 5 DIAG: surface_make_current: drawable 0x60001e DIAG: MakeContextCurrent: error NO The only differences are the addresses and uids for the contexts and the drawables, and the last two lines which are output by imagepluspoly.py when it is closed are not output by gtkvtkdebug.py. With LIBGL_ALWAYS_SOFTWARE=1, imagepluspoly.py gives: initializing libGL in apple_init_glx DIAG: CGL major 1 minor 2 DIAG: Software rendering requested. Using kCGLRendererGenericFloatID. DIAG: apple_glx_create_context: ac 0x2bdf10 ac->context_obj 0x94a400 DIAG: apple_glx_drawable_create: new drawable 0x95fa00 DIAG: create_surface: created a surface for drawable 0x600002 with uid 245 DIAG: surface_make_current: ac->context_obj 0x94a400 s->surface_id 5 DIAG: surface_make_current: drawable 0x600002 DIAG: MakeContextCurrent: error NO DIAG: surface_notify_handler: surface destroyed 245 DIAG: destroy_drawable_callback: 0x95fa00 ->reference_count before -- 2 and gtkvtkdebug.py gives: initializing libGL in apple_init_glx DIAG: CGL major 1 minor 2 DIAG: Software rendering requested. Using kCGLRendererGenericFloatID. DIAG: apple_glx_create_context: ac 0x4f42810 ac->context_obj 0x9c7200 DIAG: apple_glx_drawable_create: new drawable 0x9d8600 DIAG: create_surface: created a surface for drawable 0x60001e with uid 253 DIAG: surface_make_current: ac->context_obj 0x9c7200 s->surface_id 5 DIAG: surface_make_current: drawable 0x60001e DIAG: MakeContextCurrent: error NO but what is rendered is the same.
So it turns out the vtk-py stuff is in MacPorts' vtk5 port already, so I'm giving it a go. The two gtk scripts fail outright for me using MacPorts with either Mesa's libGL or our new hardware accelerated libGL. I see:
The program 'gtkvtkdebug2.py' received an X Window System error. This probably reflects a bug in the program. The error was 'BadValue (integer parameter out of range for operation)'. (Details: serial 20 error_code 2 request_code 0 minor_code 3) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.)
Here's the stack with our hw accelerated libGL:
#0 0x0072e08c in gdk_x_error () #1 0x018e274c in _XError () #2 0x055adfa4 in __glXSendError (dpy=0x8af400, errorCode=2, resourceID=34, minorCode=3, coreX11error=true) at glx_error.c:59 #3 0x055809f4 in CreateContext (dpy=0x8af400, vis=0x7322e40, fbconfig=0x0, shareList=0x0, allowDirect=1, contextID=0, use_glx_1_3=0, renderType=0) at glxcmds.c:388 #4 0x05580b30 in glXCreateContext (dpy=0x8af400, vis=0x7322e40, shareList=0x0, allowDirect=1) at glxcmds.c:416 #5 0x0534a2b0 in vtkXOpenGLRenderWindow::CreateAWindow () #6 0x0534b6d4 in vtkXOpenGLRenderWindow::WindowInitialize () #7 0x0534b7f0 in vtkXOpenGLRenderWindow::Initialize () #8 0x0534bc88 in vtkXOpenGLRenderWindow::Start () #9 0x0523edc0 in vtkRenderWindow::DoStereoRender () #10 0x0523ed74 in vtkRenderWindow::DoFDRender () #11 0x0523e6f8 in vtkRenderWindow::DoAARender () #12 0x0523db58 in vtkRenderWindow::Render () #13 0x0534e9d0 in vtkXOpenGLRenderWindow::Render () #14 0x04f2e67c in PyvtkXOpenGLRenderWindow_Render () ...
(gdb) frame 3 #3 0x055809f4 in CreateContext (dpy=0x8af400, vis=0x7322e40, fbconfig=0x0, shareList=0x0, allowDirect=1, contextID=0, use_glx_1_3=0, renderType=0) at glxcmds.c:388 388 __glXSendError(dpy, BadValue, vis->visualid, X_GLXCreateContext, (gdb) print mode $1 = (const __GLcontextModes *) 0x0
^^^ This is why we're seeing an error. We couldn't get a valid mode for the requested visual id:
(gdb) print vis->visualid $2 = 34
So we were told to use an invalid visual by vtkXOpenGLRenderWindow::CreateAWindow
I'm curious how you guys are getting yours to render. Perhaps this is an issue that is fixed in fink's version of vtk. Can you set the LIBGL_DUMP_VISUALID environment variable? that should tell you which visual is being requested, and you can find out about that visual by running 'glxinfo -v'.
--Jeremy
Trying this last suggestion, glxinfo -v gives: name of display: /tmp/launch-LSCUAM/:0 visualid 0x72 visualid 0x4a display: /tmp/launch-LSCUAM/:0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_rating, GLX_SGIX_fbconfig GLX version: 1.4 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_rating, GLX_SGIX_fbconfig OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: NVIDIA GeForce 8600M GT OpenGL Engine OpenGL version string: 2.0 NVIDIA-1.5.44 OpenGL shading language version string: 1.20 OpenGL extensions: GL_ARB_transpose_matrix, GL_ARB_vertex_program, GL_ARB_vertex_blend, GL_ARB_window_pos, GL_ARB_shader_objects, GL_ARB_vertex_shader, ... SNIP ... 448 GLX Visuals Visual ID: 24 depth=24 class=TrueColor bufferSize=32 level=0 renderType=rgba doubleBuffer=0 stereo=0 rgba: redSize=8 greenSize=8 blueSize=8 alphaSize=8 auxBuffers=0 depthSize=0 stencilSize=0 accum: redSize=0 greenSize=0 blueSize=0 alphaSize=0 multiSample=0 multiSampleBuffers=0 visualCaveat=Slow plus 447 more Visual ID's that are the same except a few have redSize, greenSize, and blueSize, and alphaSize = 5. I edited this output down a bit for brevity. Let me know if you need the full text. It was long. Thanks so much for your help! Valerie
On Jun 17, 2009, at 11:32, Valerie Coffman wrote:
Jeremy Huddleston wrote:
This is really better suited for xquartz-dev, so moving there...
The result for Valerie's vtk scripts is the same as with 2.3.3.2, with one exception: The "correct" vtk window from imagepluspoly.py now renders extremely slowly, it follows mouse movements with about 1 frame per second.
Whoa. it must be triggering something bad in our old libGL to be seeing such low performance.
There were some changes in 2.3.2, so I'd also try 2.3.1 and start stepping back towards 2.2.3 (which was pretty much what was in OSX 10.5.5) to see if any of those make a difference.
I had noticed the same low performance with 2.3.2 but didn't think to mention it earlier.
With 2.3.3.2 it is fluid, as are (with both 2.3.2 and 2.3.3.2) the "wrong" windows using gtk that do not show the volume object.
My configuration is similar to Valerie's, same Mbook pro, same GeForce 8600M GT graphics card. VTK is more up-to-date:
vtk: 5.4 (fink package vtk54-5.4.0-1)
but this doesn't seem to make a difference.
I just got back from my trip, so I'm going to try reproducing this. I'm a MacPorts guy, so I'm installing our vtk5 port right now. MP doesn't have a vtk-py port, so I'll need to put one together first assuming vtk5 builds alright here.
Based on the recommendations from your earlier email in the X11 list, I tried setting LIBGL_DIAGNOSTIC=1
When I run (and then close) the script that gives the "correct" rendering, imagepluspoly.py, I get:
initializing libGL in apple_init_glx DIAG: CGL major 1 minor 2 DIAG: apple_glx_create_context: ac 0x2bdf10 ac->context_obj 0x94a400 DIAG: apple_glx_drawable_create: new drawable 0x98f400 DIAG: create_surface: created a surface for drawable 0x600002 with uid 181 DIAG: surface_make_current: ac->context_obj 0x94a400 s->surface_id 5 DIAG: surface_make_current: drawable 0x600002 DIAG: MakeContextCurrent: error NO DIAG: surface_notify_handler: surface destroyed 181 DIAG: destroy_drawable_callback: 0x98f400 ->reference_count before -- 2
When I run the script that gives the "wrong" behavior, gtkvtkdebug.py, I get:
initializing libGL in apple_init_glx DIAG: CGL major 1 minor 2 DIAG: apple_glx_create_context: ac 0x4f42810 ac->context_obj 0x9c7200 DIAG: apple_glx_drawable_create: new drawable 0xa08600 DIAG: create_surface: created a surface for drawable 0x60001e with uid 229 DIAG: surface_make_current: ac->context_obj 0x9c7200 s->surface_id 5 DIAG: surface_make_current: drawable 0x60001e DIAG: MakeContextCurrent: error NO
The only differences are the addresses and uids for the contexts and the drawables,
Yeah, could you figure out the visual id as well? I'm still curious why it's choosing a bad visual on my system.
and the last two lines which are output by imagepluspoly.py when it is closed are not output by gtkvtkdebug.py.
Hmm... that's not really a concern since the application is exiting. The server should notice the fd close and cleanup memory.
With LIBGL_ALWAYS_SOFTWARE=1, imagepluspoly.py gives:
but what is rendered is the same.
Ok, well that means it's not an nVidia issue. So it's either OpenGL.framework, X11 (less likely due to the email I just sent), or VTK (my money is on this one).
Trying this last suggestion, glxinfo -v gives: ...
plus 447 more Visual ID's that are the same except a few have redSize, greenSize, and blueSize, and alphaSize = 5.
I edited this output down a bit for brevity. Let me know if you need the full text. It was long.
No, I don't want the full text. I just want the one for the visual that is being used by your application. You need to set the LIBGL_DUMP_VISUALID environment variable when you run your application, and it will just print a hex number which is the visual id. Just copy/paste the info for that visual.
Could you please remove me from the distribution list? Thank you. Regards Johan Stalpaert On 17 Jun 2009, at 20:44, Jeremy Huddleston wrote:
On Jun 17, 2009, at 11:32, Valerie Coffman wrote:
Jeremy Huddleston wrote:
This is really better suited for xquartz-dev, so moving there...
The result for Valerie's vtk scripts is the same as with 2.3.3.2, with one exception: The "correct" vtk window from imagepluspoly.py now renders extremely slowly, it follows mouse movements with about 1 frame per second.
Whoa. it must be triggering something bad in our old libGL to be seeing such low performance.
There were some changes in 2.3.2, so I'd also try 2.3.1 and start stepping back towards 2.2.3 (which was pretty much what was in OSX 10.5.5) to see if any of those make a difference.
I had noticed the same low performance with 2.3.2 but didn't think to mention it earlier.
With 2.3.3.2 it is fluid, as are (with both 2.3.2 and 2.3.3.2) the "wrong" windows using gtk that do not show the volume object.
My configuration is similar to Valerie's, same Mbook pro, same GeForce 8600M GT graphics card. VTK is more up-to-date:
vtk: 5.4 (fink package vtk54-5.4.0-1)
but this doesn't seem to make a difference.
I just got back from my trip, so I'm going to try reproducing this. I'm a MacPorts guy, so I'm installing our vtk5 port right now. MP doesn't have a vtk-py port, so I'll need to put one together first assuming vtk5 builds alright here.
Based on the recommendations from your earlier email in the X11 list, I tried setting LIBGL_DIAGNOSTIC=1
When I run (and then close) the script that gives the "correct" rendering, imagepluspoly.py, I get:
initializing libGL in apple_init_glx DIAG: CGL major 1 minor 2 DIAG: apple_glx_create_context: ac 0x2bdf10 ac->context_obj 0x94a400 DIAG: apple_glx_drawable_create: new drawable 0x98f400 DIAG: create_surface: created a surface for drawable 0x600002 with uid 181 DIAG: surface_make_current: ac->context_obj 0x94a400 s->surface_id 5 DIAG: surface_make_current: drawable 0x600002 DIAG: MakeContextCurrent: error NO DIAG: surface_notify_handler: surface destroyed 181 DIAG: destroy_drawable_callback: 0x98f400 ->reference_count before -- 2
When I run the script that gives the "wrong" behavior, gtkvtkdebug.py, I get:
initializing libGL in apple_init_glx DIAG: CGL major 1 minor 2 DIAG: apple_glx_create_context: ac 0x4f42810 ac->context_obj 0x9c7200 DIAG: apple_glx_drawable_create: new drawable 0xa08600 DIAG: create_surface: created a surface for drawable 0x60001e with uid 229 DIAG: surface_make_current: ac->context_obj 0x9c7200 s->surface_id 5 DIAG: surface_make_current: drawable 0x60001e DIAG: MakeContextCurrent: error NO
The only differences are the addresses and uids for the contexts and the drawables,
Yeah, could you figure out the visual id as well? I'm still curious why it's choosing a bad visual on my system.
and the last two lines which are output by imagepluspoly.py when it is closed are not output by gtkvtkdebug.py.
Hmm... that's not really a concern since the application is exiting. The server should notice the fd close and cleanup memory.
With LIBGL_ALWAYS_SOFTWARE=1, imagepluspoly.py gives:
but what is rendered is the same.
Ok, well that means it's not an nVidia issue. So it's either OpenGL.framework, X11 (less likely due to the email I just sent), or VTK (my money is on this one).
Trying this last suggestion, glxinfo -v gives: ...
plus 447 more Visual ID's that are the same except a few have redSize, greenSize, and blueSize, and alphaSize = 5.
I edited this output down a bit for brevity. Let me know if you need the full text. It was long.
No, I don't want the full text. I just want the one for the visual that is being used by your application. You need to set the LIBGL_DUMP_VISUALID environment variable when you run your application, and it will just print a hex number which is the visual id. Just copy/paste the info for that visual.
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
johan stalpaert johan.stalpaert@pandora.be
Jeremy Huddleston wrote: []
No, I don't want the full text. I just want the one for the visual that is being used by your application. You need to set the LIBGL_DUMP_VISUALID environment variable when you run your application, and it will just print a hex number which is the visual id. Just copy/paste the info for that visual.
The strange thing is that for the ("correct") figure without gtk, there is a visualid shown, but for the "bad" one, there is *nothing* shown: costabel% env LIBGL_DUMP_VISUALID=1 vtkpython ./imagepluspoly.py visualid 0x66 visualid 0x66 visualid 0x66 costabel% env LIBGL_DUMP_VISUALID=1 vtkpython ./gtkvtkdebug.py ./gtkvtkdebug.py:449: GtkDeprecationWarning: gtk.mainquit is deprecated, use gtk.main_quit instead gtk.main() costabel% (The last two lines appear when the window is closed.) -- Martin
participants (4)
-
Jeremy Huddleston
-
johan stalpaert
-
Martin Costabel
-
Valerie Coffman