From 68eac1a1e7ac931576a8b59dd159a7961189ca48 Mon Sep 17 00:00:00 2001 From: James Ross-Gowan Date: Thu, 7 Sep 2017 20:18:06 +1000 Subject: vo_gpu: d3d11: initial implementation 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. --- DOCS/man/options.rst | 41 +++++++++++++++++++++++++++++++++++------ 1 file changed, 35 insertions(+), 6 deletions(-) (limited to 'DOCS/man/options.rst') diff --git a/DOCS/man/options.rst b/DOCS/man/options.rst index a6c2136947..d6dfc48535 100644 --- a/DOCS/man/options.rst +++ b/DOCS/man/options.rst @@ -686,8 +686,8 @@ Video :dxva2: requires ``--vo=gpu`` with ``--gpu-context=angle`` or ``--gpu-context=dxinterop`` (Windows only) :dxva2-copy: copies video back to system RAM (Windows only) - :d3d11va: requires ``--vo=gpu`` with ``--gpu-context=angle`` - (Windows 8+ only) + :d3d11va: requires ``--vo=gpu`` with ``--gpu-context=d3d11`` or + ``--gpu-context=angle`` (Windows 8+ only) :d3d11va-copy: copies video back to system RAM (Windows 8+ only) :mediacodec: requires ``--vo=mediacodec_embed`` (Android only) :mediacodec-copy: copies video back to system RAM (Android only) @@ -775,10 +775,11 @@ Video BT.601 or BT.709, a forced, low-quality but correct RGB conversion is performed. Otherwise, the result will be totally incorrect. - ``d3d11va`` is usually safe (if used with ANGLE builds that support - ``EGL_KHR_stream path`` - otherwise, it converts to RGB), except that - 10 bit input (HEVC main 10 profiles) will be rounded down to 8 bits, - which results in reduced quality. + ``d3d11va`` is safe when used with the ``d3d11`` backend. If used with + ``angle`` is it usually safe, except that 10 bit input (HEVC main 10 + profiles) will be rounded down to 8 bits, which will result in reduced + quality. Also note that with very old ANGLE builds (without + ``EGL_KHR_stream path``,) all input will be converted to RGB. ``dxva2`` is not safe. It appears to always use BT.601 for forced RGB conversion, but actual behavior depends on the GPU drivers. Some drivers @@ -4272,6 +4273,30 @@ The following video options are currently all specific to ``--vo=gpu`` and as mpv's vulkan implementation currently does not try and protect textures against concurrent access. +``--d3d11-warp=`` + Use WARP (Windows Advanced Rasterization Platform) with the D3D11 GPU + backend (default: auto). This is a high performance software renderer. By + default, it is only used when the system has no hardware adapters that + support D3D11. While the extended GPU features will work with WARP, they + can be very slow. + +``--d3d11-feature-level=<12_1|12_0|11_1|11_0|10_1|10_0|9_3|9_2|9_1>`` + Select a specific feature level when using the D3D11 GPU backend. By + default, the highest available feature level is used. This option can be + used to select a lower feature level, which is mainly useful for debugging. + Most extended GPU features will not work at 9_x feature levels. + +``--d3d11-flip=`` + Enable flip-model presentation, which avoids unnecessarily copying the + backbuffer by sharing surfaces with the DWM (default: yes). This may cause + performance issues with older drivers. If flip-model presentation is not + supported (for example, on Windows 7 without the platform update), mpv will + automatically fall back to the older bitblt presentation model. + +``--d3d11-sync-interval=<0..4>`` + Schedule each frame to be presented for this number of VBlank intervals. + (default: 1) Setting to 1 will enable VSync, setting to 0 will disable it. + ``--spirv-compiler=`` Controls which compiler is used to translate GLSL to SPIR-V. This is (currently) only relevant for ``--gpu-api=vulkan``. The possible choices @@ -4694,6 +4719,8 @@ The following video options are currently all specific to ``--vo=gpu`` and Win32, using WGL for rendering and Direct3D 9Ex for presentation. Works on Nvidia and AMD. Newer Intel chips with the latest drivers may also work. + d3d11 + Win32, with native Direct3D 11 rendering. x11 X11/GLX x11vk @@ -4728,6 +4755,8 @@ The following video options are currently all specific to ``--vo=gpu`` and Allow only OpenGL (requires OpenGL 2.1+ or GLES 2.0+) vulkan Allow only Vulkan (requires a valid/working ``--spirv-compiler``) + d3d11 + Allow only ``--gpu-context=d3d11`` ``--opengl-es=`` Controls which type of OpenGL context will be accepted: -- cgit v1.2.3