On 09/05/17 09:04, wm4 wrote: > On Tue, 9 May 2017 08:48:45 +0100 > Mark Thompson <[email protected]> wrote: > >> On 09/05/17 06:07, wm4 wrote: >>> On Mon, 8 May 2017 22:59:11 +0100 >>> Mark Thompson <[email protected]> wrote: >>>> On 04/05/17 07:44, wm4 wrote: >>>>> To be used with the new d3d11 hwaccel decode API. >>>>> >>>>> With the new hwaccel API, we don't want surfaces to depend on the >>>>> decoder (other than the required dimension and format). The old D3D11VA >>>>> pixfmt uses ID3D11VideoDecoderOutputView pointers, which include the >>>>> decoder configuration, and thus is incompatible with the new hwaccel >>>>> API. This patch introduces AV_PIX_FMT_D3D11, which uses ID3D11Texture2D >>>>> and an index. It's simpler and compatible with the new hwaccel API. >>>>> >>>>> The introduced hwcontext supports only the new pixfmt. >>>>> >>>>> Significantly based on work by Steve Lhomme <[email protected]>, but with >>>>> heavy changes/rewrites. >>> >>> >>>>> --- >>>>> Somewhat sketchy: if initial_pool_size is set, the pool is assumed to >>>>> be static. >>>>> --- >>> >>> Any comments on that? >> >> It's how all of the other implementations with fixed pools work, so fine? > > Ah, you're right. when I looked at the vaapi implementation, I thought > it allocated normal surfaces once the initial pool size is exceeded, but > on a closer look it actually explicitly fails allocation in that case. > > So my code behaves the same. > >>>> Is the staging texture somehow magic such that it isn't going to be >>>> uncached memory or anything tricky like that? >>> >>> Yes, I'm fairly sure it simply lives in CPU memory, and >>> CopySubresourceRegion() will access the actual video memory. >>> >>> This is also why d3d11 with copy back is slower than dxva2, apparently. >> >> Well, at least it's probably faster on Braswell :P > > How so? For dxva2, we do use a magic memcpy for uncached memory.
Well, I assume the copy from surface to staging texture is driven by the GPU (i.e. like the vaGetImage() case in VAAPI). Since magic memcpy sucks epically on Braswell, this approach will end up being faster there. >>>>> + AV_PIX_FMT_D3D11, ///< HW decoding through Direct3D11 via new >>>>> API, Picture.data[0] contains a ID3D11Texture2D pointer, and data[1] >>>>> contains the texture array index of the frame as intptr_t if the >>>>> ID3D11Texture2D is an array texture (or 0 if it's a normal texture) >>>> >>>> The old format was specifically for decoding, but the new one is more >>>> general than that. >>> >>> OK. Well, someone new to the API who's trying to figure out which >>> format to use is going to be confused, so mentioning the new decode API >>> might help. >> >> Yeah, fair. Mention decoding but not as the only thing, then. > > Fine, maybe: > > + AV_PIX_FMT_D3D11, ///< Direct3D11 texture (in particular for HW > decoding through the new d3d11 hwaccel API), Picture.data[0] contains a > ID3D11Texture2D pointer, and data[1] contains the texture array index of the > frame as intptr_t if the ID3D11Texture2D is an array texture (or 0 if it's a > normal texture) Sounds good to me. (Long line is long, I think move it to a /** */ block before the value.) _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
