Gamestudio Links
Zorro Links
Newest Posts
Zorro Trader GPT
by TipmyPip. 03/06/24 09:27
VSCode instead of SED
by 3run. 03/01/24 19:06
Deeplearning Script
by wolfi. 02/26/24 12:46
Sam Foster Sound | Experienced Game Composer for Hire
by titanicpiano14. 02/22/24 16:22
AssetAdd() vs. modern asset list?
by jcl. 02/21/24 15:01
How many still using A8
by Aku_Aku. 02/20/24 12:18
AUM Magazine
Latest Screens
The Bible Game
A psychological thriller game
SHADOW (2014)
DEAD TASTE
Who's Online Now
1 registered members (1 invisible), 610 guests, and 7 spiders.
Key: Admin, Global Mod, Mod
Newest Members
sakolin, rajesh7827, juergen_wue, NITRO_FOREVER, jack0roses
19043 Registered Users
Previous Thread
Next Thread
Print Thread
Rate Thread
Page 4 of 10 1 2 3 4 5 6 9 10
Re: video memory and d3d_texfree [Re: Superku] #465400
04/24/17 16:38
04/24/17 16:38
Joined: Jul 2000
Posts: 27,977
Frankfurt
jcl Offline

Chief Engineer
jcl  Offline

Chief Engineer

Joined: Jul 2000
Posts: 27,977
Frankfurt
If you have a script that reliably produces an E_OUTOFMEMORY error, like your d3d_texbmaps script above, post it and I'll look into it. I can then at least identify with which texture or other object it happened.

Re: video memory and d3d_texfree [Re: jcl] #465403
04/24/17 19:33
04/24/17 19:33
Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Superku Offline
Senior Expert
Superku  Offline
Senior Expert

Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Uhh... I'm not sure what I'm doing and what those values mean exactly but I've tried a program called VMMap (which I found in some non-Gamestudio thread looking for E_OUTOFMEMORY) and looked at my game's (process's) address space ~ I guess.

Committed: This graph shows the committed (memory that represents data or code) memory usage of the process: 1.402GB

Working Set: This graph shows the working set usage of the process by memory type. Working set represents the amount of commited virtual memory that's in physical memory and owned by the process: 1.120GB

Summary of the virtual and physical usage of the process by type (like Image, Mapped File, Heap, Private Data, ...), "Total": 1.845GB

RAM usage according to the task manager: 1.050GB



When I now change the resolution (from 1920x1080 to 1600x1050), memory for the render targets is reallocated. I read somewhere that DirectX does not flush (?) memory immediately on "release", instead you need to flush the data manually if you really need to (let's say when you're low on memory). I get the standard E2005.
The values are now as follows: 1.489, 1.153, 1.920, 1.079GB. The second to last value looks a little alarming to me (esp. if contiguous or fragmented memory is important in this case, which I assume it is).
The acklog part (after all bmap_create instructions are done):
Quote:
MEMORY NOW (after all bmap creations): (nexus: 63.5/ 150.0) (sys_memory: 210.7) (d3d_texfree: 3963.0) (d3d_texlimit: 8192.0) (d3d_texbmaps: 73.7) (d3d_texskins: 4.3) (d3d_texsmaps: 1.7) (d3d_texsurfs: 0.1) (sum: 79.7MB) (GetAvailableTextureMem: 4280287232)
Error E2005: Can't create DirectX texture unnamed
D3D_TexCreate: 8007000e - E_OUTOFMEMORY



Is that one value, the "summary/ total" value the one that matters? And the RAM usage in the task manager "totally irrelevant"?
To make sure this is not project related (or because of a damaged file):
Click to reveal..
Code:
///////////////////////////////
#include <acknex.h>
#include <default.c>
///////////////////////////////

#define MAX_BMAPS 196 // start with the default nexus/ "run current script"
BMAP* test_bmps[MAX_BMAPS];

#define EXTRA_BMAPS 1
BMAP* extra_bmps[EXTRA_BMAPS];

#define MAX_VIEWS 64
MATERIAL* mat_chain[MAX_VIEWS];
VIEW* view_chain[MAX_VIEWS];

void createExtraBmaps()
{
	int i;
	for(i = 0; i < EXTRA_BMAPS; i++) extra_bmps[i] = bmap_create("test8MB.tga");
}

void switchResolution()
{
	video_mode = 10+(video_mode == 10);
	video_switch(video_mode,0,2);
}

void main()
{
	int i;
	fps_max = 60;
	video_mode = 6;
	level_load(NULL);
	me = ent_create(CUBE_MDL,vector(128,0,0),NULL);
	for(i = 0; i < MAX_BMAPS; i++) test_bmps[i] = bmap_create("test8MB.tga");
	
	wait(1);
	VIEW* view_prev = camera;
	for(i = 0; i < MAX_VIEWS; i++)
	{
		//mat_chain[i] = mtl_create();
		//effect_load(mat_chain[i],"blur_h_test.fx"); 
		
		view_chain[i] = view_create(0);
		set(view_chain[i],PROCESS_TARGET);
		//view_chain[i].material = mat_chain[i];
		//if(i < MAX_VIEWS-1) view_chain[i].bmap = bmap_createblack(screen_size.x,screen_size.x,24);
		
		view_prev.stage = view_chain[i];
		view_prev = view_chain[i];
	}
	on_1 = createExtraBmaps;
	on_space = switchResolution;
	while(1)
	{
		my.pan += 6*time_step;
		draw_text(str_printf(NULL,"sys_memory: %.1f",(double)sys_memory),20,20,COLOR_RED);
		draw_text(str_printf(NULL,"d3d_texbmaps: %.1f",(double)d3d_texbmaps),20,40,COLOR_RED);
		wait(1);
	}
}


There I create a ton of 2048x1024 (8+MB) textures to get the RAM usage above 1.6GB and the "summary/ total" value > 1.9GB. When I now press [Space] twice, E2005 happens. (Which seems somewhat reasonable to me that it errors here, except the difference of 600MB -task manager- compared to my real project.) Btw. if you just add additional bitmaps (with the createExtraBmaps()) function you get a (probably legit)
Error E1005: Out of memory.


"Falls das Resultat nicht einfach nur dermassen gut aussieht, sollten Sie nochmal von vorn anfangen..." - Manual

Check out my new game: Pogostuck: Rage With Your Friends
Re: video memory and d3d_texfree [Re: Superku] #465404
04/25/17 08:40
04/25/17 08:40
Joined: Jul 2000
Posts: 27,977
Frankfurt
jcl Offline

Chief Engineer
jcl  Offline

Chief Engineer

Joined: Jul 2000
Posts: 27,977
Frankfurt
I get no error with your script regardless of how often I press space, which indicates that it might be something different than insufficient memory. Maybe a certain render target size or format is not supported by your hardware.

For finding out, print GetAvailableTextureMem(). d3d_texfree works also, but is only updated once per frame. If it's really a video memory issue, GetAvailableTextureMem() should return a low value immediately before the error. If not, it's a system memory issue or something different.

Released memory is indeed not immediately flushed, but that should not be the problem since D3D has a memory manager.

Re: video memory and d3d_texfree [Re: jcl] #465405
04/25/17 10:00
04/25/17 10:00
Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Superku Offline
Senior Expert
Superku  Offline
Senior Expert

Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Originally Posted By: jcl
I get no error with your script regardless of how often I press space

Hmmm just tried it again and no error at first. However, I increased MAX_BMAPS gradually until I got an "Out of memory" error at start, then reduced it again (to 202) so it only gave me the DirectX error when pressing space. (Oh, it's a 32bit texture btw, 8.193MB.)

Originally Posted By: jcl
Maybe a certain render target size or format is not supported by your hardware.

Well those usually all work, no matter what I set the target to, except when there's a notable amount of stuff loaded into memory.

Originally Posted By: jcl
For finding out, print GetAvailableTextureMem(). d3d_texfree works also, but is only updated once per frame. If it's really a video memory issue, GetAvailableTextureMem() should return a low value immediately before the error. If not, it's something different.

Tried doing that as you can see in my previous post. The lowest value I ever got was still greater than 4.1GB. EDIT: Tried printing before and after manual bmap creation (not applicable in this test code), at the end of a frame and on_d3d_lost, on_d3d_reset).

Last edited by Superku; 04/25/17 10:01.

"Falls das Resultat nicht einfach nur dermassen gut aussieht, sollten Sie nochmal von vorn anfangen..." - Manual

Check out my new game: Pogostuck: Rage With Your Friends
Re: video memory and d3d_texfree [Re: Superku] #465407
04/25/17 15:21
04/25/17 15:21
Joined: Jul 2000
Posts: 27,977
Frankfurt
jcl Offline

Chief Engineer
jcl  Offline

Chief Engineer

Joined: Jul 2000
Posts: 27,977
Frankfurt
8 MB * 202 = 1.6 GB without mipmaps. So it the 4.1 GB can obviously not be right. Did GetAvailableTextureMem return 2.4 GB before the crash?

Re: video memory and d3d_texfree [Re: jcl] #465412
04/25/17 23:55
04/25/17 23:55
Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Superku Offline
Senior Expert
Superku  Offline
Senior Expert

Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Well I have 8GB of VRAM, not sure how that would work then. Therefore I've now grabbed my laptop with an Intel HD Graphics 5500, 3839MB shared system memory ("Gemeinsam genutzter Systemspeicher") - hopefully that doesn't make a difference in this case.
Same issue but with MAX_BMAPS = 212. Surprisingly, GetAvailableTextureMem() shows similar values here as well, and always > 4.0GB.
"Before the crash"
I put the call in the main function again, the switchResolution function, on_d3d_lost, on_d3d_reset, always > 4.0GB with only minor differences. I must be doing something wrong.
Tbh I'm majorly confused right now what I'm looking at or checking. Just for clarification:

Quote:
UINT GetAvailableTextureMem()
The function returns an estimate of the available texture memory. Remarks: The returned value is rounded to the nearest MB.

This is not true, right? Or is it? I assumed this was in bytes, as I get values like 4278190080 (which I just interpreted as 4,278,190,080 ~ 4.278GB). This value is awfully close to 4294967294, the range of uint (took the int range -2147483648 to 2147483647 from the manual, times 2). However, there's no unsigned int in lite-C - it's 4 bytes either way, so I guess %u interprets the bytes correctly.



So... back to the example/ test code:
I moved the bitmap creation into the main function like this:
Code:
if(num_bmaps < MAX_BMAPS)
{
	test_bmps[num_bmaps] = bmap_create("test8MB.tga");
	num_bmaps++;
}


sys_memory slowy builds up with each bitmap creation up until ~1641MB. However, d3d_texfree remains the same, that is the initial
Video memory found: 4094 MB (3838MB on my laptop)
minus 2MB (the nexus/ d3d_texbmaps). It just stays at 4092MB. GetAvailableTextureMem() always returns the same value, too (laptop and desktop). It only ever changes slightly when I change resolutions.
Just removed the render chain and this is what I got:
Click to reveal..
Quote:
D3D_DrawPrimitive: D3DERR_INVALIDCALL at 0.393
switchResolution() at frame 149: (GetAvailableTextureMem: 4290772992)
D3D_Resize Window: 1440x900
on_d3d_lost_event() at frame 149: (GetAvailableTextureMem: 4291821568)
on_d3d_reset_event() at frame 149: (GetAvailableTextureMem: 4284481536) -> Window: 1x1440x900x32
D3D_DrawPrimitive: D3DERR_INVALIDCALL
switchResolution() at frame 175: (GetAvailableTextureMem: 4278190080)
D3D_Resize Window: 1680x1050
on_d3d_lost_event() at frame 175: (GetAvailableTextureMem: 4279238656)
on_d3d_reset_event() at frame 175: (GetAvailableTextureMem: 4280287232) -> Window: 1x1680x1050x32
D3D_DrawPrimitive: D3DERR_INVALIDCALL
Malfunction W1246: DirectX driver failure: D3DERR_INVALIDCALL
Error E1005: Out of memory

This may be something else though, I get the first warning immediately (after "1st frame with 4094 MB").


"Falls das Resultat nicht einfach nur dermassen gut aussieht, sollten Sie nochmal von vorn anfangen..." - Manual

Check out my new game: Pogostuck: Rage With Your Friends
Re: video memory and d3d_texfree [Re: Superku] #465421
04/26/17 13:13
04/26/17 13:13
Joined: Jul 2000
Posts: 27,977
Frankfurt
jcl Offline

Chief Engineer
jcl  Offline

Chief Engineer

Joined: Jul 2000
Posts: 27,977
Frankfurt
Hmm. If GetAvailableTextureMem really returned a wrong value with your 3D card, then the error message could be correct and you're in fact exceeding the memory. What 3D card are you using? Just to be sure, can you run a simple test like this?

Code:
void main()
{
	fps_max = 60;
	video_mode = 6;
	int i;
	for(i = 0; i < 10000; i++) {
		wait(1);
		BMAP *Bmap = bmap_createblack(1048,1024,32);
		draw_quad(Bmap,vector(10,10,10),NULL,NULL,NULL,NULL,50,0);
		draw_text(str_printf(NULL,"d3d_texfree: %d MB",d3d_texfree),20,60,COLOR_RED);
	}
}



At some point this will exceed either the available video memory or the available system memory, and the texture creation will fail. Does d3d_texfree then really display still your full 4 GB?

Re: video memory and d3d_texfree [Re: jcl] #465424
04/26/17 15:34
04/26/17 15:34
Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Superku Offline
Senior Expert
Superku  Offline
Senior Expert

Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Ran the test, draw_quad makes the difference here - in your or my example code.
With draw_quad, d3d_texbmaps increases and d3d_texfree gradually decreases!
1) Desktop (GTX 1080): E2005 appears after 201 bitmaps ~ d3d_texbmaps 1608MB, RAM usage of 1655MB and a remaining free memory of 2492MB = d3d_texfree. sys_memory does not increase.

2) Laptop (HD 5500): E2005 after 213 bitmaps, d3d_texfree 2141MB.

3) Old Laptop, < 4GB RAM:
A) Integrated graphics, HD 2200 or something like that, only ~1640MB shared memory: The test virtually kills this laptop, memory allocations take forever when d3d_texfree gets low. E2005 appears at d3d_texfree = 5MB (or less because of double buffering?). Memory usage in the task manager crawls up to > 1.5GB, then, when d3d_texfree gets lower, it jumps to 353-416MB in the task manager.(?)
B) Dedicated graphics card, Geforce 310M (not quite sure how much VRAM there is): E2005 after 210 bitmaps, d3d_texfree 990MB. Here the RAM usage in the task manager looks normal/ as expected, probably because of dedicated memory/ VRAM.


My code example (tested on computer 2):
- Without draw_quad, sys_memory increases with each bitmap creation, d3d_texbmaps does not and d3d_texfree does not decrease. This is probably working as intended, right? Memory is copied over/ sent to the graphics card/ VRAM when it's needed..?
I can create 212 bitmaps.
- With draw_quad(test_bmps[num_bmaps],...) (see previous post) sys_memory increases as well as d3d_texbmaps. E2005 after 105 bitmaps at 889MB sys_memory, 824MB d3d_texbmaps. RAM sits at 1722MB though.
-> If I replace bmap_create("test8MB.tga") with bmap_createblack(2048,1024,32), I can create 212 bitmaps again. sys_memory does not increase, d3d_texbmaps does and d3d_texfree decreases.


Btw. texture creation should already fail at > 2GB, right? Because of reasons mentioned earlier in this thread.
Oh, and yesterday I read that GetAvailableTextureMem() is unreliable and includes some system/ shared memory as well.


"Falls das Resultat nicht einfach nur dermassen gut aussieht, sollten Sie nochmal von vorn anfangen..." - Manual

Check out my new game: Pogostuck: Rage With Your Friends
Re: video memory and d3d_texfree [Re: Superku] #465432
04/27/17 12:05
04/27/17 12:05
Joined: Jul 2000
Posts: 27,977
Frankfurt
jcl Offline

Chief Engineer
jcl  Offline

Chief Engineer

Joined: Jul 2000
Posts: 27,977
Frankfurt
d3d_texfree only decreases with draw_quad, because video memory is only allocated when the bmap is rendered. From what I now learned, generating a texture fails not only when not enough video memory is available, but also when not enough normal memory is available. So you must have enough of both.


Re: video memory and d3d_texfree [Re: jcl] #465435
04/27/17 12:43
04/27/17 12:43
Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Superku Offline
Senior Expert
Superku  Offline
Senior Expert

Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Originally Posted By: jcl
So you must have enough of both.

But I do have enough of both, no?

Can you please comment on the following:

Originally Posted By: Superku
- With draw_quad(test_bmps[num_bmaps],...) (see previous post) sys_memory increases as well as d3d_texbmaps. E2005 after 105 bitmaps at 889MB sys_memory, 824MB d3d_texbmaps. RAM sits at 1722MB though.
-> If I replace bmap_create("test8MB.tga") with bmap_createblack(2048,1024,32), I can create 212 bitmaps again. sys_memory does not increase, d3d_texbmaps does and d3d_texfree decreases.

Does that make sense? If so, why?


"Falls das Resultat nicht einfach nur dermassen gut aussieht, sollten Sie nochmal von vorn anfangen..." - Manual

Check out my new game: Pogostuck: Rage With Your Friends
Page 4 of 10 1 2 3 4 5 6 9 10

Moderated by  old_bill, Tobias 

Gamestudio download | chip programmers | Zorro platform | shop | Data Protection Policy

oP group Germany GmbH | Birkenstr. 25-27 | 63549 Ronneburg / Germany | info (at) opgroup.de

Powered by UBB.threads™ PHP Forum Software 7.7.1