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])=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]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<>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