I think I have asked that before but since I have a ticket with Microsoft open and they want me to verify this once more I'll ask once again.
I have found limitations on how many textures I can create and they don't make sense to me... I am running the following code on a 48 Gig machine with a GTX 480. See the table below for results.
SlimDX.Direct3D11.Device device = new SlimDX.Direct3D11.Device(DriverType.Hardware, DeviceCreationFlags.None);List<Texture2D> textureList = new List<Texture2D>();int width = 8192;int height = 4096;for (int i = 0; i < 100000; i++){ try { Texture2DDescription texDesc = new Texture2DDescription(); texDesc.ArraySize = 1; texDesc.BindFlags = BindFlags.ShaderResource; texDesc.CpuAccessFlags = CpuAccessFlags.None; texDesc.Format = SlimDX.DXGI.Format.R16_Float; texDesc.Height = height; texDesc.MipLevels = 1; texDesc.OptionFlags = ResourceOptionFlags.None; texDesc.SampleDescription = new SampleDescription(1, 0); texDesc.Usage = ResourceUsage.Default; texDesc.Width = width; Texture2D texture = new Texture2D(device, texDesc); textureList.Add(texture); } catch (Exception ex) { MessageBox.Show("Error at texture " + i + " : " + ex.ToString()); break; }}foreach (Texture2D texture in textureList){ texture.Dispose();}
Now these are the results that I'm getting for different texture sizes...
Texture Dimension Format Size MB Max # Textures Memory Used GB256x256 R16_Float 0.125 62,256 7.60512x256 R16_Float 0.25 31,040 7.58512x512 R16_Float 0.5 15,520 7.581024x512 R16_Float 1 7,760 7.582048x1024 R16_Float 4 1,940 7.584096x2048 R16_Float 16 485 7.588192x4096 R16_Float 64 485 30.318192x8192 R16_Float 128 485 60.6316384x8192 R16_Float 256 242 60.5016384x16384 R16_Float 512 121 60.5016384x16384 R32_Float 1024 60 60.00
As you can see the first few rows seem to be limited to about 7.6 gigs, the one row that is limited at a bit over 30 gigs, and the remaining rows are limited at 60 gigs and even though I only have 48 gigs physical RAM in my computer, I was able to create all those textures up to the limit stated above...
if any of the SlimDX devs could verify that this is indeed not a problem stemming from SlimDX, that would be greatly appreciated.
Thanks for your help
Marcel