On 25/11/2018 22:22, Mark Thompson wrote:
> 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.)
Urgh, sorry - ignore that question, I misread "can be not 0" as "cannot be 0".
>>
>> 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@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
