Browse Prior Art Database

Video Performance Analysis Tool

IP.com Disclosure Number: IPCOM000113857D
Original Publication Date: 1994-Oct-01
Included in the Prior Art Database: 2005-Mar-27
Document File: 4 page(s) / 112K

Publishing Venue

IBM

Related People

Spinner, JA: AUTHOR [+3]

Abstract

A program is disclosed that allows the user to characterize video subsystems in terms of peak hardware rates and software overhead for popular graphics Application Programming Interface (API) calls. The methodology developed isolates the execution time attributable to the hardware and software components by timing a controlled series of graphics API calls and then using the data obtained as a matrix for solving a linear equation.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Video Performance Analysis Tool

      A program is disclosed that allows the user to characterize
video subsystems in terms of peak hardware rates and software
overhead for popular graphics Application Programming Interface (API)
calls.  The methodology developed isolates the execution time
attributable to the hardware and software components by timing a
controlled series of graphics API calls and then using the data
obtained as a matrix for solving a linear equation.

      The method disclosed here relies on the understanding that
video performance of a particular function is comprised of two
primary components: total software time, which includes setup time,
and raw hardware video rates.

      In a coupled asynchronous video system, a video operation is
setup and triggered and then the hardware and software can work on
independent operations until the next interaction with the video
hardware is reached by the software.  At that point, if the hardware
operation is not yet complete the software must wait, so the
effective time of a video operation can be limited by either the
software or hardware, depending on the execution time for each.  Fig.
1 shows the synchronization of the hardware and software execution
within the video subsystem.

      The software loop time for a given call is constant and the
hardware time varies with the number of pixels affected by the call.
In addition, for each call, the software must wait until the hardware
is ready and then perform a sequence of setup operations before the
hardware is triggered.  The setup time is "dead time" during which
the video hardware cannot be active.

      By systematically varying the parameters of a call, a data set
is obtained from which we determine:
  o  when execution time is hardware or software limited
  o  the maximum hardware rate
  o  the amount of setup time for a given call

      By using a fixed call and simply varying the size (pixels
rendered), the total time for each call produces a curve like that
shown in Fig. 2.

      The curve in Fig. 2 shows two distinct operating domains for
the OS/2* GpiPolyLine operation.  In the first domain (for short line
segments), the time per operation is constant - this corresponds to
the domain where the hardware is ready when each segment-draw
synchronization point is reached.  This will occur for very short
line segments, since the hardware time is proportional to the segment
length, and the constant execution time is the sum of the polyline
software overhead and the setup tim...