Maximum total size of vertex arrays via ATI_vertex_array_object?

OpenGL OpenGL: Advanced Coding
1

Just revisiting this question in hopes it’ll find an answer. . .

I’m putting a huge amount of vertex data into vertex and element arrays via ATI_vertex_array_object and am running into OUT_OF_MEMORY errors. I’m just why it is that with a 128 MB video card I should be having this problem at all. It appears to start when I go beyond 30 MB of data.

2

The driver does limit allocation sizes, to prevent it from being overloaded by a large block of locked down memory. For instance, allocating an overly large chunk can prevent the driver from doing a good job of managing textures in the future.

I believe you are likely hitting the max single allocation limit. You should be able to allocate more if you use multiple blocks. If you still can’t get more, you may want to update your drivers. You also may want to see if AGP memory is working on that system, as it may be limiting you to X% of all the memory it has to work with.

If you still see an issue mail devrel@ati.com.

-Evan

3

Why are you putting 30+MB of data in one array? What are you doing that has that much vertex data associated with it?

4

I would assume VAO memory to live in AGP memory, not VRAM. Your available AGP memory allocation may be limited by any of:

  • available contiguous physical RAM (unlikely)
  • available AGP/GART mappable RAM
  • OS physical RAM allocation policy
  • total RAM size of the machine
5

VAO can be in either VRAM or AGP. The driver will make a decision about where is best based on the system. A big advantage to systems like VAO over something like VAR is that the user never has a persistent pointer, and the driver is free to switch the location if desirable.

-Evan

6

Thanks for responding, Evan!

I’m actually not putting that much data into a single array, though. I’m creating a heightmapped terrain engine based sorta off of what was done with Morrowind. Each 256x256 section is put into a single vertex array. Then, an octree for each section is generated and element arrays are created for each node. Thus, I’m not using all 30 MB for a single array.

Even in my first post regarding this problem (with the 640x640 section of terrain), the vertex array took up only 17.2 MB. Upon increasing to a 650x650 section of terrain, at which point the OUT_OF_MEMORY error appears, the array is 17.7 MB. Hmm. . . it appears I was wrong about something, though. With the element array, that 650x650 terrain section takes up only 27.4 MB, so the OUT_OF_MEMORY error appears before I even get to 30 MB. . .

I’m using the latest official drivers: Catalyst 3.0, dated 10 January, 2003.

EDIT: Oh, and my AGP aperture size is set to 256 MB (I think. . . at the very least it is 128 MB).

[This message has been edited by Ostsol (edited 02-06-2003).]

7

For a long time there was a 32 Mb limit in the Nvidia drivers; only recently this has been fixed. You can allocate 200 Mb of AGP memory if you want now. Just to say that i wouldn’t be surprized if ATI had a driver limit too.

Y.

8

Originally posted by Ostsol:
Thanks for responding, Evan!
Even in my first post regarding this problem (with the 640x640 section of terrain), the vertex array took up only 17.2 MB. Upon increasing to a 650x650 section of terrain, at which point the OUT_OF_MEMORY error appears, the array is 17.7 MB. Hmm. . . it appears I was wrong about something, though. With the element array, that 650x650 terrain section takes up only 27.4 MB, so the OUT_OF_MEMORY error appears before I even get to 30 MB. . .

Vertex layout, please

9

Um. . . do you mean my vertex format?

struct MVertex
{
	float coords[3];
	float colour[3];
	float normal[3];
	float texcoord[2];
}
10

Originally posted by Ostsol:
[b]Um. . . do you mean my vertex format?

[quote]

struct MVertex
{
	float coords[3];
	float colour[3];
	float normal[3];
	float texcoord[2];
}

[/b][/QUOTE]Yes, that’s what I meant. I thought that maybe some fancy padding comes into play and might reduce your usable vertex memory.
Doesn’t look like it. The only (minor) gripe I have with your vertex format is your use of 3 floats for color. Shouldn’t introduce any padding though. Have you tried
a)4 floats
or
b)4 unsigned bytes
?
If you need high dynamic range, forget about b.

11

Well, I could technically use 4 unsigned bytes for colour, or even three since for terrain I don’t exactly need an alpha component. It’d reduce my vertices memory footprint by a little over 20%. Still, this doesn’t not help me overall; I still need to be able to put more vertex data into vertex arrays.

12

Damn. Problem still exists with the Cat 3.1 drivers.

13

Ostsol - I am using VAO in a similar tiled heightfield approach. Rather than out of memory errors, some of my vertexes (the ones at the end of the array) on larger heightmaps appear incorrect - they form a “banded wall” all clustered together.

Anyway - how are you retrieving your “Out of Memory” error - Is there a specific API call like getLastError() that I can call?

Thanks for any help…