Let the application manage PBOs.
authorSteinar H. Gunderson <sgunderson@bigfoot.com>
Sat, 11 Jan 2014 23:48:41 +0000 (00:48 +0100)
committerSteinar H. Gunderson <sgunderson@bigfoot.com>
Sun, 12 Jan 2014 00:07:20 +0000 (01:07 +0100)
commit9cf78e3b5a801b7841133011f74fc7962861705d
treea1732d8e2749ca1c3447c47340cf06126305d40f
parent9ab1efe8dbd389f309a8a3e7f68c48f114a2b901
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
flat_input.cpp
flat_input.h
flat_input_test.cpp
ycbcr_input.cpp
ycbcr_input.h
ycbcr_input_test.cpp