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.