[FFmpeg-devel] [INFO]AMD D3D11 to OpenCL interop extension for NV12 and P010 textures - split planes

Mark Thompson sw at jkqxz.net
Mon Nov 26 00:22:07 EET 2018


On 25/11/2018 21:28, Mironov, Mikhail wrote:
> It seem that the failure is not in the new extension but before, in the interop from D3D11 to OCL. It can happen in two cases: OCL device/context are created without D3D11 device or format of the texture is not supported. NV12 is supported. I went through the latest ffmpeg snapshot and found that function opencl_enumerate_d3d11_devices() looks correct, pointer to the function is set to OpenCLDeviceSelector::enumerate_devices member but I cannot find a call to selector->enumerate_devices(). Instead opencl_enumerate_devices() is called directly. So my guess is that created OCL device is not created from D3D11.

Hmm, right - patch just sent to fix the selection call.

It doesn't actually make any difference to this case, though, since the filter made it choose the right device anyway and CL_CONTEXT_D3D11_DEVICE_KHR was always set when deriving from D3D11.  (It could only have made a difference if there were other conflicting D3D11 devices it could have picked incorrectly.)

> Just in case OCL device creation sample: https://github.com/GPUOpen-LibrariesAndSDKs/AMF/blob/master/amf/public/samples/CPPSamples/common/DeviceOpenCL.cpp
> 
> Regarding the new split extension: here is a working snippet:
> cl_mem clImage2D = 0;
> cl_mem clImages[AMF_SURFACE_MAX_PLANES];
> // index can be not 0 if texture is allocated as an array.
>  clImage2D = clCreateFromD3D11Texture2DKHR(m_clContext, memflags, pTexture, index, &clStatus);

Where is the comment about index being nonzero coming from there?  Other callers to this definitely start from a zero index.  (I tried adding one to my index values but it didn't change the result.)

> 
>  for(int i = 0; i < planesNumber; i++)
>   {
>   	clImages[i] = clGetPlaneFromImageAMD(m_clContext, clImage2D, (cl_uint)i, &clStatus);
> 	
> }
> // don’t forget to release clImages[i] and clImage2D

Otherwise, that agrees with how I read the extension document.

Thanks,

- Mark


More information about the ffmpeg-devel mailing list