From ram to vram

BlitzMax Forums/BlitzMax Programming/From ram to vram

VinceA(Posted 2008) [#1]
Large animations!

I am looking for a way to handle large animations without overflowing the vram. The animations are a series of png’s in a folder (not a strip).

My current thinking is to first load and store all the images in the system-ram and then real-time load it from ram to vram on a need to show basis.

Is this a good approach?
And how can be implemented (ram -> vram)?


tonyg(Posted 2008) [#2]
BMAX does this for you anyway. The first load goes to sram and, when you drawimage, it is sent to vram. That's why there is a slight delay when drawing an image the first time.
The DX driver uses the DX memory cache manager replacing least used surfaces.
What I have done is created a resource manager where each resource has a 'keep cached' priority attached. At set points I draw the resource to ensure it has a good chance of being in VRAM (i.e. before a section which will use it).
Hope it helps.


VinceA(Posted 2008) [#3]
Thanks, very helpful!
So is it something like this.. Or am i doing too much.

I want to insure that only the currImg is in the Vram

Local images:TImage[]
images:+[LoadImage("img00.png") ]  
images:+[LoadImage("img01.png") ]  
images:+[LoadImage("img02.png") ]  


Local frame:Int = 0


SetGraphicsDriver D3D7Max2DDriver()
Graphics 512,512


While Not KeyDown(KEY_ESCAPE)
	Cls
	SetColor 255,255,255
	SetBlend AlphaBlend
	
	frame = (frame + 1) Mod Len(images)
	
	Local currImg:TImage = New TImage
	currImg = images[frame]
	DrawImage currImg,0,0 
	currImg = Null
	
	Flip 1
Wend
End



tonyg(Posted 2008) [#4]
Don't know how OGL manages VRAM but it *will* load every drawn image from RAM to VRAM and, afaik, you cannot remove it. I have only checked the source for DX which will remove or replace unused surfaces when a threshold is reached on the 'last-used/least-used' basis.
<EDIT> What I am trying to say is that you can decide when to move them from RAM to VRAM (by drawing them) but cannot decide when to get them out of VRAM.


VinceA(Posted 2008) [#5]
Actually i meant to do it DX the OGL is just a mistake.

Ok i see.
It is a problem if I can't remove stuff from the vram. My app crash when it draws to many images.
Can i manually set the vram limit in DX ?


tonyg(Posted 2008) [#6]
You app shouldn't crash. It might affect performance if you're drawing lots of images as it deletes old surfaces and moves new ones in but it should n't crash.
Using OGL I *THINK* you get white rectangles when you have filled VRAM but even then it doesn't crash.


VinceA(Posted 2008) [#7]
Ok thanks alot, i will run a test again, and hope that it i something else that made it crash.

BTW; I know it sounds a little strange with so extensive animations, but i am trying to port some childrens flash games. And they like thier animations!! ; )


tonyg(Posted 2008) [#8]
They do,. Consider the max size of the textures your graphics cards can handle as well. Lots of large textures takes its toll on memory.


MGE(Posted 2008) [#9]
Here's one for the VRAM gurus....

What happens in this scenario? (Using pseudo syntax)

global Myimage.TImage

For x=1 to 1000
cls
MyImage.Load "filename"+x+".jpg"
MYImage.Draw
Flip
next x

Has 1000 textures been created by the GPU or is only one being used and reused each frame update?


tonyg(Posted 2008) [#10]
A new surface is created each time because the base image changes. The other,redundant, surfaces will remain in VRAM until the caching algo decides they haven't been used recently enough.


MGE(Posted 2008) [#11]
Anyway to adapt the above code so only 1 surface is used/reused?


MGE(Posted 2008) [#12]
And while we're at it, how would we "flush" or destroy all current GPU created surfaces?


ImaginaryHuman(Posted 2008) [#13]
Cant you just do loadpixmap and drawpixmap? If you don't need to keep the image in video ram then the transfer TO video ram can be combined with the draw to the backbuffer, rather than transferring it to an image (which takes the same time as transferring it from a pixmap). Might possibly be faster. You could load all of your pixmaps for all images into main memory and then just drawpixmap one frame at a time.


MGE(Posted 2008) [#14]
Actually, I'm just trying to apply this to my normal game engine. In DX mode, this is not a problem because of the managed handling, but in OpenGL you don't have texture management so once you fill up vram you apparently get white squares? So I was just wondering if the above loop (cycling through 1000 images) would eventually start displaying white squares?


ImaginaryHuman(Posted 2008) [#15]
Like I said use pixmaps, you don't even need to keep a copy of each frame in video ram, unless you want to pre-load a whole bunch of frames and have them play back at maximum framerate.


Grey Alien(Posted 2008) [#16]
but in OpenGL you don't have texture management so once you fill up vram you apparently get white squares
Surely this is not true? Guess you can test it with your code.


MGE(Posted 2008) [#17]
I started a thread in the beginners section about the texture management issue.


ImaginaryHuman(Posted 2008) [#18]
"but in OpenGL you don't have texture management so once you fill up vram you apparently get white squares"

I don't think that's true, but maybe the driver on some machines handled it that way. I've seen images still work as normal when video ram is full, due to stuff getting spooled off to main memory.