Is there a limit to how much VAR mem you can allocate?

I’ve read the papers but they’re confusing. I don’t know which is vid mem and system mem…in fact I’m not even sure you can allocate system mem. I do know that the block of mem you allocate has to be continues(I think that’s the right word). In other words the mem cannot be broken up.

Aaron Taylor

The amount of video memory you can allocate depends on the amount of video memory your vid card has and has available. If the allocation fails for for video memory, then you should try and allocate AGP memory which is in your system ram but its uncached. So because its cached, you have to write to it sequentially and it will have bad read access. Meaning if you have to pull the data from there to your program to do stuff to it will be slow, but the transfer from AGP mem to he card will be fast.

in fact I’m not even sure you can allocate system mem.

Easy, here is how:
GLfloat *data = new GLfloat[size_you_want_to_allocate];

The thing that sucks about having your vertices in system mem rather than agp or vid mem is that all the data has to be copied over the bus every frame so that can create a slow down if you have lots of data. AGP has to be copied from the mem to the card also but its setup where its a bit faster.

If that is not completly accurate, someone please correct me.

-SirKnight

Ah, I see where I was unclear now! AGP memory is on the motherboard. So system memory and AGP memory use the same RAM chips. So, if I’m correct, AGP mem is only used when the Video memory won’t allocate enough specified memory.

LOL SirKnight! Of course I know how to allocate with new. I laugh 'cause I wouldn’t even be posting here if I didn’t .

…so doesn’t that mean that AGP mem uses that 2x or 4x or whatever multiplier thingy that your motherboard supports?

Just a while ago I tried modifying the Var data…and boy is that slow(as you said it would) . So you still have to use system ram when you want to deform meshes realtime . So the moral of the story is that VAR is best used for static geometry.

Oh yeah, the Var mem I was messing with was the Color array. I was testing to see if I could still modify the color vertices to use for bumpmapping.

In my opinion, it would be better to use video mem for your static geometry (for performance issues)
Anyway, if you want to know the available memory available on the card just try to allocate a certain amount of video memory and if it fails try again with less mem…
->
if (pFastMem != NULL){
glDisableClientState(GL_VERTEX_ARRAY_RANGE_NV);

	wglFreeMemoryNV(pFastMem);
	pFastMem = NULL;
}

for (i=0; (i < vrMaxCacheVerticeSize) && (pFastMem == NULL) ;i+=1024){
	cacheSize = vrMaxCacheVerticeSize-i;
	pFastMem = wglAllocateMemoryNV(cacheSize,0.f,0.f,1.f);
}

if (pFastMem == NULL){
	for (i=0; (i < vrMaxCacheVerticeSize) && (pFastMem == NULL) ;i+=1024){
		cacheSize = vrMaxCacheVerticeSize-i;
		pFastMem = wglAllocateMemoryNV(cacheSize,0.25f,0.25f,0.70f);
	}
	if (pFastMem == NULL){
		return VR_FALSE;
	}

	return VR_FALSE;
}

hth

I found an interesting thing - I’ve always been unable to allocate more than 64mb of agp memory - it just fails. My aperture size is set to 128 in the bios. Now, I’ve downloaded PowerStrip, which reports that my aperture size is 128, but immediately below that number is another (undocumented) figure called “System memory available” which reads 68.4mb. This is all in the AGP section of powerstrip - so why does it read 68.4mb and not 128mb? This is obviously related to me not being able to allocate more than 64mb in opengl.

[This message has been edited by knackered (edited 04-08-2002).]

So because its cached…

Opps, i meant UNcached. Sorry for any confusion.

-SirKnight

how do you like this:

uint MeasureVARMemory(float fMemType)
{
   // 1 GB should be enough for anybody  [img]http://www.opengl.org/discussion_boards/ubb/smile.gif[/img]
   uint iSizeHi = 2 * 1024 * 1024 * 1024;
   uint iSizeLo = 0;
   uint iResult = 0;

   while ( iSizeHi - iSizeLo > 1024 )
   {
      const uint iSize = (iSizeHi + iSizeLo) / 2;
      const PTR pMem = wglAllocateMemoryNV(iSize, 0, 0, fMemType);
      if ( pMem )
      {
         wglFreeMemoryNV(pMem);
         iSizeLo = iSize;
         iResult = iSize;
      }
      else
         iSizeHi = iSize;
   }

   return iResult;
}

on my system (aperture 128M, 28.32) i get even 32M agp or 32M video.

Originally posted by SirKnight:
The thing that sucks about having your vertices in system mem rather than agp or vid mem is that all the data has to be copied over the bus every frame so that can create a slow down if you have lots of data. AGP has to be copied from the mem to the card also but its setup where its a bit faster.

Huh? AGP memory is system memory.

Without AGP memory, transfers will go at PCI-66 speeds (roughly AGP 1x).

  • Matt

Be aware, though, that although you request video memory, what you might actually get is agp memory. The only failsafe way to find this out is looking at write speeds…

Michael

I haven’t timed the difference between VAR in cached memory and VAR in AGP memory with copying in ages. Last time I tried, it, AGP+copying was no worse than cached memory and no copying. Perhaps these days, it’s actually better!

Huh? AGP memory is system memory.

Uh, yes i know that, i even stated that in my first paragraph. Please re-read it. I guess how i worded that quote of mine may have been kinda confusing. O well.

Hmm, but even then, i dont see how you thought i was saying AGP mem wasnt in system mem. After me saying in the first paragraph that AGP mem is in system mem but the diff is that its uncached would have made that quote you posted make more sence. O well, we all dont think the same way i guess.

-SirKnight

[This message has been edited by SirKnight (edited 04-09-2002).]

In my opinion, it would be better to use video mem for your static geometry

If your application is fill rate limited, then pulling vertex data from VRAM and pulling texture data from VRAM and writing framebuffer data to VRAM all at the same time doesn’t seem like the best way to structure things. Modern hardware can pull data from AGP at the same time as it’s pulling texture data from VRAM, thus vertex data in AGP is faster in this case.

If you’re NOT fill rate limited, then you should be figuring out how to get there, as you’re under-utilizing available hardware :slight_smile: