Convert a loop to range-based for.

[movit] / README

diff --git a/README b/README
index 06afddee89782e1228eb3dab5f973b293e0db53a..dfddd7ad596dc633727cb718aa4e7e7bbadc0643 100644 (file)
--- a/README
+++ b/README
@@ -29,11 +29,9 @@ OK, you need
 * The [epoxy] library, for dealing with OpenGL extensions on various
   platforms.
 
 * 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
 
 
 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:
 
 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!)
 
   (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
 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.
 
 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 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
+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,
 
 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,