Performance under Linux

Hello,

I am a student who is programming with OpenGL. It seems to be that the performance of my machine running opengl under linux is very poor. I am running a Athlon 600mhz with a Matrox G400 Max 32mb . I am using Matrox’s latest linux drivers and dri is running, so is agpgart. I am using Xfree 86 4.0.3. The problem is hidden surfaces sometimes shows up when i rotate an object fast , but when i roate a object slowly it doesnt do this. That is why i think its a performance issue. I run the exact same code under a Sun Blade 100 and it looks perfect. Sometime when i run the code under linux it will even lock up my machine. With no possible way to kill the program but rebooting the machine.

Any help would be greatley appreciated. Below is output of glxinfo.

glxinfo
display: :0.0 screen:0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
client glx vendor string: SGI
client glx version string: 1.2
client glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context,
GLX_ARB_get_proc_address
GLX extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
OpenGL vendor string: Precision Insight, Inc.
OpenGL renderer string: Mesa DRI G400 20000510
OpenGL version string: 1.2 Mesa 3.4
OpenGL extensions:
GL_ARB_multitexture, GL_ARB_tranpose_matrix, GL_EXT_abgr,
GL_EXT_blend_func_separate, GL_EXT_clip_volume_hint,
GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels,
GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_stencil_wrap,
GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_object,
GL_EXT_vertex_array, GL_MESA_window_pos, GL_MESA_resize_buffers,
GL_NV_texgen_reflection, GL_PGI_misc_hints, GL_SGIS_pixel_texture,
GL_SGIS_texture_edge_clamp

visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat

0x23 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None
0x24 16 tc 0 16 0 r . . 5 6 5 0 0 16 0 0 0 0 0 0 0 None
0x25 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow
0x26 16 tc 0 16 0 r . . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow
0x27 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow
0x28 16 tc 0 16 0 r . . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow
0x29 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow
0x2a 16 tc 0 16 0 r . . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow
0x2b 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None
0x2c 16 dc 0 16 0 r . . 5 6 5 0 0 16 0 0 0 0 0 0 0 None
0x2d 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow
0x2e 16 dc 0 16 0 r . . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow
0x2f 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow
0x30 16 dc 0 16 0 r . . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow
0x31 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow
0x32 16 dc 0 16 0 r . . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow

I do not understand your assumption about how a speed drop will show hidden surfaces. The output from glxinfo says that some modes are slow, perhaps did you used one of them?
I do not know about Matrox but nvidia cards has more precision in the depth buffer if you run in 24 bit color depth instead. This is also a must for hardware stencil buffer support.
Mesa 4.0 is out with later versions and maybe will it also run faster.

This sounds like what happens when you start writing to AGP buffers before the previous frame has been fully rendered by the graphics hardware.

Cas

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.