]> git.sesse.net Git - movit/blobdiff - README
Release Movit 1.7.1.
[movit] / README
diff --git a/README b/README
index 79a63d9b0d78a8ee066306392b9beeb40eef23a3..0d99fabb1a1eea842a7bb5c2505cc249f98d378c 100644 (file)
--- a/README
+++ b/README
@@ -17,7 +17,7 @@ TL;DR, please give me download link and system demands
 
 OK, you need
 
-* A C++11 compiler. GCC will do. (I haven't tried Windows, but it
+* A C++14 compiler. GCC will do. (I haven't tried Windows, but it
   works fine on Linux and OS X, and Movit is not very POSIX-bound.)
 * GNU Make.
 * A GPU capable of running OpenGL 3.0 or newer. GLES3 (for mobile devices)
@@ -29,11 +29,9 @@ OK, you need
 * The [epoxy] library, for dealing with OpenGL extensions on various
   platforms.
 
-Movit has been tested with Intel GPUs with the Mesa drivers
-(you'll probably need at least Mesa 8.0), Radeon 3850 and GeForce GTX 550
-on Linux with the manufacturer's drivers, and with GeForce 8800 on OS X.
-Again, most likely, GPU compatibility shouldn't be a big issue. See below
-for performance estimates.
+Movit has been tested with various Intel, AMD and NVIDIA GPUs, on Linux
+and Windows. Again, most likely, GPU compatibility shouldn't be a big issue.
+See below for performance estimates.
 
 
 Still TL;DR, please give me the list of filters
@@ -118,13 +116,13 @@ fragment shaders. While “run on the GPU” does not equal “infinite speed”
 GPU programming is probably the _simplest_ way of writing highly parallel code,
 and it also frees the CPU to do other things like video decoding.
 
-Although compute shaders are supported, and can be used or speedups if
+Although compute shaders are supported, and can be used for speedups if
 available (currently, only the deinterlacer runs as a compute shader), it is
 surprisingly hard to get good performance for compute shaders for anything
 nontrivial. This is also one of the primary reasons why Movit uses GLSL and
 not any of the major GPU compute frameworks (CUDA and OpenCL), although it
 is also important that it is widely supported (unlike CUDA) and driver quality
-general is fairly good (unlike OpenCL).
+generally is fairly good (unlike OpenCL).
 
 Exactly what speeds you can expect is of course highly dependent on
 your GPU and the exact filter chain you are running. As a rule of thumb,