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

[Mironov, Mikhail]

Hi Mark,
Did you have chance to try this sample?
BTW: Alex Karvchenko waits for your review and commit for AMF context for some 
time. With this commit he can add more interesting things. Could you please 
take a look?
Thanks,
Mikhail

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Mironov, Mikhail
> Sent: November 29, 2018 10:52 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [INFO]AMD D3D11 to OpenCL interop extension
> for NV12 and P010 textures - split planes
> 
> HI,
> I've wrote a small sample you can use:
> https://www.dropbox.com/s/c8m8evoao731tbm/OCLDX11Interop.zip?dl=0
> If it doesn’t work - you have conflict of drivers with Intel - saw this 
> before.
> Thanks,
> Mikhail
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> Mark
> > Thompson
> > Sent: November 27, 2018 7:05 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [INFO]AMD D3D11 to OpenCL interop
> > extension for NV12 and P010 textures - split planes
> >
> > On 26/11/2018 15:32, Mironov, Mikhail wrote:
> > > 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.
> >
> > Ok, that's fair I suppose.  Fixing it hasn't changed anything, though.
> >
> > > Also I would add tracing to ensure that CL_CONTEXT_D3D11_DEVICE_KHR
> > is actually set and clGetDeviceIDsFromD3D11KHR is called.
> >
> > The first was always true (Intel requires it too), the second is now.
> >
> > > In AMF code I always set CL_CONTEXT_INTEROP_USER_SYNC to true.
> >
> > I'm not completely sure of the precise semantics of D3D11, but I don't
> > think we want that here - the clEnqueueAcquireD3D11ObjectsKHR() call
> > should be the first synchronisation point following the previous
> > component (generally a decoder).
> >
> > I tried setting it anyway, but the behaviour doesn't change - I still
> > get CL_INVALID_D3D11_RESOURCE_KHR.
> >
> > > Also I would trace other parameters to
> clCreateFromD3D11Texture2DKHR:
> > memory flags and texture descriptor.
> >
> > For the flags, I tried all of CL_MEM_READ_WRITE / CL_MEM_WRITE_ONLY
> /
> > CL_MEM_READ_ONLY, which are the only allowed values.  The texture
> > descriptor is just the one created for the decoder.
> >
> > > BTW: does the interop work for NV or Intel?
> >
> > The D3D11 interop works on Intel, though not directly in the ffmpeg
> > utility without a little change because it requires the textures to be
> > created with D3D11_RESOURCE_MISC_FLAG (as described in the extension
> > document
> >  > 11 _nv12_media_sharing.txt>).  Intel doesn't care whether
> > clGetDeviceIDsFromD3D11KHR() is used or not (though I've fixed that
> > anyway), but it does require the CL_CONTEXT_D3D11_DEVICE_KHR option
> to
> > clCreateContext() (fails with CL_INVALID_CONTEXT if it isn't).
> >
> > It can't work on Nvidia because they don't offer any way to share NV12
> > textures.
> >
> > The DXVA2/D3D9 interop works correctly on both AMD and Intel with only
> > the common standard extension.  The one Nvidia device I can find
> > easily doesn't have cl_khr_dx9_media_sharing at all, so that doesn't work.
> >
> > Thanks,
> >
> > - Mark
> >
> >
> > >> -Original Message-
> > >> From: ffmpeg-devel  On Behalf Of
> > >> Mark Thompson
> > >> Sent: November 25, 2018 5:22 PM
> > >> To: ffmpeg-devel@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-
> > >> 

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

[Mironov, Mikhail]

HI,
I've wrote a small sample you can use: 
https://www.dropbox.com/s/c8m8evoao731tbm/OCLDX11Interop.zip?dl=0
If it doesn’t work - you have conflict of drivers with Intel - saw this before.
Thanks,
Mikhail

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Mark Thompson
> Sent: November 27, 2018 7:05 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [INFO]AMD D3D11 to OpenCL interop extension
> for NV12 and P010 textures - split planes
> 
> On 26/11/2018 15:32, Mironov, Mikhail wrote:
> > 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.
> 
> Ok, that's fair I suppose.  Fixing it hasn't changed anything, though.
> 
> > Also I would add tracing to ensure that CL_CONTEXT_D3D11_DEVICE_KHR
> is actually set and clGetDeviceIDsFromD3D11KHR is called.
> 
> The first was always true (Intel requires it too), the second is now.
> 
> > In AMF code I always set CL_CONTEXT_INTEROP_USER_SYNC to true.
> 
> I'm not completely sure of the precise semantics of D3D11, but I don't think
> we want that here - the clEnqueueAcquireD3D11ObjectsKHR() call should be
> the first synchronisation point following the previous component (generally a
> decoder).
> 
> I tried setting it anyway, but the behaviour doesn't change - I still get
> CL_INVALID_D3D11_RESOURCE_KHR.
> 
> > Also I would trace other parameters to clCreateFromD3D11Texture2DKHR:
> memory flags and texture descriptor.
> 
> For the flags, I tried all of CL_MEM_READ_WRITE / CL_MEM_WRITE_ONLY /
> CL_MEM_READ_ONLY, which are the only allowed values.  The texture
> descriptor is just the one created for the decoder.
> 
> > BTW: does the interop work for NV or Intel?
> 
> The D3D11 interop works on Intel, though not directly in the ffmpeg utility
> without a little change because it requires the textures to be created with
> D3D11_RESOURCE_MISC_FLAG (as described in the extension document
>  _nv12_media_sharing.txt>).  Intel doesn't care whether
> clGetDeviceIDsFromD3D11KHR() is used or not (though I've fixed that
> anyway), but it does require the CL_CONTEXT_D3D11_DEVICE_KHR option to
> clCreateContext() (fails with CL_INVALID_CONTEXT if it isn't).
> 
> It can't work on Nvidia because they don't offer any way to share NV12
> textures.
> 
> The DXVA2/D3D9 interop works correctly on both AMD and Intel with only
> the common standard extension.  The one Nvidia device I can find easily
> doesn't have cl_khr_dx9_media_sharing at all, so that doesn't work.
> 
> Thanks,
> 
> - Mark
> 
> 
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf Of
> >> Mark Thompson
> >> Sent: November 25, 2018 5:22 PM
> >> To: ffmpeg-devel@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, );
> >>
> >> 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, );
> >>>
> >>> }

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

[Mark Thompson]

On 26/11/2018 15:32, Mironov, Mikhail wrote:
> 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.

Ok, that's fair I suppose.  Fixing it hasn't changed anything, though.

> Also I would add tracing to ensure that CL_CONTEXT_D3D11_DEVICE_KHR is 
> actually set and clGetDeviceIDsFromD3D11KHR is called.

The first was always true (Intel requires it too), the second is now.

> In AMF code I always set CL_CONTEXT_INTEROP_USER_SYNC to true.

I'm not completely sure of the precise semantics of D3D11, but I don't think we 
want that here - the clEnqueueAcquireD3D11ObjectsKHR() call should be the first 
synchronisation point following the previous component (generally a decoder).

I tried setting it anyway, but the behaviour doesn't change - I still get 
CL_INVALID_D3D11_RESOURCE_KHR.

> Also I would trace other parameters to clCreateFromD3D11Texture2DKHR: memory 
> flags and texture descriptor.

For the flags, I tried all of CL_MEM_READ_WRITE / CL_MEM_WRITE_ONLY / 
CL_MEM_READ_ONLY, which are the only allowed values.  The texture descriptor is 
just the one created for the decoder.

> BTW: does the interop work for NV or Intel?

The D3D11 interop works on Intel, though not directly in the ffmpeg utility 
without a little change because it requires the textures to be created with 
D3D11_RESOURCE_MISC_FLAG (as described in the extension document 
).
  Intel doesn't care whether clGetDeviceIDsFromD3D11KHR() is used or not 
(though I've fixed that anyway), but it does require the 
CL_CONTEXT_D3D11_DEVICE_KHR option to clCreateContext() (fails with 
CL_INVALID_CONTEXT if it isn't).

It can't work on Nvidia because they don't offer any way to share NV12 textures.

The DXVA2/D3D9 interop works correctly on both AMD and Intel with only the 
common standard extension.  The one Nvidia device I can find easily doesn't 
have cl_khr_dx9_media_sharing at all, so that doesn't work.

Thanks,

- Mark


>> -Original Message-
>> From: ffmpeg-devel  On Behalf Of
>> Mark Thompson
>> Sent: November 25, 2018 5:22 PM
>> To: ffmpeg-devel@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, );
>>
>> 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, );
>>>
>>> }
>>> // don’t forget to release clImages[i] and clImage2D
>>
>> Otherwise, that agrees with how I read the extension document.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [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  On Behalf Of
> Mark Thompson
> Sent: November 25, 2018 5:22 PM
> To: ffmpeg-devel@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, );
> 
> 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, );
> >
> > }
> > // 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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Mark Thompson]

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, );
> 
> 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, );
>>  
>> }
>> // 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

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

[Mark Thompson]

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, );

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, );
>   
> }
> // 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

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

[Mironov, Mikhail]

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.
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, );

 for(int i = 0; i < planesNumber; i++)
  {
clImages[i] = clGetPlaneFromImageAMD(m_clContext, clImage2D, 
(cl_uint)i, );

}
// don’t forget to release clImages[i] and clImage2D
Regards,
Mikhail

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Mark Thompson
> Sent: November 25, 2018 2:35 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [INFO]AMD D3D11 to OpenCL interop extension
> for NV12 and P010 textures - split planes
> 
> On 24/05/2018 15:26, Mironov, Mikhail wrote:
> > AMD has published OpenCL extension which allows split D3D11 texture
> interoped as a single 2D image into two 2D images representing Y and UV
> planes.
> >
> https://www.khronos.org/registry/OpenCL/extensions/amd/cl_amd_planar
> _y
> > uv.txt
> 
> I had a go at implementing this now that it is actually visible in released
> drivers, but I can't get it to work.
> 
> Patch trying to implement it is below.  It finds the extension and the new
> function correctly, but I'm stuck on the creation of the whole-texture image
> with clCreateFromD3D11Texture2DKHR().  The error returned is
> CL_INVALID_D3D11_RESOURCE_KHR (-1007), but as far as I can tell none of
> the documented failure cases which would return that error code apply.
> 
> $ ./ffmpeg_g.exe -report -v debug -y -hwaccel d3d11va -hwaccel_device 0 -
> hwaccel_output_format d3d11 -i input.mp4 -an -vf
> "hwmap=derive_device=opencl:mode=read,unsharp_opencl,hwdownload,fo
> rmat=nv12" -f null - ...
> [AVHWDeviceContext @ 01c0de80] Using device 1002:665f (AMD
> Radeon (TM) R7 360 Series).
> ...
> [h264 @ 0284adc0] Format d3d11 chosen by get_format().
> ...
> [Parsed_hwmap_0 @ 02a2be00] Configure hwmap d3d11 ->
> opencl.
> [AVHWDeviceContext @ 0d328500] 2 OpenCL platforms found.
> [AVHWDeviceContext @ 0d328500] 1 OpenCL devices found on
> platform "Intel(R) OpenCL".
> [AVHWDeviceContext @ 0d328500] Device Intel(R) Core(TM) i3-
> 6300 CPU @ 3.80GHz skipped (not GPU).
> [AVHWDeviceContext @ 0d328500] 1 OpenCL devices found on
> platform "AMD Accelerated Parallel Processing".
> [AVHWDeviceContext @ 0d328500] 1.0: AMD Accelerated Parallel
> Processing / Bonaire [AVHWDeviceContext @ 0d328500] DXVA2 to
> OpenCL mapping function found (clCreateFromDX9MediaSurfaceKHR).
> [AVHWDeviceContext @ 0d328500] DXVA2 in OpenCL acquire
> function found (clEnqueueAcquireDX9MediaSurfacesKHR).
> [AVHWDeviceContext @ 0d328500] DXVA2 in OpenCL release
> function found (clEnqueueReleaseDX9MediaSurfacesKHR).
> [AVHWDeviceContext @ 0d328500] cl_khr_d3d11_sharing found as
> platform extension.
> [AVHWDeviceContext @ 0d328500] cl_amd_planar_yuv found as
> device extension.
> [AVHWDeviceContext @ 0d328500] D3D11 to OpenCL mapping
> function found (clCreateFromD3D11Texture2DKHR).
> [AVHWDeviceContext @ 0d328500] D3D11 in OpenCL acquire
> function found (clEnqueueAcquireD3D11ObjectsKHR).
> [AVHWDeviceContext @ 0d328500] D3D11 in OpenCL release
> function found (clEnqueueReleaseD3D11ObjectsKHR).
> [AVHWDeviceContext @ 0d328500] D3D11 to OpenCL mapping on
> AMD function found (clGetPlaneFromImageAMD).
> [AVHWFramesContext @ 02c13180] Failed to create CL image from
> D3D texture index 0: -1007.
> [Parsed_hwmap_0 @ 02a2be00] Failed to create derived frames
> context: -5.
> [Parsed_hwmap_0 @ 02a2be00] Failed to configure output pad on
> Parsed_hwmap_0
> 
> 
> Are there any examples of using this extension that I could compare with?
> Alternatively, is the source code for the CL driver available somewhere so
> that I can work out what that error actually means?
> 
> Thanks,
> 
> - Mark
> 
> 
> From 25fb98f021b1347394d56ecf4781466096616542 Mon Sep 17 00:00:00
> 2001
> From: Mark Thompson 
> Date: Sun, 25 Nov 2018 16:59:24 +
> Subject: [PATCH] hwcontext_opencl: Add support for D3D11 to OpenCL

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

[Mark Thompson]

On 24/05/2018 15:26, Mironov, Mikhail wrote:
> AMD has published OpenCL extension which allows split D3D11 texture interoped 
> as a single 2D image into two 2D images representing Y and UV planes.
> https://www.khronos.org/registry/OpenCL/extensions/amd/cl_amd_planar_yuv.txt

I had a go at implementing this now that it is actually visible in released 
drivers, but I can't get it to work.

Patch trying to implement it is below.  It finds the extension and the new 
function correctly, but I'm stuck on the creation of the whole-texture image 
with clCreateFromD3D11Texture2DKHR().  The error returned is 
CL_INVALID_D3D11_RESOURCE_KHR (-1007), but as far as I can tell none of the 
documented failure cases which would return that error code apply.

$ ./ffmpeg_g.exe -report -v debug -y -hwaccel d3d11va -hwaccel_device 0 
-hwaccel_output_format d3d11 -i input.mp4 -an -vf 
"hwmap=derive_device=opencl:mode=read,unsharp_opencl,hwdownload,format=nv12" -f 
null -
...
[AVHWDeviceContext @ 01c0de80] Using device 1002:665f (AMD Radeon (TM) 
R7 360 Series).
...
[h264 @ 0284adc0] Format d3d11 chosen by get_format().
...
[Parsed_hwmap_0 @ 02a2be00] Configure hwmap d3d11 -> opencl.
[AVHWDeviceContext @ 0d328500] 2 OpenCL platforms found.
[AVHWDeviceContext @ 0d328500] 1 OpenCL devices found on platform 
"Intel(R) OpenCL".
[AVHWDeviceContext @ 0d328500] Device Intel(R) Core(TM) i3-6300 CPU @ 
3.80GHz skipped (not GPU).
[AVHWDeviceContext @ 0d328500] 1 OpenCL devices found on platform "AMD 
Accelerated Parallel Processing".
[AVHWDeviceContext @ 0d328500] 1.0: AMD Accelerated Parallel Processing 
/ Bonaire
[AVHWDeviceContext @ 0d328500] DXVA2 to OpenCL mapping function found 
(clCreateFromDX9MediaSurfaceKHR).
[AVHWDeviceContext @ 0d328500] DXVA2 in OpenCL acquire function found 
(clEnqueueAcquireDX9MediaSurfacesKHR).
[AVHWDeviceContext @ 0d328500] DXVA2 in OpenCL release function found 
(clEnqueueReleaseDX9MediaSurfacesKHR).
[AVHWDeviceContext @ 0d328500] cl_khr_d3d11_sharing found as platform 
extension.
[AVHWDeviceContext @ 0d328500] cl_amd_planar_yuv found as device 
extension.
[AVHWDeviceContext @ 0d328500] D3D11 to OpenCL mapping function found 
(clCreateFromD3D11Texture2DKHR).
[AVHWDeviceContext @ 0d328500] D3D11 in OpenCL acquire function found 
(clEnqueueAcquireD3D11ObjectsKHR).
[AVHWDeviceContext @ 0d328500] D3D11 in OpenCL release function found 
(clEnqueueReleaseD3D11ObjectsKHR).
[AVHWDeviceContext @ 0d328500] D3D11 to OpenCL mapping on AMD function 
found (clGetPlaneFromImageAMD).
[AVHWFramesContext @ 02c13180] Failed to create CL image from D3D 
texture index 0: -1007.
[Parsed_hwmap_0 @ 02a2be00] Failed to create derived frames context: -5.
[Parsed_hwmap_0 @ 02a2be00] Failed to configure output pad on 
Parsed_hwmap_0


Are there any examples of using this extension that I could compare with?  
Alternatively, is the source code for the CL driver available somewhere so that 
I can work out what that error actually means?

Thanks,

- Mark


From 25fb98f021b1347394d56ecf4781466096616542 Mon Sep 17 00:00:00 2001
From: Mark Thompson 
Date: Sun, 25 Nov 2018 16:59:24 +
Subject: [PATCH] hwcontext_opencl: Add support for D3D11 to OpenCL mapping on 
AMD

Uses cl_amd_planar_yuv.
---
 libavutil/hwcontext_opencl.c | 106 ---
 1 file changed, 86 insertions(+), 20 deletions(-)

diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
index 728877553f..c745b91775 100644
--- a/libavutil/hwcontext_opencl.c
+++ b/libavutil/hwcontext_opencl.c
@@ -64,6 +64,12 @@
 #if HAVE_OPENCL_D3D11
 #include 
 #include "hwcontext_d3d11va.h"
+
+// From cl_amd_planar_yuv; unfortunately no header is provided.
+typedef cl_mem (*clGetPlaneFromImageAMD_fn)(cl_context context,
+cl_mem mem,
+cl_uintplane,
+cl_int*errcode_ret);
 #endif
 
 #if HAVE_OPENCL_DRM_ARM
@@ -113,12 +119,17 @@ typedef struct OpenCLDeviceContext {
 
 #if HAVE_OPENCL_D3D11
 int d3d11_mapping_usable;
+int d3d11_map_amd;
+int d3d11_map_intel;
+
 clCreateFromD3D11Texture2DKHR_fn
 clCreateFromD3D11Texture2DKHR;
 clEnqueueAcquireD3D11ObjectsKHR_fn
 clEnqueueAcquireD3D11ObjectsKHR;
 clEnqueueReleaseD3D11ObjectsKHR_fn
 clEnqueueReleaseD3D11ObjectsKHR;
+clGetPlaneFromImageAMD_fn
+clGetPlaneFromImageAMD;
 #endif
 
 #if HAVE_OPENCL_DRM_ARM
@@ -817,17 +828,25 @@ static int opencl_device_init(AVHWDeviceContext *hwdev)
 #if HAVE_OPENCL_D3D11
 {
 const char *d3d11_ext = "cl_khr_d3d11_sharing";
-const char *nv12_ext  = "cl_intel_d3d11_nv12_media_sharing";
+const char *amd_ext   = "cl_amd_planar_yuv";
+const char *intel_ext = 

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

[Kirill Gavrilov]

> Probably the extension is still not enumerated in device/platform
> extensions list
> Any way it can be used now.
>
> Thanks,
> Alexander
>

Since it was a private extension it is not visible as device extension but
> if one asks for the function pointer it is there. The implementation was
> done 3-4 years ago, I can dig the driver eversion if needed.
> I will check with developer if he plans to expose it in device extension
> list.
> Mikhail
>
No, you cannot query extension which is not present in enumeration:

A non-NULL return value for *clGetExtensionFunctionAddressForPlatform* does
> not guarantee that an extension function is actually supported by the
> platform
> ...
> The behavior of calling a device extension function on a device not
> supporting that extension is undefined.
>
So, I suppose that as in case of OpenGL world, trying to use function from
extension not listed in extensions might lead to application crash (at
least on Linux).

Regards,
Kirill
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Alexander Kravchenko
> Sent: May 27, 2018 11:19 AM
> To: 'FFmpeg development discussions and patches'  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [INFO]AMD D3D11 to OpenCL interop extension
> for NV12 and P010 textures - split planes
> 
> 
> 
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > Of Mark Thompson
> > Sent: Sunday, May 27, 2018 3:29 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [INFO]AMD D3D11 to OpenCL interop
> > extension for NV12 and P010 textures - split planes
> >
> > On 27/05/18 07:57, Alexander Kravchenko wrote:
> > > сб, 26 мая 2018 г. в 19:45, Mark Thompson :
> > >
> > >> On 24/05/18 15:26, Mironov, Mikhail wrote:
> > >>> AMD has published OpenCL extension which allows split D3D11
> > >>> texture
> > >> interoped as a single 2D image into two 2D images representing Y
> > >> and UV planes.
> > >>>
> > >>
> https://www.khronos.org/registry/OpenCL/extensions/amd/cl_amd_plana
> > >> r_
> > >> yuv.txt
> > >>
> > >> Nice!  That looks like exactly what we want :)
> > >>
> > >> Is there any timeline for when this will be available in released 
> > >> drivers?
> > >>
> > > Hi Mark.
> > > This extension was implemented while ago, so it can be used now.
> >
> > I have what claims to be the most recent version of the Radeon drivers
> > (18.5.1, driver version 18.10.16, OpenCL version 24.20.11016.4
> > - I don't know which of these is relevant), and it gives me:
> >
> > Platform extensions:
> > cl_khr_icd cl_khr_d3d10_sharing cl_khr_d3d11_sharing
> > cl_khr_dx9_media_sharing cl_amd_event_callback cl_amd_offline_devices
> >
> > Device extensions:
> > cl_khr_fp64 cl_amd_fp64 cl_khr_global_int32_base_atomics
> > cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics
> > cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics
> > cl_khr_int64_extended_atomics cl_khr_3d_image_writes
> > cl_khr_byte_addressable_store cl_khr_gl_sharing cl_khr_gl_depth_images
> > cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf
> > cl_amd_media_ops cl_amd_media_ops2 cl_amd_popcnt
> cl_khr_d3d10_sharing
> > cl_khr_d3d11_sharing cl_khr_dx9_media_sharing
> > cl_khr_image2d_from_buffer cl_khr_spir cl_khr_subgroups
> > cl_khr_gl_event cl_khr_depth_images cl_khr_mipmap_image
> > cl_khr_mipmap_image_writes cl_amd_liquid_flash
> >
> > which doesn't include this extension?
> >
> 
> 
> Hi Mark,
> 
> It does include the extension.
> Extension was implemented while ago (years ago), but wasn't officially
> published till now.
> 
> Probably the extension is still not enumerated in device/platform extensions
> list Any way it can be used now.
> 
> 
> Thanks,
> Alexander
> 

Since it was a private extension it is not visible as device extension but if 
one asks for the function pointer it is there. The implementation was done 3-4 
years ago, I can dig the driver eversion if needed.
I will check with developer if he plans to expose it in device extension list.
Mikhail

> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Alexander Kravchenko]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark 
> Thompson
> Sent: Sunday, May 27, 2018 3:29 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [INFO]AMD D3D11 to OpenCL interop extension for 
> NV12 and P010 textures - split planes
> 
> On 27/05/18 07:57, Alexander Kravchenko wrote:
> > сб, 26 мая 2018 г. в 19:45, Mark Thompson :
> >
> >> On 24/05/18 15:26, Mironov, Mikhail wrote:
> >>> AMD has published OpenCL extension which allows split D3D11 texture
> >> interoped as a single 2D image into two 2D images representing Y and
> >> UV planes.
> >>>
> >> https://www.khronos.org/registry/OpenCL/extensions/amd/cl_amd_planar_
> >> yuv.txt
> >>
> >> Nice!  That looks like exactly what we want :)
> >>
> >> Is there any timeline for when this will be available in released drivers?
> >>
> > Hi Mark.
> > This extension was implemented while ago, so it can be used now.
> 
> I have what claims to be the most recent version of the Radeon drivers 
> (18.5.1, driver version 18.10.16, OpenCL version 24.20.11016.4
> - I don't know which of these is relevant), and it gives me:
> 
> Platform extensions:
> cl_khr_icd cl_khr_d3d10_sharing cl_khr_d3d11_sharing cl_khr_dx9_media_sharing 
> cl_amd_event_callback cl_amd_offline_devices
> 
> Device extensions:
> cl_khr_fp64 cl_amd_fp64 cl_khr_global_int32_base_atomics 
> cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics
> cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics 
> cl_khr_int64_extended_atomics cl_khr_3d_image_writes
> cl_khr_byte_addressable_store cl_khr_gl_sharing cl_khr_gl_depth_images 
> cl_amd_device_attribute_query cl_amd_vec3
> cl_amd_printf cl_amd_media_ops cl_amd_media_ops2 cl_amd_popcnt 
> cl_khr_d3d10_sharing cl_khr_d3d11_sharing
> cl_khr_dx9_media_sharing cl_khr_image2d_from_buffer cl_khr_spir 
> cl_khr_subgroups cl_khr_gl_event cl_khr_depth_images
> cl_khr_mipmap_image cl_khr_mipmap_image_writes cl_amd_liquid_flash
> 
> which doesn't include this extension?
> 


Hi Mark,

It does include the extension. 
Extension was implemented while ago (years ago), but wasn't officially 
published till now. 

Probably the extension is still not enumerated in device/platform extensions 
list
Any way it can be used now.


Thanks,
Alexander

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Mark Thompson]

On 27/05/18 07:57, Alexander Kravchenko wrote:
> сб, 26 мая 2018 г. в 19:45, Mark Thompson :
> 
>> On 24/05/18 15:26, Mironov, Mikhail wrote:
>>> AMD has published OpenCL extension which allows split D3D11 texture
>> interoped as a single 2D image into two 2D images representing Y and UV
>> planes.
>>>
>> https://www.khronos.org/registry/OpenCL/extensions/amd/cl_amd_planar_yuv.txt
>>
>> Nice!  That looks like exactly what we want :)
>>
>> Is there any timeline for when this will be available in released drivers?
>>
> Hi Mark.
> This extension was implemented while ago, so it can be used now.

I have what claims to be the most recent version of the Radeon drivers (18.5.1, 
driver version 18.10.16, OpenCL version 24.20.11016.4 - I don't know which of 
these is relevant), and it gives me:

Platform extensions:
cl_khr_icd cl_khr_d3d10_sharing cl_khr_d3d11_sharing cl_khr_dx9_media_sharing 
cl_amd_event_callback cl_amd_offline_devices

Device extensions:
cl_khr_fp64 cl_amd_fp64 cl_khr_global_int32_base_atomics 
cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics 
cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics 
cl_khr_int64_extended_atomics cl_khr_3d_image_writes 
cl_khr_byte_addressable_store cl_khr_gl_sharing cl_khr_gl_depth_images 
cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf cl_amd_media_ops 
cl_amd_media_ops2 cl_amd_popcnt cl_khr_d3d10_sharing cl_khr_d3d11_sharing 
cl_khr_dx9_media_sharing cl_khr_image2d_from_buffer cl_khr_spir 
cl_khr_subgroups cl_khr_gl_event cl_khr_depth_images cl_khr_mipmap_image 
cl_khr_mipmap_image_writes cl_amd_liquid_flash

which doesn't include this extension?

Thanks,

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Alexander Kravchenko]

Hi Mark.
This extension was implemented while ago, so it can be used now.

Thanks,
Alexander
сб, 26 мая 2018 г. в 19:45, Mark Thompson :

> On 24/05/18 15:26, Mironov, Mikhail wrote:
> > AMD has published OpenCL extension which allows split D3D11 texture
> interoped as a single 2D image into two 2D images representing Y and UV
> planes.
> >
> https://www.khronos.org/registry/OpenCL/extensions/amd/cl_amd_planar_yuv.txt
>
> Nice!  That looks like exactly what we want :)
>
> Is there any timeline for when this will be available in released drivers?
>
> Thanks,
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Mark Thompson]

On 24/05/18 15:26, Mironov, Mikhail wrote:
> AMD has published OpenCL extension which allows split D3D11 texture interoped 
> as a single 2D image into two 2D images representing Y and UV planes.
> https://www.khronos.org/registry/OpenCL/extensions/amd/cl_amd_planar_yuv.txt

Nice!  That looks like exactly what we want :)

Is there any timeline for when this will be available in released drivers?

Thanks,

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Mironov, Mikhail]

AMD has published OpenCL extension which allows split D3D11 texture interoped 
as a single 2D image into two 2D images representing Y and UV planes.
https://www.khronos.org/registry/OpenCL/extensions/amd/cl_amd_planar_yuv.txt
Mikhail

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel