OpenGL "out of memory" error when exceeding 128MB of textures

Question

I am working on an embedded OpenGL graphics application running on an Intel Atom z530 with the GMA500 graphics hardware. (It's my understanding that the GMA500 is a PowerVR under the hood, but I'm not sure). I'm running with the Tungsten Graphics "Gallium" driver on Ubuntu 9.10 Karmic Koala. Oh, you should also know that i have 1 GB of available system memory.

Here's the problem: I have code that allocates a bunch of 512x512x32 textures (about 1MB apiece). When I get to about 118-120 of these, I get an "out of memory" error from OpenGL, and I also get this message on the console: "error: INTEL_ESCAPE_ALLOC_REGION failed".

This, along with simple measurements while looking at "top", indicate to me that I'm hitting up against an ~128MB limit for textures. The odd thing is this: this architecture doesn't have dedicated video ram, it's shared. And I can tell for sure that OpenGL is using system ram for the textures because I can see the "free" ram going down in 'top'. So why would I get an 'out of memory' error? I would expect opengl to simply use more of my available system ram. Why would there be such a hard limit? Is there some way to change what this apparent "hard limit" is set to?

Thanks! Chris

---

Here's my output from glxinfo:

$ glxinfo

name of display: :0.0
display: :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_SGIS_multisample, GLX_SGIX_hyperpipe, 
    GLX_SGIX_swap_barrier, 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_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, 
    GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, 
    GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, 
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, 
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
    GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_swap_control, 
    GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, 
    GLX_SGIX_fbconfig, GLX_EXT_texture_from_pixmap
OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Gallium 0.1, pipe/psb/Poulsbo on IEGD
OpenGL version string: 2.0 Mesa 7.1
OpenGL shading language version string: 1.10
OpenGL extensions:
    GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program, 
    GL_ARB_fragment_shader, GL_ARB_multisample, GL_ARB_multitexture, 
    GL_ARB_occlusion_query, GL_ARB_pixel_buffer_object, 
    GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shader_objects, 
    GL_ARB_shading_language_100, GL_ARB_shading_language_120, GL_ARB_shadow, 
    GL_ARB_texture_border_clamp, GL_ARB_texture_compression, 
    GL_ARB_texture_cube_map, GL_ARB_texture_env_add, 
    GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, 
    GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, 
    GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, 
    GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, 
    GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ARB_window_pos, 
    GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, 
    GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, 
    GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, 
    GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, 
    GL_EXT_copy_texture, GL_EXT_draw_range_elements, 
    GL_EXT_framebuffer_object, GL_EXT_framebuffer_blit, GL_EXT_fog_coord, 
    GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, 
    GL_EXT_pixel_buffer_object, GL_EXT_point_parameters, 
    GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, 
    GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, 
    GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, GL_EXT_subtexture, 
    GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_compression_s3tc, 
    GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, 
    GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, 
    GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, 
    GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, 
    GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, 
    GL_ATI_blend_equation_separate, GL_ATI_separate_stencil, 
    GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, 
    GL_INGR_blend_func_separate, GL_MESA_ycbcr_texture, GL_MESA_window_pos, 
    GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_point_sprite, 
    GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_OES_read_format, 
    GL_SGI_color_matrix, GL_SGIS_generate_mipmap, 
    GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, 
    GL_SGIS_texture_lod, GL_SUN_multi_draw_arrays

    ...truncated visuals part...

Answer 1

Have you taken into account the lower resolution copies of the texture that get created to do mipmapping?

pre-calculated, optimized collections of images that accompany a main texture, intended to increase rendering speed and reduce aliasing artifacts.

These reduce in steps of powers of 2 so you'll have a 256x256, a 128x128, a 64x64, ... image accompanying the main texture. This will eat into your texture memory much faster than if you just had the single image.

In the example they use on Wikipedia the original texture is 256x256 and they take the mip-map textures all the way down to 1x1. By their calculations

The increase in storage space required for all of these mipmaps is a third of the original texture

This assumes that you haven't turned it off of course.

As to how you increase the amount of memory you can have access to - sorry no idea.

Answer 2

Use smaller or compressed textures, or palletized ones. Also be wary about geometry/display lists which also suck GPU resources.

(You can do the palette lookup yourself in a shader if your GL implemention doesn't support such textures.)

Answer 3

Shared video memory does not mean that all the available RAM can be used for textures. Usually the graphics unit get's only a slice of the system memory, which is not available to the rest of the system at all. In your case that may be 128MiB. This kind of the same thing like the AGP aperture used by on board chipset graphics, or the framebuffer size of Intel Core integrated graphics.

Since OpenGL declares a purely virtual object model it must keep a copy of each object in "persistent" memory (the contents of the GPU's memory may be invalidated at any time, for example by VT switches, GPU resets, stuff like that), that's whats consumed from the regular system memory.