Let the application manage PBOs.

Creating a PBO to hold the texture data just before upload (like we
did before this patch) is pointless; if that would help at all, the driver
could just do it itself. Instead, we expose the PBOs to the application
(in a way such that applications that don't care can continue to use
the simple interface). This means that a client that needs to do
e.g. a fade can optimize its texture upload by a process like this:

  1. Decode frame from input A.
  2. Upload frame from input A to GPU (by putting it into a PBO).
     Texture upload starts in the background.
  3. Decode frame from input B.
  4. Upload frame from input B to GPU. (This time, there will be
     no parallelism, though.)
  5. Render.

With correct use of ping-ponging PBOs, it is also possible to overlap
step 4/5 with operations from the _next_ frame in the fade.

More information can be found in this presentation:

  http://on-demand.gputechconf.com/gtc/2012/presentations/S0356-GTC2012-Texture-Transfers.pdf
Remove unused element need_texture_update from DitherEffect.

Found by Coverity Scan.
Remove the support for 1D textures as parameters.

This isn't required anymore after the Gamma{Compression,Expansion}Effect
stopped using it; and after seeing how it was easy to missample them
with regards to texture coordinates, I'm not honestly so sure anymore
they were a good idea in the first place.
Add a file-level comment for EffectChain.
Document EffectChain threading considerations.
Add a shared ResourcePool to share resources between EffectChains.

Right now in this first implementation, we only share shaders,
which mainly saves compile time when multiple EffectChains are
similar (e.g., many clips all are modified by white balance only).
However, in the future, the plan is for them to also be able to
share temporary textures.
Make effect_id phase-local instead of global.

This is mainly to reduce the number of substantially identical shaders
we have to keep around and compile; even though two chains may be
different, often, some phase (and very often, a large one at that)
will be similar. However, in the old system, since effects had global
IDs, a change in an earlier phase would displace identifiers in a
later one, and the shader would be uncacheable.

Note that this means that an effect can actually have multiple effect_ids
now (since it could already be part of multiple phases). This is the
reason why we can't just keep having a single effect_id on the node
that we set phase-locally; it really needs to be different between phases.
We need to link the main library against pthreads now, since we lock in ResourcePool.
Add a new effect that can do FFT/IFFT.
Turn off .dot and .frag file generation during unit tests.

Even though this is sometimes useful in the effect_chain_test,
this makes the test suite literally five times as fast on my
machine due to all the disk I/O. We can always turn it on again
when debugging specific issues.
Store GL_FLOAT FlatInputs as fp32, not fp16.

There are two primary reasons for this:

 - GL_FLOAT FlatInput is primarily used for tests, and even more importantly,
   mostly accuracy tests. ATI's drivers appear to round off fp32 -> fp16
   wrong (truncate instead of round), which breaks some of these tests.
 - In case someone _would_ use GL_FLOAT inputs, they'd probably be updated
   every frame anyway, so the fp32 -> fp16 conversion step (probably on CPU)
   will negate any performance benefits by fp16 sampling anyway.
Round explicitly after dithering, for GPUs that don't do it properly themselves.

This was causing unit test failures in the DitherEffect unit test both on
ATI and nVidia GPUs; Intel also rounds somewhat inaccurately, but much,
much better, so the extra code won't be activated for them.

I think this might be driver-dependent, but we will detect it correctly
in any case.
Disable OpenGL dithering, just to be on the safe side.

I don't actually think any modern OpenGL implementations actually
heed this flag for 8-bit rendering, but it's fine to be on the safe
side nevertheless.
Retire the GL_GENERATE_MIPMAP hack for FlatInput.

I found very similar workaround code for this bug in Chromium,
with the following comment:

  // Workaround for Mac driver bug. In the large scheme of things setting
  // glTexParamter twice for glGenerateMipmap is probably not a lage performance
  // hit so there's probably no need to make this conditional. The bug appears
  // to be that if the filtering mode is set to something that doesn't require
  // mipmaps for rendering, or is never set to something other than the default,
  // then glGenerateMipmap misbehaves.

Going back all the way to the point in which this code was written,
it is indeed true; we called glGenerateMipmap(), and then right afterwards
set the mode to GL_LINEAR_MIPMAP_NEAREST. Since then, the code has been
reorganized and moved around a lot, and now we set the mode long before
the first call to glGenerateMipmap(), and thus we can retire the hack;
simply generate mipmaps on-demand, and that's the end of it. I tested
with the Mesa 8.0.x version where I originally saw this bug, and it passes
flat_input_test without any problems (well, actually all tests except
the tests for deconvolution sharpen, whose shaders are too big for it).

This is nice not only because it gives us a less hacky structure, but also
because GL_GENERATE_MIPMAPS is a nightmare for the driver to handle;
several edge conditions are tricky, from what I've been told.
Add support to the ResourcePool for 2D textures.

Currently we don't have a freelist, but this will change shortly.
Complete a forgotten comment.
Fix YCbCrInput after the ResourcePool texture changes.
Add missing format LUMINANCE8.
Implement the texture freelist in ResourcePool.
Use the ResourcePool to allocate RTT textures in EffectChain.