[mikegi]

I'm trying to understand how incorporate GPGPU functionality into my regular Direct3D programs. Right now all my main computational tasks are implemented as background threads in C++. I'd like to move some of those background computational tasks to the GPU for speed. I don't fully understand how to partition the D3D stuff:

1) Should I create a second Direct3D device for the GPGPU thread? Since the main D3D device is used extensively for rendering in Windows, I don't believe I can use it simultaneously in the background without complicating the rendering code tremendously and/or causing stuttering in the UI.

2) What's the easiest way to a create a "windowless" D3D device? The GPGPU thread will be used exclusively for computation and will not display anything.

3) Will creating a second device cause stuttering in my main UI when the GPGPU thread is busy crunching numbers? I guess I'm wondering how well D3D handles thread switching in a multithreaded program.

I'd appreciate hearing anyone's thoughts and experience doing such a thing.
Thanks

[Seth]

I can help with #2:

ID3D10Device *g_pd3dDevice = NULL;
D3D10CreateDevice(NULL, D3D10_DRIVER_TYPE_HARDWARE, NULL, 0, D3D10_SDK_VERSION, &g_pd3dDevice);

Of course, I haven't done too much with multiple device creation...

[mikegi]

Originally Posted by Seth

I can help with #2:

ID3D10Device *g_pd3dDevice = NULL;
D3D10CreateDevice(NULL, D3D10_DRIVER_TYPE_HARDWARE, NULL, 0, D3D10_SDK_VERSION, &g_pd3dDevice);

Of course, I haven't done too much with multiple device creation...

Unfortunately, I need to use D3D9. I was never clear to me exactly why D3D needed a window handle to begin with and why the concern about window callbacks. Maybe it was due to hardware limitations in the early days or fullscreen mode. It seems like the Present call is the only place that a window handle would be needed (to know where to blt the output). Anyway, my programs are all windowed if that simplifies things.

Edit: wanted to add that my programs are scientific applications, not games.

[Tim Murray]

Why are you using D3D for scientific computing instead of CUDA/Stream/waiting for OCL? CUDA has D3D interop, I don't know if Stream does, and OCL certainly has robust OGL interop.

[mikegi]

Originally Posted by Tim Murray

Why are you using D3D for scientific computing instead of CUDA/Stream/waiting for OCL? CUDA has D3D interop, I don't know if Stream does, and OCL certainly has robust OGL interop.

D3D is the API I use for rendering throughout the app. I'm not going to switch to OGL. My app has to work on any PS 2.x+ graphics adapter, so CUDA is out. In addition, I don't want my users to have to install, or for me to have to distribute, other drivers/DLLs/etc.

All I was interested in was whether anyone here had used D3D for GPGPU computing as part of an app that already uses D3D extensively for rendering. Basically, what are the gotchas to look out for, etc.