doc/html/appendix-g-section-03.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
   2 <html>
   3 <head>
   4 <meta name="generator" content=
   5 "HTML Tidy for FreeBSD (vers 1 September 2005), see www.w3.org">
   6 <meta http-equiv="Content-Type" content=
   7 "text/html; charset=us-ascii">
   8 <title>Getting the Best Performance from the API</title>
   9 <meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
  10 <link rel="start" href="index.html" title=
  11 "NVIDIA Accelerated FreeBSD Graphics Driver README and Installation Guide">
  12 <link rel="up" href="appendix-g.html" title=
  13 "Appendix&nbsp;G.&nbsp;VDPAU Support">
  14 <link rel="prev" href="appendix-g-section-02.html" title=
  15 "Performance Levels">
  16 <link rel="next" href="appendix-g-section-04.html" title=
  17 "Additional Notes">
  18 </head>
  19 <body>
  20 <div class="navheader">
  21 <table width="100%" summary="Navigation header">
  22 <tr>
  23 <th colspan="3" align="center">Getting the Best Performance from
  24 the API</th>
  25 </tr>
  26 <tr>
  27 <td width="20%" align="left"><a accesskey="p" href=
  28 "appendix-g-section-02.html">Prev</a>&nbsp;</td>
  29 <th width="60%" align="center">Appendix&nbsp;G.&nbsp;VDPAU
  30 Support</th>
  31 <td width="20%" align="right">&nbsp;<a accesskey="n" href=
  32 "appendix-g-section-04.html">Next</a></td>
  33 </tr>
  34 </table>
  35 <hr></div>
  36 <div class="section" lang="en">
  37 <div class="titlepage">
  38 <div>
  39 <div>
  40 <h2 class="title" style="clear: both"><a name="id2658870" id=
  41 "id2658870"></a>Getting the Best Performance from the API</h2>
  42 </div>
  43 </div>
  44 </div>
  45 <p>System performance (raw throughput, latency, and jitter
  46 tolerance) can be affected by a variety of factors. One of these
  47 factors is how the client application uses VDPAU; i.e. the number
  48 of surfaces allocated for buffering, order of operations, etc.</p>
  49 <p>NVIDIA GPUs typically contain a number of separate hardware
  50 modules that are capable of performing different parts of the video
  51 decode, post-processing, and display operations in parallel. To
  52 obtain the best performance, the client application must attempt to
  53 keep all these modules busy with work at all times.</p>
  54 <p>Consider the decoding process. At a bare minimum, the
  55 application must allocate one video surface for each reference
  56 frame that the stream can use (2 for MPEG or VC-1, a variable
  57 stream-dependent number for H.264) plus one surface for the picture
  58 currently being decoded. However, if this minimum number of
  59 surfaces is used, performance may be poor. This is because
  60 back-to-back decodes of non-reference frames will need to be
  61 written into the same video surface. This will require that decode
  62 of the second frame wait until decode of the first has completed; a
  63 pipeline stall.</p>
  64 <p>Further, if the video surfaces are being read by the video mixer
  65 for post-processing, and eventual display, this will "lock" the
  66 surfaces for even longer, since the video mixer needs to read the
  67 data from the surface, which prevents any subsequent decode
  68 operations from writing to the surface. Recall that when advanced
  69 de-interlacing techniques are used, a history of video surfaces
  70 must be provided to the video mixer, thus necessitating that even
  71 more video surfaces be allocated.</p>
  72 <p>For this reason, NVIDIA recommends the following number of video
  73 surfaces be allocated:</p>
  74 <div class="itemizedlist">
  75 <ul type="disc">
  76 <li>
  77 <p>(num_ref + 3) for progressive content, and no
  78 de-interlacing.</p>
  79 </li>
  80 <li>
  81 <p>(num_ref + 5) for interlaced content using advanced
  82 de-interlacing.</p>
  83 </li>
  84 </ul>
  85 </div>
  86 <p></p>
  87 <p>Next, consider the display path via the presentation queue. This
  88 portion of the pipeline requires at least 2 output surfaces; one
  89 that is being actively displayed by the presentation queue, and one
  90 being rendered to for subsequent display. As before, using this
  91 minimum number of surfaces may not be optimal. For some video
  92 streams, the hardware may only achieve real-time decoding on
  93 average, not for each individual frame. Using compositing APIs to
  94 render on-screen displays, graphical user interfaces, etc., may
  95 introduce extra jitter and latency into the pipeline. Similarly,
  96 system level issues such as scheduler algorithms and system load
  97 may prevent the CPU portion of the driver from operating for short
  98 periods of time. All of these potential issues may be solved by
  99 allocating more output surfaces, and queuing more than one
 100 outstanding output surface into the presentation queue.</p>
 101 <p>The reason for using more than the minimum number of video
 102 surfaces is to ensure that the decoding and post-processing
 103 pipeline is not stalled, and hence is kept busy for the maximum
 104 amount of time possible. In contrast, the reason for using more
 105 than the minimum number of output surfaces is to hide jitter and
 106 latency in various GPU and CPU operations.</p>
 107 <p>The choice of exactly how many surfaces to allocate is a
 108 resource usage v.s. performance trade-off; Allocating more than the
 109 minimum number of surfaces will increase performance, but use
 110 proportionally more video RAM. This may cause allocations to fail.
 111 This could be particularly problematic on systems with a small
 112 amount of video RAM. A stellar application would automatically
 113 adjust to this by initially allocating the bare minimum number of
 114 surfaces (failures being fatal), then attempting to allocate more
 115 and more surfaces, provided the allocations kept succeeding, up to
 116 the suggested limits above.</p>
 117 <p>The video decoder's memory usage is also proportional to the
 118 maximum number of reference frames specified at creation time.
 119 Requesting a larger number of reference frames can significantly
 120 increase memory usage. Hence it is best for applications that
 121 decode H.264 to request only the actual number of reference frames
 122 specified in the stream, rather than e.g. hard-coding a limit of
 123 16, or even the maximum number of surfaces allowable by some
 124 specific H.264 level at the stream's resolution.</p>
 125 <p>Note that the NVIDIA implementation correctly implements all
 126 required interlocks between the various pipelined hardware modules.
 127 Applications never need worry about correctness (providing their
 128 API usage is legal and sensible), but simply have to worry about
 129 performance.</p>
 130 </div>
 131 <div class="navfooter">
 132 <hr>
 133 <table width="100%" summary="Navigation footer">
 134 <tr>
 135 <td width="40%" align="left"><a accesskey="p" href=
 136 "appendix-g-section-02.html">Prev</a>&nbsp;</td>
 137 <td width="20%" align="center"><a accesskey="u" href=
 138 "appendix-g.html">Up</a></td>
 139 <td width="40%" align="right">&nbsp;<a accesskey="n" href=
 140 "appendix-g-section-04.html">Next</a></td>
 141 </tr>
 142 <tr>
 143 <td width="40%" align="left" valign="top">Performance
 144 Levels&nbsp;</td>
 145 <td width="20%" align="center"><a accesskey="h" href=
 146 "index.html">Home</a></td>
 147 <td width="40%" align="right" valign="top">&nbsp;Additional
 148 Notes</td>
 149 </tr>
 150 </table>
 151 </div>
 152 </body>
 153 </html>