X-Git-Url: https://git.sesse.net/?p=movit;a=blobdiff_plain;f=README;h=aef8bc72a2ff60ef2905b173e522e7b8952cccbd;hp=06afddee89782e1228eb3dab5f973b293e0db53a;hb=dff7a05663a3c9c32cf1d75b928fac3ebe384ffd;hpb=0ed2c7fe3876a49d1565e3425e5a491206ffe32d

diff --git a/README b/README
index 06afdde..aef8bc7 100644
--- a/README
+++ b/README
@@ -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
@@ -91,12 +89,12 @@ OK, I can read a bit. What do you mean by “modern”?
 Backwards compatibility is fine and all, but sometimes we can do better
 by observing that the world has moved on. In particular:
 
-* It's 2017, so people want to edit HD video.
-* It's 2017, so everybody has a GPU.
-* It's 2017, so everybody has a working C++ compiler.
+* It's 2018, so people want to edit HD video.
+* It's 2018, so everybody has a GPU.
+* It's 2018, so everybody has a working C++ compiler.
   (Even Microsoft fixed theirs around 2003!)
 
-While from a programming standpoint I'd love to say that it's 2016
+While from a programming standpoint I'd love to say that it's 2018
 and interlacing does no longer exist, but that's not true (and interlacing,
 hated as it might be, is actually a useful and underrated technique for
 bandwidth reduction in broadcast video). Movit may eventually provide
@@ -113,15 +111,18 @@ is written using straight-up single-threaded, scalar C! Clearly there is
 room for improvement here, and that improvement is sorely needed.
 We want to edit 1080p video, not watch slideshows.
 
-Movit has chosen to run all pixel processing on the GPU, using GLSL—OpenCL is
-way too young, and CUDA is single-vendor (and also surprisingly hard to
-get good performance from for anything nontrivial). While “run on the GPU”
-does not equal “infinite speed” (I am fairly certain that for many common
-filters, I can beat the Intel-based GPU in my laptop with multithreaded SSE
-code on the CPU—especially as moving the data to and from the GPU has a cost that is not
-to be taken lightly), 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.
+Movit has chosen to run all pixel processing on the GPU, mostly using GLSL
+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
+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).
 
 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,