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

[Mironov, Mikhail]

You assume that device ID returned from regular enumeration is the same as device ID returned from clGetDeviceIDsFromD3D11KHR. It is not guaranteed and I didn't try this. Also I would add tracing to ensure that CL_CONTEXT_D3D11_DEVICE_KHR is actually set and clGetDeviceIDsFromD3D11KHR is called. In AMF code I always set CL_CONTEXT_INTEROP_USER_SYNC to true. Also I would trace other parameters to clCreateFromD3D11Texture2DKHR: memory flags and texture descriptor.
BTW: does the interop work for NV or Intel?
Thanks,
Mikhail

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Mark Thompson
> Sent: November 25, 2018 5:22 PM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [INFO]AMD D3D11 to OpenCL interop extension
> for NV12 and P010 textures - split planes
> 
> 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
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel