[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 <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Mironov, Mikhail
> Sent: November 29, 2018 10:52 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at 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 <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Mark
> > Thompson
> > Sent: November 27, 2018 7:05 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 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
> > <https://www.khronos.org/registry/OpenCL/extensions/intel/cl_intel_d3d
> > 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 <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.
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel at ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel