PDA

View Full Version : Video Card Memory Management



JRGlide
02-05-2010, 09:33 AM
I have a program to display point cloud data and am researching the idea of using VBOs to speed up the display. The catch is that I could be displaying 10-30 million points. Each point requires 28 bytes for the point and color data. That means that 10 million points would require 280 meg of video RAM; 20 million points would require 560 meg of RAM, and so on.

I read an older question found here:

www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=243993&fpart=1 (http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=243993&fpart=1)

that says that the video card breaks up the memory into chunks and I may only have 256 meg available. However, this posting is also several years old.

So my question is does this limit still apply? And is there a way to find out how much memory is available and how big the chunks are? Am I am trying to use the video card beyond what it was intended?

I already am using Vector Arrays. One way to get around this problem is to use decimation instead of VBO's and only display part of the data while rotating. Would this be a better approach?

Thank you for any insites.

Stephen A
02-05-2010, 09:53 AM
On a modern OS like Vista or Win7, video memory is virtualized and will be paged in/out as necessary. This won't happen on XP however, and you may get out-of-memory errors.

Decimation could help and can be used along with VBOs for fast rendering.

You can also use multiple passes reusing the same VBOs (i.e. updating the VBOs between rendering passes).

Finally, if your target hardware supports shaders, there are ways to compress the VBOs and decompress them on the fly during rendering. Depending on the required precision, you could get away with 8-12bytes per point.

Ilian Dinev
02-05-2010, 10:18 AM
I had posted here some tests+ bench results, on using i.e 1GB texture-memory on a 256MB VRAM GF8600, WinXP, 2GB sysRAM. (but it's texture-memory, it's possible vtx-data is handled differently) . That same test was crashing on a 512MB VRAM Radeon2600XT, WinXP, 1GB sysRAM (paging file 1.5GB). Later, another test if 2 apps could load and use 2GB of FBOs each, on GTX275 896MB VRAM: success, 5.1GB peak system allocation (winxp 32-bit, 2GB sysRAM...);

Alfonse Reinheart
02-05-2010, 11:53 AM
Each point requires 28 bytes for the point and color data.

Unless your positions are doubles (in which case make the floats. You're not losing anything; doubles are not directly supported in hardware... yet), I'd be interested to see how exactly that works.


Finally, if your target hardware supports shaders, there are ways to compress the VBOs and decompress them on the fly during rendering. Depending on the required precision, you could get away with 8-12bytes per point.

You don't need shaders to do some basic compression. glVertexPointer can accept shorts just fine. A little matrix fiddling, and you should be OK. But yes, if you want to get really fancy with compression, you'll need to use shaders.

JRGlide
02-05-2010, 12:26 PM
Thank you for the responses.

The reason the data is 28 bytes per point is that I am using floating point for the data and floating point RGBA for the color.

I could convert the data to shorts as suggested by applying a scaling factor. Unfortunately, the data can come from multiple sources as shorts or floats. And if the data is UTM data then it comes in as doubles. But by using an offset and scaling factor I could convert that to floats or even shorts.

The reason I am using RGBA is that I'm using the alpha data for filtering the data using the glAlphaFunc. That way I can filter the data by simply changing the alpha value rather than make multiple copies of the data (like I was originally doing).

I could easily use unsigned char for the RGB data and cut its size by 1/4. The only reason I am using floats is that I read that internally GL uses floats and there was an overhead penalty converting the data from unsigned char to float. Is this a valid concern, or is the penalty small?

Stephen A, you mentioned making multiple passes using the same VBOs. I'm not sure I understand what you are saying. If I pass part of the data into a VBO and then pass in the other half, it seems like I'm defeating the purpose since I am still passing data. Maybe you are saying to create multiple VBOs, each one being 256 Meg in size (or whatever the limit is). Is that what you are suggesting?

And finally, how are you making these Quote Boxes? I don't see anything that lets me do that.

Thanks again.

Alfonse Reinheart
02-05-2010, 01:53 PM
The only reason I am using floats is that I read that internally GL uses floats and there was an overhead penalty converting the data from unsigned char to float. Is this a valid concern, or is the penalty small?

There is no penalty. You probably read something very old.

Furthermore, even if there is, cutting down memory usage would allow your code to work. Being able to draw, but draw slightly slower, is still better than not being able to draw ;)

Get it working first. Optimize later, and only if you need it.


And finally, how are you making these Quote Boxes?

You use tags. Like [ quote ] and [ /quote ] (but without the spaces). Or you press the "switch to full reply" button and press the button that looks like a double-quote.

Dark Photon
02-08-2010, 06:21 AM
And finally, how are you making these Quote Boxes? I don't see anything that lets me do that.
For a list of all these little formatting tips, click FAQ (http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=faq) up in the menu bar, search down for UBBCode, and click the "+" sign. The most useful tag "quote" is at the bottom, of course. ;)