[SlimDx]: 64 bit and Multiple GPU access

1) Yes, see documentation.
2) We expose native D3D verbatim, and it would be done the same way.
3) Same as (2).
4) Same as (2), however the numbers reported vary from inaccurate (WinXP) to completely wrong (Vista+). I recommend you do not do this at any point; however WMI should be able to report the correct number.
5) Same as (2).

This is GREAT news. Thank you!!

When playing with the example code and reading the documentation, I failed to figure out how to get the number of graphics devices (GPU) on the computer. And also I was unable to select which one to use.

If I read the docs on GetAdapterCount and GetAdapter correctly, this should work:

int MyAdapterCount = SlimDX.DXGI.Factory.GetAdapterCount();
SlimDX.DXGI.Adapter MyAdapter = SlimDX.DXGI.Factory.GetAdapter(MyAdapterCount-1);

However, the Visual Studio code complete engine does not recognize the methods GetAdapterCount and GetAdapter.

Links to docs are below:

http://slimdx.mdxinfo.com/latestdocs/Default.aspx?helpfile=Help/Html/M_SlimDX_DXGI_Factory_GetAdapter_1_cd2d7ec9.htm

http://slimdx.mdxinfo.com/latestdocs/Default.aspx?helpfile=Help/Html/M_SlimDX_DXGI_Factory_GetAdapterCount.htm

Those aren't static methods; you need to actually create an instance of a DXGI factory first.

Thanks! This worked perfectly!! To help others, here is what I did:

SlimDX.DXGI.Factory myFactory = new SlimDX.DXGI.Factory();
int MyAdapterCount = myFactory.GetAdapterCount();
SlimDX.DXGI.Adapter MyAdapter = myFactory.GetAdapter(MyAdapterCount-1);

Next question: I seem to recall, that I could read how much of the texture memory is free, so that I know if there is room for more textures or if I shall dispose some of the existing ones first. Strangely enough I can't find that anymore... You mentioned in your first post, that this number was not accurate - is that valid for Windows 7 too? You also suggest using WMI. I'm afraid I do not know what WMI means and how I would use that to get the memory status.

The 9 device at least offers a function to get available texture memory; it's just that the number tends to be a lie.

What does "9 device" mean? Even if the number turns out to be bogus, when you try to load a texture, I would assume that you could capture some kind of exception, and then use that to learn that you have filled the memory, and in that case dispose some older elements and add the one again? Could that work?

9 as in D3D 9. Yes, catching the exception (which would have a code of ResultCode.OutOfMemory I guess) would work, I imagine. I dunno that it's the best way to handle it.

For reference: This is documented here:
http://slimdx.mdxinfo.com/latestdocs/Default.aspx?helpfile=Help/Html/P_SlimDX_Direct3D9_Device_AvailableTextureMemory.htm

Yes, the number is very likely bogus. My little laptop with Nvidia FX-570M reports "1592786944" as free texture memory.

Thanks for your help. I'll keep diving and learning the framework. Very exciting and promising I must say.

My experience with DirectX is limited to what I got from working with XNA. They provided good examples on how to load an XNB file into a texture, then draw that texture in a sprite batch.

Would you know where to find a similar simple example? The examples I found with the XNA framework seemed to focus on vertex and not sprites... Also I am not sure what format SlimDx will want textures in. I am sure it is not XNB, but I would not expect it to be JPG either. As you can see this question is based on my exposure to XNA and not C++ direct X programming.

Quote:

Original post by nanckekr What does "9 device" mean? Even if the number turns out to be bogus, when you try to load a texture, I would assume that you could capture some kind of exception, and then use that to learn that you have filled the memory, and in that case dispose some older elements and add the one again? Could that work?

I should just mention that if you're using DirectX 10, then you won't get an "out of memory" error because DirectX 10 implements virtual video memory. Like how virtual memory works on the CPU, with virtual video memory, you can allocate a whole bunch of video memory and if it can't all fit into VRAM, it gets "paged" to system memory automatically.