
1.
Introduction
Several hardware subsystems in the PNX15xx Series deal directly with images. Such
hardware subsystems must follow the same memory representation and
interpretation of images in order to successfully pass images between subsystems.
Software modules also constitute subsystems that can produce or consume images.
Although most modules are designed with an abstraction layer from the underlying
format, some legacy modules may exist that assume a particular pixel representation
in memory.
In order to run a wide variety of software modules the PNX15xx Series uses the
following pixel format strategy:
A limited number of native pixel formats are supported by all image subsystems,
as appropriate.
The Memory Based Scaler supports conversion from arbitrary pixel formats to
any native format during the anti-icker ltering operation. (This operation is
usually required on graphics images anyway, so no extra passes are introduced.)
Hardware subsystems support all native pixel formats in both little-endian and
big-endian system operation.
Software always sees the same component layout for a native pixel format unit,
whether it is running in little-endian or big-endian mode— i.e., for a given native
format, RGB (or YUV) and alpha are always in the same place.
Software dealing with multiple units at a time in Single Instruction Multiple Data
(SIMD) style must be aware of system endian mode.
The native formats of the PNX15xx Series include the most common indexed,
packed RGB, packed YUV and planar YUV formats used by Microsoft
DirectX
and Apple
QuickTime, with 100% bit layout compatibility in both little and big-
endian modes.
Chapter 28: Pixel Formats
PNX15xx Series Data Book – Volume 1 of 1
Rev. 3 — 17 March 2006
Product data sheet