Introduction to the University of Washington Mediaprocessor User Consortium (UW-MPUC)
Wed, 2006-11-22 15:07 — sluo
Image Computing Systems Laboratory
Figure 1. Role of UW-MPUC.
Figure 2. Dilemma in Evaluating the Performance of Mediaprocessors.
-->
Another factor that has limited the success of mediaprocessors is a lack of awareness about mediaprocessors. When developing a new product, set makers are faced with a decision on whether to use hardwired components or programmable components. With the uncertainties in the performance of mediaprocessors and the time and manpower needed to make the transition from hardwired to programmable component-based products, set makers are often hesitant in choosing a programmable approach for their products. UW-MPUC will help increase the awareness of mediaprocessors and facilitate the transition to mediaprocessor-based products. Figure 3 shows how UW-MPUC fits into the product development paradigm. Increased awareness of mediaprocessors and their proven advantages via publications and seminars will help convince set makers to use mediaprocessors in their products. Next, evaluation reports provided by the UW-MPUC will help the set makers narrow the field of mediaprocessors to a small number of mediaprocessors to be further evaluated. Finally, once the set maker has decided which mediaprocessor to use, the UW-MPUC would provide the set maker with training, sample code, and a small library of functions for the mediaprocessor.
Figure 3. UW-MPUC Can Help Member Companies in Many Different Ways.
1.invert8: 8-bit image invert
2.add8: add two 8-bit images
3.bin_dilate: dilate an image with a morphology structuring element
4.flip8_x: flip an 8-bit input image vertically (around the x axis)
5.flip8_y: flip an 8-bit input image horizontally (around the y axis)
6.transpose8: tranpose an 8-bit input image
7.affine8: affine warping
8.conv8: 2D convolution with various kernel sizes
9.cfft: 2D complex fast Fourier transform (FFT)
10.dwt4: D4 wavelet transform
11.histo8: histogram generation for 8-bit input data
12.idct8x8: 8 inverse discrete cosine transform (IDCT)
During the life of the UW Mediaprocessor User Consortium, several new functions could be added to the UW-MPCL while some functions could be deleted. The Consortium Advisory Board can make these decisions.For details on our approaches to implement these functions on multiple mediaprocessors, click here.
Figure 4. Difference between UW-MPUC and Chip-Specific Consortia.
The UW-MPUC is not intended to replace the chip-specific consortia. On the contrary, the UW-MPUC will act as an umbrella organization over the MAP UWICL and any other chip-specific mediaprocessor consortia that the UW Image Computing Systems Laboratory may develop in the future. Since all functions in the UW-MPCL for the MAP have already been developed and are available as part of the MAP UWICL, the MAP UWICL Consortium Advisory Board in its meeting on April 24, 2000 unanimously approved the inclusion of 10-15 functions from the existing MAP UWICL in the UW-MPCL so that the MAP can become one of the target mediaprocessors supported by the UW-MPUC.
Set makers who are undecided on which mediaprocessor to use in their product(s) can join the UW-MPUC first and then later join an available chip-specific consortium.
Figure 5. Application-Specific Programming Interfaces (ASPIs)
and Hierarchical Software Modules.
Low and medium-level software modules as well as the ASPIs may be developed by set makers or third-party companies as shown in Figure 5. The low and medium-level modules developed and maintained by a set maker are likely to fit the top-level modules developed by the same set maker better, but may require a large amount of work to attain the same quality or performance as those developed by third-party companies. Even though some of these low and medium-level software modules may be developed to provide the same (or similar kinds of) functionalities, their corresponding ASPIs could be very different depending on the developers. As a result, it could be very difficult for the set makers to select the most appropriate low and medium-level modules for their products since they would have to be concerned with whether or not the modules are compatible with the top-level modules and how these incompatibilities would be solved.
To reduce the set-maker's effort in using low and medium-level modules developed by third-party companies, the UW-MPUC could lead the effort in standardizing the ASPIs for selected applications. The standard ASPI would initially define the function prototypes and data structures to provide a consistent interface between the top-level module and the lower-level modules. Furthermore, the standard ASPIs would allow for software extensibility. For example, if a third-party company adds new features to one of their modules, the set maker could still use the module without having to change their high-level module since the interface would not change. The UW-MPUC could coordinate a meeting (or a series of meetings) between the UW-MPUC member companies and the third-party companies developing low and medium-level functions to make sure that the ASPIs would be beneficial to both the set makers and the third-party software companies.The set makers will benefit since applications using the standard ASPIs would be more portable and upgradable since the lower-level modules could be easily swapped with the new ones developed for a different processor (assuming the top-level module is processor-independent) with more computing performance, lower power consumption, and/or other improvements. In addition, allowing the set makers to easily use low and medium-level modules developed by third-party companies will help the set makers focus their engineering resources on developing more sophisticated products. For example, the set maker could improve the user interface, add more features, and create new services and applications.Standard ASPIs will benefit the third-party module developers as well since more set makers will be able to use their modules.
Image Computing Systems Laboratory
University of Washington
Seattle, Washington 98195 U.S.A.
1.0 Summary
University of Washington
Mediaprocessor User Consortium (UW-MPUC) is an organization that aims to
facilitate and promote the widespread use of programmable mediaprocessors
(MPs). UW-MPUC will provide publications, internal reports, web site, training
courses, software libraries, and objective evaluations of mediaprocessors,
to increase the awareness of the benefits of mediaprocessors over application
specific integrated circuits (ASICs), make the transition to mediaprocessor-based
products easier for set makers, and help them attain full advantage of
using mediaprocessors. UW-MPUC will also promote the development of standards
to increase the portability and interoperability of mediaprocessor software.
Member companies of UW-MPUC pay annual sponsorship fees to cover the expense
of the consortium operations (e.g., library function development, training,
publications, and other R&D activities). UW-MPUC will begin its operation
in Fall 2000. Figure 1 shows the role of UW-MPUC. Governance of UW-MPUC
will be via Consortium Advisory Board consisting of the entire UW-MPUC
member companies in consultation with the University of Washington.
Figure 1. Role of UW-MPUC.
2.0 Background
Early mediaprocessors,
such as Texas Instruments TMS320C80 (MVP), have had success in professional
markets, e.g., medical imaging and machine vision. However, the success
of early mediaprocessors was limited due to difficulty in programming,
insufficient computing power, and high cost. Fortunately, several newer
mediaprocessors, which are available or under development (e.g., Hitachi/ETI
MAP, Philips TriMedia, and BOPS ManArray), are easier to program, less
expensive, and/or have more computing power. Even with the increasing computing
power, flexibility, adaptability, multi-function capability and reduced
time-to-market that newer mediaprocessors can provide, mediaprocessors
have yet to achieve widespread commercial successes.
As Figure 2 illustrates,
evaluating the performance of mediaprocessors is not a trivial task. With
the increasing number of mediaprocessors available and under development
and the increasing number and complexity of multimedia applications, current
benchmarks are mostly inadequate in determining how well a mediaprocessor
would perform for a specific application. Furthermore, the inability of
mediaprocessor compilers to utilize all of the mediaprocessor's on-chip
resources and parallelism available has led to the increasing use of C
intrinsics in mediaprocessor software. C intrinsics, which are hints to
the compiler on which assembly instructions to use, improve the performance
of mediaprocessor software significantly. Unfortunately, these C intrinsics
are mediaprocessor-specific, which as a result, reduces mediaprocessor
software portability. All of these factors cause the MP user companies
(set makers) to spend a large amount of resources in evaluating mediaprocessors,
which in turn becomes a barrier to the use of mediaprocessors.
Figure 2. Dilemma in Evaluating the Performance of Mediaprocessors.
-->
Another factor that has limited the success of mediaprocessors is a lack of awareness about mediaprocessors. When developing a new product, set makers are faced with a decision on whether to use hardwired components or programmable components. With the uncertainties in the performance of mediaprocessors and the time and manpower needed to make the transition from hardwired to programmable component-based products, set makers are often hesitant in choosing a programmable approach for their products. UW-MPUC will help increase the awareness of mediaprocessors and facilitate the transition to mediaprocessor-based products. Figure 3 shows how UW-MPUC fits into the product development paradigm. Increased awareness of mediaprocessors and their proven advantages via publications and seminars will help convince set makers to use mediaprocessors in their products. Next, evaluation reports provided by the UW-MPUC will help the set makers narrow the field of mediaprocessors to a small number of mediaprocessors to be further evaluated. Finally, once the set maker has decided which mediaprocessor to use, the UW-MPUC would provide the set maker with training, sample code, and a small library of functions for the mediaprocessor.
Figure 3. UW-MPUC Can Help Member Companies in Many Different Ways.
3.0 Mission and Goals of UW-MPUC
UW-MPUC strives to
help the mediaprocessor user companies by reducing barriers to the widespread
use of mediaprocessors in their products.
Goals of UW-MPUC:
- Increase
the acceptance of mediaprocessors.
- Support
the needs of MP user companies.
- Help in
mediaprocessor selection and mediaprocessor-based implementations.
- Training
for MP user companies.
- Produce
well-trained students for the industry.
- Advancement
in mediaprocessor architectures and programming.
- Promote
industry-industry interaction and industry-academia collaboration.
4.0 UW Mediaprocessor Computing Library (UW-MPCL)
4.1 Functions
Mapping and implementation
of several low-level multimedia processing functions on each mediaprocessor,
e.g., 2D convolution, 2D FFT and warping, could reveal very useful information
and new insights on the chip's architecture, characteristics, and performance.
12 functions to be included in the UW-MPCL are listed as below:
1.invert8: 8-bit image invert
2.add8: add two 8-bit images
3.bin_dilate: dilate an image with a morphology structuring element
4.flip8_x: flip an 8-bit input image vertically (around the x axis)
5.flip8_y: flip an 8-bit input image horizontally (around the y axis)
6.transpose8: tranpose an 8-bit input image
7.affine8: affine warping
8.conv8: 2D convolution with various kernel sizes
9.cfft: 2D complex fast Fourier transform (FFT)
10.dwt4: D4 wavelet transform
11.histo8: histogram generation for 8-bit input data
12.idct8x8: 8 inverse discrete cosine transform (IDCT)
During the life of the UW Mediaprocessor User Consortium, several new functions could be added to the UW-MPCL while some functions could be deleted. The Consortium Advisory Board can make these decisions.For details on our approaches to implement these functions on multiple mediaprocessors, click here.
4.2 How is the UW-MPUC Different from Chip-Specific Consortia?
The University of Washington
developed the MVP University of Washington Image Computing Library (UWICL)
Consortium in 1994. Also, the MAP UWICL Consortium has been in existence
since 1998. These are the chip-specific (Texas Instruments TMS320C80 and
Hitachi/Equator Technologies MAP) consortia while the UW-MPUC is a consortium
targeted to promote all mediaprocessors.
The MVP and MAP libraries
contain more than 100 highly-optimized functions, whereas the software
library provided by the UW-MPUC will likely contain no more than 15 functions
for every mediaprocessor supported by the UW-MPUC. The source code for
all mediaprocessors that have gone through the UW-MPUC's evaluation and
function development will be included in the UW-MPCL releases.
In addition to these
small libraries, the UW-MPUC will provide objective evaluation of mediaprocessors,
training on mediaprocessors and their programming, and tools for easier
mediaprocessor programming. Figure 4 shows the differences between the
UW-MPUC and chip-specific consortia.
Figure 4. Difference between UW-MPUC and Chip-Specific Consortia.
The UW-MPUC is not intended to replace the chip-specific consortia. On the contrary, the UW-MPUC will act as an umbrella organization over the MAP UWICL and any other chip-specific mediaprocessor consortia that the UW Image Computing Systems Laboratory may develop in the future. Since all functions in the UW-MPCL for the MAP have already been developed and are available as part of the MAP UWICL, the MAP UWICL Consortium Advisory Board in its meeting on April 24, 2000 unanimously approved the inclusion of 10-15 functions from the existing MAP UWICL in the UW-MPCL so that the MAP can become one of the target mediaprocessors supported by the UW-MPUC.
Set makers who are undecided on which mediaprocessor to use in their product(s) can join the UW-MPUC first and then later join an available chip-specific consortium.
5.0 Other Proposed Tasks
5.1 Application Specific Programming Interface (ASPI)
The software for a
product typically consists of a top-level module and several low and medium-level
software modules (e.g., imaging and graphics libraries, MPEG, JPEG, or
H.26x). Examples of top-level software modules are a video conferencing
system control and user interface based on H.26x, a set-top box software
layer that calls an MPEG-2 decoding software module in addition to providing
top-level control and user interface services, or a cellular phone or digital
TV user interface with voice recognition. The low and medium-level software
modules, which could be available for several different programmable processors
or implemented in hardwired components, are statically linked to or dynamically
called by the top-level software through application-specific programming
interfaces (ASPIs). An ASPI defines the complete interface between the
top-level module and the lower-level modules for a selected application.
For example, the ASPI defines the function prototypes of the lower-level
modules (e.g., return type, input argument types and ordering) and the
data structures used to pass arguments to the modules.
Figure 5. Application-Specific Programming Interfaces (ASPIs)
and Hierarchical Software Modules.
Low and medium-level software modules as well as the ASPIs may be developed by set makers or third-party companies as shown in Figure 5. The low and medium-level modules developed and maintained by a set maker are likely to fit the top-level modules developed by the same set maker better, but may require a large amount of work to attain the same quality or performance as those developed by third-party companies. Even though some of these low and medium-level software modules may be developed to provide the same (or similar kinds of) functionalities, their corresponding ASPIs could be very different depending on the developers. As a result, it could be very difficult for the set makers to select the most appropriate low and medium-level modules for their products since they would have to be concerned with whether or not the modules are compatible with the top-level modules and how these incompatibilities would be solved.
To reduce the set-maker's effort in using low and medium-level modules developed by third-party companies, the UW-MPUC could lead the effort in standardizing the ASPIs for selected applications. The standard ASPI would initially define the function prototypes and data structures to provide a consistent interface between the top-level module and the lower-level modules. Furthermore, the standard ASPIs would allow for software extensibility. For example, if a third-party company adds new features to one of their modules, the set maker could still use the module without having to change their high-level module since the interface would not change. The UW-MPUC could coordinate a meeting (or a series of meetings) between the UW-MPUC member companies and the third-party companies developing low and medium-level functions to make sure that the ASPIs would be beneficial to both the set makers and the third-party software companies.The set makers will benefit since applications using the standard ASPIs would be more portable and upgradable since the lower-level modules could be easily swapped with the new ones developed for a different processor (assuming the top-level module is processor-independent) with more computing performance, lower power consumption, and/or other improvements. In addition, allowing the set makers to easily use low and medium-level modules developed by third-party companies will help the set makers focus their engineering resources on developing more sophisticated products. For example, the set maker could improve the user interface, add more features, and create new services and applications.Standard ASPIs will benefit the third-party module developers as well since more set makers will be able to use their modules.
5.2 Mediaprocessor Programming Interface (MPI)
Even with the standard
ASPIs, the issue of software compatibility is still a concern. For example,
many software modules in an application may contain mediaprocessor-specific
C intrinsics. To address the issue of code compatibility across various
mediaprocessors, the UW-MPUC could look into the research and development
of a standard mediaprocessor programming interface (MPI), which consists
of a universal set of C intrinsics and/or a program to translate between
the universal and native C intrinsics of a specific mediaprocessor. The
MPI could promote the transportability of mediaprocessor programs and therefore
allow faster deployment of software in the field.Although
the MPI might not be as efficient as native C intrinsics, it would significantly
reduce the amount of porting efforts for mediaprocessor-based products
since the product designer could initially use the previously-developed
code for an old mediaprocessor. The MPI-translated code could be upgraded
at a later time with the higher performance code that is written specifically
for the new mediaprocessor.
6.0 Support
Member companies of
the UW-MPUC can report bugs in the UW-MPCL or general suggestions/questions
to uw-mpuc-support@icsl.ee.washington.edu. The UW ICSL will attempt to
answer and supply fixes to any bugs within 1-4 weeks of receipt of the
report. Details of the support procedures for bugs in the UW-MPCL are documented
in the Quality Assurance Guide.
7.0 Availability and Schedule
There
is an annual sponsorship fee of $45,000 per member company to support the
UW-MPUC as specified in Article 2 of the Exhibit 2. The company receives
the UW-MPCL software (with regular updates and expansion as long as the
company remains as a UW-MPUC member) and a nonexclusive, perpetual, royalty-free,
paid-up license with limitations (for details, see Article 3 of the Exhibit
3), i.e., the UW-MPCL software is free to the UW-MPUC member companies.When
a UW-MPUC member company joins any chip-specific Consortium run by the
UW Image Computing Systems Laboratory, $16,200 per year will be credited
to the chip-specific Consortium's sponsorship fee (Article 3 of the Exhibit
2).
Generally, there will
be a minimum of two UW-MPUC Consortium Advisory Board meetings per year. For
Consortium's past and tentative schedules, click here.
8.0 Contact for the UW Mediaprocessor User Consortium
Professor Yongmin Kim
Director of the UW-MPUC
Departments of Bioengineering and Electrical Engineering
University of Washington, Box 352500
Seattle, Washington98195-2500U.S.A.
Tel: (206) 685-2271, Fax: (206) 221-6837
Email: ykim@u.washington.edu
WWW site: http://icsl.ee.washington.edu/uw-mpuc