Driver Considerations for Multimedia Performance
Updated: October 5, 2006
This paper provides information about writing device drivers for the Microsoft Windows family of operating systems. It provides guidelines for driver developers to minimize the negative impact of driver behavior on multimedia applications.
On This Page
This paper provides information about writing kernel-mode device drivers for client versions of the Microsoft Windows family of operating systems.
Device-driver behavior significantly impacts the performance of multimedia applications. Obviously, it is important that driver developers minimize any potentially negative impact. This paper therefore provides both information on how driver behavior affects the Microsoft Windows environment and tips on how to minimize these effects. The information and tips include:
How Driver Behavior Affects Multimedia Applications
ISRs and DPCs consume the processing time of the actively running thread. If this thread is a multimedia thread, the multimedia application could miss a deadline and present either incorrect content to the user or correct content at the wrong time. For example, a DVD playback application must load, decode, and display a video frame every 33 milliseconds. The application cannot meet this deadline if too much processing time is taken from the decoding thread to run a long DPC. Consequently, the user perceives a glitch.
To deliver high-quality audio and video, multimedia applications must consider the amount of processing time that each driver on the system consumes at an IRQL higher than PASSIVE_LEVEL. However, driver behavior is defined as unpredictable if the IRQL remains higher than PASSIVE_LEVEL for an unbounded amount of time. Because driver behavior is currently unpredictable in the Microsoft Windows environment, multimedia applications often provide a less-than-optimal experience. Contrastingly, dedicated set-top boxes and game systems maintain predictable environments, because they use well-behaved, proprietary drivers. These systems can thus support high-quality multimedia applications-even though the platforms are comprised of the same hardware that is used to run the Microsoft Windows operating system.
Improving Users' Multimedia Experiences
Microsoft is incorporating functionality into Windows Vista that improves users’ multimedia experiences-by enabling them to determine why glitches happen. A user can identify the devices that consume large amounts of processing time and investigate ways to reconfigure, disable, or replace the devices or their driversbringing about a glitch-free multimedia experience.
Guidelines on ISR and DPC Behavior
Because the definition of the phrase too much processing time is subjective, the guidelines in this section are derived from the requirements of multimedia applications and other time-sensitive applications. The guidelines thus apply to a moderately powerful system, which is defined as a system that contains no more than one 900-MHz processor, 512 MB RAM, and a 133-MHz system bus.
To provide a predictable and bounded environment for multimedia applications, all device drivers must adhere to the following guidelines:
Adhering to the preceding guidelines is essential to the success of Microsoft Windows as a home multimedia platform. A system containing a loaded driver that does not meet these guidelines is unsuitable for multimedia scenarios.
Measuring ISR and DPC Execution Times
Microsoft added infrastructure to Microsoft Windows XP Service Pack 2 (SP2) that enables the reporting of ISR and DPC execution times. You can use this infrastructure at driver-development time to measure and optimize the driver’s behavior. The following section briefly describes how to use the event-tracing tools that are built on the infrastructure.
You can use the Tracelog.exe and Tracerpt.exe tools to leverage the event-tracing infrastructure. Tracelog.exe turns trace collection on and off, while Tracerpt.exe converts a trace log file into a comma-separated file in text format and generates a summary file in text format.
To gather driver-relevant data:
The first row in Dumpfile.csv begins with the text "Event Name" and contains column titles for the report.
In Dumpfile.csv, the DPC, Timer DPC, and ISR events have the following format:
PerfInfo, (DPC|ISR|Timer DPC), unused, end time, kernel time, user time, start time, routine address, unused, unused
To get an approximation of the execution time for a DPC, Timer DPC, or ISR that a routine address points to, subtract the start time from the end time.
In Dumpfile.csv, the context swap events have the following format:
Thread, ContxtSwap, unused, end time, kernel time, user time, new thread id, old thread id, new thread priority, old thread priority, , , , 1, old thread state, old thread ideal processor number, unused, unused
Executing at PASSIVE_LEVEL
When a driver must perform work that will cause it to exceed the time limit, the driver should perform the work at PASSIVE_LEVEL. Two options exist for performing work at PASSIVE_LEVEL: the driver can create dedicated threads to execute long work items or it can use kernel-mode worker threads that the system provides.
Although creating a dedicated thread is a more flexible approach, leveraging system-worker threads is simpler and more efficient from the system's point of view.
For more information on how drivers can create and use dedicated-driver threads and system-worker threads, see the "Thread Objects" section in the Microsoft DDK.