After some delay...

Lots of changes everywhere:

* The cl_khr_image2d_from_buffer requirement is entirely removed.  This also 
removes Beignet -> VAAPI mapping, but that was a bit clumsy anyway (gave you 
X-tiled surfaces by default which VAAPI then always copied to Y-tiled surfaces 
internally).  Beignet will just use the reverse mapping like the other APIs 
have to.

* More generic infrastructure in lavfi - now converts OpenCL source files to C 
files containing strings to compile them into the binary.  (Useful for 
debugging if nothing else - the "error at line 1 column 9001"-type message from 
the previous structure was mildly unhelpful.)

* Proper device derivation implementation.

* D3D11 mapping support.  This only works on Intel because it depends on 
cl_intel_d3d11_nv12_media_sharing to be able to map NV12 surfaces (which is 
unfortunately not supported by the common extension).  It currently only does 
NV12, but could be extended to a lot of other formats if RGB/RGBA was useful to 
anyone (P010 isn't obviously allowed, though).

* Many small things, including incorporating all review comments from the 
previous round.


Future:

* D3D11 for libmfx surfaces - this would allow full hardware transcode for 
Intel on Windows with OpenCL filtering, as is already possible with this series 
on Linux.

* The libavfilter stuff is still a bit dirty.  The colorspace bits in 
particular could use a look from someone who understands that sort of thing.

* The Media SDK VAAPI sharing extension doesn't work (for me) the way it 
appears to be meant to.  It looks like the D3D sharing extensions, where you 
map all the surfaces in advance and then only acquire/release them while 
running.  But, it seems to only allow one mapping - attempting to map a second 
surface always fails.  I might be doing something incorrectly, but I tried a 
lot of variations and it looks like this is just broken (all visible public 
code just does map-acquire/release-unmap for single surfaces, too).

* There is some weird clumsiness in Direct3D device derivation because the 
implementations seem to give you more devices than it feels like they should 
when asking for those matching Direct3D instances (you have a DXVA2 instance on 
an Intel GPU and it gives you a CPU device as well as the GPU - I filter for 
GPU devices only to avoid that case).  I'm not sure if there is any cleaner 
solution to this, and there may be further problems with other drivers which I 
haven't tried.

* D3D11 requires the D3D11_RESOURCE_MISC_SHARED flag on all textures, but we 
can't set that anywhere in avconv at the moment.  Patch 12 is a hack adding it 
for testing.

* hwcontext_opencl.c is 2679 lines and all the ifdeffery is kindof crazy.  It 
is pretty strongly interlinked, though, so unclear whether this can actually be 
made any nicer.
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to