PDA

View Full Version : Using 256Mb memory video cards



Alessandro_dup1
07-13-2003, 01:33 AM
Hi, i own a 128Mb nvidia Ti4200 card on a AGP8x bus, and doing some testing i have seen that loading a texture of 4096x4096 (about 48Mb) takes a quite long time (about 35 seconds). So i was wondering what's the use to have 128 or 256Mb cards: if we want to store display lists or several textures up to their size it will take about 3 minutes to load ...

Jan
07-13-2003, 01:41 AM
Usually newer cards do not only have more memory, but also faster memory.
That means on a 256MB card it wonīt take 3 minutes, but only 2 http://www.opengl.org/discussion_boards/ubb/wink.gif
Well, thatīs still a lot of time, but this is done only once, and than you can render beautiful, hi-res worlds pretty fast, which might be a problem, when the stuff every frame has to be transfered over AGP.
And if you are one of the guys, who donīt want the user having to wait that long, than you could still create a system, which first loads the vey important data, than starts rendering but still keeps on loading the less important data. This way one might only have to wait 10 seconds or so (take a look at Dungeon Siege, if you are interessted in this).

But honestly, i donīt think that in near future games will need more than 64 or maybe 128 MB of memory. But then we will see.

Jan.

Alessandro_dup1
07-13-2003, 01:52 AM
Thank you Jan, yes i have to agree, what is after all 2 or 3 minutes if the engine is then showing in all its beauty ? http://www.opengl.org/discussion_boards/ubb/smile.gif
Do you know a method to retrieve available agp memory ?

rgpc
07-13-2003, 02:44 AM
Originally posted by Jan2000:
But honestly, i donīt think that in near future games will need more than 64 or maybe 128 MB of memory. But then we will see.


UT2K3 can benefit from a 256Meg card. There's an option in the texture details menu that was hidden because the cards at the time (128Meg) weren't big enough.

Jan
07-13-2003, 03:45 AM
In OpenGL there is no way to get the amount of available Video or AGP memory. You can use some tricks (uploading as much data as possible, and check if they are "resident") but this takes a lot of time and isnīt really efficient.
However getting the available AGP memory might be possible (cause that has something to do with BIOS settings, not OpenGL), but i donīt know how. And certainly it will be different on every OS.

Jan.

MZ
07-13-2003, 04:06 AM
48MB at 35 seconds = 1.3 MB/s

This is what I've just measured on my GF3, 32 MB VAR "video" memory block:
writing speed = 190 MB/s
reading speed = 8.2 MB/s

So, writing full 256 MB, taking faster memory into account, should theoretically take ~0.5 second... ??

Maybe your low speed happens only because of using extremally large texture, what probably forces driver to optimize layout of objects already loaded in memory, and move large blocks around. If this is performed on CPU side...


[This message has been edited by MZ (edited 07-13-2003).]

Shag
07-13-2003, 05:13 AM
I think he's talking about loading from the hard disk.

Edit - can't spell

[This message has been edited by Shag (edited 07-13-2003).]

V-man
07-13-2003, 05:49 AM
Originally posted by penetrator:
Hi, i own a 128Mb nvidia Ti4200 card on a AGP8x bus, and doing some testing i have seen that loading a texture of 4096x4096 (about 48Mb) takes a quite long time (about 35 seconds). So i was wondering what's the use to have 128 or 256Mb cards: if we want to store display lists or several textures up to their size it will take about 3 minutes to load ...

I'm assuming you are uploading GL_RGB or GL_BGR texture?

Try GL_BGRA. It will be 64MB but it will probably be faster.

It could be that some work must be done on the CPU with the RGB data.

Anyway, try to match the cards internal format and perhaps upload pre-compressed textures.

jwatte
07-13-2003, 03:33 PM
If you're telling the card to compress the data on the fly, texture upload will be REALLY SLOW. And quality won't be great. Pre-compress using a high-quality compressor, if you want to use compressed textures.

I see no reason that uploading a 4096x4096x4 texture should take 35 seconds, assuming it's supported by the hardware (what is the reported max texture size ?) That's 64 MB of I/O though -- perhaps your hard disk is really old, or really fragmented, or somehow running PIO mode instead of DMA mode? Or are you loading this over a network? CD-ROM? Modem? :-)

Obli
07-14-2003, 07:39 AM
I think 128+MB on a video card is useful to do real time textures. You know, pbuffers and this kind of stuff.

Passing thuru hd and agp is a real pain. Looks like Pixel data range can speed up this a lot however textures must be read from from HD and this is the worse problem in my opinion. I'm doing some research on this problem that may turn out interesting...

jwatte
07-14-2003, 09:22 AM
A modern UDMA drive should pull 10 MB/s from the file system, even on a bad day. If you're getting much less than that, your system needs a tune-up, de-fragmentation, or a new hard drive.

Of course, if you target 5 year old hard drives, those were lucky to get to 5 MB/s on a sustained basis (necessary to do DV25 recording).

You probably want to load texture data and geometry data from disk into memory in a background thread, so that you can load what's immediately necessary to display to the user first, and as soon as that's available, load everything else in the background while staying interactive. Disk load takes no CPU, so that shouldn't be a performance hit at all. If you do this, I suggest putting loaded data into a queue, and uploading data from the queue to GL each frame from the main thread; don't try to multi-thread the GL (you can theoretically multi-thread, but it's not necessary and it's fairly hard to get it to be solid and well performing).