Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

BeanDog

Conserving vidmem - SYSMEM IS SLOW SLOW SLOW!

This topic is 6924 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have run out of video memory. My program will not start up now, because I just added a new 768x96x16bpp surface and it has exceeded all the available vram. It runs when I set all my surfaces to system, but it is SO SLOW!!! Now I am pretty darn sure that the surfaces I have are not taking up all 16mb of that there memory. How can I fix this problem? Blt''s from SYSMEM ARE REALLY REALLY REALLY SLOW!!! ~BenDilts(NULL* Intelligence); Bean Dog

Share this post


Link to post
Share on other sites
Advertisement
What resolution are you using for your primary surface and back buffers? How many other surfaces are you trying to put in vidmem and what are their resolutions?

You can keep an eye on available video memory with lpdd->GetCaps(&helcaps, &halcaps) and then looking at halcaps.dwVidMemTotal and halcaps.dwVidMemFree.

aig

Share this post


Link to post
Share on other sites
Yes I possibly could. I have 4 128x32x16bpp surfaces for terrain, about 6 variously sized ones from 256x128 to 768x96 for units, a main one, a back buffer, an extra 640x480 one for a terrain layer so I don''t have to redraw it every frame, and about a half dozen others.

Share this post


Link to post
Share on other sites
yes u are true
i tested:
vram to vram blits=25 queryperformance counts
sysmem to sysmem blits=8000 counts
sysmem to vidmem blits=7000 counts
and i have a p2/400 voodo3
so u see it is slow
problem is u cant setup all surfaces in vidmem esp when u are doing large 800x600 2D graphics

So what ca u do?
Not much:
1.Reduce resolution.... why do i think u will not
2.Never blit from vidmem to sysmem ...this is more slower
3.blit directly to primary..and save backbuffer...but some artifacts may show depending on videoboard
4.write ur own ASM blit for sysmem to sysmmem ... i can do it in aprox 800 counts then only one blit from sysmem to vidmem.... now do u use ASM? dont u? hmm i think C
5.Cache surfaces to vidmem when u can like terrain until u do a scroll ... like current caracters on screen...
not funny at all
6.Ask users to buy 64Mb videoram and make rich Micro$/3dfx

Ooops dont know what else...
Hope to hepl
PS.if anybody found better solutions pls let me know

Share this post


Link to post
Share on other sites
There are a few ways which you could use to save vid mem.

-First check if your GFX card supports DXT texture formats. If so, just use those since it reduces textures to about 1/4 of original mem footprint. Then simply call blt as normal and the card will decompress them on the fly
-Use AGP memory to store your surfaces (if your card supports it). Some cards might be a ble to blt directly from AGP without any penalty, some though will have reduced capablities if bltting from AGP, but it will still be better than sys mem.
-Use palettized surfaces. This should reduce your surfaces memory footfprint by 2, since it looks like you are using 16bpp, and palletized modes use 8bpp. (This will reduce the ''beauty'' of the images though(
-Try this:
Before creating any surfaces, get the amount of free vid mem.
Create 1 surface, and calculate how much you ''think'' the surface uses. Then get the free vid mem again, and check if your estimate was good or way out.
The repeat for all the other surfaces.
Try printing the mem results to a log file.
Then try the same again, but this time create the surfaces in a different order, and check your results.
Sometimes the creation order can make a difference because of memory fragmentation in the video card and other alignment issues.

-Try reducing the size of your surfaces by say 1 pixel at a time, until they fit (reduce the size of the largest surfaces first). This way the data loss will be minimal, and if your GFX supports blt stretching, you can simply blt to the size you want, and you will probably not notice any difference (depending on how much you reduced the surfaces).

I am sure there are other techniques, but my mind has gone blank now. Hope that helps...

Share this post


Link to post
Share on other sites
Ok, first of all, bogdanontanu''s numbers are VERY misleading. The video-to-video numbers he quoted are obviously just SETUP time for ASYNCHRONOUS blits, meaning YES they free up lots of CPU power to be used elsewhere, but they do NOT allow you to render THAT many more images to the screen per second. I''ve seen figures of a 2-3X performance difference between vid-vid and sys-vid blts. He was correct though about vid-sys, which are often 2-4X slower than sys-sys or sys-vid. So DO NOT ever put a surface in video memory that will be used as a source for bliting to a system memory buffer.

Second, I would recommend you think about each of your surfaces as having a rating, such as "average blts per frame" and then create a 2 dimensional graph using "average blts per pixel" and buffer size as your two dimensions. Then favor things in the SMALL and HIGH USAGE corner first, then extend your range toward the MID SIZED, HIGH USAGE direction. In conparing a group of small buffers to a single large one, consider the groups size to be it''s total, and ALSO consider it''s usage rating to be the total of the ratings. The reason for this is that the more blts that can be done asynchronously the better, and that the agp/pci bus is better at sending 1-2 large transfers than setting up and resolving 10-20 small ones. So as a recap, favor high use, small buffers for vid memory, and favor lower use larger buffers for video memory.

In YOUR particular case, i believe you will probably find that you want the terrain sources AND buffers in video memory, but you can put the units / building tiles in system memory. Second, when running low on video memory (since you are probably going to target 4MB and larger cards), leave the terrain BUFFER in video memory, but more the source tiles to system memory.

Good Luck

Share this post


Link to post
Share on other sites
What exactly is the frame rate difference between vid mem and system memory?

Try putting your buffers in Videomem (you have to specify) then bltting textures in sysmem, and a final blt to videomem, it''s slower, but faster than some other alternatives...

If the app is to be distributed:
btw, your texture sizes are just simply unrealistic if you expect the game to run on others'' machines. There are still computers that only have 2mb video mem. Maybe you could make a tile engine?

Share this post


Link to post
Share on other sites
I''m not convinced that reserving 600k of video memory just to avoid redrawing every frame is doing you much good. After all, you are obviously having to redraw a fair amount each time anyway when you take units etc into account. And if freeing up that extra 600k (probably more like 960k when you take pitch into account) allows you to fit all you need into video memory, then you will probably see a performance increase, even drawing the whole thing each frame.

Other ideas:

Why are your other surfaces such irregular sizes (eg. long and thin)? Maybe you could alter some of the units surfaces to the next power of 2 downwards in terms of width, extending the height to compensate, to see if that saves memory?

Do you always need all unit surfaces to be in memory at all times? How about a load-on-demand function? Is it perceivable that certain surfaces might never be used in a given level/zone/whatever, and therefore might not be loaded?

Either way, relying on a 16mb video card is not going to get you very far if you care about distributing your game, so you need to find some way of either reducing the size/amount of your surfaces, or prioritising them (even if those priorities may change in real time).

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!