Intel® OpenSource HD Graphics
Programmer’s Reference Manual (PRM)
Volume 4 Part 2: Shared Functions –
Message Gateway, URB, Video Motion
Estimation, Pixel Interpolator (Ivy Bridge)


For the 2012 Intel® Core™ Processor Family


May 2012
Revision 1.0


NOTICE:
This document contains information on products in the design phase of development, and Intel
reserves the right to add or remove product features at any time, with or without changes to this
open source documentation.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12
Creative Commons License
You are free to Share — to copy, distribute, display, and perform the work

Under the following conditions:

Attribution. You must attribute the work in the manner specified by the author or licensor (but not in any
way that suggests that they endorse you or your use of the work).

No Derivative Works. You may not alter, transform, or build upon this work.
                                                                                           ®
INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO
LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL
PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S
TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY
WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO
SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO
FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY
PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT.

A "Mission Critical Application" is any application in which failure of the Intel Product could result, directly
or indirectly, in personal injury or death. SHOULD YOU PURCHASE OR USE INTEL'S PRODUCTS FOR
ANY SUCH MISSION CRITICAL APPLICATION, YOU SHALL INDEMNIFY AND HOLD INTEL AND ITS
SUBSIDIARIES, SUBCONTRACTORS AND AFFILIATES, AND THE DIRECTORS, OFFICERS, AND
EMPLOYEES OF EACH, HARMLESS AGAINST ALL CLAIMS COSTS, DAMAGES, AND EXPENSES
AND REASONABLE ATTORNEYS' FEES ARISING OUT OF, DIRECTLY OR INDIRECTLY, ANY CLAIM
OF PRODUCT LIABILITY, PERSONAL INJURY, OR DEATH ARISING IN ANY WAY OUT OF SUCH
MISSION CRITICAL APPLICATION, WHETHER OR NOT INTEL OR ITS SUBCONTRACTOR WAS
NEGLIGENT IN THE DESIGN, MANUFACTURE, OR WARNING OF THE INTEL PRODUCT OR ANY
OF ITS PARTS.

Intel may make changes to specifications and product descriptions at any time, without notice. Designers
must not rely on the absence or characteristics of any features or instructions marked "reserved" or
"undefined". Intel reserves these for future definition and shall have no responsibility whatsoever for
conflicts or incompatibilities arising from future changes to them. The information here is subject to
change without notice. Do not finalize a design with this information.

The products described in this document may contain design defects or errors known as errata which
may cause the product to deviate from published specifications. Current characterized errata are
available on request.

Implementations of the I2C bus/protocol may require licenses from various entities, including Philips
Electronics N.V. and North American Philips Corporation.

Intel and the Intel logo are trademarks of Intel Corporation in the U.S. and other countries.

*Other names and brands may be claimed as the property of others.


Copyright © 2012, Intel Corporation. All rights reserved.




2                                              5/29/2012                 Doc Ref #: IHD-OS-V4 Pt 2 – 05 12
Contents
1.     Shared Functions - Message Gateway ................................................................................................ 5
   1.1 Messages ............................................................................................................................................. 5
     1.1.1 Message Descriptor ........................................................................................................................ 6
     1.1.2 OpenGateway Message ................................................................................................................. 7
     1.1.3 CloseGateway Message ................................................................................................................. 8
     1.1.4 GetTimeStamp Message .............................................................................................................. 11
     1.1.5 BarrierMsg Message .................................................................................................................... 13
     1.1.6 MMIOReadWrite Message ........................................................................................................... 15
2.     Shared Functions - Unified Return Buffer (URB) ............................................................................. 17
   2.1 URB Size ............................................................................................................................................ 17
   2.2 URB Access ....................................................................................................................................... 17
   2.3 State ................................................................................................................................................... 18
   2.4 URB Messages .................................................................................................................................. 18
     2.4.1 Execution Mask ............................................................................................................................ 19
     2.4.2 Message Descriptor ...................................................................................................................... 19
     2.4.3 URB_WRITE* and URB_READ* .................................................................................................. 20
     2.4.4 URB_ATOMIC* ............................................................................................................................. 32
3.     Shared Functions – Video Motion Estimation .................................................................................. 34
   3.1 Theory of Operation ........................................................................................................................... 34
     3.1.1 Shape Decision ............................................................................................................................ 34
     3.1.2 Integer Motion Estimation ............................................................................................................. 39
     3.1.3 Fractional Motion Estimation ........................................................................................................ 44
     3.1.4 BME and Weighted Prediction...................................................................................................... 45
     3.1.5 Skip Check.................................................................................................................................... 46
     3.1.6 Intra Prediction Estimation ............................................................................................................ 48
     3.1.7 Transform Adjusted SAD .............................................................................................................. 48
     3.1.8 Early Decisions ............................................................................................................................. 50
     3.1.9 Performance Information .............................................................................................................. 51
     3.1.10 VME Changes............................................................................................................................. 52
   3.2 Surfaces ............................................................................................................................................. 52
   3.3 State ................................................................................................................................................... 52
     3.3.1 BINDING_TABLE_STATE............................................................................................................ 52
     3.3.2 SURFACE_STATE ....................................................................................................................... 52
     3.3.3 VME_STATE ................................................................................................................................ 53
   3.4 Change Details ................................................................................................................................... 56
     3.4.1 Record Stream-out and Stream-in ............................................................................................... 56
     3.4.2 MV Definitions and Precision........................................................................................................ 57
     3.4.3 Expanded MV Costs ..................................................................................................................... 58
     3.4.4 Remove Skip MV Restriction ........................................................................................................ 59
     3.4.5 Bilinear Interpolation ..................................................................................................................... 59
     3.4.6 AVC Intra Mode Mask .................................................................................................................. 59
   3.5 Messages ........................................................................................................................................... 59
     3.5.1 VME Motion Search Request ....................................................................................................... 60
     3.5.2 Message Descriptor ...................................................................................................................... 60
     3.5.3 Input Message .............................................................................................................................. 61
     3.5.4 Writeback Message ...................................................................................................................... 80
     3.5.5 Stream-in\Stream-out Message.................................................................................................... 90
4.     Shared Functions Pixel Interpolater .................................................................................................. 93



Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                                      5/31/2012                                                                           3
 4.1 Messages ........................................................................................................................................... 93
   4.1.1 Initiating Message ......................................................................................................................... 93
   4.1.2 Writeback Message ...................................................................................................................... 98




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                                   5/31/2012                                                                         4
1. Shared Functions - Message Gateway
The Message Gateway shared function provides a mechanism for active thread-to-thread communication.
Such thread-to-thread communication is based on direct register access. One thread, a requester
thread, is capable of writing into the GRF register space of another thread, a recipient thread. Such
direct register access between two threads in a multi-processor environment some time is referred to as
remote register access. Remote register access may include read or write. The architecture supports
remote register write, but not remote register read (natively). Message Gateway facilitates such remote
register write via message passing. The requester thread sends a message to Message Gateway
requesting a write to the recipient thread’s GRF register space. Message Gateway sends a writeback
message to the recipient thread to complete the register write on behave of the requester. The requester
thread and the recipient thread may be on the same EU or on different EUs.
When Bypass Gateway Control is set to 1, commands OpenGateway and CloseGateway are no longer
used, the gateway parameters are taking the default values as the following:

     RegBase = 0
     Gateway Size check and Key check are bypassed.
     Gateway Open (an internal signal that is used to be set by OpenGateway message) check is
      bypassed

A separate Gateway exists per half-slice in the architecture. For ForwardMsg this is handled
transparently, but barriers can only be accessed by threads in the local half-slice. This means that all
threads that access a shared barrier need to use the half-slice select in GPGPU_OBJECT and
MEDIA_OBJECT to stay on a single half-slice. GPGPU_WALKER handles this automatically.


1.1      Messages
Message Gateway supports such thread-to-thread communication with the following three messages:

     OpenGateway: opens a gateway for a requester thread. Once a thread successfully opens its
      gateway, it can be a recipient thread to receive remote register write.
     CloseGateway: closes the gateway for a requester thread. Once a thread successfully closes its
      gateway, Message Gateway will block any future remote register writes to this thread.
     ForwardMsg: forwards a formatted message (remote register write) from a requester thread to a
      recipient thread.
     GetTimeStamp: reads absolute and relative timestamps for a requester thread.
     BarrierMsg: A set of threads sends this message to the Gateway. When all threads in a group have
      sent the message, a reply (both a register write and an N0 notification) is sent to each member of
      the group.
     UpdateGatewayState: updates the internal state of the Message Gateway.
      One example usage is to allow a control thread to change Barrier Byte to convey dynamic state
      information. This may be used to support interrupt when persistent compute/worker threads are
      synchronized using Barrier.
     MMIO Read/Write: allows a message to read or write an MMIO register. The MEDIA_VFE_STATE
      command has a field which limits the accesses for security.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                 5/31/2012                                                5
1.1.1        Message Descriptor
The following message descriptor applies to all messages supported by Message Gateway.
 Bit                                                        Description
 19
        Header Present
        This bit must be set to zero for all Message Gateway messages.
        (this bit is not part of the shared function specific message descriptor)

18:17
        Ignored (these bits are not part of the shared function specific message descriptor)
16:15
        Notify. Send Notification Signal.
        This is a two-bit field indicating which notify event is sent.
        00: No notify
        01: Increment recipient thread’s N0 notification counter
        10: Increment recepient thread’s N2 notification counter
        11: Reserved
        This field is only valid for a ForwardMsg message. It is ignored for other messages. The BarrierMsg message
        always increments the N0 notification counter.
 14
        AckReq. Acknowledgment Required. When this bit is set, an acknowledgment return message is required.
        Message Gateway will send a writeback message containing the error code to the requester thread using the
        post destination register address. When this bit is not set, no writeback message is sent to the requesting
        thread by Message Gateway, even if an error occurs.
        This field is valid for OpenGateway, CloseGateway, ForwardMsg and BarrierMsg messages.
        When this bit is set, post destination register must be valid and the response length must be 1.
        When this bit is not set, post destination register must be null and the response length must be 0.
        This bit cannot be set when EOT is set; otherwise, hardware behavior is undefined.
        0 = No Acknowledgement is required.
        1 = Acknowledgement is required.
13:3 Reserved: MBZ
 2:0
      SubFuncID. Identify the supported sub-functions by Message Gateway. Encodings are:
        000 = OpenGateway. Open the gateway for the requester thread.
        001 = CloseGateway. Close the gateway for the requester thread.
        010 = ForwardMsg. Forward the formatted message to the recipient thread with the given offset from the
        recipient’s register base.
        011 = GetTimeStamp. Read absolute and relative timestamps.
        100 = BarrierMsg. Record an additional thread reaching the barrier.
        101 = UpdateGatewayState. Update the barrier byte for a barrier.
        110 = MMIO Read/Write
        Others are reserved




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                          5/31/2012                                                  6
1.1.2      OpenGateway Message
The OpenGateway message opens a communication channel between the requesting thread and other
threads. It specifies a key for other threads to access its gateway, as well as the GRF register range
allowed to be written. The message consists of a single 256-bit message payload.
If the AckReq bit is set, a single 256-bit payload writeback message is sent back to the requesting thread
after completion of the OpenGateway function. Only the least significant DWord in the post destination
register is overwritten.
If the EOT is set for this message, Message Gateway will ignore this message; instead, it will close the
gateway for the requesting thread regardless of the previous state of the gateway.
It is software’s policy to determine how to generate the key.

1.1.2.1         Message Payload
DWord Bit                                                       Description
 M0.7 31:0
                Reserved

 M0.6 31:0
                Reserved

        31:29
 M0.5           Reserved: MBZ

        28:21
                RegBase: The register base address to be stored in the Message Gateway. It is used to compute the
                destination GRF register address from the offset field in ForwardMsg. RegBase contains 256-bit GRF
                aligned register address.
                Note 1: This field aligns with bits [28:21] of the Offset field of the message payload for ForwardMsg.
                Note 2: the most significant bit of this field must be zero.
                Format = U8
                Range = [0,127]

        20:11
                Reserved: MBZ

        10:8
                Gateway Size: The range limit for messages through the Message Gateway. The maximal allowed
                Gateway Size is 32 GRF registers.
                000: 1 GRF Register
                001: 2 GRF Registers
                010: 4 GRF Registers
                011: 8 GRF Registers
                100: 16 GRF Registers
                101: 32 GRF Registers
         7:0
                Dispatch ID: This ID is assigned by the fixed function unit and is a unique identifier for the thread. It is
                used to free up resources used by the thread upon thread completion.
                This field is ignored by Message Gateway
                This field is only required for a thread that is created by a fixed function (therefore, not a child thread)
                and EOT bit is set for the message.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                         5/31/2012                                                            7
DWord Bit                                                        Description
      31:16
 M0.4       Reserved: MBZ

         15:0
                 Reserved: MBZ

M0.3:0          Ignored


1.1.2.2          Writeback Message to Requester Thread
The writeback message is only sent if the AckReq bit in the message descriptor is set.
DWord Bit                                       Description
W0.7:1       Reserved (not overwritten)
 W0.0 31:20 Reserved
       19:16
              Shared Function ID: Contains the message gateway’s shared function ID.

         15:3 Reserved
          2:0
               Error Code
                 000: Successful. No Error (Normal)
                 101: Opcode Error. Attempt to send a message which is not either open/close/forward
                 other codes: Reserved



1.1.3       CloseGateway Message
The CloseGateway message closes a communication channel for the requesting thread that was
previously opened with OpenGateway. Each thread is allowed to have only one open gateway at a time,
thus no additional information in the message payload is required to close the gateway. The message
consists of a single 256-bit message payload.is
If the AckReq bit is set, a single 256-bit payload writeback message is sent back to the requesting thread
after completion of the CloseGateway function. Only the least significant DWord in the post destination
register is overwritten.

1.1.3.1          Message Payload
DWord Bit                                                  Description
M0.7:6      Ignored
       31:8 Ignored
 M0.5
        7:0
             Dispatch ID: This ID is assigned by the fixed function unit and is a unique identifier for the thread. It is
             used to free up resources used by the thread upon thread completion.
                This field is ignored by Message Gateway
                This field is only required for a thread that is created by a fixed function (therefore, not a child thread)
                and EOT bit is set for the message.
M0.4:0      Ignored




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                          5/31/2012                                                           8
1.1.3.2        Writeback Message to Requester Thread
The writeback message is only sent if the AckReq bit in the message descriptor is set.
DWord Bit                                       Description
W0.7:1       Reserved (not overwritten)
 W0.0 31:20 Reserved
       19:16
              Shared Function ID: Contains the message gateway’s shared function ID.

        15:3 Reserved
         2:0
              Error Code
               000: Successful. No Error (Normal)
               101: Opcode Error. Attempt to send a message which is not either open/close/forward
               other codes: Reserved


1.1.3.3        ForwardMsg Message
The ForwardMsg message gives the ability for a requester thread to write a data segment in the form of
a byte, a dword, 2 dwords, or 4 dwords to a GRF register in a recipient thread. The message consists of a
single 256-bit message payload, which contains the specially formatted data segment.
The ForwardMsg message utilizes a communication channel previously opened by the recipient thread.
The recipient thread has communicated its EUID, TID, and key to the requester thread previously via
some other mechanism. Generally, this is done through the thread spawn message from parent to child
thread, allowing each child (requester) to then communicate with its parent through a gateway opened by
the parent (recipient). The child could then use ForwardMsg message to communicate its own EUID, TID,
and key back to the parent to enable bi-directional communication after opening its own gateway.
If the AckReq bit is set, a single 256-bit payload writeback message is sent back to the requester thread
after completion of the ForwardMsg function. Only the least significant DWord in the post destination
register is overwritten.
If the Notify bit in the message descriptor is set, a ‘notification’ is sent to the recipient thread in order to
increment the recipient thread’s notification counter. This allows multiple messages to be sent to the
recipient without waking up the recipient thread. The last message, having this bit set, will then wake up
the recipient thread.

1.1.3.4        Message Payload
DWord Bit                                                      Description
 M0.7 31:0
               Reserved

 M0.6 31:0
               Reserved

        31:29 Reserved: MBZ
 M0.5
        28:16
               Offset: It provides the destination register position in the recipient thread GRF register space as the
               offset from the RegBase stored in the recipient thread’s gateway entry. The offset is in unit of byte,
               such that bits [28:21] is the 256-bit aligned register offset and bits [4:0] is the sub-register offset. The
               sub-register offset must be aligned to the Length field in bits [10:8]. The subfields of Offset are further




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                        5/31/2012                                                            9
DWord Bit                                                       Description
                illustrated as the following.
                Offset[28:21]: Register offset from the gateway base (Range [0, 127]: bit 12 MBZ)
                Offset[20:18]: DW offset
                Offset[17:16]: Byte offset (must be 00 for all DW length cases)
                Programming restriction: R0 can not be used as destination GRF register for ForwardMsg. NULL
                register is also not allowed as destination.
        15:11 Reserved: MBZ
         10:8
               Length: The length of the data segment.
                000: 1 byte
                001: 1 word
                010: 1 dword
                011: 2 dwords
                100: 4 dwords
                101-111: Reserved

         7:0
                Dispatch ID: This ID is assigned by the fixed function unit and is a unique identifier for the thread. It is
                used to free up resources used by the thread upon thread completion.
                This field is ignored by Message Gateway
                This field is only required for a thread that is created by a fixed function (therefore, not a child thread)
                and EOT bit is set for the message.
        31:30 Ignored
 M0.4
         29
         28
        31:30
        29:28
        27:24
               EUID: The Execution Unit ID as part of the Recipient field is used to identify the recipient thread to
               whom the message is forwarded.
        23:19 Ignored
        18:16
               TID: The Thread ID as part of the Recipient field is used to identify the recipient thread to whom the
               message is forwarded.

        15:0
                Key
                The key to match with the one stored in the recipient thread’s entry in Message Gateway.
                Ignored
M0.3 31:0
                Data Segment DWord 3: valid only for the 4-DWord data segment length

M0.2 31:0
                Data Segment DWord 2: valid only for the 4-DWord data segment length

M0.1 31:0
                Data Segment Dword 1: valid only for the 2- and 4-DWord data segment lengths

        31:24
 M0.0           Data Segment Byte 0: the same byte must be copied to all           Data Segment Dword 0: valid only for
                four positions within this DWord. Valid only for the 1-Byte        the 1-, 2- and 4-Dword data segment




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                         5/31/2012                                                        10
DWord Bit                                                 Description
               data segment length.                                        lengths
       23:16
               Data Segment Byte 0

        15:8
               Data Segment Byte 0

        7:0
               Data Segment Byte 0



1.1.3.5        Writeback Message to Requester Thread
The writeback message is only sent if the AckReq bit in the message descriptor is set.
DWord Bit                                       Description
W0.7:1       Reserved (not overwritten)
 W0.0 31:20 Reserved
       19:16
              Shared Function ID: Contains the message gateway’s shared function ID.

        15:3 Reserved
         2:0
              Error Code
               000: Successful. No Error (Normal)
               001: Reserved
               010: Gateway Closed. Attempt to send a message through a closed gateway
               101: Opcode Error. Attempt to send a message which is not either open/close/forward
               110: Invalid Message Size. Attempt to forward a message with length greater than 4 DW
               111: Reserved


1.1.3.6        Writeback Message to Recipient Thread
This message contains the byte or dwords data segment indicated in the message written to the GRF
register offset indicated. Only the byte/dword(s) will be enabled, all other data in the GRF register is
untouched.


1.1.4      GetTimeStamp Message
The GetTimeStamp message gives the ability for a requester thread to read the timestamps back from
the message gateway. The message consists of a single 256-bit message payload.
AbsoluteTimeLap is based on an absolute wall clock in unit of nSec/uSec that is independent of context
switch or GPU frequency adjustment. Message Gateway shares the same GPU timestamp. Details can
be found in the TIMESTAMP register section in vol1c Memory Interface and Command Stream.
RelativeTimeLap is based on a relative time count that is counting the GPU clocks for the context. The
relative time count is saved/restored during context switch.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                   5/31/2012                                              11
1.1.4.1         Message Payload
DWord Bit                                                     Description
 M0.7 31:0
             Reserved

 M0.6 31:0
             Reserved

        31
 M0.5        Return to High GRF:
             0: the return 128-bit data goes to the first half of the destination GRF register
             1: the return 128-bit data goes to the second half of the destination GRF register
        30:8 Reserved : MBZ
         7:0
              Dispatch ID: This ID is assigned by the fixed function unit and is a unique identifier for the thread. It is
              used to free up resources used by the thread upon thread completion.
             This field is ignored by Message Gateway
             This field is only required for a thread that is created by a fixed function (therefore, not a child thread)
             and EOT bit is set for the message.
 M0.4 31:0 Ignored
 M0.3 31:0 Ignored
 M0.2 31:0 Ignored
 M0.1 31:0 Ignored
 M0.0 31:0 Ignored


1.1.4.2         Writeback Message to Requester Thread
As the writeback message is only sent if the AckReq bit in the message descriptor is set, AckReq bit
must be set for this message.
Only half of the destination GRF register is updated (via write-enables). The other half of the register is
not changed. This is determined by the Return to High GRF control field.
Writeback Message if Return to High GRF is set to 0:
DWord Bit                                                Description
W0.7:4     Reserved (not overwritten)
 W0.3 31:0
            RelativeTimeLapHigh: This field returns the MSBs of time lap for the relative clock since the previous
            reset. This field represents 1.024 uSec increment of the time stamp. Hardware handles the
            wraparound (over 64 bit boundary) of the timestamp.
                Format: U12

        31:20
 W0.2           RelativeTimeLapLow: This field returns the LSBs of time lap for the relative clock since the previous
                reset. This field represents 1/4 nSec increment of the time stamp. Hardware handles the wraparound
                (over 64 bit boundary) of the timestamp.
                Format: U12
      19:0 Reserved : MBZ
 W0.1 31:0
            AbsoluteTimeLapHigh: This field returns the MSBs of time lap for the absolute clock since the
            previous reset. This field represents 1.024 uSec increment of the time stamp. Hardware handles the
            wraparound (over 64 bit boundary) of the timestamp.
                Format: U12




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                       5/31/2012                                                            12
DWord Bit                                                 Description
      31:20
 W0.0       AbsoluteTimeLapLow: This field returns the LSBs of time lap for the absolute clock since the
            previous reset. This field represents 1/4 nSec increment of the time stamp. Hardware handles the
            wraparound (over 64 bit boundary) of the timestamp.
                 Format: U12
         19:0 Reserved : MBZ

Writeback Message if Return to High GRF is set to 1:
DWord Bit                                              Description
 W0.7 31:0
                 RelativeTimeLapHigh

         31:20
 W0.6            RelativeTimeLapLow

          19:0 Reserved : MBZ
 W0.5     31:0
                AbsoluteTimeLapHigh

         31:20
 W0.4            AbsoluteTimeLapLow

          19:0 Reserved : MBZ
W0.3:0         Reserved : MBZ


1.1.5       BarrierMsg Message
The BarrierMsg message gives the ability for multiple threads to synchronize their progress. This is useful
when there are data shared between threads. The message consists of a single 256-bit message
payload.
Upon receiving one such message, Message Gateway increments the Barrier counter and mark the
Barrier requester thread. There is no immediate response from the Message Gateway. When the counter
value equates Barrier Thread Count, Message Gateway will send response back to all the Barrier
requesters.

1.1.5.1          Message Payload
DWord Bit                                                      Description
 M0.7 31:0
                 Reserved

 M0.6 31:0
                 Reserved

 M0.5 31:0 Ignored
 M0.4 31:0 Ignored
 M0.3 31:0 Ignored
      31:28 Ignored
 M0.2
      27:24
             BarrierID. This field indicates which one from the 16 Barrier States is updated.
                 Format: U4
                 Note: this field location matches with that of R0 header.
         23:16
                 Barrier.Offset. This is the offset for the Barrier to indicate the offset from the requester’s RegBase.
                 Regbase is 0 if Bypass Gateway Control is 1. Barrier.Offset + RegBase must be in the valid GRF
                 range, but not point to r0. Otherwise, hardware behavior is undefined.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                        5/31/2012                                                         13
DWord Bit                                                       Description
                 It is in unit of 256-bit GRF register.
                 The most significant bit of this field must be zero.
                 Format = U8
                 Range = [0,127]
     15:0 Ignored
M0.1 31:0 Ignored
M0.0 31:4 Ignored


1.1.5.2          Message Payload
DWord Bit                                                  Description
 M0.7 31:0
                    Ignored

 M0.6     31:0
                    Ignored

 M0.5     31:0 Ignored
 M0.4     31:0 Ignored
 M0.3     31:0
                Ignored

          31
 M0.2               Ignored

        30:28 Ignored
        27:24
               BarrierID. This field indicates which one from the 16 Barrier States is updated.
                    Format: U4
                    Note: this field location matches with that of R0 header.
        23:16
                    Ignored

          15
                    Barrier Count Enable: Allows the message to reprogram the barrier count.
                    If set, the current value of the barrier state is compared to the Barrier Count field
                    (below). If these values are equal, the barrier is considered satisfied, barrier responses
                    are sent to the waiting thread(s) including the sending thread, and the barrier state is
                    reset to 0. If these values are not equal, the barrier state is incremented and the
                    sending thread is added to the list of threads waiting on this barrier.
                    If clear, the Message Gateway increments the Barrier counter and marks the Barrier
                    requester thread. There is no immediate response from the Gateway. When the
                    counter value equates Barrier Thread Count, Gateway will send response back to all
                    the Barrier requesters.
                    Format: Enable
          14:9
                    Barrier Count:
                    If Barrier Count Enable is set, this field specifies the terminating barrier count.
                    Otherwise this field is ignored. All threads that belong to a single barrier must deliver
                    the same value for this field for a particular barrier iteration.

           8:0 Ignored
 M0.1     31:0 Ignored
 M0.0     31:4 Ignored




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                         5/31/2012                                              14
1.1.5.3          Writeback Message to Requester Thread
The writeback message is only sent if the AckReq bit in the message descriptor is set.
    DWord                   Bit                                           Description
    W0.7:1                           Reserved (not overwritten)
     W0.0                31:20       Reserved
                         19:16       Shared Function ID: Contains the message gateway’s shared function ID.
                          15:3       Reserved
                           2:0
                                      Error Code
                                      000: Successful. No Error (Normal)
                                      001: Error (Barrier is inactive).
                                      Other encodings are reserved.


1.1.5.4          Broadcast Writeback Message
When the count for a Barrier reaches Barrier.Count, the Message Gateway sends the notification bit N0
to each EU/Thread that reached the barrier. A Barrier Return Byte is not sent.
DWord      Bit      Description
W0.7:1      Reserved (not overwritten)
      31:16 Reserved (not overwritten)
 W0.0
       15:8 Reserved (not overwritten)
        7:0
             Reserved (not overwritten)



1.1.6       MMIOReadWrite Message

1.1.6.1          Message Payload
DWord Bit                                              Description
 M0.7 31:0
                 Reserved

 M0.6 31:0
                 Reserved

 M0.5 31:0 Ignored
 M0.4 31:0 Ignored
 M0.3 31:1 Ignored
       0
            MMIO R/W:
                  0 – MMIO Read – a response will be sent to the EU with read data
                  1 – MMIO Write – no response is sent to EU (unless acknowledge requested in sideband)
         31:28 Ignored
 M0.2
          22:2
                MMIO Address:
                  The MMIO DWord address to be accessed.
       1:0 Ignored
 M0.1 31:0 Ignored
 M0.0 31:0 MMIO Write Data (Only if MMIO R/W = 1, otherwise ignored).




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                       5/31/2012                                             15
1.1.6.2      Writeback Message to Requester Thread (MMIO Read Only)
DWord      Bit                    Description
 R0.7     31:0   Ignored
 R0.6     31:0   Ignored
 R0.5     31:0   Ignored
 R0.4     31:0   Ignored
 R0.3     31:0   Ignored
 R0.2     31:0   Ignored
 R0.1     31:0   Ignored
 R0.0     31:0
                 MMIO Read Data




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12               5/31/2012             16
2. Shared Functions - Unified Return
   Buffer (URB)
The Unified Return Buffer (URB) is a general-purpose buffer used for sending data between different
threads, and, in some cases, between threads and fixed-function units (or vice-versa). A thread accesses
the URB by sending messages.


2.1      URB Size
A URB entry is a logical entity within the URB, referenced by an entry handle and comprised of some
number of consecutive rows. A row corresponds in size to a 256-bit EU GRF register. Read/write access
to the URB is generally supported on a row-granular basis.
URB Size URB Rows URB Rows when SLM Enabled
128k     4096    2048
256k     8096    4096



2.2      URB Access
The URB can be written by the following agents:

     Command Stream (CS) can write constant data into Constant URB Entries (CURBEs) as a result of
      processing CONSTANT_BUFFER commands.
     The Video Front End (VFE) fixed-function unit of the Media pipeline can write thread payload data in
      to its URB entries.
     The Vertex Fetch (VF) fixed-function unit of the 3D pipeline can write vertex data into its URB entries
     Threads can write data into URB entries via URB_WRITE messages sent to the URB shared
      function.

The URB can be read by the following agents:

     The Thread Dispatcher (TD) is the main source of URB reads. As a part of spawning a thread,
      pipeline fixed-functions provide the TD with a number of URB handles, read offsets, and lengths.
      The TD reads the specified data from the URB and provide that data in the thread payload pre-
      loaded into GRF registers.
     The Geometry Shader (GS) and Clipper (CLIP) fixed-function units of the 3D pipeline can read
      selected parts of URB entries to extract vertex data required by the pipeline.
     The Windower (WM) FF unit reads back depth coefficients from URB entries written by the Strip/Fan
      unit.

Note that the CPU can not read the URB directly.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                 5/31/2012                                                17
2.3      State
The URB function is stateless, with all information required to perform a function being passed in the write
message.
See URB Allocation (Graphics Processing Engine ) for a discussion of how the URB is divided amongst the
various fixed functions.


2.4      URB Messages
This section documents the global aspects of the URB messages. The actual data stored in URB entries
differs for each fixed function – refer to 3D Pipeline and the fixed-function chapters or details on 3D URB
data formats and Media for media-specific URB data formats.
URB Handles: Unlike prior products where the URB handle contents was not specified for software use,
URB handles are now specified as offsets into the URB partition in the L3 cache, in 512-bit units. Thus,
kernels are now allowed to perform math operations on URB handles.

     The End of Thread bit in the message descriptor may be set on URB messages only in threads
      dispatched by the vertex shader (VS), hull shader (HS), domain shader (DS), and geometry shader
      (GS). The End of Thread bit cannot be set on URB_READ* or URB_ATOMIC* messages.

Execution Mask. The low 8 bits of the execution mask on the send instruction determines which DWords
from each write data phase are written or which DWords from each read phase are written to the
destination GRF register. The execution mask is ignored on URB_ATOMIC* messages, since this is a
scalar operation that is always enabled.
Out-of-Bounds Accesses. Reads to addresses outside of the URB region allocated in the L3 cache
return 0. Writes to addresses outside of the URB region are dropped and will not modify any URB data.
                   Header      Shared Local Memory       Stateless                                  Vector
 Message Type     Required           Support             Support           Address Modes            Width
URB Read            yes                N/A                  N/A                                      1, 2
HWORD
                                                                          handle + URBoffset
                                                                          or
                                                                          handle + URBoffset +
                                                                          offset
URB Write            yes                N/A                  N/A                                     1, 2
HWORD
                                                                          handle + URBoffset
                                                                          or
                                                                          handle + URBoffset +
                                                                          offset
URB Read             yes                N/A                  N/A                                     1, 2
OWORD
                                                                          handle + URBoffset
                                                                          or
                                                                          handle + URBoffset +
                                                                          offset
URB Write            yes                N/A                  N/A                                     1, 2
OWORD
                                                                          handle + URBoffset




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                5/31/2012                                                  18
                      Header       Shared Local Memory           Stateless                                    Vector
Message Type         Required            Support                 Support              Address Modes           Width
                                                                                     or
                                                                                     handle + URBoffset +
                                                                                     offset
URB Atomic              yes                   N/A                   N/A        handle + URBoffset                1
MOV
URB Atomic INC          yes                   N/A                   N/A        handle + URBoffset                1

 “offset” is in the message payload, and is per-slot.
“handle” is the handle address in the message header.
“URBoffset” is the Global Offset field in the URB message descriptor.


2.4.1       Execution Mask
The Execution Mask specified in the ‘send’ instruction determines which DWords within each message
register are read/written to the URB.


2.4.2       Message Descriptor
 Bit                                                      Description
 19 Header Present
            This bit must be set to one for all URB messages.

18:17 Ignored
 16
           Per Slot offset: If clear, the slot offset fields in the header are ignored.

            If set the slot offset fields are added to the global offset to obtain the overall offset.
       Programming Notes:
           This bit must be 0 for URB_ATOMIC_* messages.

 15
       Complete

            For URB_WRITE*, URB_SIMD8_WRITE and URB_ATOMIC*: This bit is ignored.
            For URB_READ* and URB_SIMD8_READ: If set, this signals that the thread is finished reading from the
            URB entry(s) referenced by the handles(s), causing the entry(s) to be deallocated.
            This bit is strictly control information passed to snooping FF units. The URB shared function
            itself does not use this bit for any purpose.
 14
            Swizzle Control. This field is used to specify which “swizzle” operation is to be performed on the write
            data. It indirectly specifies whether one or two handles are valid.
            0: URB_NOSWIZZLE
            The message accesses a single URB entry (using URB Handle 0).

            1: URB_INTERLEAVED
            The message accesses two URB entries. The data is interleaved such that the upper DWords (7:4) of
            each 256-bit unit contain data associated with URB Handle 1, and the lower DWords (3:0) contain data




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                       5/31/2012                                                      19
 Bit                                                     Description
          associated with URB Handle 0.

13:3
          Global Offset. This field specifies a destination offset (in 256-bit units) from the start of the URB entry(s),
          as referenced by URB Handle n, at which the data (if any) will be written to or read from.

          When URB_INTERLEAVED is used, this field provides a 256-bit granular offset applied to both
          URB entries.
          If the Per Slot Offset bit is set, this offset is added to the per-slot offsets in the header to obtain the
          overall offset.
          For the URB_*_OWORD messages, this offset is in 128-bit units instead of 256-bit units.
          For the URB_ATOMIC* messages, this offset is in 32-bit units instead of 256-bit units.
          Format = U11
          Range = [0, 1023] for URB_*_HWORD messages.
          Range = [0, 2047] for URB_*_OWORD messages.
          Range = [0, 2047] for URB_ATOMIC* messages.
 2:0
       URB Opcode

          0: URB_WRITE_HWORD
          1: URB_WRITE_OWORD
          2: URB_READ_HWORD
          3: URB_READ_OWORD
          4: URB_ATOMIC_MOV
          5: URB_ATOMIC_INC
          6-7: Reserved



2.4.3     URB_WRITE* and URB_READ*
The URB_WRITE* and URB_READ* messages share the same header definition. URB_WRITE has
additional payload containing the write data, but has no writeback message. URB_READ has no payload
beyond the header (message length is always one), but always has a writeback message.
URB_WRITE_SIMD4x2 has a single-phase payload with the per-slot offsets followed by the write data,
and has no writeback message. URB_READ_SIMD4x2 has a single phase payload containing the per-
slot offsets.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                      5/31/2012                                                        20
2.4.3.1     Message Header
M0.5[7:0] bits in message header are used for enabling DWs in cull test, at HDC unit by HS kernel, while
writing TF data using URB write messages. Cull test is performed on outside TF and HS kernel set the
appropriate DW enable, which carry the TF for different domain types. When DW is enabled and if cull
test is positive, HS stage will be informed by HDC unit, to cull the HS handle early at HS stage itself.
 DWord     Bits                              Description
  M0.7     31:0
                  Reserved

  M0.6     31:0
                  Reserved

  M0.5    31:17 Ignored
           16
                 High OWORD Enable

                     For URB_READ_OWORD and URB_WRITE_OWORD with
                     NOSWIZZLE indicates whether the 128 bits of the GRF
                     register is used.
                     0: 1 OWord, read into or written from the low 128 bits of the
                     GRF register
                     1: 1 OWord, read into or written from the high 128 bits of the
                     GRF register
           15
                     Vertex 1 DATA [3] / Vertex 0 DATA[7] Channel Mask
                     When Swizzle Control = URB_INTERLEAVED this bit controls
                     Vertex 1 DATA[3], when Swizzle Control = URB_NOSWIZZLE
                     this bit controls Vertex 0 DATA[7]. This bit is ANDed with the
                     corresponding channel enable to determine the final channel
                     enable. For the URB_READ_OWORD &
                     URB_READ_HWORD messages, when final channel enable
                     is 1 it indicates that Vertex 1 DATA [3] will be included in the
                     writeback message. For the URB_WRITE_OWORD &
                     URB_WRITE_HWORD messages, when final channel enable
                     is 1 it indicates that Vertex 1 DATA [3] will be written to the
                     surface.
                     0: Vertex 1 DATA [3] / Vertex 0 DATA[7] channel not included
                     1: Vertex DATA [3] / Vertex 0 DATA[7] channel included
           14
                     Vertex 1 DATA [2] Channel Mask

           13
                     Vertex 1 DATA [1] Channel Mask

           12
                     Vertex 1 DATA [0] Channel Mask

           11
                     Vertex 0 DATA [3] Channel Mask

           10
                     Vertex 0 DATA [2] Channel Mask

            9
                     Vertex 0 DATA [1] Channel Mask




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12               5/31/2012                                              21
 DWord   Bits                                Description
          8
                    Vertex 0 DATA [0] Channel Mask

          7:0
                 Reserved

  M0.4   31:0
                    Slot 1 Offset. This field, after adding to the Global Offset field in
                    the message descriptor, specifies the offset (in 256-bit units)
                    from the start of the URB entry, as referenced by URB Handle
                    1, at which the data will be accessed. This field is ignored
                    unless Swizzle Control is set to URB_INTERLEAVED.
                    For the URB_*_OWORD messages, this offset is in 128-bit
                    units instead of 256-bit units.
                    Format = U32
                    Range = [0, 1023] for URB_*_HWORD messages. The range
                    of the calculated offset must fall within the range [0, 1023] or
                    behavior is undefined.
                    Range = [0, 2047] for URB_*_OWORD messages. The range
                    of the calculated offset must fall within the range [0, 2047] or
                    behavior is undefined.
  M0.3   31:0
                    Slot 0 Offset. This field, after adding to the Global Offset field in
                    the message descriptor, specifies the offset (in 256-bit units)
                    from the start of the URB entry, as referenced by URB Handle
                    0, at which the data will be accessed.

                    For the URB_*_OWORD messages, this offset is in 128-bit
                    units instead of 256-bit units.
                    Format = U32
                    Range = [0, 1023] for URB_*_HWORD messages. The range
                    of the calculated offset must fall within the range [0, 1023] or
                    behavior is undefined.
                    Range = [0, 2047] for URB_*_OWORD messages. The range
                    of the calculated offset must fall within the range [0, 2047] or
                    behavior is undefined.
         31:16
  M0.2              : GS Number of Output Vertices for Slot 1. Indicates the number
                    of vertices output for geometry shader slot 1 primitive. This
                    field is only defined if end-of-thread is set on the message. It is
                    ignored for all messages from non-GS threads.
                     Format = U16

          15:0      : GS Number of Output Vertices for Slot 0. Indicates the number
                    of vertices output for geometry shader slot 0 primitive. This
                    field is only defined if end-of-thread is set on the message. It is
                    ignored for all messages from non-GS threads.
                    Format = U16




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                5/31/2012                                  22
 DWord       Bits                              Description
  M0.1      31:16
                       : Handle ID 1. This ID is assigned by the fixed function unit and
                       links the work in channel 1 to a specific entry within the fixed
                       function unit. This field is ignored unless Swizzle Control
                       indicates Interleave mode.
             15:0
                       URB Handle 1. This is the URB handle where channel 1’s
                       results are to be written or read. This field is ignored unless
                       Swizzle Control indicates interleave mode.

  M0.0      31:16
                       Handle ID 0. This ID is assigned by the fixed function unit and
                       links the work in channel 0 to a specific entry within the fixed
                       function unit.
             15:0
                       URB Handle 0. This is the URB handle where channel 0’s
                       results are to be written or read.


2.4.3.2       URB_WRITE_HWORD Write Data Payload
For the URB_WRITE_HWORD messages, the message payload will be written to the URB entries
indicated by the URB return handles in the message header.
    Payload                                                    Usage
URB_NOSWIZZLE
                          The message payload contains data to be written to a single URB entry (e.g.,
                          one Vertex URB entry). The Swizzle Control field of the message descriptor must
                          be set to ‘NoSwizzle’.
URB_INTERLEAVED
                          The message payload contains data to be written to two separate URB entries.
                          The payload data is provided in a high/low interleaved fashion. The Swizzle
                          Control field of the message descriptor must be set to ‘Interleave’.


2.4.3.2.1           URB_NOSWIZZLE
URB_NOSWIZZLE is used to simply write data into consecutive URB locations (no data swizzling
applied).
Programming Notes:

    The URB function will use (not ignore) the Channel Enables associated with this message.

When URB_NOSWIZZLE is used to write vertex data, the following table shows an example layout of a
URB_NOSWIZZLE payload containing one (non-interleaved) vertex containing n pairs of 4-DWord vertex
elements (where for the example, n is >2).
DWord Bit                            Description
 M1.7 31:0
             Vertex Data [7]

 M1.6 31:0
             Vertex Data [6]

 M1.5 31:0
             Vertex Data [5]




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                  5/31/2012                                             23
DWord Bit                             Description
 M1.4 31:0
             Vertex Data [4]

M1.3 31:0
             Vertex Data [3]

M1.2 31:0
             Vertex Data [2]

M1.1 31:0
             Vertex Data [1]

M1.0 31:0
             Vertex Data [0]

M2.7 31:0
             Vertex Data [15]

M2.6 31:0
             Vertex Data [14]

M2.5 31:0
             Vertex Data [13]

M2.4 31:0
             Vertex Data [12]

M2.3 31:0
             Vertex Data [11]

M2.2 31:0
             Vertex Data [10]

M2.1 31:0
             Vertex Data [9]

M2.0 31:0
             Vertex Data [8]

  …
             …

Mn.7 31:0
             Vertex Data [8(n-1)+7]

Mn.6 31:0
             Vertex Data [8(n-1)+6]

Mn.5 31:0
             Vertex Data [8(n-1)+5]

Mn.4 31:0
             Vertex Data [8(n-1)+4]

Mn.3 31:0
             Vertex Data [8(n-1)+3]

Mn.2 31:0
             Vertex Data [8(n-1)+2]

Mn.1 31:0
             Vertex Data [8(n-1)+1]

Mn.0 31:0
             Vertex Data [8(n-1)+0]




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                   5/31/2012   24
2.4.3.2.2        URB_INTERLEAVED
The following table shows an example layout of a URB_INTERLEAVED payload containing two
interleaved vertices, each containing n 4-DWord vertex elements (n>1).
Programming Restrictions:

     The URB function will use (not ignore) the Channel Enables associated with this message.
     Writes to overlapping addresses of vertex0 and vertex1 will have undefined write ordering.
DWord Bit         Description
 M1.7 31:0
             Vertex 1 Data [3]

 M1.6 31:0
             Vertex 1 Data [2]

 M1.5 31:0
             Vertex 1 Data [1]

 M1.4 31:0
             Vertex 1 Data [0]

 M1.3 31:0
             Vertex 0 Data [3]

 M1.2 31:0
             Vertex 0 Data [2]

 M1.1 31:0
             Vertex 0 Data [1]

 M1.0 31:0
             Vertex 0 Data [0]

 M2.7 31:0
             Vertex 1 Data [7]

 M2.6 31:0
             Vertex 1 Data [6]

 M2.5 31:0
             Vertex 1 Data [5]

 M2.4 31:0
             Vertex 1 Data [4]

 M2.3 31:0
             Vertex 0 Data [7]

 M2.2 31:0
             Vertex 0 Data [6]

 M2.1 31:0
             Vertex 0 Data [5]

 M2.0 31:0
             Vertex 0 Data [4]

  …
             …

 Mn.7 31:0
             Vertex 1 Data [4(n-1)+3]

 Mn.6 31:0
             Vertex 1 Data [4(n-1)+2]

 Mn.5 31:0
             Vertex 1 Data [4(n-1)+1]

 Mn.4 31:0
             Vertex 1 Data [4(n-1)+0]




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                5/31/2012                                         25
DWord Bit         Description
 Mn.3 31:0
             Vertex 0 Data [4(n-1)+3]

 Mn.2 31:0
             Vertex 0 Data [4(n-1)+2]

 Mn.1 31:0
             Vertex 0 Data [4(n-1)+1]

 Mn.0 31:0
             Vertex 0 Data [4(n-1)+0]



2.4.3.3       URB_READ_HWORD Writeback Message
For the URB_READ_HWORD messages, the URB entries indicated by the URB handles in the message
header are read and returned in the writeback message. The amount of read data returned is determined
by the Response Length field.
While GS threads will read one vertex at a time to the URB, the VS will read two interleaved vertices. The
description of the URB read messages will refer to the per-vertex DWords described in the Vertex URB
Entry Formats section of the 3D Overview chapter.
    Payload                                                   Usage
URB_NOSWIZZLE
                          The writeback message contains data read from a single URB entry (e.g., one
                          Vertex URB entry). The Swizzle Control field of the message descriptor must be
                          set to ‘NoSwizzle’.
URB_INTERLEAVED
                          The writeback message contains data read from two separate URB entries. The
                          data is provided in a high/low interleaved fashion. The Swizzle Control field of the
                          message descriptor must be set to ‘Interleave’.


2.4.3.3.1        URB_NOSWIZZLE
URB_NOSWIZZLE is used to simply read data into consecutive URB locations (no data interleaving
applied).
When URB_NOSWIZZLE is used to read vertex data, the following table shows an example layout of a
URB_NOSWIZZLE writeback message containing one (non-interleaved) vertex containing n pairs of 4-
DWord vertex elements (where for the example, n is >2).
DWord Bit       Description
 W0.7 31:0
             Vertex Data [7]

W0.6 31:0
             Vertex Data [6]

W0.5 31:0
             Vertex Data [5]

W0.4 31:0
             Vertex Data [4]

W0.3 31:0
             Vertex Data [3]

W0.2 31:0
             Vertex Data [2]

W0.1 31:0
             Vertex Data [1]




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                 5/31/2012                                                 26
DWord Bit        Description
 W0.0 31:0
             Vertex Data [0]

W1.7 31:0
             Vertex Data [15]

W1.6 31:0
             Vertex Data [14]

W1.5 31:0
             Vertex Data [13]

W1.4 31:0
             Vertex Data [12]

W1.3 31:0
             Vertex Data [11]

W1.2 31:0
             Vertex Data [10]

W1.1 31:0
             Vertex Data [9]

W1.0 31:0
             Vertex Data [8]

  …
             …

Wn.7 31:0
             Vertex Data [8n+7]

Wn.6 31:0
             Vertex Data [8n+6]

Wn.5 31:0
             Vertex Data [8n+5]

Wn.4 31:0
             Vertex Data [8n+4]

Wn.3 31:0
             Vertex Data [8n+3]

Wn.2 31:0
             Vertex Data [8n+2]

Wn.1 31:0
             Vertex Data [8n+1]

Wn.0 31:0
             Vertex Data [8n+0]


2.4.3.3.2         URB_INTERLEAVED
The following table shows an example layout of a URB_INTERLEAVED payload containing two
interleaved vertices, each containing n 4-DWord vertex elements (n>1).
DWord Bit        Description
 W0.7 31:0
             Vertex 1 Data [3]

W0.6 31:0
             Vertex 1 Data [2]

W0.5 31:0
             Vertex 1 Data [1]

W0.4 31:0
             Vertex 1 Data [0]

W0.3 31:0
             Vertex 0 Data [3]




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12           5/31/2012                                     27
DWord Bit        Description
 W0.2 31:0
             Vertex 0 Data [2]

W0.1 31:0
             Vertex 0 Data [1]

W0.0 31:0
             Vertex 0 Data [0]

W1.7 31:0
             Vertex 1 Data [7]

W1.6 31:0
             Vertex 1 Data [6]

W1.5 31:0
             Vertex 1 Data [5]

W1.4 31:0
             Vertex 1 Data [4]

W1.3 31:0
             Vertex 0 Data [7]

W1.2 31:0
             Vertex 0 Data [6]

W1.1 31:0
             Vertex 0 Data [5]

W1.0 31:0
             Vertex 0 Data [4]

  …
             …

Wn.7 31:0
             Vertex 1 Data [4n+3]

Wn.6 31:0
             Vertex 1 Data [4n+2]

Wn.5 31:0
             Vertex 1 Data [4n+1]

Wn.4 31:0
             Vertex 1 Data [4n+0]

Wn.3 31:0
             Vertex 0 Data [4n+3]

Wn.2 31:0
             Vertex 0 Data [4n+2]

Wn.1 31:0
             Vertex 0 Data [4n+1]

Wn.0 31:0
             Vertex 0 Data [4n+0]



2.4.3.4       URB_WRITE_OWORD Write Data Payload
For the URB_WRITE_OWORD messages, the message payload will be written to the URB entries
indicated by the URB return handles in the message header.
    Payload                                                  Usage
URB_NOSWIZZLE
                          The message payload contains data to be written to a single URB entry (e.g.,
                          one Vertex URB entry). The Swizzle Control field of the message descriptor must
                          be set to ‘NoSwizzle’.
URB_INTERLEAVED
                          The message payload contains data to be written to two separate URB entries.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                5/31/2012                                             28
      Payload                                                Usage
                          The payload data is provided in a high/low interleaved fashion. The Swizzle
                          Control field of the message descriptor must be set to ‘Interleave’.


2.4.3.4.1         URB_NOSWIZZLE
URB_NOSWIZZLE is used to simply write data into a single 128-bit URB location (no data swizzling
applied).
Programming Notes:

    The URB function will use (not ignore) the Channel Enables associated with this message.

When URB_NOSWIZZLE is used to write vertex data, the following table shows an example layout of a
URB_NOSWIZZLE payload containing one (non-interleaved) vertex containing 4-DWord vertex elements
and HIGH OWORD ENABLE is 0.
DWord Bit     Description
 M1.7 31:0 Ignored
 M1.6 31:0 Ignored
 M1.5 31:0 Ignored
 M1.4 31:0 Ignored
 M1.3 31:0
            Vertex 0 Data [3]

 M1.2 31:0
             Vertex 0 Data [2]

 M1.1 31:0
             Vertex 0 Data [1]

 M1.0 31:0
             Vertex 0 Data [0]

When URB_NOSWIZZLE is used to write vertex data, the following table shows an example layout of a
URB_NOSWIZZLE payload containing one (non-interleaved) vertex containing 4-DWord vertex elements
and HIGH OWORD ENABLE is 1.
DWord Bit       Description
 M1.7 31:0
             Vertex 0 Data [3]

 M1.6 31:0
             Vertex 0 Data [2]

 M1.5 31:0
             Vertex 0 Data [1]

 M1.4 31:0
             Vertex 0 Data [0]

 M1.3 31:0 Ignored
 M1.2 31:0 Ignored
 M1.1 31:0 Ignored
 M1.0 31:0 Ignored




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                5/31/2012                                              29
2.4.3.4.2        URB_INTERLEAVED
The following table shows an example layout of a URB_INTERLEAVED payload containing two
interleaved vertices, each containing 4-DWord vertex elements.
Programming Restrictions:

    The URB function will use (not ignore) the Channel Enables associated with this message.
    Writes to overlapping addresses of vertex0 and vertex1 will have undefined write ordering.
DWord Bit      Description
 M1.7 31:0
             Vertex 1 Data [3]

 M1.6 31:0
             Vertex 1 Data [2]

 M1.5 31:0
             Vertex 1 Data [1]

 M1.4 31:0
             Vertex 1 Data [0]

 M1.3 31:0
             Vertex 0 Data [3]

 M1.2 31:0
             Vertex 0 Data [2]

 M1.1 31:0
             Vertex 0 Data [1]

 M1.0 31:0
             Vertex 0 Data [0]



2.4.3.5       URB_READ_OWORD Writeback Message
For the URB_READ_HWORD messages, the URB entries indicated by the URB handles in the message
header are read and returned in the writeback message. The amount of read data returned is determined
by the Response Length field.
Programming Restrictions:

    Response Length must be set to 1.

While GS threads will read one vertex at a time to the URB, the VS will read two interleaved vertices. The
description of the URB read messages will refer to the per-vertex DWords described in the Vertex URB
Entry Formats section of the 3D Overview chapter.
    Payload                                                   Usage
URB_NOSWIZZLE
                          The writeback message contains data read from a single URB entry (e.g., one
                          Vertex URB entry). The Swizzle Control field of the message descriptor must be
                          set to ‘NoSwizzle’.
URB_INTERLEAVED
                          The writeback message contains data read from two separate URB entries. The
                          data is provided in a high/low interleaved fashion. The Swizzle Control field of the
                          message descriptor must be set to ‘Interleave’.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                 5/31/2012                                                 30
2.4.3.5.1        URB_NOSWIZZLE
URB_NOSWIZZLE is used to simply read data into consecutive URB locations (no data interleaving
applied).
When URB_NOSWIZZLE is used to read vertex data, the following table shows an example layout of a
URB_NOSWIZZLE writeback message containing one (non-interleaved) vertex containing 4-DWord
vertex elements and HIGH OWORD ENABLE is 0.
DWord Bit          Description
 W0.7 31:0 Reserved (not written to GRF)
 W0.6 31:0 Reserved (not written to GRF)
 W0.5 31:0 Reserved (not written to GRF)
 W0.4 31:0 Reserved (not written to GRF)
 W0.3 31:0
            Vertex Data [3]

W0.2 31:0
             Vertex Data [2]

W0.1 31:0
             Vertex Data [1]

W0.0 31:0
             Vertex Data [0]

When URB_NOSWIZZLE is used to read vertex data, the following table shows an example layout of a
URB_NOSWIZZLE writeback message containing one (non-interleaved) vertex containing 4-DWord
vertex elements and HIGH OWORD ENABLE is 1.
DWord Bit           Description
 W0.7 31:0
             Vertex Data [3]

W0.6 31:0
             Vertex Data [2]

W0.5 31:0
             Vertex Data [1]

W0.4 31:0
             Vertex Data [0]

W0.3 31:0 Reserved (not written to GRF)
W0.2 31:0 Reserved (not written to GRF)
W0.1 31:0 Reserved (not written to GRF)
W0.0 31:0 Reserved (not written to GRF)


2.4.3.5.2        URB_INTERLEAVED
The following table shows an example layout of a URB_INTERLEAVED payload containing two
interleaved vertices, each containing 4-DWord vertex elements.
DWord Bit      Description
 W0.7 31:0
             Vertex 1 Data [3]

W0.6 31:0
             Vertex 1 Data [2]

W0.5 31:0
             Vertex 1 Data [1]

W0.4 31:0
             Vertex 1 Data [0]




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12            5/31/2012                                             31
DWord Bit      Description
 W0.3 31:0
             Vertex 0 Data [3]

W0.2 31:0
             Vertex 0 Data [2]

W0.1 31:0
             Vertex 0 Data [1]

W0.0 31:0
             Vertex 0 Data [0]



2.4.4     URB_ATOMIC*
The URB_ATOMIC messages implement atomic operations on a single DWord in the URB. The location
of the DWord within the URB is specified by the single URB handle and the Global Offset field in the
message descriptor, which for these messages is a DWord offset from the URB handle. The DWord
selected will be operated on according to the following table:

URB Opcode           new_dst       ret
URB_ATOMIC_MOV
                          src0    none

URB_ATOMIC_INC
                    old_dst + 1 old_dst



The previous contents of the DWord are returned in the destination register for the URB_ATOMIC_INC.
The URB_ATOMIC_MOV opcode does not return data (response length must be zero).
The URB_ATOMIC* messages consist only of the header. A single URB handle is specified.

2.4.4.1       Message Header
DWord Bit                                              Description
 M0.7 31:0
 M0.6 31:0
 M0.5 31:0 Ignored
 M0.4 31:0 Ignored
 M0.3 31:0 Ignored
 M0.2 31:0
                Source0 Data

                  Specifies the source 0 data for the atomic operation. This field is ignored for the
                  URB_ATOMIC_INC message.
                  Format = U32
 M0.1 31:0 Ignored
 M0.0 31:16 Ignored
       15:0
                 URB Handle. This specifies the URB handle to be accessed.



2.4.4.2       Writeback Message
A writeback message is only returned for the URB_ATOMIC_INC message. Only the low 32 bits of the
destination GRF register are overwritten with the return data.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                 5/31/2012                                             32
DWord Bit                                Description
W0.7:1     Reserved (not written to GRF)
 W0.0 31:0
            Return Data

                 Specifies the value of the return data for the atomic operation.
                 Format = U32

Here is a description of the 3DMark11 usage model (from their func spec):
4.4.1 Depth of Field
The effect is computed using the following procedure:
1. Circle of confusion radius is computed for all screen pixels and stored in a full resolution
DXGI_FORMAT_R16_FLOAT texture.
2. Half and quarter resolution versions are made from the radius texture and the original illumination texture.
3. Positions of out-of-focus pixels whose circle of confusion radius exceeds a predefined threshold are appended to
a buffer.
4. The position buffer is used as point primitive vertex data and, utilizing Geometry Shader (GS), image of hexagon-
shaped bokeh is splatted to positions of these vertices. Splatting is done to a
DXGI_FORMAT_R16G16B16A16_FLOAT texture. Multiple viewports are used to partition the texture to regions with
different sizes. First region is screen size and the rest are a series of halved regions down to size 1x1 texels. The
radius of the splatted bokeh determines the used viewport. The larger the radius the smaller the used viewport.
5. Steps 3 and 4 are done separately for full, half, and quarter resolution image data with different radius thresholds.
Larger bokehs are generated from lower resolution image data.
6. The different regions of the splatting texture are combined by up-scaling the data in the smaller regions to the
screen size region.
7. The combined splatted out-of-focus illumination is combined with the original illumination.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                      5/31/2012                                                      33
3. Shared Functions – Video Motion
   Estimation
The Video Motion Estimation (VME) engine is a shared function that provides motion estimation services.
It includes motion estimation for various block sizes and also standard specific operations such as

     Motion estimation and mode decision for AVC
     Intra prediction and mode decision for AVC
     Motion estimation and mode decision for MPEG2
     Motion estimation and mode decision for VC1

The motion estimation engine may also be used for other coding standards or other video processing
applications.


3.1      Theory of Operation
VME performs a sequence of operations to find the best mode for a given macroblock. Each operation
step can be enabled/disabled through the control of the income message. Early termination, skipping of
subsequent operation steps, is also supported when certain search criteria are met.
VME contains the following operation steps:
            1.   Skip check
            2.   IME: Integer motion estimation
            3.   FME: Fractional motion estimation
            4.   BME: Bidirectional motion estimation
            5.   IPE: Intra prediction estimation (AVC only)


3.1.1      Shape Decision
As a terminology, we call sub-block shapes: 8x4, 4x8, and 4x4 minor shapes (corresponding to sub-
partitions of 8x8 sub-macroblock), and 16x16, 16x8, 8x16, and 8x8 major shapes (corresponding to sub-
macroblocks of a 16x16 macroblock).
If the maximal allowed number of motion vectors MaxNumMVs (MaxNumMVs =
MaxNumMVsMinusOne + 1) is less than 4, we will set minor MV flag off: MinorMVsFlag = 0, i.e. no
minor motion vectors will be generated.
The reason of having this parameter MaxNumMVs is due to high level AVC conformance restrictions for
certain profiles: the total number of motion vectors of any two consecutive macroblocks not exceeding 16 (or 32) .
The mechanism here allows a reasonable degree of user control. In disable cases, MaxNumMVs should
be set to 32.
In the coding process of VME, the shape decision is done in multiple locations:
 1) After IME and before FME, intermediate shape decision is performed to reduce the FME searching
     candidates
 2) After FME and before BME, existing shape decision is revised among the remaining candidates and
     to see if there is further reduction.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                     5/31/2012                                                 34
 3) Final shape decision is done after BME.
Partition decision before BME uses unidirectional motion vector count to meet MaxNumMVs requirement.
Adding BME for the partition candidates may exceed MaxNumMVs. As BME is performed on a block by
block basis using the block order for a given partition, BME step for a given block is skipped and the best
unidirectional motion vectors are used for the block if the overall motion vector count exceeds
MaxNumMVs when that particular block is switched to bidirectional. The process continues to the last
block of the partition.
Note: This is a sub-optimal solution to simplify the hardware implementation. For some cases,
bidirectional modes with larger sub-partitions might be better than unidirectional modes with finer sub-
partitions.
The VME implementation has the following restriction: Multiple partition candidates are only enabled if
PartCandidateEn is set. And this only applies to source block of size 16x16.
If PartCandidateEn is not set, only the best partition is kept in state 1 (after IME) above and carried
through FME and BME. In other words, FME if enabled only operates on one partition candidate, and
BME if enabled only operates on one partition candidate. Bidirectional mode check only applies to the
partition candidates that meet the bidirectional restriction provided by BiSubMbPartMask. For example, if
a minor partition determined based on best unidirectional cost function is not 8x8 but one of 4x8, 8x4 or
4x4, VME skips the bidirectional mode check.
If PartCandidateEn is set, up to two sets of candidates are maintained by VME hardware, if the second
best partition candidate is within PartToleranceThrhd from the best one. The second best partition is
selected only from the two major partition candidates based on the unidirectional motion vector count,
subject to that the major partition is enabled:

    1MV: The 16x16 partition
    4MV: The 4x(8x8) partition with no minor shape

The following partitions are not supported as alternative partition.

    2MV: The best of 2x(16x8) and 2x(8x16) partitions
    More than 4MV: The best of all 4x(8x8) partitions with at least one 8x8 having minor shape of 8x4,
     4x8 or 4x4

3.1.1.1      Minor Shape Decision Prior to FME
If any minor shapes are selected, we decide the best minor first.
For each 8x8 sub-block, before performing bidirectional, we reduce code candidates to no more than
three based on the best unidirectional motion search results (best of the forward and backward):
     0)         One MV, i.e. the best in shape of 8x8.
     1)         Up to two MVs, i.e. the best in shapes 8x8, 8x4, or 4x8. And
     2)         Up to four MVs, i.e. the best for the sub-block 8x8.
Now for the first and the second sub-blocks, we can merge them into up to six candidates of 2, 3, 4, 5, 6,
and 8 possible motion vectors.
Do the same to the third and the fourth sub-blocks, we have similarly up to six candidates.
Now we further combine these two groups, and find the best solution under the constraint of not
exceeding the number of motion vectors more than MaxNumMVs. (see pseudo-code below for detail.)




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                 5/31/2012                                                35
Consequently, we have the best combined 8x8 solutions with N motion vectors for some N less or equal
to MaxNumMVs.
Assume distA[k][s] is the cost-adjusted distortion of the best forward or backward motion vector mix of
the k-th 8x8 sub-block of the sub-shape s, where s=0,1,2, and 3 represent shape partitioning 8x8, 8x4,
4x8, and 4x4 respectively. Assume distA[k][s] is the bidirectional one of the corresponding bus-block
and sub-shape. And assume some large number, say 128x16=2048 is assigned to the variable, if there
were no valid corresponding codes. Hence, the following pseudo-code explains the code selection
algorithm.
Let’s first explain the case MaxNumMVs is disbled, i.e.MaxNumMVs16:
void SelectBestCombinedMinors(
short *distA,
short*MinorShape,
short*MinorDisto
){
shorts[4], d[4];
      s = ShapeList;
      d = DistoList;
      for(int k=0;k<4;k++){
s[k] = 0;d[k] = distA[k][0];
if(distA[k][1])<d[k]){ d[k]=distA[k][1]; s[k]=1; }
if(distA[k][2])<d[k]){ d[k]=distA[k][3]; s[k]=2; }
if(distA[k][3])<d[k]){ d[k]=distA[k][3]; s[k]=3; }
}
      *MinorDisto = d[0]+d[1]+d[2]+d[3];
*MinorShape = s[0]|(s[1]<<2)|(s[2]<<4)|({s[3]<<6};
}

Now for the case of using MaxNumMVs control:
void SelectBestCombinedMinors(
short *distA,
intMaxNumMVs,
short*MinorShape,
short*MinorDisto
){
int k, n;
short dist, best0 = 0, best1 = 0;
      if(MaxNumMVs< 4){ // we reset other parameters
switch(MaxNumMvs){
case 0:
     DoIntraInter &= (~DO_INTER); // not do Inter
     break;
case 1:
     ShapeMask |= (NO_16X8|NO_8X16);
     BidirMask |= NO_16X16;
case 2: case 3:
     ShapeMask |= (NO_8X8|NO_8X4|NO_4X8|NO_4X4);




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12              5/31/2012                                             36
    BidirMask |= (NO_16X8|NO_8X16);
    break;
}
     }
     if(MaxNumMVs>=16){ // it should use unrestricted code selection
SelectBestCombinedMinors(DistA,MinorShape,MinorDisto);
return;
     }
short*s, ShapeList[18];
short*d, DistoList[18];
     s = ShapeList;
     d = DistoList;
     for(k=0;k<4;k++){
s[0] = 0;// 1 mv
d[0] = distA[k][0];
s[4] = (distA[k][2]<distA[k][1])+1; // 2 mvs
d[4] = distA[k][s[1]];
s[8] = 3;// 4 mvs
d[8] = distA[k][3];
s ++, d ++;
     }
     // Merge two:
     s = ShapeList;
     d = DistoList;
     for(k=0;k<2;k++){
s[16]= 0x33; // 8 mvs
d[16]= d[8]+d[10];
s[12]= (d[4]+d[10]<d[6]+d[8])?(s[4]|0x30):(0x03|(s[6]<<4));// 6 mvs
d[12]= (d[4]+d[10]<d[6]+d[8])?(d[4]+d[10])<(d[6]+d[8]);
s[10]= (d[0]+d[10]<d[8]+d[2])?0x30:0x03; // 5 mvs
d[10]= (d[0]+d[10]<d[8]+d[2])?(d[0]+d[10])<(d[8]+d[2]);
s[8] = s[4]|(s[6]<<4);// 4 mvs
d[8] = d[4]+d[6];
s[6] = (d[4]+d[2]<d[0]+d[6])?s[4]:(s[6]<<4);        // 3 mvs
d[6] = (d[4]+d[2]<d[0]+d[6])?(d[4]+d[2])<(d[0]+d[6]);
s[4] = 0; // 2 mvs
d[4] = d[0]+d[2];
if(d[ 6]>d[ 4]) d[ 6] = d[ 4];
if(d[ 8]>d[ 6]) d[ 8] = d[ 6];
if(d[10]>d[ 8]) d[10] = d[ 8];
if(d[12]>d[10]) d[12] = d[10];
d[14] = d[12];
if(d[16]>d[12]) d[16] = d[12];
s ++; d ++;
     }




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12       5/31/2012                      37
     s = ShapeList;
     d = DistoList;
*MinorDisto = 2048;
     for(k=0;k<8;k++){
n = MaxNumMVs – k;
if(n>=2 && n<=8)<2){
dist = d[(k<<1)+1]+d[n<<1];
if(dist<*MinorDisto){
*MinorDisto = dist;
best0 = (n<<1);
best1 = (k<<1)+1;
}
}
     }
     while(best0>1 && d[best0]==d[best0-2]) best0 -= 2;
     while(best1>1 && d[best1]==d[best1-2]) best1 -= 2;
     *MinorShape = s[best0]|((s[best1]<<2);
}


3.1.1.2      Major Shape Decision Prior to FME
Now considering the best of each 8x8 is done, and we have the total cost-adjusted-distortion for this sub-
block level partition. Now among the four choices: the resulting 8x8 sub-partitioning, one 16x16, two
16x8, and two 8x16, the one gives the best cost-adjusted-distortion, will determine the final decision of
partitioning shape. Any among these four, if its cost-adjusted-distortion is within the intermediate
tolerance (which is a predefined system state) from the best distortion will be marked as candidate
shapes.
Notice that, when the intermediate tolerance is set to 0, only the best shape will be selected as the
candidate. When the intermediate tolerance is large, all four shapes will become candidates.
Assume we have all the distortions for majors enumerated in DistoMajor[k], where k = 0, 1, 2, 3, 4, and
5, for 16x16, 16x8, 8x16, the combined minors, 16x8 field, and 8x8 field respectively. Assume BestDisto
is equal to the minimal of the six values DistoMajor[k], for k = 0, …5. Assume the intermediate
tolerance is IntTol, the major shape k is a candidate shape if and only if
DistoMajor[k]<=BestDisto+IntTol.

3.1.1.3      Shape Update after FME
Among all the candidate shapes, we recheck the distortion, if any of them is no longer with in the
intermediate tolerance DistortionTolerance from the best choice; we drop it for reduced calculation.

3.1.1.4      Final Code Decision after BME
For any given candidate shape, for each motion vector, if we do have improved distortion by switch from
the single direction to bi-direction, then we do it, unless the increased number of motion vectors hits
above MaxNumMVs; in this case, we take as many as possible first the ones generate the most
improvement.
Then, we choose the best among the improved candidate shapes.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                5/31/2012                                              38
3.1.2      Integer Motion Estimation
IME, the integer motion estimation, is the most key part of VME. In our current design, the minimal
functional block is to do a full search over a search unit. This functional block is then called via two
distinctive methods:
1)           Via a predefined searching path of search units.
2)           Via a dynamic process based on the previous results.
This section will describe both.

3.1.2.1      Reference Window and Search Units
The reference window is a rectangular region fetched put in the reference cache for VME. Either one or
two reference windows are allowed to be loaded into the reference cache. In the case of dual windows,
both windows follow a common search path or different paths (relative to their corresponding Start
Center) depending on the dual search path option flag.
The total reference cache is limited to 2K bytes and only the luma component searching is performed. For
example, we may select the reference windows to be one of the following sample choices: one 64x32
area, one 48x40 area, two 40x24 areas, or two 32x32 areas, where the possible reference address will
cover an area of 48x16, 32x24, 24x8, and 16x16.
As a convention, we will call the valid reference addressing region the reference region, and its width and
height are called the reference window width and height respectively. So the reference loading region of
VME has therefore 16 more columns and 16 more rows.
It is not efficient for hardware to search one location at a time due to reference cache access bandwidth and
latency constraints. Thus, possible reference search locations are grouped in a predefined pattern, and all
locations within the same group must be either all are chosen or all are skipped. These predefined groups
are called search unit (SU). Reference Window and Search Units shows a sample of grouping search locations
into searching units. The reference window in the figure has a dimension of 32x20, and assuming the
source block is 8x8, the dark dots indicate all legitimate reference locations for motion searching. It shows
a partitioning of SUs of 16 locations.
In general, the indices of SUs are given by counting rows and units within the row.




Example of Search Units in a reference window
Given a fixed reference cache access latency, SU size is determined solely based on the source block
size as shown in Reference Window and Search Units. Note that SU sizes for both 16x8 and 8x16 source
blocks are both 8x4, which gives a preference for motions along horizontal direction.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                   5/31/2012                                               39
Determination of Search Unit size based on Source Block dimension
         Source Block Dimension                         Search Unit (SU) Size (X x Y)           GT Support
                 16x16                                              4x4                             Y
                  16x8                                              8x4                             Y
                  8x16                                              8x4                             N
                   8x8                                              8x8                             Y

To keep tracking on whether a SU has been searched or not, an equivalent hardware process is
implemented performing as a search record that marks whether any search units being searched is a bit-
plan of the bit-length equal to the maximal index of SUs. Before searching starts, the search record must
be reset which sets the value 0 (= yet-to-be-searched) to all legitimate SU indices, and the value 1 (= no
longer available) for other SUs that are not intended to be searched.
Given a search window, unique indices are assigned to all SUs. A search path (SP), is a sequence of such
indices. The number of SUs in a SP is called the length of the walker (denoted by LenSP here), which shall be
a number more than one. Instead of storing the absolute indices of a search path, relative search unit deltas
are sent instead. In the current VME a search unit delta is a 8 bit index consisting of a pair of 4-bit signed
integers in [-8,8).

Given start center in a pair of 4-bit unsigned integer (sx, sy), and denote a search path described in SU deltas
(dx[i],dy[i]). The first search unit SU[0] will be the search unit which has the first reference address (sx*4,
sy*4) in integer-pel relative to the reference origin., i.e.

SU[0].x = sx*4, and SU[0].y = sy*4.

The second search unit SU[1] is derived by adding (dx[0],dy[0]):

SU[1].x = SU[0].x + dx[0]*4, and SU[1].y = SU[0].y + dy[0]*4.
In general, we have:
SU[i+1].x = SU[i].x + dx[i]*4, and SU[i+1].y = SU[i].y + dy[i]*4.

When SU[i] is out of range, it is either always skipped or always wrapped depending on the SU wrapping flag.
When the SU wrapping flag is on, it is equivalent to as we perform
SU[i].x = SU[i].x(mod ref_win_width), and

SU[i].y = SU[i].y(mod ref_win_height),
As a convention, a NULL delta marks the end of the search path.

3.1.2.2       Fixed and Adaptive Search Paths
A fixed pattern motion search algorithm is an algorithm following some predefined SP with the designated
MaxNumSU (maximal number of search units) less or equal to LenSP (the fixed search path length). This is
referred to as fixed pattern searching or predetermined searching.
When MaxNumSU > LenSP, (the maximal number of SU is more than what are given by the SP), the
searching continues unless reaching a local minimum, which is called dynamic searching or adaptive
searching or gradient searching. In this case, the current best result is used. If it is located in some SU
boundary, the neighborhood SUs are checked and any one of them that is yet-to-be-searched will be the
next SU to be searched. If all neighbor SU’s are done, the process of IME is done. Fixed and Adaptive
Search paths illustrates on how neighbor SUs are defined for dynamic search.

Hardware maintains one scoreboard per reference to keep track of the state of SUs, whether being
searched or yet-to-be-searched. When dual records are enabled on a single reference, both records will
share the same scoreboard for the reference.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                     5/31/2012                                               40
Sample neighborhood SUs in a dynamic search


Fixed and Adaptive Search paths shows the algorithm of this integrated solution. In order to hide the decision
logic of dynamic walking, the one-step-delayed-queue is implemented. So when searching the current
SU, the next SU will be put in the queue. If there are more SUs yet to be searched in the current SP, the
next SU will be the next SU according to SP; if there is no more SU from SP, the first unsearched
neighbor SU (in some predefined order) based on the current best result will be put instead, and if there is
no more unsearched neighbor SU, the integer searching terminates.
To reduce the one-step-delay, and to support bidirectional, we create the dual mode that allows the
above algorithm to be ping-pong-ed between two search paths. Fixed and Adaptive Search paths illustrates
this case.
In both figures, the best MVs refer to the best resulting motion vectors so far. There are potentially total
41 motion vectors (1 for 16x16, 2 for 16x8, 2 for 8x16, 4 for 8x8, and 32 more for 8x4, 4x8 and 4x4
cases). The current hardware implementation only considers the four 8x8 MVs.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                 5/31/2012                                                    41
VME in single SP mode




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12   5/31/2012   42
VME in Dual SP mode




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12   5/31/2012   43
3.1.3      Fractional Motion Estimation
Instead of following the exact interpolation as specified by the individual video standards, 4 tap
interpolation is used for the Fractional Motion Estimation (FME) step in the VME engine. It is expected to
be adjusted according to different standards.

3.1.3.1      Interpolations
Instead of following the exact interpolation as specified by the individual video standards, fixed 4 tap
interpolation is used in the VME engine, as defined below:
1)           (-1,5,5,-1)/8 for ½-pel, i.e. s = (P1+P2*5+P3*5P4+4)/8 and

2)           (-1,13,5,-1)/16 for ¼-pel position, i.e. c = (P1+P2*13+P3*5P4+8)/16.




Fractional pixel locations
The quarter-pels are actually the averages of its nearest integer and half pixel values.
It is not hard to see our suggested interpolation formulas are very much the good approximations of the
formulas from various standards
For AVC, they should be the following 6-tap formulas in theory:
1)           (1, -5,20,20,-5,1)/32 for ½-pel, i.e. s = ((P2+P3)*20(P1+P4)*5+(F0+F6), and
2)           (1,-5,52,20-5,-1)/64 for ¼-pel position.. n.
For VC-1, the 4-tap filters are precisely defined:
1)           (-1,9,9,-1)/16 for ½-pel, and
2)           (-4,53,18,-3)/64 for ¼-pel position.
In general, bilinear interpolation is accepted too:
3)           (0,1,1,0)/2 for ½-pel (as used in MPEG2), and
4)           (0,3,1,0)/4 for ¼-pel position.
After IME is done, if the best Inter result is too bad, we may decide to stop the Inter-search to not waste
the effort further computationally. If we decided to continue, we have the option to decide shape first to
cut down FME calculation or to perform FME for all possible configurations.
VME performs the sub-block level intermediate shape decision first (see Shape Decision section for detail),
then perform FME only for the reduced candidate shapes. In this way, the computation is reduced
significantly with tunable small quality hit.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                      5/31/2012                                              44
3.1.3.2      8+8 vs. 7x7
With a given sub-block of motion vector search, we also have multiple options to pursue the searching.
Name two common extremes: 7x7 and 8+8.
Given an integer motion vector location, surrounding it there are 48 surrounding quarter-pel locations, and
among them there are 8 are in half-pel grids. So we may check all 48, which covers the 7x7 region, for
the best, or we may adopt a two-step approach by considering the half-pel grids first then followed by the
second step of the quarter-pel refinement.
The one step method is named as 7x7, and the two step method called 8+8 as only 16 block comparisons
are performed as shown in the next figure.
VME hardware follows the 8+8 approach.




                             7x7                                              8+8


7x7 vs. 8+8, whereas the 8+8 method is used by VME

3.1.3.3      Partitioning Refinement
When the partitioning refinement is enabled, the FME refinement results will be propagated to or sub-
blocks as well, and a shape partitioning will be redone after the completion of both half-pel and quarter-
pel searching for a possible better choice.
In the case when alternative candidate is enabled, both half-pel refinements are done in parallel, and then
records are combined. Then, both quarter-pel refinements are done again in parallel, and combined again
prior to the final repartitioning. In HW implementation, we do the coarser on first, and the finer one later to
achieve the above equivalence.


3.1.4      BME and Weighted Prediction
Bidirectional searching is performed to all candidate shapes.
A weighted bidirectional search is supported particularly for AVC implicit weighted prediction. Only a
common subset of frame relations, which falls into linear interpolation with positive weight, is




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                 5/31/2012                                                  45
implemented. The weight between forward and backward is approximated into 5 cases only: 16 (quarter
distance like Rf B X X Rb), 21 (one third distance like Rf B X Rb), 32 (half distance like Rf B Rb), 43 (two
third distance like Rf X B Rb), and 48 (three quarter distance like RXXBR). Here the notation is for
bidirectional prediction with display picture order, whereas Rf stands for forward reference, Rb for
backward reference, B for the current bidirectional predicted picture and X is another picture in the
sequence.
So if the forward prediction is {Ref0[i]}, and the corresponding backward reference is {Ref1[i]}, then
the combined bidirectional motion prediction is calculated as the following:
     Ref[i] = ((64-alpha)*Ref0[i] + alpha*Ref1[0] + 32)>>6;
where, alpha is one of the 5 weighting numbers mentioned above.


3.1.5      Skip Check
There are two SKIP modes:

          SKIP_1MVP – one MV pair for 16x16 macroblock, and
          SKIP_4MVP – four MV pairs for four 8x8 subblocks.

Otherwise, when Skip Check is enabled and the skip MV number does not exceed MaxMumMV, VME will
first perform the fractional motion estimation at the skip centers provided by the motion vector pairs as
specified by the corresponding mode. In this case the following distortions will be calculated:
      1.   RawSkipDist – (intended for AVC PB_Skip) the raw SAD/HAAR distortion calculated from the
           skip motion vectors with no costing added.
      2.   NonSkipDist – (intended for AVC B_Direct16x16) the adjusted non-skip distortion is defined by
           adding optionally the zero motion vector cost and 16x16 Inter mode penalty to RawSkipDist.
           And
      3.   NonSkip8x8Dist[4] – (intended for AVC B_Direct8x8) the four adjusted non-skip distortions for
           four individual 8x8 subblocks with the ZMV cost and 8x8q Inter mode penalty optionally added.
           (Note: This case may produce partitions with 8x8 subblock even if the 8x8 subblock shape is
           disabled.)
“Optional” implies whether add or not is purely depende on two enabling input bits: NonSkipModeAdded
and NonSkipMvAdded. It should be also noted that MODE_INTER_BWD is not added to NonSkipDist
or NonSkip8x8Dist[] even though a skip center contains backward motion vector (this is for a direct
mode, whether the motion vector for a block is forward, backward or bidirection is derived from its spatial
or temporal predictor and there is no coding cost).
If RawSkipDist is less than or equal to EarlySkipSuccess threshold, MinDist will be set to RawSkipDist
if the skip MV number does not exceed MaxMumMV.

          If EarlySuccessEn flag is on, VME exits immediately afer setting MbSkipFlag on, and
           Direct8x8Pattern = Fh.
          If EarlySuccessEn flag is off, VME continue the IME, FME, BME, and Direct8x8 searching
           after setting MbSkipFlag on and Direct8x8Pattern = Fh. VME will choose the skip output
           unless another better choice of code with less adjusted distortion is found.

If RawSkipDist is greater than EarlySkipThreshold, MinDist will be set to NonSkipDist if the skip MV
number does not exceed MaxMumMV. MbSkipFlag will be always set to off. VME continue the IME,
FME, BME, and Direct8x8 searchings. VME will still choose the skip output (with MbSkipFlag off) unless
another better choice of code with less adjusted distortion is found.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                 5/31/2012                                                46
3.1.5.1      Direct 8x8 Search
Direct8x8 Searching and then possible replacement is performed ONLY for 16x16 source block.
Direct8x8 Searching is performed only for Skip_4MVP mode when skip check is on to candidates of
MbType in a partition that is in the Inter shape of 8x8 or minors, after IME, FME, and BME searchings.
For each candidate in 8x8 or smaller partition, and for each 8x8 sub-block, the corresponding codes will
be replaced by the skip motion vector (pair) of the same 8x8 subblock, if all of the following requirements
are satisfied:

          The non-skip 8x8 distortion NonSkip8x8Dist[k] is less than or equal to the adjusted 8x8
           distortion of the corresponding codes.
          The merge does not violate uni-mix and bi-mix rules (the violating cases are skipped).
          The number of MVs used for the cadidate adding the number of subblocks of the shape 8x8
           must be less than or equal to MaxNumMV. Or otherwise it does not replace a uni-directional
           8x8 MV with a true bi-directional skip MV pair.

Note that, during all of the above comparisons, we skip the process whenever the MV numbers
exceeding the MaxNumMV.
If either UniMixDisable or BiMixDis is set, then there would be no direct8x8 block level replacement.

3.1.5.2      Skip Check Only Mode
VME supports the skip check only mode, when Intra is set off, Inter and Skip are enabled, and all 7 inter
shapes (SubMbPartMask): 16x16, 16x8, 8x16, 8x8, 8x4, 4x8, and 4x4 are set to 1 (all sub partitions are
turned off). That indicates that none of the partition and sub partitions are valid for IME. Therefore IME is
not performed, and no subsequent FME/BME is performed. This is another performance optimization
choice if the intended usage is to check the skip centers only.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                 5/31/2012                                                47
3.1.6        Intra Prediction Estimation
Intra Prediction Estimation state supports all Intra16x16, Intra8x8, and Intra4x4 modes. All predictions are
based on original frame pixels for quick performance, as widely adopted in HW industry. There is a known
quality drop.
For supporting AVS as well as providing finer knobs for AVC, five enabling flags are defined:

     Enable Intra16x16: whether Intra16x16 shall be performed.
     Enable Intra8x8: Enable all Intra8x8 modes, and the next flag determines which ones are actually
      performed.
     AVS Intra8x8 Flag: whether should perform the subset of 5 AVS modes or perform the super set of 8
      AVC modes.
     Enable Intra4x4: Enable all Intra4x4 modes, and the next flag determines which ones are actually
      performed.
     AVS Intra4x4 Flag: whether should perform the subset of 5 AVS modes or perform the super set of 8
      AVC modes.


3.1.7        Transform Adjusted SAD
A simple Wavelet transform, Haar transform, is used to refine the cost function measure of SAD. The per
pixel difference goes through a 4x4 Haar transform. Then the SAD is replaced by the sum of the absolute
values the transform domain coefficients (L1 norm) in the cost function. Haar transform here is used as a
coarse estimation of the integer transform.
Assume the a 4x4 block Blk is given in the following order:
 0 1 2 3
 4 5 6 7
 8 9 10 11
12 13 14 15

The 4x4 Haar transform is performed using cascaded 2x2 Haar filters of the following steps:

     Four 4-tap row filter
     Two 4-tap column filter
     Two 2-tap row filter
     Two 2-tap column filter

Where the 2x2 Haar transform is give as
     1 1
     1 -1

                      x00 x01 x02 x03     1 0 1 0
                      x10 x11 x12 x13     1 0 -1 0
                      x20 x21 x22 x23     0 1 0 1
                      x30 x31 x32 x33     0 1 0 -1

            1 1 0 0   t00 t01 h08 h09




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                5/31/2012                                               48
          0 0 1 1   t02 t03 h10 h11
          1 -1 0 0 t04t05 h12 h13
          0 0 1 -1 t06t07 h14 h15

                    t00 t01               1 1
                                          1 -1
                    t02 t03
                    h04 h05
                    h06 h07

          1 1       t00 h02
          1 -1
                    t01 h03

                    h00
                    h01

This is equivalent to the following pseudo codes:
void Haar(short Blk4x4[16], short Haar4x4[16])
{
      shortTmp[16];
      //First level 4-element horizontal Haar for 4 rows
      For(int i=0;i<8;i++) {
              Haar4x4[8+i] = (Blk4x4[i*2]-Blk4x4[i*2+1]);
              // Storing LP 2x4 in scan order
              Tmp[i]          = (Blk4x4[i*2]+Blk4x4[i*2+1]));
      }
      //First level 4-element vertical Haar for 2 columns
     Haar4x4[4] = (Tmp[0]-Tmp[2]);
     Haar4x4[5] = (Tmp[1]-Tmp[3]);
     Haar4x4[6] = (Tmp[4]-Tmp[6]);
     Haar4x4[7] = (Tmp[5]-Tmp[7]);
     Tmp[0] = (Tmp[0]+Tmp[2]); //Storing LP 2x2 in scan order
     Tmp[1] = (Tmp[1]+Tmp[3]);
     Tmp[2] = (Tmp[4]+Tmp[6]);
     Tmp[3] = (Tmp[5]+Tmp[7]);
     //Second level 2-element horizontal Haar for 2 columns
     Haar4x4[3] = (Tmp[0]-Tmp[1]);
     Haar4x4[2] = (Tmp[2]-Tmp[3]);
     Tmp[0] = (Tmp[0]+Tmp[2]); //Storing LP 1x2
     Tmp[1] = (Tmp[1]+Tmp[3]);
     //Second level 2-element vertical Haar
     Haar4x4[1] = (Tmp[0]-Tmp[1]);
     Haar4x4[0] = (Tmp[0]+Tmp[1]);
}
int AdjustedSAD(BYTE Src[16], BYTE Ref[16]){
     short diff[16], diffH[16];




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                5/31/2012      49
      for(int i=0;i<16;i++) diff[i] = r[i]-s[i];
      Haar(diff,diffH);
      intasad = 0;
      for(int i=0;i<16;i++) asad += (diff[i]<0?-diff[i]:diff[i]);
      asad >>= (12-DISTBIT4X4);
      return (asad);
}

Thus instead of calculating the SAD of the actual pixel values, now we apply SAD to the after
transformation values.
As the Haar transform basis vectors have a magnitude of ½, instead of the normalized Haar of 1/sqrt(2),
the resulting transformed coefficients maintain the same bit precision as the input. Thus the sum tree has
the same precision as without the transform adjustment. However, this version of Haar transform has low
weightings on the DC and low AC terms, which may not be optimal as a motion-search cost function.


3.1.8      Early Decisions
There are 5 programmable early decision states are available for fine control of the VME process. All
stored in one byte of U4U4 format to representing a value of (B<<S), (where B, called base, is the 4-LSB
of the byte and S, called shift, is the 4-MSB of the byte,) they are the following:
    a) ESS: EarlySkipSuccess = Early successful return after Skip is checked
    b) EIS: EarlyImeStop = Early IME stop when a good match is found inside of IME process.
    b) ITG: ImeTooGood = Early successful return after IME is done when a good enough match is found.
  a) ITB: ImeTooBad = Early termination do skip fractional and bidirectional refinement after IME is done
with a hopelessly bad match as the best result.
    c) EFS: EarlyFmeSuccess = Early Success after Fractional ME to skip bidirectional search.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12               5/31/2012                                               50
Note. For any reason, if all possible code types are not chosen, VME will return Intra16x16 type with all
modes set to 0, and the MinDist is set to 0x3FFF.


3.1.9      Performance Information
VME makes many internal decisions such as whether or not early exits occurred. Additionally, the number
of search units processed and the total clocks spent per message are valuable to software for real-time
adjustments or testing and statistical analysis. VME output message contains such information to fulfill
this basic feature.
The output message for VME contains fields to encode decision and performance counters. This includes
performed sub-functions (IME, FME, BME, etc), the early exit conditions, and other internal decisions.
Of the “other” internal decisions, there are fields for whether or not FME or BME improved the primary
candidate. These bits will be set when FME or BME modifies the best mv decision. If the “alternate
partition” or “extra candidate” results in a lower cost at the end of VME, a bit will be used to represent that
the alternate beat the original best. Lastly, 1 bit will be used to indicate partitioning was constrained by
MaxMV. For example, if 16x16 was the lowest sad+cost and MaxMV was set to 10, the partitioning was
not constrained. However, if 8x8 was the lowest sad+cost and MaxMV was set to 1, partitioning was
constrained by MaxMV and this bit would be set.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                  5/31/2012                                                 51
There are also 3 counter values. One is to report the total number of search units processed by the back-
end (max is 48). Another is to report the total time the front-end is starved due to cache misses, counted
in divisions of 16 clocks (max is 1024*16 clocks). This will most likely be active at the beginning of a VME
request, however, even after processing has begun, if any front-end stalls occur this counter should
resume counting. Hence, when the VME request has finished, this counter will have the total time the
front-end is stalled. The third field is used to report the total time the back-end consumed for computation,
also counted in divisions of 16 clocks (max is 256*16 clocks) [Note: this should include any bubbles in the
pipe, simply put, if front-end is not stalled, this counter should be free-running]. Thus, by adding total
front-end starved time with total back-end computation time, the exact total VME message time can be
obtained.


3.1.10 VME Changes
VME remains fundamentally unchanged (same sub-functions, etc). However there are a few features
being added:

           Bilinear interpolation,
           AVC Intra mode mask,
           Native multi-call support,
           Expanded MV cost distance),
           Motion vector, Skip center, and Cost center redefinitions to be relative to source MB,
           Removal of a skip motion vector restriction that required skip centers must be contained within
            the search window.

These have a non-trivial impact to the input & output message format and it is cleaner to describe a new
message for, which can be found in section 6.5 and 6.6 along with further details.


3.2      Surfaces
The data elements accessed by VME are called “surfaces”. Surfaces are accessed using the surface
state model.
VME uses the binding table to bind indices to surface state, using the same mechanism used by the
sampling engine. A Binding Table Index (specified in the message descriptor) of less than 255 is used to
index into the binding table, and the binding table entry contains a pointer to the SURFACE_STATE.
SURFACE_STATE contains the parameters defining the surface to be accessed, including its location,
format, and size.


3.3      State

3.3.1       BINDING_TABLE_STATE
VME uses the binding table to retrieve surface state. Refer to Sampling Engine for the definition of this
state.


3.3.2       SURFACE_STATE
VME uses the surface state for current and reference surfaces. Refer to Sampling Engine for the definition
of this state.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                   5/31/2012                                               52
3.3.3      VME_STATE
This state structure contains the state used by the VME engine for data processing. VME state contains
the motion search path location tables and rate-distortion weight look-up-tables. As the two sets of tables
are fairly large, they are accessed as two separate states via state indexing mechanism so that
applications can inter-mix the use of the search path tables and RDLUT tables.
Even though VME engine has its unique shared function ID (see Target Function ID field in the SEND
instruction), the VME state is delivered through the Sampler State Pointer. When the General Purpose
Pipe is used, the Sampler State Pointer is programmed in the
MEDIA_INTERFACE_DESCRIPTOR_LOAD command and delivered directly to Sampler/VME by
hardware. This posts one usage limitation. As the VME state is overloaded on top of the Sampler State
Pointer, VME messages cannot be intermixed with other Sampler messages.
Each VME state may contain up to 8 VME_SEARCH_PATH_LUT_STATE. When multiple
VME_SEARCH_PATH_LUT_STATE are used, they need to be stored in memory contiguously. Each
VME_SEARCH_PATH_LUT_STATE contains 32 dwords in comparison of 4 dwords of a Sampler State.
When enabling sampler state pre-fetch (programming the Sampler Count field in the
MEDIA_INTERFACE_DESCRIPTOR_LOAD command), one VME_SEARCH_PATH_LUT_STATE is
equivalent to 8 Samplers. Hardware may support up to two VME_SEARCH_PATH_LUT_STATE to be
pre-fetched (See vol2b Media chapter for more details).

3.3.3.1         VME_SEARCH_PATH_LUT_STATE
Up to eight VME_SEARCH_PATH_LUT_STATE allowed for a message to select. Each state contains
one set of search path locations, and four sets of rate distortion cost function LUT for various modes and
rate distortion cost function LUT for motion vectors (relative to ‘cost center’). Motion vector cost function is
provided as a piece-wise-linear curve with only the values of the power-of-2 positions provided.
DWord Bit                                                    Description
 0:13           Search Path

   0    31:24 Search Path Location [3] (X, Y) – Relative distance from location [2]

        23:16 Search Path Location [2] (X, Y) – Relative distance from location [1]

         15:8 Search Path Location [1] (X, Y) – Relative distance from location [0]

          7:4   Search Path location [0] (Y) – specifies relative Y distance of the next walk from the starting position
                in unit of Search Unit (SU) in U4
                Format = U4, (e.g. 0x3 + 0xE = 0x1)

          3:0   Search Path Distance [0] (X) – specifies relative X distance of the next walk from the starting position
                in unit of SU.
                Format = U4

 1:13           Search Path Location [4 – 55] (X, Y)

14:31           RD LUT SET 0-4

  14    31:24
                LUT_MbMode [9] for Set 1
                Format = U4U4 (encoded value must fit in 12-bits)




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                      5/31/2012                                                       53
DWord Bit                                                Description
     23:16
              LUT_MbMode [8] for Set 1
              Format = U4U4 (encoded value must fit in 12-bits)
       15:8
              LUT_MbMode [9] for Set 0
              Format = U4U4 (encoded value must fit in 12-bits)

       7:0
              LUT_MbMode [8] for Set 0
              Format = U4U4 (encoded value must fit in 12-bits)
 15   31:24
              LUT_MbMode [9] for Set 3
              Format = U4U4 (encoded value must fit in 12-bits)
      23:16
              LUT_MbMode [8] for Set 3
              Format = U4U4 (encoded value must fit in 12-bits)
       15:8
              LUT_MbMode [9] for Set 2
              Format = U4U4 (encoded value must fit in 12-bits)

       7:0
              LUT_MbMode [8] for Set 2
              Format = U4U4 (encoded value must fit in 12-bits)
 16   31:24
              LUT_MbMode [3] for Set 0
              Format = U4U4 (encoded value must fit in 12-bits)
      23:16
              LUT_MbMode [2] for Set 0
              Format = U4U4 (encoded value must fit in 12-bits)

       15:8
              LUT_MbMode [1] for Set 0
              Format = U4U4 (encoded value must fit in 12-bits)
       7:0
              LUT_MbMode [0] for Set 0
              Format = U4U4 (encoded value must fit in 10-bits)
 17   31:24
              LUT_MbMode [7] for Set 0
              Format = U4U4 (encoded value must fit in 10-bits)
      23:16
              LUT_MbMode [6] for Set 0
              Format = U4U4 (encoded value must fit in 10-bits)

       15:8
              LUT_MbMode [5] for Set 0
              Format = U4U4 (encoded value must fit in 10-bits)
       7:0
              LUT_MbMode [4] for Set 0
              Format = U4U4 (encoded value must fit in 12-bits)




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                  5/31/2012           54
DWord Bit                                                  Description
 18 31:24
                LUT_MV [3] – For MV = 4 for Set 0
                Format = U4U4 (encoded value must fit in 10-bits)
        23:16
                LUT_MV [2] – For MV = 2 for Set 0
                Format = U4U4 (encoded value must fit in 10-bits)

        15:8
                LUT_MV [1] – For MV = 1 for Set 0
                Format = U4U4 (encoded value must fit in 10-bits)
         7:0
                LUT_MV [0] – For MV = 0 for Set 0
                Format = U4U4 (encoded value must fit in 10-bits)
  19    31:24
                LUT_MV [7] – For MV = 64 for Set 0
                Format = U4U4 (encoded value must fit in 10-bits)
        23:16
                LUT_MV [6] – For MV = 32 for Set 0
                Format = U4U4 (encoded value must fit in 10-bits)

        15:8
                LUT_MV [5] – For MV = 16 for Set 0
                Format = U4U4 (encoded value must fit in 10-bits)
         7:0
                LUT_MV [4] – For MV = 8 for Set 0
                Format = U4U4 (encoded value must fit in 10-bits)

20-23           Finish RD LUT SET 1

24-27           Finish RD LUT SET 2

28-31           Finish RD LUT SET 3

The assignment of LUT_MbMode entries is according to the MbTypeEx definition:
The value of each byte of the LUTs will be viewed as a pair of 4-bit units: (shift, base), and constructed as
        base << shift.
For example, an entry 0x4A represents the value (0xA<<0x4) = 10*16 = 160. Encoded value must fit in
12-bits (unsigned number); otherwise, the hardware behavior is undefined.
The only exception is for Index of 9, MODE_INTER_BWD, which is used as a bias for the two search
directions. It is a signed number instead, in the form of (SU3U4) = (sign, shift, base). The sign bit
indicates whether the bias is added to the forward (if sign = 1) or the backward (if sign = 0). The bias has
a magnitude of (base << shift), which has 11-bits precision. It should be noted that the number is always
added, there is no subtraction.
Intra Modes only apply to AVC standard. The mode penalty doesn’t apply to Skip Mode Checking. Note
that while other mode penalty applies to a fixed macroblock partition, MODE_INTRA_NONPRED applies
to all three intra modes. It is a constant cost adder for intra-mode coding regardless of the block size.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                    5/31/2012                                             55
For source block that is less than 16x16 (like a 16x8 source block), the proper mode penalty that is stated
as “added per 16x16 macroblock” is added once to the source block (like MODE_INTER_16x8 is added
once to a 16x8 source block). It will not be divided by the source block size.
The LUT_MV is added to all motion vector coordinate deltas in quarter-pel unit except for the SKIP mode,
which no costing penalty applies. Given motion vector coordinate, e.g. mvx, which is in quarter-pel
precision (S5.2), the mv delta is defined to be its difference from the given costing center, e.g. ccx, and
the costing penalty is applied to dx = |mvx-ccx|. The cost penalty is a piecewise linear interpolation from
the LUT_MV table whereas the values on power-of-2 integer samples are provided. The piecewise linear
interpolation is performed using quarter-pel precision, while the LUT_MV are only provided for the given
power-of-2 integer positions. The maximum distance provided in the table is 64 pixels. A linear ramp with
gradient of 1 on integer distance is applied for bigger distances with maximum penalty capped to 0x3FF
(10 bits). Thus,
      Costing_penalty_x = LUT_MV[int(dx)], if dx < 3 and dx = int(dx);

      Costing_penalty_x = LUT_MV[p+1], else if dx = 2p, for any p6;.
      Costing_penalty_x = LUT_MV[p+1] + ((LUT_MV[p+2] – LUT_MV[p+1])*k)>>p, else if dx = 2p+k, for
      any p<6 and k<.2p, and
      Costing_penalty_x = min (LUT_MV[7] + int(dx)– 64, 255), else if dx > 64.

The total costing penalty for a motion vector is
      Costing_penalty = Costing_penalty_x + Costing_penalty_y
As a convention, a (0,0) relative search path distance (meaning a repeat search path location) is treated
as the ending of the search path. Or the search path may also end when Max Predetermined Search
Path Length is reached, or one of the Early Success conditions is reached.
Software must program the search path to terminate with at least one (0,0).


3.4       Change Details

3.4.1      Record Stream-out and Stream-in

3.4.1.1       Overview
VME internally keeps track of the best motion vectors for all shapes and sub-shapes, totaling 41 for each
record of the two records (forward and backward). Once IME is finished, each record is mined for the best
combination of shapes (i.e. the combination of the least distortion). The return message from VME to the
EU contains only the best shape combination and the remainder of the record is discarded.
For cases when the user wants to search beyond the VME window limits (64x32 for single reference,
32x32 for dual reference) the user must call VME multiple times. Since only partial information is returned
to the kernel, extracting the best shape combination across multiple calls is impossible. The best
workarounds require the kernel to limit the types of shapes VME is allowed to return and then the kernel
will manually merge shapes from multiple calls, cumbersome and suboptimal with respect to quality.
By returning more of the record to the kernel and allowing the kernel to feed in that information on
subsequent calls as initialization information, the process of searching beyond VME size limitations is
vastly improved. Now the merging of best shapes will occur inside VME and the global best shape
combination is more optimized.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                  5/31/2012                                              56
If both records are returned in their entirety, this would require 16 additional message phases (each
shape requires 3 DWs, total of 82 shapes) for both input and output messages. A compromise to reduce
this burden yet still gain the bulk of the improvement is to stream-out only the best major shapes (9
shapes, one 16x16, two 16x8, two 8x16, and four 8x8) for both records. This adds only 4 additional
message phases (when under search control == 111b, otherwise 2 additional phases) and carries the
most important shape data across multiple calls.

3.4.1.2      Implementation Details
In essence this feature creates 2 types of records inside VME, a local and a global record. The local
record contains the best shapes within a single call to VME, i.e. the current call only. The global record is
carried via stream-in and stream-out, containing the best major shapes.
VME should only consider the local record during IME and FME, finding the local call’s optimal shapes
independent of the global record. For purposes of partitioning, the merging of the global record’s shapes
into the local record should occur after FME is finished on the current call and prior to repartitioning.
Otherwise local shapes identified during IME might not be considered for FME if the global shape was
superior to the IME result.
There is a new stage immediately following FME where the local record major shapes are compared to the
stream-in data, replacing the local record’s major shapes with the stream-in shape if it has a lower distortion.
Steps following this (repartitioning, BME, final mode decision) proceed like the previous generation.
As a part of the final stage, the stream-out record is generated simply taking the 9 major shapes out of
the local record (which was merged with local record earlier).
The merging of global and local motion vectors prior to BME could allow the winning shape combination
to not have all of its corresponding pixels in the SC (since the SC would only have local motion vector
pixels). Hence, a simple check is required prior to performing BME that ensures the motion vectors are
from the local call only, passing cases will perform BME and failing cases will not (test is applied on a per-
shape basis).
No native support within VME for multi-reference unidirectional surface mixing, the kernel can implement
a workaround if required, but there is no justification for such feature in the HW at this time.


3.4.2      MV Definitions and Precision

3.4.2.1      Overview
Given that VME is trying to natively support larger search windows with stream-in, due to both necessity
and general improvements a number of input and output vectors (aka centers) must grow in precision. At
the same time, the points from which they are relative to are also being redefined. In most cases for the
previous generation (motion vectors, skip centers, cost centers) were defined relative to the reference
window origin, requiring the kernel to calculate the necessary offsets from the source MB location. Now
all vectors are defined relative to the source MB location (and the source MB is defined relative to the
picture origin).

3.4.2.2      Implementation Details
The following diagrams provide details regarding the precision, range, and origin of all input (4 types),
output (1 type), and internal vectors (first shown all together, then individually). Many vectors are
composed from input or other internal vectors (via addition or subtract) and those equations are present.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                  5/31/2012                                                  57
3.4.3      Expanded MV Costs

3.4.3.1      Overview
Given that VME will be searching larger areas with the Record Stream-out feature, it is also necessary
that we revisit our MV costing methodology. Given this is calculated in terms of quarter-pel units, this
allows the user to provide variable costing penalty for a maximum distance of 16 pixels away from the
cost center.
We would like to expand this range by implementing a variable scaling factor (i.e. right shift, binary divide) of
the MV distance prior to comparison to the user-defined intervals (where VME previously looked at the lsbs
only). This will be provided to VME as a 2 bit value, specifying the shift amount (0: qpel, 1: hpel, 2:
single-pel, 3: two-pel). For instance, if the user a selects the MV cost scaling to be “3”, this expands the
maximum MV costing interval to a distance of 128 pixels.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                  5/31/2012                                                   58
3.4.4      Remove Skip MV Restriction

3.4.4.1      Overview
We will remove this restriction and allow the 8 skip centers to be located anywhere within the legal AVC
motion vector definitions (“Horizontal motion vector range does not exceed the range of -2048 to 2047.75,
inclusive, in units of luma samples.” And “Vertical MV component range MaxVmvR (luma frame samples) = [-512,
+511.75]”).

This restriction was originally imposed to reduce the complexity and cost of the hardware for processing
skips and directs require pixels beyond that of the reference window used for IME, FME and BME.

3.4.4.2      Implementation Details
Skips must still be associated with the same surface state as their corresponding reference window (4
skip centers are for ref0, 4 are for ref1).
Skip centers are still bound as pairs. Hence, if the fwd x-component was 0xff, that meant this skip center
pair was unidirectional and only in the bwd direction. If neither x-component are 0xff, then this is a
bidirectional pair.
However, mv.x = 0xff is now a legal motion vector value and thus we cannot overload this field to control the
skip center pair’s type.We will incorporate a new 8b field, “Skip Center Enables” (M1-DW7-31:24), to
control which of the 8 skip center pairs is valid. At least 1 of the skip centers for each pair must be valid
when in 4MVP mode (in 1MVP mode only 1 of the skip centers for the 1st pair must be valid).


3.4.5      Bilinear Interpolation

3.4.5.1      Overview
Since MPEG2 only allows for half-pel interpolation, implementation of this bilinear filter is required only for
half-pel mode. However, if there are no HW concerns implementing bilinear for quarter-pel also, please
go ahead as there could be users who prefer it over our general purpose filter.


3.4.6      AVC Intra Mode Mask

3.4.6.1      Overview
AVC has 9 different intra modes for both 4x4 and 8x8 transforms and 4 modes for 16x16 transform. For a
mask will be feed into VME (9b+9b+4b), telling it which modes cannot be selected as output candidates. This
will be a 9 bit field, disabling a given mode for the entire macroblock.



3.5       Messages
Request message bearing SFID of VME is routed to VME engine.
Programming Note:

     Use of any message to the Video Motion Estimation function with the End of Thread bit set in the
      message descriptor is not allowed.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                  5/31/2012                                                    59
3.5.1       VME Motion Search Request
Restrictions:

      the only surface type allowed is SURFTYPE_BUFFER.
      the surface format is ignored, data is returned from the constant buffer to the GRF without format
       conversion.
Applications:

      Motion search for video encoding
      Motion search for video processing such as deinterlace, frame rate conversion, etc.
Execution Mask. The execution mask is ignored.
Out-of-Bounds Accesses. Pixel replication is invoked for reads to areas outside of the surface.


3.5.2       Message Descriptor
                                                                                            Same as Prev.
 Bit                                       Description                                         Gen?
 19                                                                                             yes
         Header Present. If set, indicates that the message includes the header. This bit
         must be set to one for all VME messages
         Format = Enable
         Reserved: MBZ
 18:17                                                                                           yes
  16                                                                                             no
         Stream-in Enable. If set, additional message phases of record stream-in will be
         present with the input: 4 additional phases only when search control (M0.3 10:8)
         is 111b (dual reference & dual record) and 2 additional phases otherwise.
         Format = Enable
  15                                                                                             no
         Stream-out Enable. If set, additional message phases of record stream-out will
         be present with the output: 4 additional phases only when search control (M0.3
         10:8) is 111b (dual reference & dual record) and 2 additional phases otherwise.
          Format = Enable

14:13                                                                                            yes
         Message Type
         00: Reserved
         01: Inter-search only
         10: Intra-search only
         11: Inter- and intra-search enabled
12:11                                                                                            yes
         LUT_SUBINDEX. Specifies the index into the RDLUT state table.

 10:8                                                                                            yes
         VME_SEARCH_PATH_LUT State Index. Specifies the index into the
         VME_SEARCH_PATH_LUT state table. When dual records are used, both
         records share the same predetermined search path.
 7:0                                                                                             yes
         Binding Table Index. Specifies the index into the binding table for the current
         surface.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                      5/31/2012                                            60
                                                                                              Same as Prev.
 Bit                                       Description                                           Gen?
         Forward reference surface is implied as [Binding Table Index + 1] and
         the backward reference surface is implied as [Binding Table Index + 2]
         Format = U8
         Range = [0,254]



3.5.3       Input Message

3.5.3.1        Message Header and Payload
The message header and payload size is determined based on the Message Type:
     Message Type                       Mnemonic                          Message Length         Response Length
          01                         Inter-search only                     5 + (stream-in)        6 + (stream-out)
          10                         Intra-search only                             5                      1
          11                 Inter- and intra-search enabled               5 + (stream-in)        6 + (stream-out)

When stream-in is enabled:

      If (search control == 111b), the message length is +4 for total of 9 phases.
      Else (search control != 111b), the message length is +2 for total of 7 phases.

When stream-out is enabled:

      If (search control == 111b), the response length is +4 for total of 10 phases.
      Else (search control != 111b), the response length is +2 for total of 8 phases.

For Message Type of 01, the VME request message contains the following two phases:
                                                                                                              Same as
 DWord         Bit                                          Description                                      Prev. Gen?
  M0.7        31:0                                                                                              yes
                       Reserved

  M0.6        31:0                                                                                              yes
                       Reserved

  M0.5       31:24                                                                                              yes
                       Reference Region Height (RefHeight): This field specifies the reference region
                       height in pixels. When bidirectional search is enabled, this applies to both search
                       regions. Minus 16 provides the number of search point in vertical direction.
                       The value must be a multiple of 4.
                       Format = U8
                       Range = [20, 64]

             23:16                                                                                              yes
                       Reference Region Width (RefWidth): This field specifies the search region width
                       in pixels. When bidirectional search is enabled, this applies to both search
                       regions. Minus 16 provides the number of search point in horizontal direction.
                       The value must be a multiple of 4.
                       Format = U8
                       Range = [20, 64]
                       Note: Please make sure the reference windows are not completely outside of the




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                      5/31/2012                                                      61
                                                                                                        Same as
 DWord     Bit                                     Description                                         Prev. Gen?
                  video frame, in that case, VME behavior is undefined.

                  Ignored
           15:8                                                                                           yes
           7:0                                                                                            yes
                  Dispatch ID. This ID is assigned by the fixed function unit and is a unique
                  identifier for the thread. It is used to free up resources used by the thread upon
                  thread completion.
  M0.4
           31:0   Ignored                                                                                 yes
  M0.3
            31    Reserved : MBZ                                                                          yes
                  (for Bidirectional Mirror mode, which is used for AVS mode. 0: disable for non-
                  AVS mode; 1: enabled: the best forward and the best backward MV will be
                  mirrored for AVS bidirectional search. Notice that, the mv cost penalty shall be
                  applied only for one set of mvs in this case.)

          30:24                                                                                           yes
                  Sub-Macroblock Sub-Partition Mask (SubMbPartMask): This field defines the
                  bit-mask for disabling sub-partition and sub-macroblock modes.
                  The lower 4 bits are for the major partitions (sub-macroblock) and the higher 3
                  bits for minor partitions (with sub-partition for 4x(8x8) sub-macroblocks.
                  xxxxxx1 : 16x16 sub-macroblock disabled
                  xxxxx1x : 2x(16x8) sub-macroblock within 16x16 disabled
                  xxxx1xx : 2x(8x16) sub-macroblock within 16x16 disabled
                  xxx1xxx : 1x(8x8) sub-partition for 4x(8x8) within 16x16 disabled
                  xx1xxxx : 2x(8x4) sub-partition for 4x(8x8) within 16x16 disabled
                  x1xxxxx : 2x(4x8) sub-partition for 4x(8x8) within 16x16 disabled
                  1xxxxxx : 4x(4x4) sub-partition for 4x(8x8) within 16x16 disabled
                  Usage note: one example usage of only enabling 4x(4x4) sub-partition while all
                  other partitions are disabled is for video processing, whereas parallel motion
                  searches are performed for 16 4x4 blocks. For that no further block combination
                  (into larger sub-partitions/sub-macroblocks) is needed.

          23:22                                                                                           yes
                  Intra SAD Measure Adjustment (IntraSAD): This field specifies distortion
                  measure adjustments used for the motion search SAD comparison.
                  This field must be set to 00 if Source Block Field Mode is 1 (interleaved).
                  00 : none
                  01 : Reserved
                  Better set to 00 if Source Block Field Mode is 1 (interleaved).
          21:20                                                                                           yes
                  Inter SAD Measure Adjustment (InterSAD): This field specifies distortion
                  measure adjustments used for the motion search SAD comparison.
                  00 : none
                  01 : Reserved
                  10 : Haar transform adjusted




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                  5/31/2012                                                    62
                                                                                                             Same as
 DWord     Bit                                        Description                                           Prev. Gen?
                  11 : Reserved
                  Better set to 00 if Source Block Field Mode is 1 (interleaved).

  M0.3     19                                                                                                  yes
                  Block-Based Skip Enabled: when this field is set on the skip thresholding
                  passing criterion will be based on the maximal distortion of individual blocks
                  (8x8’s or 4x4’s) instead of their sum (i.e. the distortion of 16x16). The block size is
                  8x8 if and only if the Transform 8x8 Flag is set to ON and the source size is
                  16x16..
           18                                                                                                  no
                  Not implemented.
                  Reserved: MBZ
           17                                                                                                  yes
                  Disable Aligned VME Source Fetch: This field, when set disables the VMEunit
                  functionality that aligns source data requests to 16 pixels. (This bit is ignored if
                  SrcX and SrcSize are such that requests for source data cannot be aligned to 16
                  pixels. The source data requests will be misaligned in these cases)
           16                                                                                                  yes
                  Disable Aligned VME Reference Fetch: This field, when set disables the
                  VMEunit functionality that fragments reference data requests which are not
                  aligned to 16 pixels into 16 pixel aligned requests. This may be used when the
                  surface is not a multiple of 16 pixels and a portion of the reference data is outside
                  the surface.

           15                                                                                                  yes
                  Disable Field Cache Allocation: This field, when set to 1, disables the optimized
                  field cache line method in the Sampler Cache for reference block data when
                  RefAccess is 1 (field based). It is ignored by hardware if RefAccess is 0.
                  0 – frame cache lines
                  1 – field cache lines
           14                                                                                                  yes
                  Skip Mode Type (SkipType):
                  For B_DIRECT_16x16, both motion vectors of the skip center pair 0 are used.
                  For B_DIRECT_8x8s, all four skip center pairs are fully used (VME will never try
                  to combine them with non-skip shapes from IME, FME or BME).
                  0 : SKIP_1MVP – one MV pair for 16x16
                  1 : SKIP_4MVP – Four MV pairs for 8x8s ( in this case and only this case,
                  SkipCenter Delta 1-3 will be used)
                  Note: SkipTypeMode should be programmed to 1MVP for non-16x16 Source size
          13:12                                                                                                yes
                  Sub-Pel Mode (SubPelMode):This field defines the half/quarter pel modes. The
                  mode is inclusive, ie., higher precision mode samples lower precision locations.
                  00 : integer mode searching
                  01 : half-pel mode searching
                  10 : reserved
                  11 : quarter-pel mode searching
           11                                                                                                  yes
                  Dual Search Path Option: Used only for dual record cases, this field flags




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                   5/31/2012                                                        63
                                                                                                        Same as
 DWord     Bit                                    Description                                          Prev. Gen?
                  whether two searching records uses the same or the different paths.
                  0: use the same path as specified by the Search Path Location array
                  1: use the different paths, the first one uses the even entries of the Search Path
                  Location array and the second one uses the odd entries of the Search Path
                  Location array.

           10:8                                                                                           yes
                  Search Control (SearchCtrl): This field specifies how the motion search is
                  performed.
                  The following table shows the valid encodings. Other encodings are reserved.

                                 Code                                 Mode
                  000
                                                       Single reference, single record
                                                       and single start.
                                                       Search is performed only on
                                                       reference 0; only cost center 0 and
                                                       start 0 are used. There is only one
                                                       record. Adaptive search is also
                                                       allowed. However, when
                                                       AdaptiveEn is on, LenSU must be
                                                       at least 2 as the adaptive search in
                                                       VME is one-step delayed.
                                                       This is the common single
                                                       directional motion search mode.
                  001
                                                       Single reference, single record
                                                       and dual start.
                                                       Search is performed only on
                                                       reference 0; only cost center 0 is
                                                       used. There is only one record.
                                                       Search performs first on start 0
                                                       and then on start 1. Then if LenSP
                                                       is not reached, the predetermined
                                                       search path will start on start 1
                                                       with increment added to start 1
                                                       location. It then is followed by
                                                       adaptive search.
                                                       This is used for single direction
                                                       adaptive search.

                  011
                                                       Single reference, dual record
                                                       (and implied dual start).
                                                       Search is performed only on
                                                       reference 0; both cost center 0
                                                       and 1 and start 0 and 1 are used.
                                                       Two records are used for both
                                                       paths during IME.
                                                       When integer search is complete,
                                                       the two records are combined to
                                                       find the best search. Sub-pel




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                 5/31/2012                                                     64
                                                                                                           Same as
 DWord     Bit                                       Description                                          Prev. Gen?
                                                      refinement is only performed from
                                                      the best one.
                                                        This may be used for search for
                                                        multiple motion search
                                                        candidates/predicators.
                 111
                                                        Dual reference, dual record (and
                                                        implied dual start).
                                                        Search is performed on references
                                                        0/1 with both cost centers 0/1 and
                                                        starts 0/1. Two records are used
                                                        for both paths during IME.
                                                        When integer search is complete,
                                                        and then sub-pel refinement is
                                                        also performed separately, the two
                                                        records are combined to find the
                                                        best search on a subblock basis.
                                                        This may be used for bidirectional
                                                        motion search, or multi-reference
                                                        P search. Whether bidirectional is
                                                        enabled or not depends on the
                                                        bidirection sub-macroblock mask.
                                                        If BiSubMbPartMask is set to
                                                        1111’b, bidirectional search is
                                                        disabled. VME will output only the
                                                        best unidirectional search results.
                                                        Otherwise, BME will be performed.
                                                        Note that bidirectional search
                                                        and sub-pel refinement are
                                                        orthogonal features that can be
                                                        enabled indepdently.
            7                                                                                                yes
                 Reference Access (RefAccess): This field defines how the reference blocks are
                 accessed from the reference frames. It indicates if the source picture is a frame
                 picture or a field picture.
                 Programming Note: For all known video coding standards, reference
                 pictures always have the same picture type as the source picture.
                 Therefore, this field should be programmed to be the same as SrcAccess.
                 0 : frame based
                 1 : field based

            6                                                                                                yes
                 Source Access (SrcAccess): This field defines how the source block is
                 accessed from the source frame. It indicates if the source picture is a frame
                 picture or a field picture. It is similar to the Picture Type used in video standards.
                 0 : frame based
                 1 : field based
           5:4                                                                                               yes
                 Inter MbType Remap (MbTypeRemap): This field controls the mapping of the




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                  5/31/2012                                                       65
                                                                                                              Same as
 DWord     Bit                                        Description                                            Prev. Gen?
                  output MbType when the VME output is an Inter (IntraMbFlag = INTER). The
                  intended usage, for example, is for two forward (or backward) references or for
                  two search regions from the same reference picture in one VME call. Hardware
                  ignores this field if the VME output is an intra type (IntraMbFlag = INTRA).
                  00 : no remapping
                  01 : remapping MbType to forward only (1-3 mapped to 1, even numbers in [4-
                  14h] mapped to 4, odd numbers in [5-15h] mapped to 5, and 16h is unchanged)
                  10 : remapping MbType to backward only (1-3 mapped to 2, even numbers in [4-
                  14h] mapped to 6, odd numbers in [5-15h] mapped to 7, and 16h is unchanged)
                  11 : reserved

            3                                                                                                   yes
                  Reserved: MBZ

            2                                                                                                   yes
                  Reserved : MBZ

           1:0                                                                                                  yes
                  Source Block Size (SrcSize): This field defines how the 16x16 source block is
                  formed. When Source Block Size is less than 16x16, SU larger than 4x4 will be
                  used.
                  00: 16x16
                  01: 16x8
                  10: Reserved (for 8x16)
                  11: 8x8
  M0.2    31:16                                                                                                 no
                  Source Y (SrcY): This field defines the vertical position (of the block’s upper-left
                  pixel) in unit of pixels for the source block in the source picture (relative to picture
                  origin, not frame origin).
                  For field source (SrcAccess=1), the SrcFieldPolarity (M1.7-19), is required by
                  hardware to identify if this is top or bottom field of an interleaved memory surface.
                  The resulting Y address in the reference picture must be in even line aligned
                  within the reference picture. Specifically, if the reference picture is a frame picture.
                  the resulting Y address must be 2-line aligned; if the reference picture is a field
                  picture within a frame storage, and the resulting Y address must be 2-line aligned
                  within the field. i.e. it must be an even number for the frame case, and must be
                  equal to 0 or 1 modulo 4 for the field case.
                  Format = U16

           15;0                                                                                                 yes
                  Source X (SrcX): This field defines the horizontal position (of the block’s upper-
                  left pixel) in unit of pixels for the source block in the source picture.
                  The source block must be within the source picture starting at any integer grid.
                  Format = U16
  M0.1    31:16                                                                                                 no
                  Reference 1 Y Delta (Ref1Y): This field defines the vertical position (of the
                  upper-left corner of the reference region) in unit of pixels for Reference 1 region
                  relative to the source MB Y value on its respective picture.
                  For field reference (RefAccess=1), the Ref1FieldPolarity (M1.7-21), is required by
                  hardware to identify if this is top or bottom field of an interleaved memory surface.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                   5/31/2012                                                         66
                                                                                                            Same as
 DWord     Bit                                          Description                                        Prev. Gen?
                  The resulting Y address in the reference picture must be in even line aligned
                  within the reference picture. Specifically, if the reference picture is a frame picture.
                  the resulting Y address must be 2-line aligned; if the reference picture is a field
                  picture within a frame storage, and the resulting Y address must be 2-line aligned
                  within the field. i.e. it must be an even number for the frame case, and must be
                  equal to 0 or 1 modulo 4 for the field case.
                  Note: For search control=3, this must equal Ref0Y.
                  Format = S15
                  Hardware Range: [-2048 to 2047]

           15;0                                                                                              no
                  Reference 1 X Delta (Ref1X): This field defines the horizontal position (of the
                  upper-left corner of the reference region) in unit of pixels for Reference 1 region
                  relative to the source MB X value on its respective picture.
                  The resulting reference region is allowed to be outside the picture. Pixel
                  replication is applied to generate out of bound reference pixels.
                  This field is only valid when dual reference mode is selected
                  Note: For search control=3, this must equal Ref0X.
                  Format = S15
                  Hardware Range: [-2048 to 2047]
  M0.0    31:16                                                                                              no
                  Reference 0 Y Delta (Ref0Y): This field defines the vertical position (of the
                  upper-left corner of the reference region) in unit of pixels for Reference 0 region
                  relative to the source MB Y value on its respective picture.
                  For field reference (RefAccess=1), the Ref0FieldPolarity (M1.7-20), is required by
                  hardware to identify if this is top or bottom field of an interleaved memory surface.
                  The resulting Y address in the reference picture must be in even line aligned
                  within the reference picture. Specifically, if the reference picture is a frame picture.
                  the resulting Y address must be 2-line aligned; if the reference picture is a field
                  picture within a frame storage, and the resulting Y address must be 2-line aligned
                  within the field. i.e. it must be an even number for the frame case, and must be
                  equal to 0 or 1 modulo 4 for the field case.
                  Format = S15
                  Hardware Range: [-2048 to 2047]
           15;0                                                                                              no
                  Reference 0 X Delta (Ref0X): This field defines the horizontal position (of the
                  upper-left corner of the reference region) in unit of pixels for Reference 0 region
                  relative to the source MB X value on its respective picture.
                  The resulting reference region is allowed to be outside the picture. Pixel
                  replication is applied to generate out of bound reference pixels.
                  Format = S15
                  Hardware Range: [-2048 to 2047]

          31:24                                                                                              no
  M1.7            Skip Center Enable Mask (SkipCenterMask):
                  [bit 31…24]
                  xxxx xxx1: Ref0 Skip Center 0 is enabled [corresponds to M2.0]




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                   5/31/2012                                                      67
                                                                                                          Same as
 DWord     Bit                                      Description                                          Prev. Gen?
                  xxxx xx1x: Ref1 Skip Center 0 is enabled [corresponds to M2.1]
                  xxxx x1xx: Ref0 Skip Center 1 is enabled [corresponds to M2.2]
                  xxxx 1xxx: Ref1 Skip Center 1 is enabled [corresponds to M2.3]
                  xxx1 xxxx: Ref0 Skip Center 2 is enabled [corresponds to M2.4]
                  xx1x xxxx: Ref1 Skip Center 2 is enabled [corresponds to M2.5]
                  x1xx xxxx: Ref0 Skip Center 3 is enabled [corresponds to M2.6]
                  1xxx xxxx: Ref1 Skip Center 3 is enabled [corresponds to M2.7]
                  Illegal cases:
                  Disable both Ref0 and Ref1 Skip Center 0 in case of Skip_1MVP.
                  Disable both Ref0 and Ref1 for any Skip Center pair in case of Skip_4MVP.

                  Reserved: MBZ
          23:22                                                                                             yes
           21                                                                                               no
                  Reference1 Field Polarity Select (Ref1FieldPolarity):
                  If RefAccess = 1 (M0.3-7), meaning field based, than the hardware requires this
                  value is to derive the correct location on the reference surface in memory to fetch
                  pixels. This is because the reference is stored as a frame picture with both fields
                  interleaved in memory and the Ref1Y (M0.1-31:16) is relative to the SrcY location
                  on a field picture.
                  Hence, the starting y-pixel coordinate that will be fetched from the memory will be:
                  (SrcY+Ref1Y) * 2 + Ref1FieldPolarity
                  Else, this field is ignored by the hardware.
                  Format = U1
           20                                                                                               no
                  Reference0 Field Polarity Select (Ref0FieldPolarity):
                  If RefAccess = 1 (M0.3-7), meaning field based, than the hardware requires this
                  value is to derive the correct location on the reference surface in memory to fetch
                  pixels. This is because the reference is stored as a frame picture with both fields
                  interleaved in memory and the Ref0Y (M0.0-31:16) is relative to the SrcY location
                  on a field picture.
                  Hence, the starting y-pixel coordinate that will be fetched from the memory will be:
                  (SrcY+Ref0Y) * 2 + Ref0FieldPolarity
                  Else, this field is ignored by the hardware.
                  Format = U1
           19                                                                                               no
                  Source Field Polarity Select (SrcFieldPolarity):
                  If SrcAccess = 1 (M0.3-6), meaning field based, than the hardware requires this
                  value is to derive the correct location on the source surface in memory to fetch
                  pixels. This is because the source is stored as a frame picture with both fields
                  interleaved in memory and the SrcY value (M0.2-31:16) is the location on the field
                  picture (in other words, it does not convey the field polarity).
                  Hence, the starting y-pixel coordinate that will be fetched from the memory will be:




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                  5/31/2012                                                      68
                                                                                                                 Same as
 DWord     Bit                                          Description                                             Prev. Gen?
                  SrcY* 2 + SrcFieldPolarity
                  Else, this field is ignored by the hardware.
                  Format = U1

           18                                                                                                      no
                  Bilinear Filter Enable (BilinearEnable):
                  If set, the fractional filter will implement a simple bilinear interpolation filter instead
                  of the 4-tap filter. Note: this is supported for both hpel and qpel interpolation.
                  Format = Enable
          17:16                                                                                                    no
                  MV Cost Scaling Factor (MVCostScaleFactor):
                  This term allows the user to redefine the precision of the lookup into the LUT_MV
                  based on the MV cost difference from the cost center. The piecewise linear cost
                  function is defined from 0 to 64 in powers of 2 intervals, and the precision of the
                  difference is set by this field. There are 4 precision choices:
                  00: qpel [Qpel difference between MV and cost center: eff cost range 0-15pel]
                  01: hpel [Hpel difference between MV and cost center: eff cost range 0-31pel]
                  10: pel [Pel difference between MV and cost center: eff cost range 0-63pel]
                  11: 2pel [2Pel difference between MV and cost center: eff cost range 0-127pel]
                  Format = U2
           15:8                                                                                                    yes
                  Macroblock Intra Structure (MbIntraStruct): This is a bitmask specifies
                  neighbor macroblock availability. This allows software to constrain intra prediction
                  mode search.
                  Note: user must set Bit6=Bit5.
                                        Bits                    MotionVerticalFieldSelect Index
                                         7
                                                                Reserved : MBZ

                                          6
                                                                Reserved : MBZ

                                          5
                                                                IntraPredAvailFlagE/A – A (Left
                                                                neighbor or Left bottom half)

                                          4
                                                                IntraPredAvailFlagB – B (Upper
                                                                neighbor)
                                          3
                                                                IntraPredAvailFlagC – C (Upper
                                                                left neighbor)
                                          2
                                                                IntraPredAvailFlagD – D (Upper
                                                                right neighbor)
                                         1:0
                                                                Reserved : MBZ

            7                                                                                                      yes
                  Luma Intra Source Corner Swap (IntraCornerSwap): This field specifies the
                  format of the intra luma neighbor pixel format in the message.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                    5/31/2012                                                           69
                                                                                                       Same as
 DWord     Bit                                       Description                                      Prev. Gen?
                  0: top neighbors are in sequential order
                  1: Left-top corner is swapped with the last left-edge neighbor

            6                                                                                            yes
                  Non Skip MB Mode Cost Added (NonSkipModeAdded): This field indicates
                  that the distortion of the survived motion vectors will become non-skip, and the
                  MB mode cost will be added to its distortion.
            5                                                                                            yes
                  Non Skip Zero MV Cost Added (NonSkipZMvAdded): This field indicates that
                  the distortion of the survived motion vectors will become non-skip, and the zero
                  MV component costs will be added to its distortion.
           4:0                                                                                           yes
                  Luma Intra Partition Mask (IntraPartMask): This field specifies which Luma
                  Intra partition is enabled/disabled for intra mode decision.
                  xxxx1 : luma_intra_16x16 disabled
                  xxx1x : luma_intra_8x8 disabled
                  xx1xx : luma_intra_4x4 disabled
                  Bits [4:3] MBZ
  M1.6            Reserved: MBZ
           31:0                                                                                           no

          31:16                                                                                          no
  M1.5            CostCenter 1 Delta Y (CostCenter0Y): This field defines the Y value for the
                  second cost center (associated with the second start) relative to the picture
                  source MB Y value.
                  Format = S13.2 (2’s comp)
                  Hardware Range: [-512.00 to 511.75]
           15:0                                                                                          no
                  CostCenter 1 Delta X (CostCenter1X): This field defines the X value for the
                  second cost center (associated with the second start) relative to the picture
                  source MB X value.
                  Format = S13.2 (2’s comp)
                  Hardware Range: [-2048.00 to 2047.75]
          31:16                                                                                          no
  M1.4            CostCenter 0 Delta Y (CostCenter0Y): This field defines the Y value for the first
                  cost center (associated with the first start) relative to the picture source MB Y
                  value.
                  Format = S13.2 (2’s comp)
                  Hardware Range: [-512.00 to 511.75]
           15:0                                                                                          no
                  CostCenter 0 Delta X (CostCenter0X): This field defines the X value for the first
                  cost center (associated with the first start) relative to the picture source MB X
                  value.
                  Format = S13.2 (2’s comp)
                  Hardware Range: [-2048.00 to 2047.75]

  M1.3    31:24                                                                                          yes
                  IME Success & FME/BME Bypass Threshold (ImeTooGood): This field
                  specifies the threshold value for the ME distortion computes above which sub-pel
                  refinement search and bidirectional search are skipped (as the integer-pel




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                 5/31/2012                                                    70
                                                                                                              Same as
 DWord     Bit                                      Description                                              Prev. Gen?
                  distortion is deemed to be good enough).
                  This value, if used, should be set to be greater than Early Success Threshold.
                  Format = U4U4 (encoded value should fit in 14-bits)

          23:16                                                                                                 yes
                  Quit Inter Search Threshold (ImeTooBad): This field specifies the threshold
                  value for the ME distortion computes above which sub-pel refinement search and
                  bidirectional search are skipped (as the integer-pel distortion is deemed to be too
                  bad).
                  This value, if used, should be set to be greater than Early Success Threshold.
                  Format = U4U4 (encoded value should fit in 14-bits)
           15:8                                                                                                 yes
                  Partition Distortion Tolerance Threshold (PartToleranceThrhd): defines the
                  distortion tolerance used in the intermediate shape decision. (See Shape Decision
                  for more detail).
                  This field is only valid when PartCandidateEn is set.
                  Format = U4U4 (encoded value should fit in 14-bits)
           7:0                                                                                                  no
                  FME/BME Pruning Tolerance Threshold (FBPrunThrhd): This field specifies
                  the threshold when a normalized absolute difference of the two uni-directional
                  distortions is bigger than that, FME is skipped for the losing direction and BME is
                  skipped as well if bidirectional is enabled. The difference is normalized by the
                  number of 4x4 pixels in the tested partition. For example, for an 8x8 partition, the
                  absolute difference of the distortions is divided by 4 (right shifted by 2); and for a
                  16x16 partition, it is right shifted by 4. With the unsigned byte, this field provides a
                  control of per pixel distortion difference with a large range from 1/16 to 16.
                  This field is only valid when FBPrunEn is set to 1 (and for Search Control set to
                  111 - dual reference and dual record).
                  Format = U4U4 (encoded value should fit in 14-bits)

  M1.2    31:28                                                                                                 yes
                  Start Center 1 Y (Start1Y): This field defines the Y position of Search Path 1
                  relative to the reference Y location. It is in unit of SU.
                  Format = U4

          27:24                                                                                                 yes
                  StartCenter 1 (Start1X): This field defines the X position of Search Path 1
                  relative to the reference X location. It is in unit of SU.
                  The corresponding reference block must be fully within the reference region.
                  Format = U4
          23:20                                                                                                 yes
                  Start Center 0 Y (Start0Y): This field defines the Y position of Search Path 1
                  relative to the reference Y location. It is in unit of SU.
                  Format = U4
          19:16                                                                                                 yes
                  StartCenter 0 X (Start0X): This field defines the X position of Search Path 1
                  relative to the reference X location. It is in unit of SU.
                  The corresponding reference block must be fully within the reference region.
                  Format = U4




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                   5/31/2012                                                         71
                                                                                                           Same as
 DWord      Bit                                      Description                                          Prev. Gen?
           15:8                                                                                              yes
                  Maximum Search Path Length (MaxNumSU): This field defines the maximum
                  number of SUs per reference including the predetermined SUs and the adaptively
                  generated SUs.
                  Note: every SU in fixed path will be counted (including the out-bound ones and
                  repeated ones), and in addition for adaptive SUs only the ones actually searched
                  will be added.
                  Format = U8, with valid range of [1,63]

           7:0                                                                                               yes
                  Max Fixed Search Path Length (LenSP): This field defines the maximum
                  number of SUs per reference which are evaluated by the predetermined SUs.
                  When adaptive walk is enabled, adaptive walk starts when this number is
                  reached.
                  Note: every SU in fixed path will be counted (including the out-bound ones and
                  repeated ones)
                  Format = U8, with valid range of [1,63]
  M1.1     31                                                                                                yes
                  Extented FME Repartition Enable (RepartEn): This field specifies whether the
                  repartitioning after FME as described in 6.1.3.3 is enabled.
                  0 : disable
                  1 : enable
           30                                                                                                no
                  FME/BME Pruning Enable (FBPrunEn): This field specifies whether FME/BME
                  pruning is enabled. This is used to speedup the VME operation with low quality
                  impact.
                  This field is only valid for dual reference case (when Search Control is 111).
                  Otherwise, it must be set to zero.
                  0 : disable
                  1 : enable
                  Reserved: MBZ
           29                                                                                                yes
                  AdaptiveValidationControl: if it is on, during adaptive IME searching, VME will
                  not pipeline SUs. In other words, VME will have only 1 SU in-flight and will wait
                  until all results are updated prior to deciding which SU to move to next. When this
                  is off (non-validation mode), VME’s pipeline will have at most 2 SUs in-flight to
                  enhance performance, but the out-of-order SU completion behavior will make
                  validation efforts exceedingly complex.

           28                                                                                                yes
                  Unidirectional Mix Disable (UniMixDisable): if it is on, all unidirectional resulting
                  motion vectors must share the same direction, i.e. either all are forward, or all are
                  backward. If this field is off, each partition, down to 8x8 subblock, may have a
                  different mix of forward and backward motion vectors. (Within each 8x8 subblock,
                  only one common choice is allowed.)
                  This field is MBZ except for cases of Search Control = 111’b (e.g. 7, dual
                  reference).
          27:24                                                                                              yes
                  Bidirectional Sub-Macroblock and Sub-Partition Mask (BiSubMbPartMask):
                  This field defines the bit-mask for disabling sub-macroblock and sub-partition
                  modes. The enabled ones must be a subset of that enabled by SubMbPartMask.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                  5/31/2012                                                       72
                                                                                                    Same as
 DWord     Bit                                     Description                                     Prev. Gen?
                  Note that 16x8 and 8x16 share the same bit and all sub-partitions share the same
                  bit.
                  xxx1 : 16x16 disabled
                  xx1x : 2x(16x8) and 2x(8x16) within 16x16 disabled
                  x1xx : 4x(8x8) within 16x16 disabled
                  1xxx: sub-partitions 2x(8x4) and 2x(4x8) and 4x(4x4) within 8x8 are disabled

          23:22   Reserved: MBZ                                                                        yes
          21:16                                                                                        yes
                  Bidirectional Weight (BiWeight): This field defines the weighting for the
                  backward and forward terms to generate the bidirectional term. This field is only
                  valid for bidirectional search (SearchCtrl = 111).
                  Format = U6
                  Valid Values: [16, 21, 32, 43, 48]

           15:6   Reserved: MBZ                                                                        yes
           5:0                                                                                         yes
                  Maximum Number of Motion Vectors (MaxNumMVs): This field specifies the
                  maximum number of motion vectors allowed for the current macroblock. This field
                  affects the macroblock partition decision. VME will return the best partition with
                  MvQuantity not exceeding MaxNumMVs. MaxNumMVs = 0 will only allow skip
                  as a valid Inter mode.
                  Note: This value is used ONLY for 16x16 source MB mode.
                  Usage Example: Certain profiles/levels for AVC standard have restriction
                  for the maximum number of motion vectors allowed for two consecutive
                  macroblocks (MaxMvsPer2Mb may be 16 or 32).
                  Format = U6
                  Note: When skip is enabled, MaxNumMVs must be greater or equal to the
                  number of skip MVs.
  M1.0    31:24                                                                                        yes
                  Early IME Successful Stop Threshold (EarlyImeStop): This field specifies the
                  threshold value for the IME distortion computes of single 16x16 mode below
                  which no more search will be performed within the IME unit.
                  This field only takes effect if EarlyImeSuccessEn is set.
                  Note: Early IME exit only looks at ref0, and uses 8x8 for source 8x8 and 16x8 0
                  for source 16x8.
                  Format = U4U4 (encoded value should fit in 14-bits)
          23:16                                                                                        yes
                  Early Fme Success Threshold (EarlyFmeSuccess): Applying after fractional
                  ME, this field defines the threshold value for the ME distortion computes below
                  which the search process will exit early.
                  This field only takes effect if EarlySuccessEn is set.
                  This field only looks at primary candidate
                  Format = U4U4 (encoded value should fit in 14-bits)




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                  5/31/2012                                                 73
                                                                                                           Same as
 DWord      Bit                                      Description                                          Prev. Gen?
           15:8                                                                                              yes
                  Skip Success Threshold (SkipSuccess): Applying after skip mode checking (if
                  enabled), this field defines the threshold value for the ME distortion computes
                  below which the search process will exit early.
                  This threshold is always used for setting MbSkipFlag, when the corresponding
                  raw distortion is less than or equal to the threshold.
                  This field causes early VME termination only if EarlySuccessEn is set to 1.
                  Format = U4U4 (encoded value should fit in 14-bits)

            7                                                                                                yes
                  Transform 8x8 Flag For Inter Enable (T8x8FlagForInterEn): This field specifies
                  whether Transform8x8Flag is updated for inter mode according the resulting inter-
                  mode sub-partition size.
                  0 : disable
                  1 : enable
            6                                                                                                yes
                  Quit Inter Search Enable (QuitInterEn): This field specifies whether the inter
                  search may be prematurely terminated after IME when the IME distortion is worse
                  than the predetermined threshold QuitInterThrhd. When this field is not set, if
                  early out does occur on full-pel location, hardware switches to local sub-pel
                  refinement search. When this field is set, however, the local sub-pel refinement
                  step is skipped.
                  This field takes effect independent of EarlySuccessEn.
                  0 : disable
                  1 : enable
            5                                                                                                yes
                  Early IME Success Enable (EarlyImeSuccessEn): This field specifies whether
                  the Early Success may terminate on full-pel precision. When this field is not set, if
                  early out does occur on full-pel location, hardware continues to local sub-pel
                  refinement search and so on. When this field is set, however, the local sub-pel
                  refinement step is skipped and intra search is also skipped.
                  This field only takes effect if EarlySuccessEn is set.
                  Usage example: This may be used for cases with large static area where
                  (0,0) motion vector delivers very good results that no FME refinement is
                  needed and also intra check is also skipped. This may also be used in
                  place of Skip Mode Checking when the skip center(s) happens to be an
                  integer location inside the SU of the Start Center(s).
                  0 : disable
                  1 : enable

            4                                                                                                yes
                  Early Success Enable (EarlySuccessEn): This field enables Early Success of
                  the motion search when the ME distortion is below EarlySuccessThrhd. Early
                  Success may occur during skip mode check, integer search and sub-pel search
                  stages. Termination directly out of integer search is controlled by the
                  EarlySuccessImeEn field.
                  0 : disable
                  1 : enable




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                  5/31/2012                                                       74
                                                                                                              Same as
 DWord     Bit                                         Description                                           Prev. Gen?
            3                                                                                                   yes
                  Partition Candidates Enable (PartCandidateEn): This field enables multiple
                  partition candidates (VME hardware supports only up to two candidates). When it
                  is set, a second partition candidate that is within PartToleranceThrhd from the
                  best partition is kept for subsequent inter-search operations.
                  This field is only allowed to be set to 1 if SrcSize is 16x16.
                  0: a single partition is determined by IME
                  1: multiple partition candidates are allowed

            2                                                                                                   yes
                  Bidirectional Mix Disable (BiMixDis): if it is on, all resulting motion vectors must
                  share the same direction, i.e. either all are unidirectional (i.e. forward or
                  backward), or all bidirectional. If this field is off, each partition may have different
                  search direction (forward, backward or bidirectional).
                  Usage Example: MPEG2 bidirectional decision is at whole macroblock level,
                  while AVC decision is at subblock level.
                  0: bidirectional decision on subblock level that bidirectional mode is enabled
                  1: bidirectional decision on whole macroblock
            1                                                                                                   yes
                  Adaptive Search Enable (AdaptiveEn): This field defines whether adaptive
                  searching is enabled for IME. When Adaptive Search is enabled, there must be at
                  least two search steps preceded. It is either from a single start with step of >=2 or
                  from a dual-start.
                  0 : disable
                  1 : enable
            0                                                                                                   yes
                  Skip Mode Enable (SkipModeEn): This field specifies whether the skip mode
                  checking is performed before the motion search. If this field is set, Skip Center,
                  which may have a sub-pel precision, is first tested before IME.
                  0 : disable
                  1 : enable
                  Note: It must be 0 if Inter is not ON in Message Type or if SrcType!=00 (less
                  than 16x16)
  M2.7     31:0                                                                                                 no
                  Ref1 SkipCenter 3 Delta XY (for definition see M2.0)

  M2.6     31:0                                                                                                 no
                  Ref0 SkipCenter 3 Delta XY (for definition see M2.0)

  M2.5     31:0                                                                                                 no
                  Ref1 SkipCenter 2 Delta XY (for definition see M2.0)

  M2.4     31:0                                                                                                 no
                  Ref0 SkipCenter 2 Delta XY (for definition see M2.0)

  M2.3     31:0                                                                                                 no
                  Ref1 SkipCenter 1 Delta XY (for definition see M2.0)

  M2.2     31:0                                                                                                 no
                  Ref0 SkipCenter 1 Delta XY (for definition see M2.0)

  M2.1     31:0                                                                                                 no
                  Ref1 SkipCenter 0 Delta XY (for definition see M2.0)




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                   5/31/2012                                                         75
                                                                                                            Same as
 DWord       Bit                                        Description                                        Prev. Gen?
            31:16                                                                                              no
   M2.0             Ref0 Skip Center 0 Delta Y:
                    This field defines the Y value for the forward skip center relative to the 8x8 block
                    offset from the source MB Y location in quarter-pel precision associated with
                    Ref0.
                    To match the relative 8x8 block location, the HW will add fixed offsets to the 4
                    skip centers in each direction to generate the correct pixel location to fetch the
                    data.
                    For SkipCenter 0: VME will add 0 to the user-input Y value.
                    For SkipCenter 1: VME will add 0 to the user-input Y value.
                    For SkipCenter 2: VME will add 32 to the user-input Y value.
                    For SkipCenter 3: VME will add 32 to the user-input Y value.
                    Format = S13.2 (2’s comp)
                    Hardware Range: [-512.00 to 511.75]

             15:0                                                                                             no
                    Ref0 SkipCenter 0 Delta X:
                    This field defines the X value for the forward skip center relative to the 8x8 block
                    offset from the source MB X location in quarter-pel precision associated with
                    Ref0.
                    To match the relative 8x8 block location, the HW will add fixed offsets to the 4
                    skip centers in each direction to generate the correct pixel location to fetch the
                    data.
                    For SkipCenter 0: VME will add 0 to the user-input X value.
                    For SkipCenter 1: VME will add 32 to the user-input X value.
                    For SkipCenter 2: VME will add 0 to the user-input X value.
                    For SkipCenter 3: VME will add 32 to the user-input X value.
                    Format = S13.2 (2’s comp)
                    Hardware Range: [-2048.00 to 2047.75]

For Message Type of 10 and 11, the VME request message has additional two phases to deliver the
neighbor macroblock pixels for intra prediction. Here the neighbor pixel location [x, y] is relative to the
current 16x16 macroblock, with [x,y] = [-1, -1] for the upper-left corner edge pixel in neighbor D, [-1,
0…15] for the left edge pixels in neighbor A, and [0…15…23, -1] for the upper and upper-right edge
pixels in neighbors B and C.
Note that for Message Type of 10, which is intra-search only mode, the fields regarding reference
windows and inter-prediction control in the command are ignored by hardware (and no pixels are fetched
from the reference window(s)).
 To help with vector data access in software, horizontal neighbor pixels from D, B, and C are stored in
one register in raster order with 8 pixel alignment. Vertical neighbor pixels from A are stored in a separate
register.
                                                                                                            Same as
                                                                                                             Prev.
 DWord      Bit                                         Description                                          Gen?




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                    5/31/2012                                                     76
                                                                                                          Same as
                                                                                                           Prev.
 DWord     Bit                                        Description                                          Gen?
  M3.7    31:0                                                                                            yes, but
                  Neighbor pixel Luma value [23, -1] to [20, -1]. Upper-right pixels from neighbor
                                                                                                          was M2
                  macroblock C
  M3.6    31:0                                                                                            yes, but
                  Neighbor pixel Luma value [19, -1] to [16, -1]. Upper-right edge pixels from
                                                                                                          was M2
                  neighbor macroblock C
  M3.5    31:0                                                                                            yes, but
                  Neighbor pixel Luma value [15, -1] to [12, -1]. Top edge pixels from neighbor
                                                                                                          was M2
                  macroblock B
  M3.4    31:0                                                                                            yes, but
                  Neighbor pixel Luma value [11, -1] to [8, -1]. Top edge pixels from neighbor
                                                                                                          was M2
                  macroblock B

  M3.3    31:0                                                                                            yes, but
                  Neighbor pixel Luma value [7, -1] to [4, -1]. Top edge pixels from neighbor
                                                                                                          was M2
                  macroblock B
  M3.2   31:24                                                                                            yes, but
                  Neighbor pixel Luma value [3, -1]. Fourth top edge pixel from neighbor macroblock
                                                                                                          was M2
                  B
         23:16                                                                                            yes, but
                  Neighbor pixel Luma value [2, -1]. Third top edge pixel from neighbor macroblock
                                                                                                          was M2
                  B
          15:8                                                                                            yes, but
                  Neighbor pixel Luma value [1, -1]. Second top edge pixel from neighbor
                                                                                                          was M2
                  macroblock B

          7:0                                                                                             yes, but
                  Neighbor pixel Luma value [0, -1]. First top edge pixel from neighbor macroblock B
                                                                                                          was M2
         31:24                                                                                            yes, but
  M3.1            Corner Neighbor pixel 0. Its content depends on IntraCornerSwap field. It swaps
                                                                                                          was M2
                  with Corner Neighbor pixel 1.
                  Neighbor pixel Luma value [-1, -1]. The one upper-left edge pixel from neighbor
                  macroblock D, which is the right most edge pixel of D, if IntraCornerSwap field is 0.
                  Or
                  Neighbor pixel Luma value [-1, 15]. The last left edge pixel from neighbor
                  macroblock A, which is the left most edge pixel of D, if IntraCornerSwap field is 1.

                  Reserved: MBZ (Hardware ignores this field)
          23:4                                                                                               no
          3:0                                                                                               no
                  AVC Intra 16x16 Mode Mask (Intra16x16ModeMask):
                  Disables given intra mode as follows.
                  xxx1:
                  xx1x:
                  x1xx:
                  1xxx:

                  Reserved: MBZ (Hardware ignores this field)
  M3.0    31:25                                                                                              no
         24:16                                                                                              no
                  AVC Intra 8x8 Mode Mask (Intra16x16ModeMask):
                  Disables given intra mode as follows.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                  5/31/2012                                                      77
                                                                                                        Same as
                                                                                                         Prev.
 DWord    Bit                                       Description                                          Gen?
                 x xxxx xxx1:
                 x xxxx xx1x:
                 x xxxx x1xx:
                 x xxxx 1xxx:
                 x xxx1 xxxx:
                 x xx1x xxxx:
                 x x1xx xxxx:
                 x 1xxx xxxx:
                 1 xxxx xxxx:
                 Reserved: MBZ (Hardware ignores this field)
          15:9                                                                                             no
          8:0                                                                                             no
                 AVC Intra 4x4 Mode Mask (Intra16x16ModeMask):
                 Disables given intra mode as follows.
                 x xxxx xxx1:
                 x xxxx xx1x:
                 x xxxx x1xx:
                 x xxxx 1xxx:
                 x xxx1 xxxx:
                 x xx1x xxxx:
                 x x1xx xxxx:
                 x 1xxx xxxx:
                 1 xxxx xxxx:
  M4.7           Reserved: MBZ
          31:0                                                                                             no

  M4.6           Reserved: MBZ
          31:0                                                                                             no
  M4.5           Reserved: MBZ
          31:0                                                                                             no
  M4.4   31:28                                                                                          yes, but
                 Intra Predictor Mode for Neighbor B15 (IntraMxMPredModeB15): This field
                                                                                                        was M3
                 carries the intra prediction mode of the fourth bottom 4x4 block (Block 15 in
                 Numbers of Block4x4 in a 16x16 region) of the top neighbor macroblock B. Definition
                 of the term is according to Sections 8.3.1 and 8.3.2 of the AVC specification.
         27:24                                                                                          yes, but
                 Intra Predictor Mode for Neighbor B14 (IntraMxMPredModeB14): This field
                                                                                                        was M3
                 carries the intra prediction mode of the third bottom 4x4 block (Block 14 in Numbers
                 of Block4x4 in a 16x16 region) of the top neighbor macroblock B. Definition of the
                 term is according to Sections 8.3.1 and 8.3.2 of the AVC specification.

         23:20                                                                                          yes, but
                 Intra Predictor Mode for Neighbor B11 (IntraMxMPredModeB11): This field
                                                                                                        was M3
                 carries the intra prediction mode of the second bottom 4x4 block (Block 11 in
                 Numbers of Block4x4 in a 16x16 region) of the top neighbor macroblock B. Definition




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                 5/31/2012                                                     78
                                                                                                             Same as
                                                                                                              Prev.
 DWord    Bit                                         Description                                             Gen?
                 of the term is according to Sections 8.3.1 and 8.3.2 of the AVC specification.
         19:16                                                                                               yes, but
                 Intra Predictor Mode for Neighbor B10 (IntraMxMPredModeB10): This field
                                                                                                             was M3
                 carries the intra prediction mode of the first bottom 4x4 block (Block 10 in Numbers
                 of Block4x4 in a 16x16 region)of the top neighbor macroblock B. Definition of the
                 term is according to Sections 8.3.1 and 8.3.2 of the AVC specification.
         15:12                                                                                               yes, but
                 Intra Predictor Mode for Neighbor A15 (IntraMxMPredModeA15): This field
                                                                                                             was M3
                 carries the intra prediction mode of the fourth rightmost 4x4 block (Block 15 in
                 Numbers of Block4x4 in a 16x16 region) of the left neighbor A. Definition of the term
                 is according to Sections 8.3.1 and 8.3.2 of the AVC specification.
          11:8                                                                                               yes, but
                 Intra Predictor Mode for Neighbor A13 (IntraMxMPredModeA13): This field
                                                                                                             was M3
                 carries the intra prediction mode of the third rightmost 4x4 block (Block 13 in
                 Numbers of Block4x4 in a 16x16 region) of the left neighbor A. Definition of the term
                 is according to Sections 8.3.1 and 8.3.2 of the AVC specification.

          7:4                                                                                                yes, but
                 Intra Predictor Mode for Neighbor A7 (IntraMxMPredModeA7): This field carries
                                                                                                             was M3
                 the intra prediction mode of the second rightmost 4x4 block (Block 7 in Numbers of
                 Block4x4 in a 16x16 region) of the left neighbor A.
          3:0                                                                                                yes, but
                 Intra Predictor Mode for Neighbor A5 (IntraMxMPredModeA5): This field carries
                                                                                                             was M3
                 the intra prediction mode of the first rightmost 4x4 block (Block 5 in Numbers of
                 Block4x4 in a 16x16 region) of the left neighbor A. Definition of the term is according
                 to Sections 8.3.1 and 8.3.2 of the AVC specification.
                 Intra Predictor Modes for Neighbor A and B are only used if
                 MODE_INTRA_NOPRED is not zero.
                 For intra mode selection, bias is applied to the predicted mode if a predictor is
                 present for a partition. This is achieved by applying a penalty term
                 MODE_INTRA_NONPRED defined in the VME state to the cost functions for non-
                 predicted modes.
                 The predictor for a given partition is from its left neighbor and top neighbor. The intra
                 decision for a partition serves as the predictor for the next partition in the partition
                 order as defined in Numbers of Block4x4 in a 16x16 region and Numbers of
                 Block4x4 in an 8x8 region or numbers of Block8x8 in a 16x16 region.
                 This set of intra predictor mode for neighbor macroblocks are only used for
                 INTRA8x8 and INTRA4x4 modes.
                 Format : U4 (The value of this field is defined in Definition of Intra4x4PredMode
                 which is the same as that in Definition of Intra8x8PredMode.)
  M4.3   31:24                                                                                               yes, but
                 Corner Neighbor pixel 1. Its content depends on IntraCornerSwap field. It swaps
                                                                                                             was M3
                 with Corner Neighbor pixel 0.
                 Neighbor pixel Luma value [-1, -1]. The one upper-left edge pixel from neighbor
                 macroblock D, which is the right most edge pixel of D, if IntraCornerSwap field is 1.
                 Or
                 Neighbor pixel Luma value [-1, 15]. The last left edge pixel from neighbor
                 macroblock A, which is the left most edge pixel of D, if IntraCornerSwap field is 0.

          23:0                                                                                               yes, but
                 Neighbor pixel Luma value [-1, 14] to [-1, 12]. Left edge pixels from neighbor
                                                                                                             was M3




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                   5/31/2012                                                       79
                                                                                                             Same as
                                                                                                              Prev.
 DWord     Bit                                        Description                                             Gen?
                  macroblock A
  M4.2     31:0                                                                                              yes, but
                  Neighbor pixel Luma value [-1, 11] to [-1, 8]. Left edge pixels from neighbor
                                                                                                             was M3
                  macroblock A
  M4.1     31:0                                                                                              yes, but
                  Neighbor pixel Luma value [-1, 7] to [-1, 4]. Left edge pixels from neighbor
                                                                                                             was M3
                  macroblock A
  M4.0    31:24                                                                                              yes, but
                  Neighbor pixel Luma value [-1, 3]. Fourth left edge pixel from neighbor macroblock
                                                                                                             was M3
                  A

          23:16                                                                                              yes, but
                  Neighbor pixel Luma value [-1, 2]. Third left edge pixel from neighbor macroblock
                                                                                                             was M3
                  A
           15:8                                                                                              yes, but
                  Neighbor pixel Luma value [-1, 1]. Second left edge pixel from neighbor
                                                                                                             was M3
                  macroblock A
           7:0                                                                                               yes, but
                  Neighbor pixel Luma value [-1, 0]. First left edge pixel from neighbor macroblock A
                                                                                                             was M3


3.5.4     Writeback Message
In order to minimize kernel software overhead, the PLACEMENTS of the bit-fields as well as the
words/dwords are specifically designed to match with the inline data of the MFC_PAK_OBJECT
command of MFX.
                                                                                                             Same as
                                                                                                              Prev.
 DWord     Bit                                        Description                                             Gen?
  W0.7    31:28                                                                                                yes
                  VME Decisions – Other: These 4 bits are used to expose internal behavior of VME to
                  the kernel, specifically whether or not FME or BME had a positive impact, whether or
                  not the ExtraCandidate adds any value to be checked, and whether or not the MaxMV
                  value limited partitioning to a larger shape decision.
                      xxx1: After FME, the primary candidate’s distortion was improved.
                      xx1x: After BME, the primary candidate’s distortion was improved.
                      x1xx: When VME concludes, the ExtraCandidate ends up beating the initial
                      primary candidate.
                      1xxx: The MaxMV value restricted the final partition decision (VME would have
                      picked a more detailed shape, but couldn’t due to motion vector constraint). ).
                      This field only applies to the final partition decision of the main partitioning or
                      candidate and not the alternate candidate. It is only valid incase of SrcSize 16x16.
                      Otherwise it is MBZ.
          27:23                                                                                                 yes
                  VME Decisions – Early Exit Conditions: These 5 bits expose to the kernel that VME
                  finished prior to completing all subfunctions and for what early exit criteria this
                  occurred. Note, these values are only set when the VmeFlag “EarlySuccess” is
                  enabled.
                  xxxx1: EarlySkipExit Occurred
                  xxx1x: EarlyImeStop Occurred




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                  5/31/2012                                                          80
                                                                                                            Same as
                                                                                                             Prev.
 DWord    Bit                                         Description                                            Gen?
                 xx1xx: ImeTooGood Occurred
                 x1xxx: ImeTooBad Occurred
                 1xxxx: EarlyFmeExit Occurred
         22:16                                                                                                yes
                 VME Decisions – Sub-Functions Performed: These 7 bits expose to the kernel
                 which sub-functions VME performed. Also, each sub-function is explicitly listed for
                 primary or extra candidate for FME and BME. There is some redundancy with respect
                 to Skipcheck and Intra based on input state to VME.
                 xxxxxx1: Performed Skipcheck
                 xxxxx1x: Performed IME
                 xxxx1xx: Performed FME on primary
                 xxx1xxx: Performed FME on extra candidate
                 xx1xxxx: Performed BME on primary
                 x1xxxxx: Performed BME on extra candidate
          15:8                                                                                                yes
                 Sub-Macroblock Prediction Mode (SubMbPredMode): If InterMbMode is
                 INTER8x8, this field describes the prediction mode of the sub-partitions in the four 8x8
                 sub-macroblock. It contains four subfields each with 2-bits, corresponding to the four
                 8x8 sub-macroblocks in sequential order.
                 This field is derived from sub_mb_type for a BP_8x8 macroblock.
                 This field is derived from MbType for a non-BP_8x8 inter macroblock, and carries
                 redundant information as MbType).
                 If InterMbMode is INTER16x16, INTER16x8 or INTER8x16, this field carries the
                 prediction modes of the sub macroblock (one 16x16, two 16x8 or two 8x16). The
                 unused bits are set to zero.
                 Bits [1:0]: SubMbPredMode[0]
                 Bits [3:2]: SubMbPredMode[1]
                 Bits [5:4]: SubMbPredMode[2]
                 Bits [7:6]: SubMbPredMode[3]
          7:0                                                                                                 yes
                 Sub-Macroblock Shape (SubMbShape): This field describes the subdivision of the
                 four 8x8 sub-macroblocks. It contains four subfields each with 2-bits, corresponding to
                 the four 8x8 sub macroblocks in sequential order.
                 This field is derived from sub_mb_type for a BP_8x8 or equivalent macroblock.
                 This field is forced to 0 for a non-BP_8x8 inter macroblock, and effectively carries
                 redundant information as MbType).
                 This field is only valid If InterMbMode is INTER8x8, Otherwise, it is set to zero.
                 Bits [1:0]: SubMbShape[0]
                 Bits [3:2]: SubMbShape[1]
                 Bits [5:4]: SubMbShape[2]
                 Bits [7:6]: SubMbShape[3]




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                  5/31/2012                                                        81
                                                                                                             Same as
                                                                                                              Prev.
 DWord    Bit                                          Description                                            Gen?
  W0.6   31:26                                                                                                 yes
                 Alternate Search Path Length: Counts the number of unique search units computed
                 by VME for the alternate search path for dual reference or dual search path. If the
                 search path would return to a previously processed SU, it would not be reprocessed
                 and hence not recounted. The value of [W0.1 15:8] is the overall total search units
                 processed from both paths whereas this value is the contribution only from the second
                 search path. Note: Whenever VME is in a mode that processes only a single search
                 path, this field will be 0x0.
                 Format: U6, Range of 0-48
         25:16                                                                                                 yes
                 Total VME Stalled Clocks by 16: Counts the number of clocks VME is
                 stalled\starved while processing this request, due to cache misses. The result is
                 returned in units of 16 clock intervals. If the maximum value is returned, the full range
                 was exceeded and the value clipped to the max (this is very unlikely).
                 Format: U10, Range of 0-1023 [logical range of 0-16383 in 16 clock intervals]

          15:8                                                                                                 yes
                 Total VME Compute Clocks by 16: Counts the number of clocks VME is processing
                 this request, but not stalled\starved as a result of cache misses. The result is returned
                 in units of 16 clock intervals. If the maximum value is returned, the full range was
                 exceeded and the value clipped to the max (this is very unlikely).
          7:0                                                                                                  yes
                 Macroblock Intra Structure (MbIntraStruct): This is a bitmask specifies neighbor
                 macroblock availability. This allows software to constrain intra prediction mode search.
                 This field is simply copied from the input message (to reduce software overhead of
                 forming the output message to PAK).
                                        Bits                   MotionVerticalFieldSelect Index
                                         7
                                                               Reserved : MBZ (for
                                                               IntraPredAvailFlagF – F (pixel[-
                                                               1,7] available for MbAff)
                                          6
                                                               Reserved : MBZ (for
                                                               IntraPredAvailFlagA/E – A (left
                                                               neighbor top half for MbAff)
                                          5
                                                               IntraPredAvailFlagE/A – A (Left
                                                               neighbor or Left bottom half)
                                          4
                                                               IntraPredAvailFlagB – B (Upper
                                                               neighbor)
                                          3
                                                               IntraPredAvailFlagC – C (Upper
                                                               left neighbor)
                                          2
                                                               IntraPredAvailFlagD – D (Upper
                                                               right neighbor)

                                         1:0
                                                               Reserved : MBZ (for
                                                               ChromaIntraPredMode)

 W0.5    31:16                                                                                                 yes
                 LumaIntraPredModes[3]




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                  5/31/2012                                                         82
                                                                                                             Same as
                                                                                                              Prev.
 DWord    Bit                                         Description                                             Gen?
                  Specifies the Luma Intra Prediction mode for four 4x4 sub-block of a MB, 4-bit each.
          15:0                                                                                                 yes
                  LumaIntraPredModes[2]
                  Specifies the Luma Intra Prediction mode for four 4x4 sub-block of a MB, 4-bit each.
 W0.4    31:16                                                                                                 yes
                  LumaIntraPredModes[1]
                  Specifies the Luma Intra Prediction mode for four 4x4 sub-block of a MB, 4-bit each.
          15:0                                                                                                 yes
                  LumaIntraPredModes[0]
                  Specifies the Luma Intra Prediction mode for four 4x4 sub-block, four 8x8 block or one
                  intra16x16 of a MB.
                  4-bit per 4x4 sub-block (Transform8x8Flag=0, Mbtype=0 and intraMbFlag=1) or 8x8
                  block (Transform8x8Flag=1, Mbtype=0, MbFlag=1), since there are 9 intra modes.
                  4-bit for intra16x16 MB (Transform8x8Flag=0, Mbtype=1 to 24 and intraMbFlag=1),
                  but only the LSBit[1:0] is valid, since there are only 4 intra modes.

 W0.3                                                                                                          yes
         31:28    Direct8x8Pattern
                  This field indicates whether each of the four 8x8 sub macroblocks is using the
                  predicted MVs and will not be explicitly coded in the bitstream (the sub macroblock will
                  be coded as direct mode). It contains four 1-bit subfields, corresponding to the 4 sub
                  macroblocks in sequential order. The whole macroblock may be actually coded as
                  B_Direct_16x16 or B_Skip, according to the macroblock type conversion rules
                  described in a later sub section.
                  This field is only valid for a B slice. It is ignored by hardware for a P slice.
                  0 in a bit – Corresponding MVs are sent in the bitstream
                  1 in a bit – Corresponding MVs are not sent in the bitstream
                  Reserved: MBZ
          27:14                                                                                                yes
          13:0                                                                                                 yes
                  BestIntraDistortion
                  The IntraMbMode will indicate if this is a 16x16/8x8/4x4 distortion.
                  Format = U14
 W0.2             Reserved: MBZ
           31                                                                                                  yes

           30                                                                                                  yes
                  SkipRawDistortionInvalid
                  Format = U14
         29:16                                                                                                 yes
                  SkipRawDistortion
                  Format = U14
                  Reserved: MBZ
          15:14                                                                                                yes
          13:0                                                                                                 yes
                  InterDistortion




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                     5/31/2012                                                      83
                                                                                                        Same as
                                                                                                         Prev.
 DWord     Bit                                         Description                                       Gen?
                  Format = U14
 W0.1             Reserved: MBZ
          31:30                                                                                           yes
          29:16                                                                                           yes
                  Minimal Distortion: This field contains the overall distortion for the source block
                  associated with the winning MbType, which could be one of intra or inter modes.
                  Format = U14
          15:8                                                                                            yes
                  Search Path Length: This field returns the number of SU it takes in the integer
                  search. It includes predetermined search path and dynamic search path.
                  Format: U8

           7:4                                                                                            yes
                  Reference 1 border reached: bitmask indicating whether any border of reference 1 is
                  reached by one or more motion vectors in the winning inter mode.
                  xxx1: left border reached
                  xx1x: right border reached
                  x1xx: top border reached
                  1xxx: bottom border reached
           3:0                                                                                            yes
                  Reference 0 border reached: bitmask indicating whether any border of reference 0 is
                  reached by one or more motion vectors in the winning inter mode.
                  xxx1: left border reached
                  xx1x: right border reached
                  x1xx: top border reached
                  1xxx: bottom border reached
 W0.0
           31     ExtendedForm (IVB only)                                                                 yes
                  This field specifies that LumaIntraMode’s are fully replicated in 4x4 sub-blocks
                  respectively. And motion vectors must be in unpacked form as well. This non-DXVA
                  form is used for optimal kernel performance.

         30:29  Reserved: MBZ
          28:24                                                                                           yes
                 MvQuantity
                  Specify the number of MVs in packed format (in unit of motion vectors).
                  Note: this field is provided to help with software to meet conformance requirements
                  such as maximum number of motion vectors for two consecutive macroblocks.
                  Format: U5, valid from 0 to 32

            23    Reserved : MBZ                                                                          yes
                  (reserved for ExternalMvBufFlag. It is always 0 in this case, since MV’s are
                  included)
          22:20                                                                                           yes
                  MvSize (Motion Vector Size). This field specifies the size and format of the output
                  motion vectors.




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                   5/31/2012                                                   84
                                                                                                        Same as
                                                                                                         Prev.
 DWord    Bit                                       Description                                          Gen?
                This field is reserved (MBZ) when the output signal IntraMbFlag = 1.
                The valid encodings are:
                000 = 0: No motion vector
                100 = 8MV: Four 8x8 motion vector pairs
                110 = 32MV: 16 4x4 motion vector pairs
                Others are reserved.
                (The following encodings are intended for future usages:
                001 = 1MV: one 16x16 motion vector
                010 = 2MV: One 16x16 motion vector pair
                011 = 4MV: Four 8x8 motion vectors
                101 = 16MV: 16 4x4 motion vectors
                111 = Packed, number of MVs is given by MvQuantity.)
           19                                                                                             yes
                DcBlockCodedYFlag. This field specifies if the Luma DC sub-block is coded.
                1 – the 4x4 DC-only Luma sub-block of the Intra16x16 coded MB is present; it is still
                possible that all DC coefficients are zero.
                0 – no 4x4 DC-only Luma sub-block is present; either not in Intra16x16 MB mode or
                all DC coefficients are zero.
                VME hardware forces this output to be 1.
           18                                                                                             yes
                DcBlockCodedCbFlag. This field specifies if the Chroma Cb DC sub-block is coded.
                1 – the 2x2 DC-only Chroma Cb sub-block of all coded MB (any type) is present; it is
                still possible that all DC coefficients are zero.
                0 – no 2x2 DC-only Chroma Cb sub-block is present; all DC coefficients are zero.
                VME hardware forces this output to be 1.
           17                                                                                             yes
                DcBlockCodedCrFlag. This field specifies if the Chroma Cb DC sub-block is coded.
                1 – the 2x2 DC-only Chroma Cr sub-block of all coded MB (any type) is present; it is
                still possible that all DC coefficients are zero.
                0 – no 2x2 DC-only Chroma Cr sub-block is present; all DC coefficients are zero.
                VME hardware forces this output to be 1.

                Reserved: MBZ
           16                                                                                             yes
           15                                                                                             yes
                Transform8x8Flag (Transform 8x8 Flag)
                This field indicates that 8x8 transform is recommended.
                It is set to 1 if IntraMbFlag = INTRA and IntraMbMode = INTRA_8x8.
                For IntraMbFlag = INTER. If T8x8FlagForInterEn = 0, this field is set to 0 by VME
                hardware. If T8x8FlagForInterEn = 1, this field is set to 1 if there is no sub
                macroblock size less than 8x8 (noSubMbPartSizeLessThan8x8Flag = 1).




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                5/31/2012                                                      85
                                                                                                                    Same as
                                                                                                                     Prev.
 DWord    Bit                                            Description                                                 Gen?
                 0: 4x4 integer transform
                 1: 8x8 integer transform
                 Note: This bit will be always 0 for non-16x16 source block cases.
           14                                                                                                         yes
                 FieldMbFlag
                 This field indicates the inter prediction result is field or frame.
                 It is always set to SrcAccess.
                 0: frame macroblock
                 1: field macroblock
           13                                                                                                         yes
                 IntraMbFlag
                 This field specifies whether the current macroblock is an Intra (I) macroblock. Even
                 though I_PCM is considered as Intra MB, VME hardware cannot generate I_PCM
                 output.
                 For I-picture MB (IntraPicFlag =1), this field must be set to 1.
                 This flag must be set in consistent with the interpretation of MbType (inter or intra
                 modes).
                 0: INTER (inter macroblock)
                 1: INTRA (intra macroblock)
          12:8                                                                                                        yes
                 MbType
                 This field is encoded to match with the best macroblock type determined as described
                 in the next section. It follows an unified encoding for inter and intra macroblocks
                 according to AVC Spec.

           7                                                                                                          yes
                 FieldMbPolarityFlag
                 This field indicates the field polarity of the current macroblock.
                 Unique for AVC standard, within an MbAff frame picture, this field may be different per
                 macroblock and is set to 1 only for the second macroblock in an MbAff pair if
                 FieldMbFlag is set. Otherwise, it is set to 0.
                 Within a field picture in most coding standard, this field is a constant for the whole field
                 picture. It is set to 1 if the current picture is the bottom field picture. Otherwise, it is set
                 to 0.
                 This field is reserved and MBZ for a progressive frame picture.
                 VME hardware set this field to 1 if the source block is a field block from the bottom
                 field and otherwise sets it to 0. This is accomplished by the following equation using
                 input signals SrcAccess and SrcY: SrcAccess && (bit0(SrcY) ==1).
                 0 = Current macroblock is a field macroblock from the top field
                 1 = Current macroblock is a field macroblock from the bottom field

                 Reserved: MBZ
           6                                                                                                          yes
          5:4                                                                                                         yes
                 IntraMbMode




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                    5/31/2012                                                              86
                                                                                                             Same as
                                                                                                              Prev.
 DWord     Bit                                           Description                                          Gen?
                  This field is provided to carry redundant information as that in MbType. The full
                  extended definition of this field allows kernel software to help update the MbType field
                  when outputting controls to the MFX PAK encoding.
                  VME outputs this field regardless of MbIntraFlag value if intra mode is enabled.
                  Reserved: MBZ
           3                                                                                                   yes
           2                                                                                                   yes
                  MbSkipFlag
                  As an output of VME, this bit indicates whether one skip center (possibly of several
                  skip centers for each partition) is the winning motion vector position.
                  VME outputs this field regardless of MbIntraFlag value.
                  Note that the meaning of this field in VME is not the same as that used in PAK.

                                                                                                               yes
           1:0    InterMbMode
                  This field is provided to carry redundant information as that in MbType. The full
                  extended definition of this field allows kernel software to help update the MbType field
                  when outputting controls to the MFX PAK encoding.
                  VME outputs this field regardless of MbIntraFlag value if inter mode is enabled.

W1.7 to   31:0                                                                                                 no
                  MVb[3] to MVb[1]. Motion vectors 3 to 1 for Reference 1, and
 W1.2     Each
                  MVa[3] to MVa[1]. Motion vectors 3 to 1 for Reference 0

          31:16                                                                                                no
  W1.1            MVb[0].y: returning the y-coordinate of Motion Vector 0 for Reference 1, relative to
                  source MB location.
                  Format = S13.2 (2’s comp)
                  Hardware Range: [-512.00 to 511.75]
          15:0                                                                                                 no
                  MVb[0].x: returning the x-coordinate of Motion Vector 0 (co-located w/
                  sublbock_4x4_0) for Reference 1, relative to source MB location. Its meaning is
                  determined by MbType.
                  Format = S13.2 (2’s comp)
                  Hardware Range: [-2048.00 to 2047.75]
          31:16                                                                                                no
  W1.0            MVa[0].y: returning the y-coordinate of Motion Vector 0 for Reference 0, relative to
                  source MB location.
                  Format = S13.2 (2’s comp)
                  Hardware Range: [-512.00 to 511.75]

          15:0                                                                                                 no
                  MVa[0].x: returning the x-coordinate of Motion Vector 0 (co-located w/
                  sublbock_4x4_0) for Reference 0, relative to source MB location. Its meaning is
                  determined by MbType.
                  The returned motion vectors are placed in a fixed data format, with up to 16 motion
                  vectors for one reference and the motion vectors from reference 0 and 1 interleaved.
                  Format = S13.2 (2’s comp)




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                  5/31/2012                                                         87
                                                                                                              Same as
                                                                                                               Prev.
 DWord        Bit                                      Description                                             Gen?
                     Hardware Range: [-2048.00 to 2047.75]
W2.7 to      31:0                                                                                                no
                     MVb[7] to MVb[4]. Motion vectors 7 to 4 for Reference 1, and
 W2.0        Each
                     MVa[7] to MVa[4]. Motion vectors 7 to 4 for Reference 0

W3.7 to      31:0                                                                                                no
                     MVb[11] to MVb[8]. Motion vectors 11 to 8 for Reference 1, and
 W3.0        Each
                     MVa[11] to MVa[8]. Motion vectors 11 to 8 for Reference 0

W4.7 to      31:0                                                                                                no
                     MVb[15] to MVb[12]. Motion vectors 15 to 12 for Reference 1, and
 W4.0        Each
                     MVa[15] to MVa[12]. Motion vectors 15 to 12 for Reference 0

W5.7 to                                                                                                       yes, but
             31:0    InterDistortion[15] to InterDistortion[2]. Inter-prediction-distortion associated with
 W5.1                                                                                                         was M3
                     motion vector 15 to 2. Its meaning is determined by sub-shape.
             Each
 W5.0                Reserved: MBZ
             31:30                                                                                            yes, but
                                                                                                              was M3
             29:16                                                                                            yes, but
                     InterDistortion[1]. Inter-prediction-distortion with motion vector 1 (co-located with
                                                                                                              was M3
                     subblock_4x4_1). Its meaning is determined by sub-shape.
                     Format = U14
                     Reserved: MBZ
             15:14                                                                                            yes, but
                                                                                                              was M3

             13:0                                                                                             yes, but
                     InterDistortion[0]. Inter-prediction-distortion associated with motion vector 0 (co-
                                                                                                              was M3
                     located with subblock_4x4_0). Its meaning is determined by sub-shape. It must be
                     zero if the corresponding sub-shape is not chosen.
                     This field may be associated with MVa[0] and/or MVb[0], depending on the resulting
                     prediction mode for the sub-block. If the corresponding MV field is created by
                     “duplication”, this field must be zero.
                     Format = U14

        1.   mv_format_pic = vin_mv_format * vin_codec_select
        2.   Change vin_mvunpackenable to (vin_mvunpackenable + mv_format_pic) on all location.
        3.   extended_form_pic = vin_extended_form * vin_codec_select
        4.   (vctrl_it_Transform8x8Flag * !extended_form_pic) ? “h000” &
             vctrl_it_lumaintrapredmode0[15:12] & “h000” & vctrl_it_lumaintrapredmode0[11:8] & “h000” &
             vctrl_it_lumaintrapredmode0[7:4] & “h000” & vctrl_it_lumaintrapredmode0[3:0] :
             vctrl_it_lumaintrapredmode3[15:0] & vctrl_it_lumaintrapredmode2
MV Fub:

Mux Output Table
                                                                                           ref_index_rep_size[3:0]
                                                 Select:

Value     Output                                 Input                                      Description




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                        5/31/2012                                                    88
0001   enc_refidx_L0addr_B0_int[4:0]      enc_mode_bind_fwd_B0[4:0]
0001   enc_refidx_L0addr_B1_int[4:0]      enc_mode_bind_fwd_B1[4:0]
0001   enc_refidx_L0addr_B2_int[4:0]      enc_mode_bind_fwd_B2[4:0]
0001   enc_refidx_L0addr_B3_int[4:0]      enc_mode_bind_fwd_B3[4:0]
0001   enc_refidx_L1addr_B0_int[4:0]      enc_mode_bind_bkd_B0[4:0]
0001   enc_refidx_L1addr_B1_int[4:0]      enc_mode_bind_bkd_B1[4:0]
0001   enc_refidx_L1addr_B2_int[4:0]      enc_mode_bind_bkd_B2[4:0]
0001   enc_refidx_L1addr_B3_int[4:0]      enc_mode_bind_bkd_B3[4:0]
0010   enc_refidx_L0addr_B0_int[4:0]      enc_mode_bind_fwd_B0[4:0]
0010   enc_refidx_L0addr_B1_int[4:0]      enc_mode_bind_fwd_B1[4:0]
0010   enc_refidx_L0addr_B2_int[4:0]      enc_mode_bind_fwd_B0[4:0]
0010   enc_refidx_L0addr_B3_int[4:0]      enc_mode_bind_fwd_B1[4:0]
0010   enc_refidx_L1addr_B0_int[4:0]      enc_mode_bind_bkd_B0[4:0]
0010   enc_refidx_L1addr_B1_int[4:0]      enc_mode_bind_bkd_B1[4:0]
0010   enc_refidx_L1addr_B2_int[4:0]      enc_mode_bind_bkd_B0[4:0]
0010   enc_refidx_L1addr_B3_int[4:0]      enc_mode_bind_bkd_B1[4:0]
0100   enc_refidx_L0addr_B0_int[4:0]      enc_mode_bind_fwd_B0_ext[4:0]
0100   enc_refidx_L0addr_B1_int[4:0]      enc_mode_bind_fwd_B0_ext[4:0]
0100   enc_refidx_L0addr_B2_int[4:0]      enc_mode_bind_fwd_B1_ext[4:0]
0100   enc_refidx_L0addr_B3_int[4:0]      enc_mode_bind_fwd_B1_ext[4:0]
0100   enc_refidx_L1addr_B0_int[4:0]      enc_mode_bind_bkd_B0_ext[4:0]
0100   enc_refidx_L1addr_B1_int[4:0]      enc_mode_bind_bkd_B0_ext[4:0]
0100   enc_refidx_L1addr_B2_int[4:0]      enc_mode_bind_bkd_B1_ext[4:0]
0100   enc_refidx_L1addr_B3_int[4:0]      enc_mode_bind_bkd_B1_ext[4:0]
1000   enc_refidx_L0addr_B0_int[4:0]      enc_mode_bind_fwd_B0[4:0]
1000   enc_refidx_L0addr_B1_int[4:0]      enc_mode_bind_fwd_B0[4:0]
1000   enc_refidx_L0addr_B2_int[4:0]      enc_mode_bind_fwd_B0[4:0]
1000   enc_refidx_L0addr_B3_int[4:0]      enc_mode_bind_fwd_B0[4:0]
1000   enc_refidx_L1addr_B0_int[4:0]      enc_mode_bind_bkd_B0[4:0]
1000   enc_refidx_L1addr_B1_int[4:0]      enc_mode_bind_bkd_B0[4:0]
1000   enc_refidx_L1addr_B2_int[4:0]      enc_mode_bind_bkd_B0[4:0]
1000   enc_refidx_L1addr_B3_int[4:0]      enc_mode_bind_bkd_B0[4:0]

Combinatorial Signals Table
            Signal                                    Equation
extended_form_pic             vin_extended_form * vin_codec_selectR
enc_mode_bind_fwd_B0_ext[4:0]
                               extended_form_pic?
                                enc_mode_bind_fwd_B0[4:0] : enc_mode_bind_fwd_B0[4:0]

enc_mode_bind_fwd_B1_ext[4:0]
                                extended_form_pic?
                                enc_mode_bind_fwd_B2[4:0] : enc_mode_bind_fwd_B1[4:0]
enc_mode_bind_bkd_B0_ext[4:0]
                                extended_form_pic?
                                enc_mode_bind_bkd_B0[4:0] : enc_mode_bind_bkd_B0[4:0]
enc_mode_bind_bkd_B1_ext[4:0]
                                extended_form_pic?
                                enc_mode_bind_bkd_B2[4:0] : enc_mode_bind_bkd_B1[4:0]




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12               5/31/2012                               89
3.5.5       Stream-in\Stream-out Message
Each reference will require 2 message phases when performing multi-call. These phases will be added
onto the basic input or output message. Hence, the first stream-in or stream-out message phase
location is variable and represented below by M(X+?), where X equals the number of phases present in
the input or output message, respectively.
When both records are being streamed in or out, phases M+0 and M+1 will contain record0 (associated
with RefA) and M+2 and M+3 will contain record1 (associated with RefB). If there is only one reference
being searched (SearchControl != 111b) then only one record will be streamed in or out, specifically, only
M+0 and M+1 will be present.
  DWord       Bit                                             Description
 M(X+0).7            Reserved MBZ
              31:0

 M(X+0).6            Reserved MBZ
              31:0
             31:16
 M(X+0).5            Rec0 Shape 16x16 Y (relative to source MB)
                     Format = S13.2 (2’s comp)
                     Hardware Range: [-512.00 to 511.75]
             15:0
                     Rec0 Shape 16x16 X (relative to source MB)
                     Format = S13.2 (2’s comp)
                     Hardware Range: [-2048.00 to 2047.75]
                     Reserved MBZ
 M(X+0).4    31:16

                     Reserved MBZ
             15:14
             13:0
                     Rec0 Shape 16x16 Distortion
                     Format = U14
             31:16
 M(X+0).3            Rec0 Shape 8x8_3 Distortion
                     Hardware only uses 14 bits. Upper bits ignored (True for all 8x8_X Distortions).
              15:0 Rec0 Shape 8x8_2 Distortion
             31:16 Rec0 Shape 8x8_1 Distortion
 M(X+0).2
              15:0 Rec0 Shape 8x8_0 Distortion
             31:16
 M(X+0).1           Rec0 Shape 8x16_1 Distortion
                     Hardware only uses 15 bits. Upper bits ignored (True for all 8x16_X Distortions).

              15:0 Rec0 Shape 8x16_0 Distortion
             31:16
 M(X+0).0           Rec0 Shape 16x8_1 Distortion
                     Hardware only uses 15 bits. Upper bits ignored (True for all 16x8_X Distortions).
              15:0 Rec0 Shape 16x8_0 Distortion
             31:16 Rec0 Shape 8x8_3 Y (relative to source MB)
 M(X+1).7
              15:0 Rec0 Shape 8x8_3 X (relative to source MB)
             31:16 Rec0 Shape 8x8_2 Y (relative to source MB)
 M(X+1).6
              15:0 Rec0 Shape 8x8_2 X (relative to source MB)




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                    5/31/2012                                           90
 DWord        Bit                                         Description
            31:16 Rec0 Shape 8x8_1 Y (relative to source MB)
 M(X+1).5
             15:0 Rec0 Shape 8x8_1 X (relative to source MB)
            31:16 Rec0 Shape 8x8_0 Y (relative to source MB)
 M(X+1).4
             15:0 Rec0 Shape 8x8_0 X (relative to source MB)
            31:16 Rec0 Shape 8x16_1 Y (relative to source MB)
 M(X+1).3
             15:0 Rec0 Shape 8x16_1 X (relative to source MB)
            31:16 Rec0 Shape 8x16_0 Y (relative to source MB)
 M(X+1).2
             15:0 Rec0 Shape 8x16_0 X (relative to source MB)
            31:16 Rec0 Shape 16x8_1 Y (relative to source MB)
 M(X+1).1
             15:0 Rec0 Shape 16x8_1 X (relative to source MB)
            31:16 Rec0 Shape 16x8_0 Y (relative to source MB)
 M(X+1).0
             15:0 Rec0 Shape 16x8_0 X (relative to source MB)
 M(X+2).7         Reserved MBZ
             31:0
 M(X+2).6           Reserved MBZ
             31:0

            31:16
 M(X+2).5           Rec1 Shape 16x16 Y (relative to source MB)
                    Format = S13.2 (2’s comp)
                    Hardware Range: [-512.00 to 511.75]
            15:0
                    Rec1 Shape 16x16 X (relative to source MB)
                    Format = S13.2 (2’s comp)
                    Hardware Range: [-2048.00 to 2047.75]
                    Reserved MBZ
 M(X+2).4   31:16
                    Reserved MBZ
            15:14

            13:0
                    Rec1 Shape 16x16 Distortion
                    Format = U14
 M(X+2).3   31:16
                    Rec1 Shape 8x8_3 Distortion
                    Hardware only uses 14 bits. Upper bits ignored (True for all 8x8_X Distortions).
             15:0 Rec1 Shape 8x8_2 Distortion
 M(X+2).2   31:16 Rec1 Shape 8x8_1 Distortion
             15:0 Rec1 Shape 8x8_0 Distortion
 M(X+2).1   31:16
                   Rec1 Shape 8x16_1
                    Hardware only uses 15 bits. Upper bits ignored (True for all 8x16_X Distortions).
             15:0 Rec1 Shape 8x16_0 Distortion
 M(X+2).0   31:16
                   Rec1 Shape 16x8_1 Distortion
                    Hardware only uses 15 bits. Upper bits ignored (True for all 16x8_X Distortions).

             15:0 Rec1 Shape 16x8_0 Distortion
 M(X+3).7   31:16 Rec1 Shape 8x8_3 Y (relative to source MB)
             15:0 Rec1 Shape 8x8_3 X (relative to source MB)
 M(X+3).6   31:16 Rec1 Shape 8x8_2 Y (relative to source MB)




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                   5/31/2012                                           91
 DWord        Bit                                         Description
             15:0 Rec1 Shape 8x8_2 X (relative to source MB)
 M(X+3).5   31:16 Rec1 Shape 8x8_1 Y (relative to source MB)
             15:0 Rec1 Shape 8x8_1 X (relative to source MB)
 M(X+3).4   31:16 Rec1 Shape 8x8_0 Y (relative to source MB)
             15:0 Rec1 Shape 8x8_0 X (relative to source MB)
 M(X+3).3   31:16 Rec1 Shape 8x16_1 Y (relative to source MB)
             15:0 Rec1 Shape 8x16_1 X (relative to source MB)
 M(X+3).2   31:16 Rec1 Shape 8x16_0 Y (relative to source MB)
             15:0 Rec1 Shape 8x16_0 X (relative to source MB)
 M(X+3).1   31:16 Rec1 Shape 16x8_1 Y (relative to source MB)
             15:0 Rec1 Shape 16x8_1 X (relative to source MB)
 M(X+3).0   31:16 Rec1 Shape 16x8_0 Y (relative to source MB)
             15:0 Rec1 Shape 16x8_0 X (relative to source MB)




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                5/31/2012              92
4. Shared Functions Pixel Interpolater
The Pixel Interpolator provides barycentric parameters at various offsets relative to the pixel location.
These barycentric parameters are in the same format and layout as those received in the pixel shader
dispatch. Please refer to the “Windower” chapter in the “3D Pipeline” volume for more details on
barycentric parameters.
Barycentric parameters delivered in the pixel shader payload are at pre-defined positions based on
Barycentric Interpolation Mode bits selected in 3DSTATE_WM. The pixel interpolator allows
barycentric parameters to be computed at additional locations.


4.1       Messages
The following is the message definition for the Pixel Interpolator shared function.
Restrictions:

      Pixel Interpolator messages can only be delivered by pixel shader kernels.
      [ivbgt2 pre-K0] Hang possible if linear PI message when Barycentric Interpolation mode has any
       perspective bits set, or Pixel Shader Uses Source W is set.
      [ivbgt2 pre-K0] Hang possible if perspective PI message when Barycentric Interpolation mode has
       any non-perspective bits set.

Execution Mask. Each bit in the execution mask enables the corresponding slot’s barycentric parameter
return to the destination registers.


4.1.1       Initiating Message

4.1.1.1       Message Descriptor

 Bit                                               Description
 19
            Header Present: Specifies whether the message includes a header phase. Must be zero for all
            Pixel Interpolator messages.

            Format = Enable
18:17 Ignored
 16
           SIMD Mode. Specifies the SIMD mode of the message being sent.

            Format = U1
            0: SIMD8 mode
            1: SIMD16 mode
 15 Ignored
 14
         Interpolation Mode. Specifies which interpolation mode is to be used.

            Format = U1
            0: Perspective Interpolation




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                 5/31/2012                                                 93
 Bit                                                     Description
              1: Linear Interpolation
        Programming Notes:
             This field cannot be set to “Linear Interpolation” unless Non-Perspective Barycentric Enable in
              3DSTATE_CLIP is enabled.

13:12
              Message Type. Specifies the type of message being sent.

              Format = U2
              0: Per Message Offset (eval_snapped with immediate offset)
              1: Sample Position Offset (eval_sindex)
              2: Centroid Position Offset (eval_centroid)
              3: Per Slot Offset (eval_snapped with register offset)
 11
              Slot Group Select. This field selects whether slots 15:0 or slots 31:16 are used for bypassed
              data.
              Bypassed data includes the X/Y addresses and centroid position. For 8- and 16-pixel
              dispatches, SLOTGRP_LO must be selected on every message. For 32-pixel dispatches, this
              field must be set correctly for each message based on which slots are currently being
              processed.
              0: SLOTGRP_LO:choose bypassed data for slots 15:0
              1: SLOTGRP_HI:choose bypassed data for slots 31:16
        Programming Notes:
        This field must be set to SLOTGRP_LO for SIMD8 messages. SIMD8 messages always use bypassed data
        for slots 7:0.

10:8 Ignored
 7:0
          Message Specific Control. Refer to the sections below for the definition of these bits based on
          Message Type.


4.1.1.1.1             “Per Message Offset” Message Descriptor
Bit                                 Description
7:4
            Per Message Y Pixel Offset

            Specifies the Y Pixel Offset that applies to all slots.
            Format = S4 2’s complement representing units of 1/16 pixel.
            Range = [-8/16, +7/16]
3:0
            Per Message X Pixel Offset

            Specifies the X Pixel Offset that applies to all slots.
            Format = S4 2’s complement representing units of 1/16 pixel.
            Range = [-8/16, +7/16]




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                      5/31/2012                                                94
4.1.1.1.2           “Sample Position Offset” Message Descriptor
Bit                         Description
7:4
      Sample Index

         Specifies the sample index that applies to all slots.
         Format = U4
         Range = [0,7
3:0 Ignored


4.1.1.1.3           “Centroid Position” and “Per Slot Offset” Message Descriptor
Bit                         Description
7:0 Ignored


4.1.1.2        Message Payload for most messages
This message payload applies to the following message types:

      Per Message Offset
      Sample Position Offset
      Centroid Position Offset
DWord Bit                       Description
M0.7:0    Ignored


4.1.1.3        SIMD8 Per Slot Offset Message Payload
This message payload applies only to the SIMD8 Per Slot Offset message type. The message length is 2.
DWord Bit                                                    Description
 M0.7 31:0
              Slot 7 X Pixel Offset

                  Specifies the X pixel offset for slot 7.
                  Format = S4 2’s complement representing units of 1/16 pixel. The upper 28 bits are
                  ignored.
                  Range = [-8/16, +7/16]
 M0.6 31:0
              Slot 6 X Pixel Offset

 M0.5 31:0
              Slot 5 X Pixel Offset

 M0.4 31:0
              Slot 4 X Pixel Offset

 M0.3 31:0
              Slot 3 X Pixel Offset

 M0.2 31:0
              Slot 2 X Pixel Offset

 M0.1 31:0
              Slot 1 X Pixel Offset

 M0.0 31:0
              Slot 0 X Pixel Offset




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                    5/31/2012                                         95
DWord Bit                                                   Description
 M1.7 31:0
             Slot 7 Y Pixel Offset

                 Specifies the Y pixel offset for slot 7.
                 Format = S4 2’s complement representing units of 1/16 pixel. The upper 28 bits are
                 ignored.
                 Range = [-8/16, +7/16]
 M1.6 31:0
             Slot 6 Y Pixel Offset

 M1.5 31:0
             Slot 5 Y Pixel Offset

 M1.4 31:0
             Slot 4 Y Pixel Offset

 M1.3 31:0
             Slot 3 Y Pixel Offset

 M1.2 31:0
             Slot 2 Y Pixel Offset

 M1.1 31:0
             Slot 1 Y Pixel Offset

 M1.0 31:0
             Slot 0 Y Pixel Offset



4.1.1.4       SIMD16 Per Slot Offset Message Payload
This message payload applies only to the SIMD16 Per Slot Offset message type. The message length is
4.
DWord Bit                                                   Description
 M0.7 31:0
             Slot 7 X Pixel Offset

                 Specifies the X pixel offset for slot 7.
                 Format = S4 2’s complement representing units of 1/16 pixel. The upper 28 bits are
                 ignored.
                 Range = [-8/16, +7/16]
 M0.6 31:0
             Slot 6 X Pixel Offset

 M0.5 31:0
             Slot 5 X Pixel Offset

 M0.4 31:0
             Slot 4 X Pixel Offset

 M0.3 31:0
             Slot 3 X Pixel Offset

 M0.2 31:0
             Slot 2 X Pixel Offset

 M0.1 31:0
             Slot 1 X Pixel Offset

 M0.0 31:0
             Slot 0 X Pixel Offset

 M1.7 31:0
             Slot 15 X Pixel Offset




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                   5/31/2012                                         96
DWord Bit                                                   Description
 M1.6 31:0
             Slot 14 X Pixel Offset

M1.5 31:0
             Slot 13 X Pixel Offset

M1.4 31:0
             Slot 12 X Pixel Offset

M1.3 31:0
             Slot 11 X Pixel Offset

M1.2 31:0
             Slot 10 X Pixel Offset

M1.1 31:0
             Slot 9 X Pixel Offset

M1.0 31:0
             Slot 8 X Pixel Offset

M2.7 31:0
             Slot 7 Y Pixel Offset

                 Specifies the Y pixel offset for slot 7.
                 Format = S4 2’s complement representing units of 1/16 pixel. The upper 28 bits are
                 ignored.
                 Range = [-8/16, +7/16]
M2.6 31:0
             Slot 6 Y Pixel Offset

M2.5 31:0
             Slot 5 Y Pixel Offset

M2.4 31:0
             Slot 4 Y Pixel Offset

M2.3 31:0
             Slot 3 Y Pixel Offset

M2.2 31:0
             Slot 2 Y Pixel Offset

M2.1 31:0
             Slot 1 Y Pixel Offset

M2.0 31:0
             Slot 0 Y Pixel Offset

M3.7 31:0
             Slot 15 Y Pixel Offset

M3.6 31:0
             Slot 14 Y Pixel Offset

M3.5 31:0
             Slot 13 Y Pixel Offset

M3.4 31:0
             Slot 12 Y Pixel Offset

M3.3 31:0
             Slot 11 Y Pixel Offset

M3.2 31:0
             Slot 10 Y Pixel Offset

M3.1 31:0
             Slot 9 Y Pixel Offset

M3.0 31:0
             Slot 8 Y Pixel Offset




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                   5/31/2012                                         97
4.1.2      Writeback Message

4.1.2.1         SIMD8
The response length for all SIMD8 messages is 2. The data for each slot is written only if its
corresponding execution mask bit is set.
DWord Bit                                      Description
      31:0
 W0.7      Barycentric[1] for Slot 7

                   Format = IEEE_Float
        31:0
 W0.6          Barycentric[1] for Slot 6

        31:0
 W0.5          Barycentric[1] for Slot 5

        31:0
 W0.4          Barycentric[1] for Slot 4

        31:0
 W0.3          Barycentric[1] for Slot 3

        31:0
 W0.2          Barycentric[1] for Slot 2

        31:0
 W0.1          Barycentric[1] for Slot 1

        31:0
 W0.0          Barycentric[1] for Slot 0

        31:0
 W1.7              Barycentric[2] for Slot 7

                   Format = IEEE_Float
        31:0
 W1.6              Barycentric[2] for Slot 6

        31:0
 W1.5              Barycentric[2] for Slot 5

        31:0
 W1.4              Barycentric[2] for Slot 4

        31:0
 W1.3              Barycentric[2] for Slot 3

        31:0
 W1.2              Barycentric[2] for Slot 2

        31:0
 W1.1              Barycentric[2] for Slot 1

        31:0
 W1.0              Barycentric[2] for Slot 0




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                    5/31/2012                                   98
4.1.2.2         SIMD16
The response length for all SIMD16 messages is 4. The data for each slot is written only if its
corresponding execution mask bit is set.
DWord Bit                                       Description
      31:0
 W0.7      Barycentric[1] for Slot 7

                   Format = IEEE_Float
        31:0
 W0.6          Barycentric[1] for Slot 6

        31:0
 W0.5          Barycentric[1] for Slot 5

        31:0
 W0.4          Barycentric[1] for Slot 4

        31:0
 W0.3          Barycentric[1] for Slot 3

        31:0
 W0.2          Barycentric[1] for Slot 2

        31:0
 W0.1          Barycentric[1] for Slot 1

        31:0
 W0.0          Barycentric[1] for Slot 0

        31:0
 W1.7              Barycentric[2] for Slot 7

                   Format = IEEE_Float
        31:0
 W1.6              Barycentric[2] for Slot 6

        31:0
 W1.5              Barycentric[2] for Slot 5

        31:0
 W1.4              Barycentric[2] for Slot 4

        31:0
 W1.3              Barycentric[2] for Slot 3

        31:0
 W1.2              Barycentric[2] for Slot 2

        31:0
 W1.1              Barycentric[2] for Slot 1

        31:0
 W1.0              Barycentric[2] for Slot 0

                   Format = IEEE_Float
        31:0
 W2.7              Barycentric[1] for Slot 15

        31:0
 W2.6              Barycentric[1] for Slot 14

        31:0
 W2.5              Barycentric[1] for Slot 13

        31:0
 W2.4              Barycentric[1] for Slot 12




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12                  5/31/2012                                      99
DWord Bit                                   Description
      31:0
 W2.3          Barycentric[1] for Slot 11

        31:0
 W2.2          Barycentric[1] for Slot 10

        31:0
 W2.1          Barycentric[1] for Slot 9

        31:0
 W2.0          Barycentric[1] for Slot 8

        31:0
 W3.7          Barycentric[2] for Slot 15

        31:0
 W3.6          Barycentric[2] for Slot 14

        31:0
 W3.5          Barycentric[2] for Slot 13

        31:0
 W3.4          Barycentric[2] for Slot 12

        31:0
 W3.3          Barycentric[2] for Slot 11

        31:0
 W3.2          Barycentric[2] for Slot 10

        31:0
 W3.1          Barycentric[2] for Slot 9

        31:0
 W3.0          Barycentric[2] for Slot 8




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12              5/31/2012   100
Revision History
Revision Number Description                             Revision Date

1.0               First 2012 OpenSource edition         May 2012




                                                  §§




Doc Ref #: IHD-OS-V4 Pt 2 – 05 12           5/31/2012                   101
