Wine GPU decoding

[Stefan Dösinger]

Am 01.04.2014 um 01:48 schrieb Michael Müller <michael at fds-team.de>:
> All surfaces which are used in conjunction with the dxvapi are created
> through the CreateSurface command of the
> IDirectXVideoAccelerationService interface.
IDirectXVideoProcessor::VideoProcessBlt (http://msdn.microsoft.com/en-us/library/windows/desktop/ms697022(v=vs.85).aspx) mentions that it also accepts user-created surfaces with D3DUSAGE_RENDERTARGET, but it seems that this is a different interface.

> Moreover I can not specify the address
> to which the output data should be copied I can only map the buffer at
> an address defined by vaapi and copy it manually.
Does the va-api guarantee that the address is the same every time you map it?

> DXVA supports both: direct rendering (called native mode) and reading it
> back to system memory ( see
> http://en.wikipedia.org/wiki/DirectX_Video_Acceleration#DXVA2_implementations:_native_and_copy-back
> )
Can you call IDirectXVideoAccelerationService::CreateSurface to create a DXVA2_VideoDecoderRenderTarget surface with a format of NV12 (or another non-rgb format) surface that is in D3DPOOL_DEFAULT? It looks like the API allows it in theory, but I wonder if this works in practice. If DXVA2_VideoDecoderRenderTarget implies D3DUSAGE_RENDERTARGET creating such a surface will not be possible.

Even if the create call succeeded look at the details of the surface you got. Call IDirect3DSurface9::GetDesc to check its pool, format and usage. Check if you can Lock it. See if it has a texture container. I guess you can also compare the vtable to that of a surface created with IDirect3DDevice9::CreateOffscreenPlainSurface to see if dxva has created some sort of wrapper surface. (I doubt it. It would be asking for strange bugs).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20140401/34b49e61/attachment.sig>