Mesa is much less buggy now.

[nageru-docs] / hardware.rst

diff --git a/hardware.rst b/hardware.rst
index 5171baebad937eb69e415cf28b08572175a5d86d..344744e347eb362b5aafbe0acc3eb0840e094bbe 100644 (file)
--- a/hardware.rst
+++ b/hardware.rst
@@ -14,11 +14,10 @@ high-quality (as in e.g. gamma-correct fades and high-quality scaling)
 HD video without a monster CPU, but it also comes with certain caveats.
 
 In particular, Nageru's use of multithreaded OpenGL trickles bugs in
-some drivers, as most games access the GPU from only one thread;
-Mesa didn't work properly at all before version 11.2, and there are still
-bugs left as of 13.0. However, in general, Intel GPUs from the Haswell
-generation and newer should work well with Nageru as long as you stick to
-720p60 (ie., no 1080i inputs, which require deinterlacing). NVIDIA's
+some drivers. in general, Intel GPUs from the Haswell
+generation and newer should work well with Nageru, although they may
+see performance issues if you connect interlaced sources (since the
+automatic deinterlacing applied requires a fair bit of computing power). NVIDIA's
 proprietary drivers (occasionally known as nvidia-glx) are generally excellent
 and should give few issues in this regard.
 
@@ -39,7 +38,7 @@ output as a sort of “digital intermediate” that can much easier be stored to
 (for future editing or re-streaming) or sent to an encoder on another machine
 for final streaming.
 
-Although you can (since Nageru 1.5.0) use software encoding through x264 for
+Although you can use software encoding through x264 for
 the digital intermediate, it is generally preferred to use a hardware encoder
 if it is available. Currently, VA-API is the only hardware encoding method
 supported for encoding the digital intermediate, although Nageru might support
@@ -60,18 +59,8 @@ need to be reencoded by some external means, or you can use Nageru's x264
 support to produce a user-facing stream in addition to the digital intermediate
 (see :doc:`streaming`).
 
-By default, Nageru uses zerocopy from the GPU to the VA-API buffers in order to
-reduce memory transfer bandwidth, but this depends on EGL support (as opposed to
-the older GLX standard), and also that the GPU you are rendering to also
-supports VA-API. NVIDIA's proprietary drivers do not support either. Unfortunately,
-this is somewhat cumbersome to automatically detect before it's too late to do anything
-about it (Qt has already initialized using EGL), so on NVIDIA
-systems, Nageru will exit with an error message asking you to set *--va-display*
-to your Intel GPU manually. Simply follow the instructions printed to the terminal
-to select what looks like your Intel GPU, and Nageru will fall back to using GLX
-and transferring the memory data between the two GPUs via the CPU. (Some BIOSes
-automatically disable the Intel GPU if you have a discrete GPU installed; you
-will need to reenable it to get access to QSV, or Nageru can't run.)
+If possible, Nageru uses zerocopy from the GPU to the VA-API buffers in order to
+reduce memory transfer bandwidth.
 
 
 Video capture cards
@@ -129,8 +118,9 @@ from subsampled Y'CbCr (typically 4:2:2 for inputs and 4:2:0 for outputs)
 is done transparently on the GPU. Input and output is 8-bit Y'CbCr by default,
 but be aware that 8-bit Y'CbCr, however common, cannot capture the full color
 fidelity of 8-bit RGB (not to mention 10-bit RGB). If you have spare GPU power,
-you can enable 10-bit Y'CbCr input and output with --10-bit-input and
---10-bit-output, respectively, although you should be aware that client
+you can enable 10-bit Y'CbCr input and output with --10-bit (before Nageru 2.2.0,
+you needed to use --10-bit-input and --10-bit-output as separate flags),
+although you should be aware that client
 support for 10-bit H.264 is very limited. Also, Quick Sync Video does not
 support 10-bit H.264 encoding, so in this case, the digital intermediate needs
 to be encoded in software.