summaryrefslogtreecommitdiffstats
path: root/video/out/d3d11/ra_d3d11.c
Commit message (Collapse)AuthorAgeFilesLines
* d3d11: disable IDXGIInfoQueue usage if dxgidebug.h is incompleteKacper Michajłow2024-04-191-0/+12
| | | | Older MinGW-w64 doesn't define IDXGIInfoQueue in dxgidebug.h.
* d3d11: use IDXGIInfoQueue instead ID3D11InfoQueueKacper Michajłow2024-04-191-50/+27
| | | | | | | | | DXGI debug interface encapsulate multiple message queues, which allows to get validation not only for D3D11 calls, but also DXGI ones. Also this makes leak detector not report self debug interface as alive like it was before. And same as with validation, it has ability to detect more alive objects, not being limited to D3D11.
* ra_d3d11: fix off by one checkKacper Michajłow2023-11-181-2/+2
|
* d3d11: don't skip last char in bufferKacper Michajłow2023-10-191-1/+1
| | | | | Both buffers have the same size (32) and if the source is not null terminated it should be fixed there. Copy whole buffer.
* vo: convert some final low-hanging things to nanosecondsDudemanguy2023-10-161-10/+10
|
* ra_d3d11: change how messages are ignored during texture size lookupKacper Michajłow2023-05-181-13/+9
| | | | | | | | | | | | Filtering globally D3D11_MESSAGE_ID_CREATETEXTURE2D_INVALIDDIMENSIONS is suboptimal, because can also hide other invalid usages. In the same time it is not enough, because not only this message is emitted, but also one about E_INVALIDARG. Just flush queue before and clear messages after to ignore this part of code. As a side note, I don't believe this texture size lookup is in fact useful, but since it is there and is relatively harmless, let's leave it as is.
* various: fix typosHarri Nieminen2023-03-281-1/+1
| | | | Found by codespell
* vo_d3d11: do not call MAKEINTRESOURCEW twiceKacper Michajłow2023-02-021-1/+1
|
* various: replace abort() with MP_ASSERT_UNREACHABLE() where appropriatesfan52023-01-121-1/+1
| | | | | | | | In debug mode the macro causes an assertion failure. In release mode it works differently and tells the compiler that it can assume the codepath will never execute. For this reason I was conversative in replacing it, e.g. in mpv-internal code that exhausts all valid values of an enum or when a condition is clear from directly preceding code.
* {video,audio}: adjust unsafe strncpy usagessfan52023-01-121-2/+2
|
* ra_d3d11: fix incorrect typesfan52023-01-121-1/+1
| | | | As it happens, `SIZE_T` and `size_t` are not the same length on 32-bit Windows
* vo_gpu/d3d11: fix VRAM leakGraham Booker2022-07-211-1/+1
| | | | | | A VRAM memory leak was present in d3d11 when `idle=yes` and playback stops for an item. This patch re-enables some of the code which is only used during diagnostic which fixes the issue.
* vo_gpu/d3d11: add message ID based log level mappingJan Ekström2022-04-111-6/+64
| | | | | | | | | | | | | This lets us remap various messages which might now be happening at each frame onto the trace level, thus unaffecting the initial debug log level. Additionally - thanks to this ability - the previously globally denied message queue abandonment messages can now be handled and mapped to trace log level, as on that log level they may be of use. Recommended by rossy and based on his libplacebo commit 6d72f6445566eddb0493447d0bda72d98a99d40c .
* vo_gpu/d3d11: add helper function to get ra_format from DXGI_FORMATJan Ekström2022-04-111-0/+12
|
* vo_gpu_next: add D3D11 RA texture wrapping/unwrapping for hwdecJames Ross-Gowan2022-03-031-4/+15
| | | | This mostly copies the API used in the GL backend.
* vo_gpu: stop hard-coding max compute group threadsPhilip Langdale2021-12-191-0/+2
| | | | | | | | | | We've been assuming that maximum number of compute group threads is never less than the 1024 defined by the desktop GL spec. Given that we haven't had working compute shaders for GLES and I guess the Vulkan spec defines at least as high a value, we've gotten away with it so far. But we should really look the value up and respect it.
* vo_gpu: d3d11: set the ra_format.storable flagJames Ross-Gowan2019-10-271-3/+12
| | | | | This flag was added in e2976e662d92, but it was only set for Vulkan. In D3D11 it can be set from info in D3D11_FEATURE_FORMAT_SUPPORT2.
* vo_gpu: d3d11: use linear filtering for wrapped texturesJames Ross-Gowan2019-10-101-1/+3
| | | | | | | | | | This affects hwdec_dxva2dxgi, which uses ra_d3d11_wrap_tex to wrap RGB video frames that are shared with a D3D9 device. Without it, mpv uses nearest instead of bilinear scaling with --scale=bilinear (the default) and --hwdec=dxva2. It's kind of hard to believe this bug has gone unnoticed for almost two years, but that seems to have been the case. Fixes: #7042
* vo_gpu: d3d11: fix storage lifetime of compound literalsJames Ross-Gowan2019-08-201-8/+15
| | | | | | | | | | | | | | | | Somehow I got the idea that compound literals had function-scoped lifetime. Instead, like all other objects with automatic storage duration, compound literals are block-scoped, so they become invalid after exiting the block they were declared in. It seems like a recent change to GCC actually reuses the memory that the compound literals used to occupy, which was causing a few bugs. The pattern of conditionally assigning a pointer to a compound literal was used in a few places in ra_d3d11 where the Direct3D API expects either a pointer to an initialised struct or NULL. Change these to ensure the lifetime of the struct includes the API call. Should fix #6775.
* video/out/gpu: Add a `storable` flag to ra_formatPhilip Langdale2019-07-081-0/+3
| | | | | | | | | | | | | | | | While `ra` supports the concept of a texture as a storage destination, it does not support the concept of a texture format being usable for a storage texture. This can lead to us attempting to create a texture from an incompatible format, with undefined results. So, let's introduce an explicit format flag for storage and use it. In `ra_pl` we can simply reflect the `storable` flag. For GL and D3D, we'll need to write some new code to do the compatibility checks. I'm not going to do it here because it's not a regression; we were already implicitly assuming all formats were storable. Fixes #6657
* vo_gpu: d3d11: use the SPIRV-Cross C API directlyJames Ross-Gowan2019-06-121-19/+67
| | | | | | | | | | When the D3D11 backend was first written, SPIRV-Cross only had a C++ API and no guarantee of API or ABI stability, so instead of using SPIRV-Cross directly, mpv used an unofficial C wrapper called crossc. Now that KhronosGroup/SPIRV-Cross#611 is resolved, SPIRV-Cross has an official C API that can be used instead, so remove crossc and use SPIRV-Cross directly.
* vo_gpu: index desc namespaces by raNiklas Haas2019-04-211-1/+1
| | | | | No reason to require them be constant. This allows them to depend on runtime characteristics of the `ra`.
* vo_gpu: d3d11: implement tex_download()James Ross-Gowan2018-02-131-0/+57
| | | | | | | This allows the new GPU screenshot functionality introduced in 9f595f3a80ee to work with the D3D11 backend. It replaces the old window screenshot functionality, which was shared between D3D11 and ANGLE. The old code can be removed, since it's not needed by ANGLE anymore either.
* vo_gpu: hwdec_dxva2dxgi: initial implementationJames Ross-Gowan2018-01-061-0/+1
| | | | | | | | | | | | | This enables DXVA2 hardware decoding with ra_d3d11. It should be useful for Windows 7, where D3D11VA is not available. Images are transfered from D3D9 to D3D11 using D3D9Ex surface sharing[1]. Following Microsoft's recommendations, it uses a queue of shared surfaces, similar to Microsoft's ISurfaceQueue. This will hopefully prevent surface sharing from impacting parallelism and allow multiple D3D11 frames to be in-flight at once. [1]: https://msdn.microsoft.com/en-us/library/windows/desktop/ee913554.aspx
* vo_gpu: d3d11: avoid copying staging buffers to cbuffersJames Ross-Gowan2018-01-011-48/+15
| | | | | | | | | | | | | | | | Apparently some Intel drivers have a bug where copying from staging buffers to constant buffers does not work. We used to keep a copy of the buffer data in a staging buffer to enable partial constant buffer updates. To work around this bug, keep the copy in talloc-allocated system memory instead. There doesn't seem to be any noticable performance difference from keeping the copy in system memory. Our cbuffers are probably too small for it to matter anyway. See also: https://crbug.com/593024 Fixes #5293
* vo_gpu: d3d11: check for timestamp query supportJames Ross-Gowan2017-12-091-0/+9
| | | | | | | | | | Apparently timestamp queries are optional for 10level9 devices. Check for support when creating the device rather than spamming error messages during rendering. CreateQuery can be used to check for support by passing NULL as the final parameter. See: https://msdn.microsoft.com/en-us/library/windows/desktop/ff476150.aspx#ID3D11Device_CreateQuery
* vo_gpu: d3d11: don't use runtime version for UAV slot countJames Ross-Gowan2017-11-191-1/+1
| | | | | | FL 11_1 is only supported with the Direct3D 11.1 runtime anyway, so there is no need to check both the runtime version and the feature level.
* vo_gpu: d3d11: mark the bgra8 format as unorderedJames Ross-Gowan2017-11-191-1/+1
| | | | Whoops. I was confused by the double-negative here.
* vo_gpu: d3d11: remove flipped texture upload hackJames Ross-Gowan2017-11-121-8/+0
| | | | Made unnecessary by 4a6b04bdb930.
* vo_gpu: hwdec_d3d11va: allow zero-copy video decodingJames Ross-Gowan2017-11-071-13/+51
| | | | | | | | | | | | | | Like the manual says, this is technically undefined behaviour. See: https://msdn.microsoft.com/en-us/library/windows/desktop/ff476085.aspx In particular, MSDN says texture arrays created with the BIND_DECODER flag cannot be used with CreateShaderResourceView, which means they can't be sampled through SRVs like normal Direct3D textures. However, some programs (Google Chrome included) do this anyway for performance and power-usage reasons, and it appears to work with most drivers. Older AMD drivers had a "bug" with zero-copy decoding, but this appears to have been fixed. See #3255, #3464 and http://crbug.com/623029.
* vo_gpu: d3d11: enhance cache invalidationJames Ross-Gowan2017-11-071-4/+70
| | | | | | | | The shader cache in ra_d3d11 caches the result of shaderc, crossc and the D3DCompiler DLL, so it should be invalidated when any of those components are updated. This should make the cache more reliable, which makes it safer to enable gpu-shader-cache-dir. Shader compilation is slow with D3D11, so gpu-shader-cache-dir is highly necessary
* vo_gpu: d3d11: log shader compilation timesJames Ross-Gowan2017-11-071-0/+26
| | | | | | | Some shaders take a _long_ time to compile with the Direct3D compiler. The ANGLE backend had this problem too, to a certain extent. Logging should help identify which shaders cause long stalls and could also help with benchmarking ways of reducing compile times.
* vo_gpu: d3d11: add RA caps for ra_d3d11James Ross-Gowan2017-11-071-0/+5
| | | | | | | | | | | | | | | | ra_d3d11 uses the SPIR-V compiler to translate GLSL to SPIR-V, which is then translated to HLSL. This means it always exposes the same GLSL version that the SPIR-V compiler supports (4.50 for shaderc/glslang.) Despite claiming to support GLSL 4.50, some features that are tied to the GLSL version in OpenGL are not supported by ra_d3d11 when targeting legacy Direct3D feature levels. This includes two features that mpv relies on: - Reading from gl_FragCoord in the fragment shader (requires FL 10_0) - textureGather from any texture component (requires FL 11_0) These features have been exposed as new RA caps.
* vo_gpu: d3d11: initial implementationJames Ross-Gowan2017-11-071-0/+2235
This is a new RA/vo_gpu backend that uses Direct3D 11. The GLSL generated by vo_gpu is cross-compiled to HLSL with SPIRV-Cross. What works: - All of mpv's internal shaders should work, including compute shaders. - Some external shaders have been tested and work, including RAVU and adaptive-sharpen. - Non-dumb mode works, even on very old hardware. Most features work at feature level 9_3 and all features work at feature level 10_0. Some features also work at feature level 9_1 and 9_2, but without high-bit- depth FBOs, it's not very useful. (Hardware this old is probably not fast enough for advanced features anyway.) Note: This is more compatible than ANGLE, which requires 9_3 to work at all (GLES 2.0,) and 10_1 for non-dumb-mode (GLES 3.0.) - Hardware decoding with D3D11VA, including decoding of 10-bit formats without truncation to 8-bit. What doesn't work / can be improved: - PBO upload and direct rendering does not work yet. Direct rendering requires persistent-mapped PBOs because the decoder needs to be able to read data from images that have already been decoded and uploaded. Unfortunately, it seems like persistent-mapped PBOs are fundamentally incompatible with D3D11, which requires all resources to use driver- managed memory and requires memory to be unmapped (and hence pointers to be invalidated) when a resource is used in a draw or copy operation. However it might be possible to use D3D11's limited multithreading capabilities to emulate some features of PBOs, like asynchronous texture uploading. - The blit() and clear() operations don't have equivalents in the D3D11 API that handle all cases, so in most cases, they have to be emulated with a shader. This is currently done inside ra_d3d11, but ideally it would be done in generic code, so it can take advantage of mpv's shader generation utilities. - SPIRV-Cross is used through a NIH C-compatible wrapper library, since it does not expose a C interface itself. The library is available here: https://github.com/rossy/crossc - The D3D11 context could be made to support more modern DXGI features in future. For example, it should be possible to add support for high-bit-depth and HDR output with DXGI 1.5/1.6.
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-07 10:58:51 +0000