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-boun...@ffmpeg.org> On Behalf Of > Mironov, Mikhail > Sent: November 29, 2018 10:52 AM > To: FFmpeg development discussions and patches <ffmpeg- > 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 <ffmpeg-devel-boun...@ffmpeg.org> 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 > > <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-boun...@ffmpeg.org> 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, &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@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ > 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