| Q&A |
 KHRONOS
Group ,
Neil Trevett
Vice President Embedded Content, NVIDIA | President, Khronos
Group
June . 2007 |
| |
 |
"OpenGL
ES 2.0 supports programmable shaders. Providing more
expressive power to mobile developers, shaders will
enable more information and compelling experiences to
be displayed on small screen devices. If you have a
handheld device you need sophisticated processing per
pixel to use the restricted screen real estate to its
full potential. "
<
Dassault Aviation Rafale (OpenGL ES) |
|
| |
|
| Q1 |
The
Khronos Group maintains a large portfolio of technologies. What
do all those technologies have in common? |
| A1 |
They
are all related to graphics and media processing: 3D graphics,
vector 2D graphics, video, imaging and audio. Khronos focuses
on creating open, royalty-free standards for both authoring
and accelerating rich media content on a wide range of embedded
and desktop systems. |
| |
|
| Q2 |
OpenGL
ES is a multi-platform API. Are implementations available on
every mobile OS, including Windows Mobile? |
| A2 |
A
broad range of devices from IPhone to the Playstation 3 use
OpenGL ES - so the API is not restricted to just mobiles but
is being deployed on a wide variety of embedded devices that
need state-of-the-art 3D graphics. Every mobile operating system
that I am aware of that supports accelerated native 3D graphics
has OpenGL ES available to expose that capability to software
developers. Microsoft is not a Khronos member - but Windows
Mobile has multiple hardware and software OpenGL ES implementations
available from third parties. |
| |
|
| Q3 |
When
it comes to hardware acceleration, it seems that APIs usually
add new features before the corresponding chips are released.
What is the typical delay between the two? When does a feature
officially become part of the API? |
| A3 |
The
Khronos APIs are constantly being reviewed to enable features
that are becoming feasible in silicon. The delay between public
specification release to production silicon in a phone is typically
12-18 months. Of course Khronos members participate in creating
and reviewing draft specifications and so they get a good idea
of the direction of the spec long before its public release.
Very often silicon designs start in parallel to the specification
being finalized. Also - Khronos is careful not to introduce
new features TOO quickly or ahead of proven market need - as
that could cause fragmentation. |
| |
|
| Q4 |
Do
you think Programmable Shaders are a relevant feature on mobile
devices? |
| A4 |
Yes
- very relevant - and they will be enabled by OpenGL ES 2.0
that was released in March 2007. As well as providing more expressive
power to mobile developers, shaders will enable more information
and compelling experiences to be displayed on small screen devices.
If you have a handheld device you need sophisticated processing
per pixel to use the restricted screen real estate to its full
potential. Shaders also enable a significant amount of processing
to be shifted to the GPU - offloading the CPU and memory bus
that are often overloaded in a mobile device. In particular
advanced pixel shaders can provide great visuals while using
significantly reduced geometry - further reducing the CPU and
memory load. |
| |
|
| Q5 |
Mobile
devices are known to be heterogeneous. What solutions does the
Khronos Group provide to reduce porting costs? |
| A5 |
All
the Khronos APIs are designed to reduce porting costs by providing
non-proprietary media APIs that can be made reliably available
across multiple platforms. Very often platform fragmentation
is a result of platforms shipping buggy implementations of APIs
- even if they are based on a standard. That's why all Khronos
APIs have conformance tests - and no vendor is allowed to name
their implementation as a Khronos standard unless it has passed
those tests. One of the latest Khronos standards is OpenKODE
that brings together a number of the Khronos APIs to provides
the functionality that a media application needs - rather like
DirectX does for the PC. Unlike DirectX though, OpenKODE is
an open, non-proprietary, cross platform standard that is designed
for mobile devices. OpenKODE increases source portability in
two ways: it defines an operating system abstraction API to
hide OS differences from applications, and secondly it defines
how the various media APIs interoperate - reducing porting costs
for developers who need 2D, 3D, video and audio to seamlessly
interact in innovative new types or rich media applications. |
| |
|
| Q6 |
In
terms of performance, what is the difference between using proprietary
platform-specific APIs and using OpenKODE APIs? |
| A6 |
That
depends on the proprietary API - but most silicon vendors are
putting most of their driver porting and optimization efforts
now into open standards where that investment can be amortized
across multiple platforms. A proprietary API on a single platform
will very likely not receive the same degree of implementation
and optimization effort as it will lack the same level of commercial
momentum. |
| |
|
| Q7 |
Will
mobile devices manufacturers preload OpenKODE in their products? |
| A7 |
Of
course that's up to the handset OEMs and the operators but I
think that's is very likely - as OpenKODE will be very useful
for accelerating core device functionality such as the user
interface and TV and camera software - as well as downloaded
games. |
| |
|
| Q8 |
Are
stable OpenKODE implementations already available? What range
of hardware is currently supported? |
| A8 |
The
specification was only released a few months ago - but there
already development versions of OpenKODE available for the
PC - free-of-charge. I would expect in-handset implementations
to begin shipping in the next 12 months. Softbank Mobile recently
announced that it is going to make OpenKODE central to its
new POP-i mobile platform. ARM, NVIDIA and TI have all announced
that they will ship OpenKODE implementations. |
| |
|
| Q9 |
Do
you know any effort to create a user friendly authoring tool
enabling non-programmers to rapidly develop applications empowered
by Khronos APIs? |
| A9 |
COLLADA
is a Khronos standard that will enable a broad range of 3D authoring
tools to interoperate to make the task of 3D application creation
much more artist friendly. When this is combined with the glFX
effects framework now also being created at Khronos it will
be significantly easier for developers to author advanced visual
effects, package them and optimize them for deployment on a
range of platforms. |
| |
|
| Q10 |
What
advantages does Collaba bring to mobile platforms? |
| A10 |
COLLADA
is a very general purpose interchange format that enables 3D
assets to be freely exchanged between multiple tools. Once the
assets for an application are created they can be conditioned
for a variety of platforms. As COLLADA is an open standard -
I expect to see a significant number of authoring tools and
conditioning pipelines being built to enable very flexible content
creation for a wide variety of devices. COLLADA has already
been adopted by the major DCC tools vendors, as well as EPIC,
Google and Adobe. |
| |
|
| Q11 |
Does
Collaba aim to become a standard for 3D objects broadcasting
on the Web? Are progressive loading features available so as
to accomodate limited bandwidth? |
| A11 |
COLLADA
is strictly an authoring format and is not intended for use
at run-time. Khronos has recently announced a liaison with the
Web3D Consortium whose X3D standard is designed for deployment
of networked, real-time 3D - including over the web. The liaison
is to ensure that COLLADA and X3D seamlessly complement each
other and COLLADA provides a solid foundation for tools supporting
X3D content creation. It will be interesting to see if networked
3D technologies developed for the web will find use over mobile
networks too. |
| |
|
