cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

fkane
Journeyman III

OpenCL / DirectX9 texture interop?

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;

}

0 Likes
1 Solution
german
Staff

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.

View solution in original post

0 Likes
2 Replies
german
Staff

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.

0 Likes

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.

0 Likes