Sign in to follow this  
gumpy

[c++/sdl/opengl] strange slowness issue

Recommended Posts

gumpy    795
i recently tried using sdl and opengl and for some reason EVERY gl call is extremely slow. this includes calls merely set a flag. glx works just fine, so it's not my lack of hardware acceleration. does anyone know why gl calls would be so slow when using sdl? edit: i suppose i should mention that just setting a flag takes a minimum of about 2 seconds at 100%cpu and it takes about 90 seconds to begin drawing in a window...

Share this post


Link to post
Share on other sites
gumpy    795
i think this is pointless, but here's glxinfo.
name of display: :0.0
Xlib: extension "XFree86-DRI" missing on display ":0.0".
display: :0 screen: 0
direct rendering: No
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 extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.3 Mesa 4.0.4
OpenGL extensions:
GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_border_clamp,
GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3,
GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_blend_color,
GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_texture_env_add,
GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
GL_EXT_texture_lod_bias
glu version: 1.3
glu extensions:
GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess

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 24 tc 1 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None
0x24 24 tc 1 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None
0x25 24 tc 1 24 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None
0x26 24 tc 1 24 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None
0x27 24 dc 1 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None
0x28 24 dc 1 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None
0x29 24 dc 1 24 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None
0x2a 24 dc 1 24 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None

glxgears runs at 65-70 fps in the initial window and 10-15 fps maximized at 1024x768. i've also tested nehe tutorials, sdl and glx versions, and the glx ones start instantly and run fine, but the sdl ones run at 100% cpu for about 90 seconds before they even start drawing. i still have no clue what's causing this.

Share this post


Link to post
Share on other sites
baldurk    1028
It isn't pointless. From the output of glxinfo it's clear that you're using software rendering. You need to consult your distro's documentation on how to set up drivers for your graphics card. Make sure you get direct rendering enabled. At the moment you are using mesa which will be very slow.

Also, as regards the sdl problems, you might want to check what version of sdl you have. The latest is 1.2.8. Upgrade to that using whatever method your distro provides.

Share this post


Link to post
Share on other sites
gumpy    795
i've already stated that i'm using software rendering. it's ALL of the gl calls under sdl that have this strange issue of using 100% cpu for a minimum of about 2 seconds.

Share this post


Link to post
Share on other sites
baldurk    1028
who knows what mesa does when used by SDL. I've personally never experimented. Maybe SDL simply expects hardware acceleration and sets options based on that, which then take huge amounts of time without hardware acceleration.

Can I ask if there is a specific reason that you don't want to use hardware acceleration? without it I don't think you can expect reasonable performance on anything really.

Share this post


Link to post
Share on other sites
Sign in to follow this