I'm having trouble using cl_dx9_media_sharing to write OpenCL results to a IDirect3DTexture9. In the snippet below, I get an exception from accessing a null pointer somewhere inside the first call to clCreateFromDX9MediaSurfaceKHR. I've verified that my function pointer is valid, and the parameters all appear to be valid. The only thing I can think of is that I'm passing NULL as the shared_handle for the texture, but the spec says that this is allowed - and I don't know how to get the handle it wants. At any rate - clCreateFromDX9MediaSurfaceKHR shouldn't be crashing at all, should it?
I did create my context with the CL_CONTEXT_ADAPTER_D3D9_KHR property specifying my DX9 device, and created my OpenCL device using clGetDeviceIDsFromDX9MediaAdapter. Am I missing something, or is this extension not really meant for textures? Is there a better way? I couldn't seem to find any examples of doing this.
My driver and AMD APP SDK are both the latest. The textures passed in are D3DFMT_A32B32G32R32F format and in the default pool. I obtained the extension function pointers like:
clCreateFromDX9MediaSurface = (clCreateFromDX9MediaSurfaceKHR_fn)clGetExtensionFunctionAddressForPlatform(defaultPlatform, "clCreateFromDX9MediaSurfaceKHR");
Thanks!
bool FFTOpenCLImpl::SetOutputTextures(IDirect3DTexture9 *displacementTex, IDirect3DTexture9 *slopeFoamTex)
{
cl_int err;
if (displacementTex && slopeFoamTex) {
cl_dx9_surface_info_khr surfaceInfo;
IDirect3DSurface9 *dispSurface, *slopeSurface;
HRESULT hr = 0;
hr |= displacementTex->GetSurfaceLevel(0, &dispSurface);
hr |= slopeFoamTex->GetSurfaceLevel(0, &slopeSurface);
if (SUCCEEDED(hr)) {
surfaceInfo.resource = dispSurface;
surfaceInfo.shared_handle = NULL;
// Crash here:
displacement = clCreateFromDX9MediaSurface(context, CL_MEM_WRITE_ONLY,
CL_ADAPTER_D3D9_KHR, &surfaceInfo, 0, &err);
if (err == 0) {
surfaceInfo.resource = slopeSurface;
surfaceInfo.shared_handle = NULL;
slopeFoam = clCreateFromDX9MediaSurface(context, CL_MEM_WRITE_ONLY,
CL_ADAPTER_D3D9_KHR, &surfaceInfo, 0, &err);
}
return err == 0;
}
}
return false;
}
Solved! Go to Solution.
Does runtime report cl_khr_dx9_media_sharing extension? You can't use an extension if runtime doesn't report it:-) Anyhow we should support DX9 interop internally, but runtime doesn't report the extension:-). There is a limitation. You have to use IDirect3DDevice9Ex device object and CL_ADAPTER_D3D9EX_KHR as adapter type. Please note, if shared_handle is NULL, then you will have double copy (acquire/release) - no direct access.
Does runtime report cl_khr_dx9_media_sharing extension? You can't use an extension if runtime doesn't report it:-) Anyhow we should support DX9 interop internally, but runtime doesn't report the extension:-). There is a limitation. You have to use IDirect3DDevice9Ex device object and CL_ADAPTER_D3D9EX_KHR as adapter type. Please note, if shared_handle is NULL, then you will have double copy (acquire/release) - no direct access.
You're right; I assumed that getting the function pointers back implied support, but the spec clearly says not to rely on that. That is a bummer though; I hope full support of this extension is on the horizon, as it really limits the ability to do things like accelerating FFT-based ocean visuals with DirectX 9 on AMD cards.