I create big textures. Seriously big. However, regardless of using Default or Managed memory pool, I cannot seem to avoid getting a corresponding allocation in my process. Can this at all be avoided? If there is a temporary allocation while filling the texture this is of course something different, what I am looking for is a way to avoid the constant "overhead" corresponding to the sum of all textures currently in use. In my case the most significant ones will be VolumeTextures. When trying this, the actual texture creating does not make a significant change in virtual memory size for my process. However as soon as I try and fill the texture the chunk of memory is allocated and not released. My hunch is that SlimDX has no part in this, and that it is either something that cannot be done, or simply a matter of using the right approach. Hence the [SlimDX?] title.

How are you handling the textures with SlimDX? There are some edge cases that can cause memory pressure due to the allocation of managed (nondeterministically-freed) arrays and such. Even if you are using the optimal path for SlimDX, the actual DX stuff you are doing is worth knowing before anybody can make any real judgement.

My simplest test case is:

VolumeTexture volumeTexture = new VolumeTexture(device, 256, 256, 256, 1, Usage.Dynamic, Format.L16, Pool.Default);
using (Volume volume = volumeTexture.GetVolumeLevel(0)) {
DataBox box = volume.LockBox(LockFlags.None);
}

Normally I would then proceed to use the DataStream in the box to add content. I also tried the volumeTexture.Fill version, to see if that made any difference. My main interest is filling the texture, not reading, in case there are more suitable ways of doing this.

Dynamic textures are usually placed by the driver in AGP memory so that both the CPU and GPU can get at the texture easily. However that does mean it will use up some of your address space.

However I believe that if you created it as a non-dynamic default pool texture you'd only need a temporary copy of the data in memory (and only one surface level at a time too). The downside is that modifying the texture will probably be slower.

The other obvious solution is to upgrade to 64-bit Vista where you won't run out of address space.

Thanks for the reply Adam!

We are definitely heading the x64 route, but for 32-bit users I think we still want to explore this possibility. At least to see what kind of performance penality we are talking about.

How would one go about filling the non-dynamic default pool texture? I tried a couple of approaches but none worked.

If you were using C++ GetSurfaceLevel() followed by D3DXLoadSurfaceFromMemory() would be what I'd use. Unfortunately I'm not sure what the equivalent is in SlimDX.

In the case of volumetextures that would be GetVolumeLevel followed by Volume.FromMemory. Thanks for the input, I'll try this once I get a chance!