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 ...
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
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.
GLIM - Immediate Mode Emulation for GL3
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 ?
Do you know a method to retrieve available agp memory ?
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.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.
Scott S.
www.southurst.id.au
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.
GLIM - Immediate Mode Emulation for GL3
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).]
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).]
I'm assuming you are uploading GL_RGB or GL_BGR texture?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 ...
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.
------------------------------
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
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? :-)
"If you can't afford to do something right,
you'd better make sure you can afford to do it wrong!"
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...
Posting Permissions
