agp and video memory

I am using the VAR extension to render my geometry. I would like to load all (or at least the most critical) of my static geometry into video memory, and the dynamic geometry into agp, due to more frequent writes.
However, VAR only allows one range of memory to be set, and calling VAR causes a flush, which really slows things down, so I can’t call that frequently (preferably not at all in the render loop).
Is there any way of achieving this so I can get the benifit of the extra speed from the video memory for static geometry, without the write penality for dyanmic geometry.

(Dare I say it, but I can do this in DX using vertex buffers).

Two possibilities.

You can put all the static data in display lists, which should be stored in video memory.

Or you could allocate one portion of AGP memory and use one part of it for static data and one part for dynamic data. Apparently AGP memory will be as fast as video memory in many cases.


On the tests I have done so far, rendering 122000 polys of static geometry in agp will get me around 9394000 polys per second, while in video memory I get around 12810000. That is about a 36% increase.
Based on this, I have a strong desire to use as much video memory for static geometry as possible.

j has given you a pretty good answer: use VAR for your dynamic geometry and use display lists for static. You’re not going to be able to use both video and AGP memory through VAR. Also, display lists may not be as fast as VAR in AGP memory, so you might even want to use VAR for everything.

AGP memory and video memory - what’s the difference?

AGP memory is system memory that a graphics card is given permission to access directly. Video memory is memory on the actual graphics card.


I tried to do exactly the same thing as kerryh… but it’s somewhat complicated…

First, I used wglAllocateMemoryNV to allocate AGP memory, and then AllocMemNV again, but this time with video memory. Then, I just have to render the geometry in the AGP buffer, use wglVertexArrayRangeNV to select the vidmem buffer, and render the vidmem geometry… but changing the VAR every frame is VERY slow, and you’ll have to re-allocate the vidmem buffer, reload geometry, etc, if the user changes the video mode (as happens with textures in video memory).

Anyway, what kerryh says is true, rendering using video memory is +30% faster than AGP or Display Lists (It seems that Display List uses AGP memory).

  • Royconejo.

PS: Sorry for my bad english

Can someone tell me his/her readfreq, writefreq and priority values for AGP alloc with wglAllocateMemoryNV ? I can allocate video mem but, since i have to read a lot, the FPS drop serverly with this :frowning:

I believe calling VertexArrayRange() will do more than just flush the card. From the time it takes, I expect they are calling into the kernel to lock down memory ranges and set up scatter/gather tables for the card. Thus, VAR may be somewhat orthogonal to AllocateMemory(), as the latter would allocate less fragmented, more coherent AGP memory. This is just guessing, though.

holocaust: if you need to read the memory back, you should not use AGP or video memory. If vertex data transfer is still your bottleneck, you may be able to do your operation on a copy in regular memory, and then run a big copy loop into AGP memory and render from there.

I agree with kerryh that allowing two different VertexArrayRange() areas to be effective, or just always allowing data to come from on-card RAM even if it’s outside the array range, would be very useful. You may even have some arrays (say, texture coordinates) that don’t change, whereas others (vertex position) would change for each frame. Why not allow the static data to sit in the fastest available memory?