There's no reason to release GstMemory manually at all.
If we do release GstMemory, corresponding GstBuffer will be
discarded by GstBufferPool baseclass because the size is changed
to zero.
Actual cause of heavy CPU usage in case of fixed-size pool
(i.e., decoder output buffer pool) and if we remove GstMemory from
GstBuffer is that GstBufferPool baseclass is doing busy wait in acquire_buffer()
for some reason. That needs to be investigated though, discarding
and re-alloc every GstBuffer is not ideal already.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4935>
GstBufferPool implementation was referenced for this GstD3D11PoolAllocator,
for example GstAtomicQueue, various atomic operations, and GstPoll ones.
However, such combination seems to be almost pointless
since gst_poll_{read,write}_control() takes mutex and also
GstPoll uses Win32 event handle internally.
Use simple SRWLOCK and CONDITION_VARIABLE instead, and don't make things
complicated/inefficient.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2887>
_alloca CRT function is deprecated. Moreover, stack allocation
for string is not a good idea. We can use _malloca inline
function instead, but all use of _alloca in d3d11 library/plugin
are not performance critical path at all.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3652>
GstDXGIGetDebugInterface() is unused when targeting UWP. We directly
call DXGIGetDebugInterface1() in that case.
Fixes build failure:
../gst-libs/gst/d3d11/gstd3d11device.cpp(271): error C2440: '=': cannot convert from 'HRESULT (__cdecl *)(UINT,const IID &,void **)' to 'DXGIGetDebugInterface_t'
../gst-libs/gst/d3d11/gstd3d11device.cpp(271): note: This conversion requires a reinterpret_cast, a C-style cast or function-style cast
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3118>
We were checking possible bind flags for the DXGI format
of the source texture but that's never applied to
the destination texture desc.
Just use the already configured bind (and misc) flags of source texture
for the destination texture allocation without additional check.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2950>
* Private header name is changed to gstd3d11-private.h to follow
naming convention
* Add Since mark everywhere
* Update member variable names to be consistent with the other
object implementations in this library
* Correct outdated documentation
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2945>
GLib's GRecMutex will allocate another heap memory for CRITICAL_SECTION
struct and g_rec_mutex_lock/g_rec_mutex_unlock use WIN32 APIs actually.
We don't need such intermediate function calls and redundant heap allocation.
Just call WIN32 APIs directly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2845>
Depending on device feature level, d3d11 runtime can support
ID3D11Fence which is equivalent to ID3D12Fence.
Waiting using fence has performance-wise benefit over pulling
ID3D11Query status. If ID3D11Fence is not supported by device,
then ID3D11Query will be used instead.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2790>
We should move this functionality to gst-libs so that GstD3D11Converter
can be moved to gst-libs.
Another advantage is that applications can call our
HLSL compiler wrapper method without any worry about OS version
dependent system installed HLSL library.
Note that there are multiple HLSL compiler library versions
on Windows and system installed one would be OS version dependent.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2760>
Our Direct3D11 abstraction layer has been improved and
it gained good shape from API point of view.
Also, On Windows, GstD3D11 has various advantages over GstGL
in terms of compatibility/stability/feature/performance.
Note that WGL implementation is known to be buggy for some
drivers/vendors/scenario (that's a reason why Google implemented ANGLE).
Moreover, GstGL is not fully optimized for Windows unfortunately.
It's the time to open this interface to application developers
for various optimized processing using our Direct3D11
infrastructure.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2646>
