Intel® OpenSource HD Graphics Programmer’s Reference Manual (PRM) Volume 4 Part 1: Subsystem and Cores – Shared Functions (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 1 – 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 1 – 05 12 Contents 1. Subsystem Overview ............................................................................................................................ 5 1.1 Introduction .......................................................................................................................................... 5 1.2 Subsystem Topology............................................................................................................................ 5 1.3 Execution Units (EUs) .......................................................................................................................... 5 1.4 Thread Dispatching .............................................................................................................................. 6 1.5 Shared Functions ................................................................................................................................. 6 1.5.1 Message Payload Containing a Header ......................................................................................... 7 1.5.2 Writebacks ...................................................................................................................................... 7 1.5.3 Message Delivery Ordering Rules .................................................................................................. 8 1.5.4 Execution Mask and Messages ...................................................................................................... 8 1.5.5 End-Of-Thread (EOT) Message ..................................................................................................... 8 1.5.6 Performance ................................................................................................................................... 9 1.5.7 Message Description Syntax .......................................................................................................... 9 1.5.8 Message Errors ............................................................................................................................ 10 2. Sampling Engine ................................................................................................................................. 12 2.1 Texture Coordinate Processing ......................................................................................................... 12 2.1.1 Texture Coordinate Normalization ................................................................................................ 13 2.1.2 Texture Coordinate Computation ................................................................................................. 13 2.2 Texel Address Generation ................................................................................................................. 14 2.2.1 Level of Detail Computation (Mipmapping) .................................................................................. 14 2.2.2 Intra-Level Filtering Setup ............................................................................................................ 18 2.2.3 Texture Address Control ............................................................................................................... 21 2.3 Texel Fetch ........................................................................................................................................ 24 2.3.1 Texel Chroma Keying ................................................................................................................... 25 2.4 Shadow Prefilter Compare ................................................................................................................. 25 2.5 Texel Filtering ..................................................................................................................................... 26 2.6 Texel Color Gamma Linearization ..................................................................................................... 26 2.7 Multisampled Surface Behavior ......................................................................................................... 26 2.7.1 Multisample Control Surface ........................................................................................................ 27 2.8 Denoise/Deinterlacer .......................................................................................................................... 27 2.8.1 Introduction ................................................................................................................................... 27 2.8.2 Denoise Algorithm ........................................................................................................................ 29 2.8.3 Block Noise Estimate (part of Global Noise Estimate) ................................................................. 32 2.8.4 Deinterlacer Algorithm .................................................................................................................. 33 2.8.5 Field Motion Detector ................................................................................................................... 46 2.8.6 Implementation Overview ............................................................................................................. 48 2.9 Adaptive Video Scaler ........................................................................................................................ 50 2.9.1 Filtering Operations ...................................................................................................................... 51 2.10 Image Enhancement Filter and Video Signal Analysis ..................................................................... 52 2.10.1 Detail Filter Algorithm ................................................................................................................. 53 2.10.2 Skin-Tone Tuned IEF ................................................................................................................. 53 2.10.3 Video Analytics Functions – Functional Description................................................................... 54 2.11 Mirror pixel at boundary edges for Media (sample_8x8 messages) ................................................ 57 2.11.1 Restriction when Mirror mode is enabled for Sample_8x8 messages ....................................... 60 2.12 State.................................................................................................................................................. 61 2.12.1 BINDING_TABLE_STATE.......................................................................................................... 61 2.12.2 SURFACE_STATE ..................................................................................................................... 61 2.12.3 SAMPLER_STATE ..................................................................................................................... 91 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 3 2.12.4 SAMPLER_8x8_STATE ........................................................................................................... 111 2.12.5 SAMPLER_BORDER_COLOR_STATE .................................................................................. 116 2.12.6 3DSTATE_CHROMA_KEY ...................................................................................................... 119 2.12.7 3DSTATE_SAMPLER_PALETTE_LOAD0 .............................................................................. 120 2.12.8 3DSTATE_MONOFILTER_SIZE .............................................................................................. 122 2.13 Messages ....................................................................................................................................... 123 2.13.1 Initiating Message ..................................................................................................................... 123 2.13.2 Writeback Message .................................................................................................................. 142 3. Shared Functions – Data Port .......................................................................................................... 167 3.1 Cache Agents ................................................................................................................................... 168 3.1.1 Render Cache............................................................................................................................. 168 3.1.2 Data Cache ................................................................................................................................. 169 3.1.3 Sampler Cache ........................................................................................................................... 169 3.2 Surfaces ........................................................................................................................................... 169 3.2.1 Surface State Model ................................................................................................................... 169 3.2.2 Stateless Model .......................................................................................................................... 169 3.2.3 Shared Local Memory (SLM)...................................................................................................... 170 3.3 Write Commit ................................................................................................................................... 170 3.4 Read/Write Ordering ........................................................................................................................ 171 3.5 Accessing Buffers ............................................................................................................................ 171 3.6 Accessing Media Surfaces ............................................................................................................... 172 3.6.1 Color Processing ........................................................................................................................ 172 3.6.2 Boundary Behavior ..................................................................................................................... 197 3.7 Accessing Render Targets ............................................................................................................... 197 3.7.1 Single Source ............................................................................................................................. 198 3.7.2 Dual Source ................................................................................................................................ 198 3.7.3 Replicate Data ............................................................................................................................ 198 3.7.4 Multiple Render Targets (MRT) .................................................................................................. 199 3.8 State ................................................................................................................................................. 199 3.8.1 BINDING_TABLE_STATE.......................................................................................................... 199 3.8.2 SURFACE_STATE ..................................................................................................................... 199 3.8.3 COLOR_PROCESSING_STATE ............................................................................................... 199 3.9 Messages ......................................................................................................................................... 225 3.9.1 Global Definitions ....................................................................................................................... 225 3.9.2 Data Port Messages ................................................................................................................... 226 3.9.3 OWord Block Read/Write ........................................................................................................... 233 3.9.4 Unaligned OWord Block Read.................................................................................................... 235 3.9.5 OWord Dual Block Read/Write ................................................................................................... 236 3.9.6 Media Block Read/Write ............................................................................................................. 239 3.9.7 DWord Scattered Read/Write ..................................................................................................... 245 3.9.8 Byte Scattered Read/Write ......................................................................................................... 248 3.9.9 Typed/Untyped Surface Read/Write and Typed/Untyped Atomic Operation ............................. 251 3.9.10 Scratch Block Read/Write......................................................................................................... 274 3.9.11 Render Target Write ................................................................................................................. 276 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 4 1. Subsystem Overview 1.1 Introduction The subsystem consists of an array of execution units (EUs, sometimes referred to as an arrray of cores) along with a set of shared functions outside the EUs that the EUs leverage for I/O and for complex computations. Programmers access the subsystem via the 3D or Media pipelines. EUs are general-purpose programmable cores that support a rich instruction set that has been optimized to support various 3D API shader languages as well as media functions (primarily video) processing. Shared functions are hardware units which serve to provide specialized supplemental functionality for the EUs. A shared function is implemented where the demand for a given specialized function is insufficient to justify the costs on a per-EU basis. Instead a single instantiation of that specialized function is implemented as a stand-alone entity outside the EUs and shared among the EUs. Invocation of the shared functionality is performed via a communication mechanism called a message. A message is a small self-contained packet of information created by a kernel and directed to a specific shared function. Messages are dispatched to the shared function under software control via the send instruction. This instruction identifies the contents of the message and the GRF register locations to direct any response. The message construction and delivery mechanisms are general in their definition and capable of supporting a wide variety of shared functions. 1.2 Subsystem Topology The subsystem is organized as an array of EUs, and a set of functions that are shared among all of the EUs. (The EU array is further divided into rows with each row having its own first level instruction cache and Extended Math shared function, though this aspect of the implemented topology is not exposed to software). The Sampler, DataPort, URB and Message Gateway functions are shared among the entire array of EUs. 1.3 Execution Units (EUs) Each EU is a vector machine capable of performing a given operation on as many as 16 pieces of data of the same type in parallel (though not necessarily on the same instant in time). In addition, each EU can support a number of execution contexts called threads that are used to avoid stalling the EU during a high-latency operation (external to the EU) by providing an opportunity for the EU to switch to a completely different workload with minimal latency while waiting for the high-latency operation to complete. For example, if a program executing on an EU requires a texture read by the sampling engine, the EU may not necessarily idle while the data is fetched from memory, arranged, filtered and returned to the EU. Instead the EU will likely switch execution to another (unrelated) thread associated with that EU. If that thread encounters a stall, the EU may switch to yet another thread and so on. Once the Sampler result arrives back at the EU, the EU can switch back to the original thread and use the returned data as it continues execution of that thread. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 5 The fact that there are multiple EU cores each with multiple threads can generally be ignored by software. There are some exceptions to this rule: e.g., for  thread-to-thread communication (see Message Gateway, Media)  synchronization of thread output to memory buffers (see Geometry Shader). In contrast, the internal SIMD aspects of the EU are very much exposed to software. This volume will not deal with the details of the EUs. 1.4 Thread Dispatching When the 3D and Media pipelines send requests for thread initiation to the Subsystem, the thread Dispatcher receives the requests. The dispatcher performs such tasks as arbitrating between concurrent requests, assigning requested threads to hardware threads on EUs, allocating register space in each EU among multiple threads, and initializing a thread’s registers with data from the fixed functions and from the URB. This operation is largely transparent to software. 1.5 Shared Functions In general, a shared function has the ability to receive messages at its input, perform some specialized amount of work for each, and if required, generate output back to the message’s originating execution unit (Message Gateway may generate output to a target execution unit specified by the message). To uniquely identify shared functions, each is assigned a unique 4-bit identifier code called its ‘Function ID’. This ID is specified in the ‘send’ instruction’s 32b field of each message. Function ID assignments are listed in the Graphics Processing Engine chapter of this specification. Each shared function may support one or more related operations within itself. For example an Extended Math shared function may support operations such as reciprocal, sine, cosine, and/or others. These are generically referred to as sub-functions. The communication method as to which sub-function is desired is typically contained in the 16b ‘function-control’ field of the ‘send’ instruction field. Alternatively, a function may choose to define sub-function encodings in-band within message payload, or in the case of a single function shared-function, the function code may be implied. The architecture, in no way interprets the sub-function code and the actual implementation choice is left to the function itself. The Shared Function units included in the Subsystem are as follows (refer to the chapters devoted to each of these functions):  Extended Math function  Sampling Engine function  DataPort function  Message Gateway function  Unified Return Buffer (URB)  Thread Spawner (TS)  Null function The Extended Math function acts as an extension of the math functions already available inside the EUs. Certain functions such as inverse, square root, exponentiation, etc., require significant hardware resources to implement and are used infrequently enough that it is inefficient to implement them separately in each EU. The EUs therefore send the operands for these operations along with the Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 6 operation to be performed to the Extended Math function which computes and returns the result to the requesting EU. The Sampling Engine acts a (read-only) I/O port on behalf of the EUs, translating texture coordinates (and/or structure references) to memory addresses, reading texels and/or other data from memory, and in the case of texels, combining and filtering them according to programmed state. The resulting pixel and/or other data are then returned to the requesting EU. The Data Port function acts as another I/O port on behalf of the EUs. It is both a read and a write port, and the only way for the Graphics Processing Engine to write results (e.g., images) back to memory. The Data Port contains the render and depth caches which receive the newly rendered pixels and write them out to memory when necessary. They also permit previously rendered objects to be read back efficiently by the Graphics Processing Engine in order to blend them with other rendered objects and test for visibility of newly rendered objects. Finally, the Data Port also provides read access constant buffers (arrays of constants in memory.) The Message Gateway allows a thread to communicate (send a message to) another thread. A key is used to connect the sender and receiver threads, and a simple gateway protocol is used to send messages. This is primarily intended for media where a parent/child thread model is sometimes used and requires parent and child threads to synchronize and efficiently share information. It is not intended to be used by 3D graphics rendering threads. The Unified Return Buffer (URB) is a single set of registers that EU threads use to return result data for future fixed functions and their threads to make use of. Individual entries in the buffer are “owned” by a given fixed function but a mechanism is provided where other fixed functions (those that follow) can read the data placed there by another fixed function. The buffer is considered a “Shared Function” since EUs need to be able to write result data to it using messages. In general, EU threads write their final results either to memory via the Data Port or to the URB for re-use by subsequent EU threads or certain 3D pipeline fixed-function units (CLIP, GS). The Thread Spawner (TS) is a Shared Function that acts as a conduit for dispatching kernel-software- generated threads, one thread can request another thread to be dispatched by sending a request to the TS. TS is unique as it is also a Fixed Function in the media pipeline for dispatching threads originated from Video Front End fixed function. The Null shared function is supported to allow the broadcast of certain information (e.g, End Of Thread) without invoking any other operation or response. 1.5.1 Message Payload Containing a Header For most shared functions, the first register of the message payload contains the header payload of the message (or simply the message header). Consequently, the rest of the message payload is referred to as the data payload. Messages to Extended Math do not have a header and only contain data payload. Those messages may be referred to as header-less messages. Messages to Gateway combine the header and data payloads in a single message register. 1.5.2 Writebacks Some messages generate return data as dictated by the ‘function-control’ (opcode) field of the ‘send’ instruction (part of the field). The execution unit and message passing infrastructure do not interpret this field in any way to determine if writeback data is to be expected. Instead explicit fields in the ‘send’ instruction to the execution unit the starting GRF register and count of returning data. The execution unit uses this information to set in-flight bits on those registers to prevent execution of any Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 7 instruction which uses them as an operand until the register(s) is(are) eventually written in response to the message. If a message is not expected to return data, the ‘send’ instruction’s writeback destination specifier () must be set to ‘null’ and the response length field of must be 0 (see ‘send’ instruction for more details). The writeback data, if called for, arrives as a series of register writes to the GRF at the location specified by the starting GRF register and length as specified in the ‘send’ instruction. As each register is written back to the GRF, its in-flight flag is cleared and it becomes available for use as an instruction operand. If a thread was suspended pending return of that register, the dependency is lifted and the thread is allowed to continue execution (assuming no other dependency for that thread remains outstanding). 1.5.3 Message Delivery Ordering Rules All messages between a thread and an individual shared function are delivered in the ordered they were sent. Messages to different shared functions originating from a single thread may arrive at their respective shared functions out of order. The writebacks of various messages from the shared functions may return in any order. Further individual destination registers resulting from a single message may return out of order, potentially allowing execution to continue before the entire response has returned (depending on the dependency chain inherent in the thread). 1.5.4 Execution Mask and Messages The Architecture defines an Execution Mask (EMask) for each instruction issued. This 16b bit-field identifies which SIMD computation channels are enabled for that instruction. Since the ‘send’ instruction is inherently scalar, the EMask is ignored as far as instruction dispatch is concerned. Further the execution size has no impact on the size of the ‘send' instruction’s implicit move (it is always 1 register regardless of specified execution size). The 16b EMask is forwarded with the message to the destination shared function to indicate which SIMD channels were enabled at the time of the ‘send’. A shared function may interpret or ignore this field as dictated by the functionality it exposes. For instance, the Extended Math shared function observes this field and performs the specified operation only on the operands with enabled channels, while the DataPort writes to the render cache ignore this field completely, instead using the pixel mask included in- band in the message payload to indicate which channels carry valid data. 1.5.5 End-Of-Thread (EOT) Message The final instruction of all threads must be a ‘send’ instruction which signals ‘End-Of-Thread’ (EOT). An EOT message is one in which the EOT bit is set in the ‘send’ instruction’s 32b field. When issuing instructions, the EU looks for an EOT message, and when issued, shuts down the thread from further execution and considers the thread completed. Only a subset of the shared functions can be specified as the target function of an EOT message, as shown in the table below. Target Shared Functions Target Shared Functions supporting EOT messages not supporting EOT messages Null, DataPortWrite, URB, MessageGateway, ThreadSpawner DataPortRead, Sampler Both the fixed-functions and the thread dispatcher require EOT notification at the completion of each thread. The thread dispatcher and fixed functions in the 3D pipeline obtain EOT notification by snooping Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 8 all message transmissions, regardless of the explicit destination, looking for messages which signal end- of-thread. The Thread Spawner in the media pipeline does not snoop for EOT. As it is also a shared function, all threads generated by Thread Spawner must send a message to Thread Spawner to explicity signal end-of-thread. The thread dispatcher, upon detecting an end-of-thread message, updates its accounting of resource usage by that thread, and is free to issue a new thread to take the place of the ended thread. Fixed functions require end-of-thread notification to maintain accounting as to which threads it issued have completed and which remain outstanding, and their associated resources such as URB handles. Unlike the thread dispatcher, fixed-functions discriminate end-of-thread messages, only acting upon those from threads which they originated, as indicated by the 4b fixed-function ID present in R0 of end-of-thread message payload. This 4b field is attached to the thread at new-thread dispatch time and is placed in its designated field in the R0 contents delivered to the GRF. Thus to satisfy the inclusion of the fixed-function ID, the typical end-of-thread message generally supplies R0 from the GRF as the first register of an end- of-thread message. As an optimization, an end-of-thread message may be overload upon another “productive” message, saving the cost in execution and bandwidth of a dedicated end-of-thread message. Outside of the end-of- thread message, most threads issue a message just prior to their termination (for instance, a Dataport write to the framebuffer) so the overloaded end-of-thread is the common case. The requirement is that the message contains R0 from the GRF (to supply the fixed-function ID), and that destination shared function be either (a) the URB; (b) the Read or Write Dataport; or, (c) the Gateway, as these functions reside on the O-Bus. In the case where the last real message of a thread is to some other shared function, the thread must issue a separate message for the purposes of signaling end-of-thread to the “null” shared function. 1.5.6 Performance The Architecture imposes no requirement as to a shared function’s latency or throughput. Due to this as well as factors such as message queuing, shared bus arbitration, implementation choices in bus bandwidth, and instantaneous demand for that function, the latency in delivering and obtaining a response to a message is non-deterministic. It is expected that an implementation has some notion of fairness in transmission and servicing of messages so as to keep latency outliers to a minimum. Other factors to consider with regard to performance:  A thread may choose to have multiple messages under construction in non-overlapping registers in the MRF at the same time.  Multiple messages are allowed to be enqueued for transmission at the same time, so long as their MRF payload registers do not overlap.  Messages may rely on the MRF registers being maintained across a send message, thus constructing subsequent messages overlaid on portions of a previous message,  Software prefetching techniques may be beneficial for long latency data fetches (i.e. issue a load early in the thread for data that is required late in the thread). 1.5.7 Message Description Syntax All message formats are defined in terms of DWords (32 bits). The message registers in all cases are 256 bits wide, or 8 DWords. The registers and DWords within the registers are named as follows, where n is the register number, and d is the DWord number from 0 to 7, from the least significant DWord at bits [31:0] within the 256-bit register to the most significant DWord at bits [255:224], respectively. For Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 9 writeback messages, the register number indicates the offset from the specified starting destination register. Dispatch Messages: Rn.d Dispatch messages are sent by the fixed functions to dispatch threads. See the fixed function chapters in the 3D and Media volume. SEND Instruction Messages: Mn.d These are the messages initiated by the thread via the SEND instruction to access shared functions. See the chapters on the shared functions later in this volume. Writeback Messages: Wn.d These messages return data from the shared function to the GRF where it can be accessed by thread that initiated the message. The bits within each DWord are given in the second column in each table. 1.5.8 Message Errors Messages are constructed via software, and not all possible bit encodings are legal, thus there is the possibility that a message may be sent containing one or more errors in its descriptor or payload contents. There are two points of error detection in the message passing system: (a) the message delivery subsystem is capable of detecting bad FunctionIDs and some cases of bad message lengths; (b) the shared functions contain various error detection mechanisms which identify bad sub-function codes, bad message lengths, and other misc errors. The error detection capabilities are specific to each shared function. The execution unit hardware itself does not perform message validation prior to transmission. In both cases, information regarding the erroneous message is captured and made visible through MMIO registers, and the driver notified via an interrupt mechanism . The set of possible errors is listed in Message Errors with the associated outcome. Error Cases Error Outcome Bad Shared Function ID The message is discarded before reaching any shared function. If the message specified a destination, those registers will be marked as in-flight, and any future usage by the thread of those registers will cause a dependency which will never clear, resulting in a hung thread and eventual time-out. The destination shared function detects unknown opcodes (as specified in the ‘send’ Unknown opcode instructions field), and known opcodes where the message payload is either too long Incorrect message or too short, and threats these cases as errors. When detected, the shared function latches length and makes available via MMIO registers the following information: the EU and thread ID which sent the message, the length of the message and expected response, and any relevant portions of the first register (R0) of the message payload. The shared function alerts the driver of an erroneous message through and interrupt mechanism , then continues normal operation with the subsequent message. Bad message contents Detection of bad data is an implementation decision of the shared function. Not all fields may in payload be checked by the shared function, so an erroneous payload may return bogus data or no data at all. If an erroneous value is detected by the shared function, it is free to discard the message and continue with the subsequent message. If the thread was expecting a response, the destination registers specified in the associated ‘send’ instruction are never cleared potentially resulting in a hung thread and time-out. Incorrect response Case: too few registers specified – the thread may proceed with execution prior to all the length data returning from the shared function, resulting in the thread operating on bad data in the Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 10 Error Outcome GRF. Case: too many registers specified – the message response does not clear all the registers of the destination. In this case, if the thread references any of the residual registers, it may hand and result in an eventual time-out. Improper use of End- Any ‘send’ instruction which specifies EOT must have a ‘null’ destination register. The EU Of-Thread (EOT) enforces this and, if detected, will not issue the ‘send’ instruction, resulting in a hung thread and an eventual time-out. The ‘send’ instruction specifies that EOT is only recognized if the field of the instruction is an immediate. Should a thread attempt to end a thread using a sourced from a register, the EOT bit will not be recognized. In this case, the thread will continue to execute beyond the intended end of thread, resulting in a wide range of error conditions. Two outstanding This is not checked by HW. Due to varying latencies between two messages, and out-of- messages using order, non-contiguous writeback cycles, the outcome in the GRF is indeterminate; may be overlapping GRF the result from the first message, or the result from the second message, or a combination of destinations ranges both. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 11 2. Sampling Engine The Sampling Engine provides the capability of advanced sampling and filtering of surfaces in memory. The sampling engine function is responsible for providing filtered texture values to the Core in response to sampling engine messages. The sampling engine uses SAMPLER_STATE to control filtering modes, address control modes, and other features of the sampling engine. A pointer to the sampler state is delivered with each message, and an index selects one of 16 states pointed to by the pointer. Some messages do not require SAMPLER_STATE. In addition, the sampling engine uses SURFACE_STATE to define the attributes of the surface being sampled. This includes the location, size, and format of the surface as well as other attributes. Although data is commonly used for “texturing” of 3D surfaces, the data can be used for any purpose once returned to the execution core. The following table summarizes the various subfunctions provided by the Sampling Engine. After the appropriate subfunctions are complete, the 4-component (reduced to fewer components in some cases) filtered texture value is provided to the Core in order to complete the sample instruction. Subfunction Description Texture Coordinate Any required operations are performed on the incoming pixel’s interpolated internal texture Processing coordinates. These operations may include: cube map intersection. Texel Address The Sampling Engine will determine the required set of texel samples (specific texel values Generation from specific texture maps), as defined by the texture map parameters and filtering modes. This includes coordinate wrap/clamp/mirror control, mipmap LOD computation and sample and/or miplevel weighting factors to be used in the subsequent filtering operations. Texel Fetch The required texel samples will be read from the texture map. This step may require decompression of texel data. The texel sample data is converted to an internal format. Texture Palette For streams which have “paletted” texture surface formats, this function uses the “index” values Lookup read from the texture map to look up texel color data from the texture palette. Shadow Pre-Filter For shadow mapping, the texel samples are first compared to the 3 rd (R) component of the Compare pixel’s texture coordinate. The boolean results are used in the texture filter. Texel Filtering Texel samples are combined using the filter weight coefficients computed in the Texture Address Generation function. This “combination” ranges from simply passing through a “nearest” sample to blending the results of anisotropic filters performed on two mipmap levels. The output of this function is a single 4-component texel value. Texel Color Gamma Performs optional gamma decorrection on texel RGB (not A) values. Linearization Denoise/ Performs denoise and deinterlacing functions for video content () Deinterlacer 8x8 Video Scaler Performs scaling using an 8x8 filter () Image Enhancement Image Enhancement functions for video content () Filter / Video Signal Analysis 2.1 Texture Coordinate Processing The Texture Coordinate Processing function of the Sampling Engine performs any operations on the texture coordinates that are required before physical addresses of texel samples can be generated. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 12 2.1.1 Texture Coordinate Normalization A texture coordinate may have normalized or unnormalized values. In this function, unnormalized coordinates are normalized. Normalized coordinates are specified in units relative to the map dimensions, where the origin is located at the upper/left edge of the upper left texel, and the value 1.0 coincides with the lower/right edge of the lower right texel . 3D rendering typically utilizes normalized coordinates. Unnormalized coordinates are in units of texels and have not been divided (normalized) by the associated map’s height or width. Here the origin is the located at the upper/left edge of the upper left texel of the base texture map. Unnormalized coordinates delivered to the sampling engine are only supported with the “ld” type messages. Normalized vs. Unnormalized Texture Coordinates 2.1.2 Texture Coordinate Computation Cartesian (2D) and homogeneous (projected) texture coordinate values are projected from (interpolated) screen space back into texture coordinate space by dividing the pixel’s S and T components by the Q component. This operation is done as part of the pixel shader kernel in the Core. Vector (cube map) texture coordinates are generated by first determining which of the 6 cube map faces (+X, +Y, +Z, -X, -Y, -Z) the vector intersects. The vector component (X, Y or Z) with the largest absolute value determines the proper (major) axis, and then the sign of that component is used to select between the two faces associated with that axis. The coordinates along the two minor axes are then divided by the coordinate of the major axis, and scaled and translated, to obtain the 2D texture coordinate ([0,1]) within the chosen face. Note that the coordinates delivered to the sampling engine must already have been divided by the component with the largest absolute value. An illustration of this cube map coordinate computation, simplified to only two dimensions, is provided below: Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 13 Cube Map Coordinate Computation Example 2.2 Texel Address Generation To better understand texture mapping, consider the mapping of each object (screen-space) pixel onto the textures images. In texture space, the pixel becomes some arbitrarily sized and aligned quadrilateral. Any given pixel of the object may “cover” multiple texels of the map, or only a fraction of one texel. For each pixel, the usual goal is to sample and filter the texture image in order to best represent the covered texel values, with a minimum of blurring or aliasing artifacts. Per-texture state variables are provided to allow the user to employ quality/performance/footprint tradeoffs in selecting how the particular texture is to be sampled. The Texel Address Generation function of the Sampling Engine is responsible for determining how the texture maps are to be sampled. Outputs of this function include the number of texel samples to be taken, along with the physical addresses of the samples and the filter weights to be applied to the samples after they are read. This information is computed given the incoming texture coordinate and gradient values, and the relevant state variables associated with the sampler and surface. This function also applies the texture coordinate address controls when converting the sample texture coordinates to map addresses. 2.2.1 Level of Detail Computation (Mipmapping) Due to the specification and processing of texture coordinates at object vertices, and the subsequent object warping due to a perspective projection, the texture image may become magnified (where a texel covers more than one pixel) or minified (a pixel covers more than one texel) as it is mapped to an object. In the case where an object pixel is found to cover multiple texels (texture minification), merely choosing one (e.g., the texel sample nearest to the pixel’s texture coordinate) will likely result in severe aliasing artifacts. Mipmapping and texture filtering are techniques employed to minimize the effect of undersampling these textures. With mipmapping, software provides mipmap levels, a series of pre-filtered texture maps of decreasing resolutions that are stored in a fixed (monolithic) format in memory. When mipmaps are provided and enabled, and an object pixel is found to cover multiple texels (e.g., when a textured object is Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 14 located a significant distance from the viewer), the device will sample the mipmap level(s) offering a texel/pixel ratio as close to 1.0 as possible. The device supports up to 14 mipmap levels per map surface, ranging from 8192 x 8192 texels to a 1 X 1 texel. Each successive level has ½ the resolution of the previous level in the U and V directions (to a minimum of 1 texel in either direction) until a 1x1 texture map is reached. The dimensions of mipmap levels need not be a power of 2. Each mipmap level is associated with a Level of Detail (LOD) number. LOD is computed as the approximate, log2 measure of the ratio of texels per pixel. The highest resolution map is considered LOD 0. A larger LOD number corresponds to lower resolution mip level. The Sampler[]BaseMipLevel state variable specifies the LOD value at which the minification filter vs. the magnification filter should be applied. When the texture map is magnified (a texel covers more than one pixel), the base map (LOD 0) texture map is accessed, and the magnification mode selects between the nearest neighbor texel or bilinear interpolation of the 4 neighboring texels on the base (LOD 0) mipmap. 2.2.1.1 Base Level Of Detail (LOD) The per-pixel LOD is computed in an implementation-dependent manner and approximates the log2 of the texel/pixel ratio at the given pixel. The computation is typically based on the differential texel-space distances associated with a one-pixel differential distance along the screen x- and y-axes. These texel- space distances are computed by evaluating neighboring pixel texture coordinates, these coordinates being in units of texels on the base MIP level (multiplied by the corresponding surface size in texels). The q coordinates represent the third dimension for 3D (volume) surfaces, this coordinate is a constant 0 for 2D surfaces. The ideal LOD computation is included below. 2.2.1.2 LOD Bias A biasing offset can be applied to the computed LOD and used to artificially select a higher or lower miplevel and/or affect the weighting of the selected mipmap levels. Selecting a slightly higher mipmap level will trade off image blurring with possibly increased performance (due to better texture cache reuse). Lowering the LOD tends to sharpen the image, though at the expense of more texture aliasing artifacts. The LOD bias is defined as sum of the LODBias state variable and the pixLODBias input from the input message (which can be non-zero only for sample_b messages). The application of LOD Bias is unconditional, therefore these variables must both be set to zero in order to prevent any undesired biasing. Note that, while the LOD Bias is applied prior to clamping and min/mag determination and therefore can be used to control the min-vs-mag crossover point, its use has the undesired effect of actually changing the LOD used in texture filtering. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 15 2.2.1.3 LOD Pre-Clamping The LOD Pre-Clamping function can be enabled or disabled via the LODPreClampEnable state variable. Enabling pre-clamping matches OpenGL semantics, while disabling it matches . After biasing and/or adjusting of the LOD , the computed LOD value is clamped to a range specified by the (integer and fractional bits of) MinLOD and MaxLOD state variables prior to use in Min/Mag Determination. MaxLOD specifies the lowest resolution mip level (maximum LOD value) that can be accessed, even when lower resolution maps may be available. Note that this is the only parameter used to specify the number of valid mip levels that be can be accessed, i.e., there is no explicit “number of levels stored in memory” parameter associated with a mip-mapped texture. All mip levels from the base mip level map through the level specified by the integer bits of MaxLOD must be stored in memory, or operation is UNDEFINED. MinLOD specifies the highest resolution mip level (minimum LOD value) that can be accessed, where LOD==0 corresponds to the base map. This value is primarily used to deny access to high-resolution mip levels that have been evicted from memory when memory availability is low. MinLOD and MaxLOD have both integer and fractional bits. The fractional parts will limit the inter-level filter weighting of the highest or lowest (respectively) resolution map. For example if MinLOD is 4.5 and MipFilter is LINEAR, LOD 4 can contribute only up to 50% of the final texel color. 2.2.1.4 Min/Mag Determination The biased and clamped LOD is used to determine whether the texture is being minified (scaled down) or magnified (scaled up). The BaseMipLevel state variable is subtracted from the biased and clamped LOD. The BaseMipLevel state variable therefore has the effect of selecting the “base” mip level used to compute Min/Map Determination. (This was added to match OpenGL semantics). Setting BaseMipLevel to 0 has the effect of using the highest-resolution mip level as the base map. If the biased and clamped LOD is non-positive, the texture is being magnified, and a single (high- resolution) miplevel will be sampled and filtered using the MagFilter state variable. At this point the computed LOD is reset to 0.0. Note that LOD Clamping can restrict access to high-resolution miplevels. If the biased LOD is positive, the texture is being minified. In this case the MipFilter state variable specifies whether one or two mip levels are to be included in the texture filtering, and how that (or those) levels are to be determined as a function of the computed LOD. 2.2.1.5 LOD Computation Pseudocode This section illustrates the LOD biasing and clamping computation in pseudocode, encompassing the steps described in the previous sections. The computation of the initial per-pixel LOD value LOD is not shown. Bias:S4.8 MinLod:U4.8 MaxLod:U4.8 Base:U4.1 MIPCnt:U4 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 16 SurfMinLod: U4.8 ResMinLod: U4.8 AdjMaxLod = min(MaxLod, MIPCnt) AdjMinLod = min(MinLod, MIPCnt) AdjPR_minLOD = ResMinLod – SurfMinLod AdjMinLod = max(AdjMinLod, AdjPR_minLOD) Out_of_Bounds = AdjPR_minLOD > MIPCnt if (sample_b) LOD += Bias + bias_parameter else if (sample_l or ld) LOD = Bias + lod_parameter else LOD += Bias PreClamp = LODPreClampEnable If (PreClamp) LOD = min(LOD, MaxLod) LOD = max(LOD, MinLod) MagMode = (LOD - Base <= 0) MagClampMipNone = 1 If ((MagMode && MagClampMipNone) or MipFlt = None) LOD = 0 LOD = min(LOD, ceil(AdjMaxLod)) LOD = max(LOD, floor(AdjMinLod)) else if (MipFlt = Nearest) LOD = min(LOD, AdjMaxLod) LOD = max(LOD, AdjMinLod) LOD = min(LOD, AdjMaxLod) LOD = max(LOD, AdjMinLod) LOD +=0.5 LOD = floor(LOD) else// MipFlt = Linear LOD = min(LOD, AdjMaxLod) LOD = max(LOD, AdjMinLod) Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 17 TriBeta = frac(LOD) LOD0 = floor(LOD) LOD1 = LOD0 + 1 if (!lod)// “LOD” message type Lod += SurfMinLod If Out_of_Bounds is true, LOD is set to zero and instead of sampling the surface the texels are replaced with zero in all channels, except for surface formats that don’t contain alpha, for which the alpha channel is replaced with one. These texels then proceed through the rest of the pipeline. Errata: Out of Bound true on surface format that doesn’t contain alpha will be forced to 0 instead of 1.0 for the case the filet type is Anisotropic. Errata: when AdjPR_minLOD > MIPCnt and MIPFILTER_LINEAR texel values will not force to zero. 2.2.1.5.1 Inter-Level Filtering Setup The MipFilter state variable determines if and how texture mip maps are to be used and combined. The following table describes the various mip filter modes: MipFilter Value Description MIPFILTER_NONE Mipmapping is DISABLED. Apply a single filter on the highest resolution map available (after LOD clamping). MIPFILTER_NEAREST Choose the nearest mipmap level and apply a single filter to it. Here the biased LOD will be rounded to the nearest integer to obtain the desired miplevel. LOD Clamping may further restrict this miplevel selection. MIPFILTER_LINEAR Apply a filter on the two closest mip levels and linear blend the results using the distance between the computed LOD and the level LODs as the blend factor. Again, LOD Clamping may further restrict the selection of miplevels (and the blend factor between them). When minifying and MIPFILTER_NEAREST is selected, the computed LOD is rounded to the nearest mip level. When minifying and MIPFILTER_LINEAR is selected, the fractional bits of the computed LOD are used to generate an inter-level blend factor. The LOD is then truncated. The mip level selected by the truncated LOD, and the next higher (lower resolution) mip level are determined. Regardless of MipFilter and the min/mag determination, all computed LOD values (two for MIPFILTER_LINEAR, otherwise one) are then unconditionally clamped to the range specified by the (integer bits of) MinLOD and MaxLOD state variables. 2.2.2 Intra-Level Filtering Setup Depending on whether the texture is being minified or magnified, the MinFilter or MagFilter state variable (respectively) is used to select the sampling filter to be used within a mip level (intra-level, as opposed to any inter-level filter). Note that for volume maps, this selection also applies to filtering between layers. The processing at this stage is restricted to the selection of the filter type, computation of the number and texture map coordinates of the texture samples, and the computation of any required filter parameters. The filtering of the samples occurs later on in the Sampling Engine function. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 18 The following table summarizes the intra-level filtering modes. Sampler[]Min/MagFilter value Description MAPFILTER_NEAREST Supported on all surface types. The texel nearest to the pixel’s U,V,Q coordinate is read and output from the filter. MAPFILTER_LINEAR Not supported on buffer surfaces. The 2, 4, or 8 texels (depending on 1D, 2D/CUBE, or 3D surface, respectively) surrounding the pixel’s U,V,Q coordinate are read and a linear filter is applied to produce a single filtered texel value. MAPFILTER_ANISOTROPIC Not supported on buffer or 3D surfaces. A projection of the pixel onto the texture map is generated and “subpixel” samples are taken along the major axis of the projection (center axis of the longer dimension). The outermost subpixels are weighted according to closeness to the edge of the projection, inner subpixels are weighted equally. Each subpixel samples a bilinear 2x2 of texels and the results are blended according to weights to produce a filtered texel value. MAPFILTER_MONO Supported only on 2D surfaces. This filter is only supported with the monochrome (MONO8) surface format. The monochrome texel block of the specified size surrounding the pixel is selected and filtered. 2.2.2.1 MAPFILTER_NEAREST When the MAPFILTER_NEAREST is selected, the texel with coordinates nearest to the pixel’s texture coordinate is selected and output as the single texel sample coordinates for the level. 2.2.2.2 MAPFILTER_LINEAR The following description indicates behavior of the MIPFILTER_LINEAR filter for 2D and CUBE surfaces. 1D and 3D surfaces follow a similar method but with a different number of dimensions available. When the MAPFILTER_LINEAR filter is selected on a 2D surface, the 2x2 region of texels surrounding the pixel’s texture coordinate are sampled and later bilinearly filtered. Bilinear Filter Sampling Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 19 The four texels surrounding the pixel center are chosen for the bilinear filter. The filter weights each texel’s contribution according to its distance from the pixel center. Texels further from the pixel center receive a smaller weight. 2.2.2.3 MAPFILTER_ANISOTROPIC The MAPFILTER_ANISOTROPIC texture filter attempts to compensate for the anisotropic mapping of pixels into texture map space. A possibly non-square set of texel sample locations will be sampled and later filtered. The MaxAnisotropy state variable is used to select the maximum aspect ratio of the filter employed, up to 16:1. The algorithm employed first computes the major and minor axes of the pixel projection onto the texture map. LOD is chosen based on the minor axis length in texel space. The anisotropic “ratio” is equal to the ratio between the major axis length and the minor axis length. The next larger even integer above the ratio determines the anisotropic number of “ways”, which determines how many subpixels are chosen. A line along the major axis is determined, and “subpixels” are chosen along this line, spaced one texel apart, as shown in the diagram below. In this diagram, the texels are shown in light blue, and the pixels are in yellow. Each subpixel samples a bilinear 2x2 around it just as if it was a single pixel. The result of each subpixel is then blended together using equal weights on all interior subpixels (not including the two endpoint subpixels). The endpoint subpixels have lesser weight, the value of which depends on how close the “ratio” is to the number of “ways”. This is done to ensure continuous behavior in animation. 2.2.2.4 MAPFILTER_MONO When the MAPFILTER_MONO filter is selected, a block of monochrome texels surrounding the pixel sample location are read and filtered using the kernel described below. The size of this block is controlled by Monochrome Filter Height and Width (referred to here as Nv and Nu, respectively) state. Filters from 1x1 to 7x7 are supported (not necessarily square). The figure below shows a 6x5 filter kernel as an example. The footprint of the filter (filter kernel samples) is equal to the size of the filter and the pixel center lies at the exact center of this footprint. The position of the upper left filter kernel sample (uf, vf) relative to the pixel center at (u, v) is given by the following: Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 20 u and v are the fractional parts of uf and vf, respectively. The integer parts select the upper left texel for the kernel filter, given here as T0,0. Sampling Using MAPFILTER_MONO The formula for the final filter output F is given by the following. Since this is a monochrome filter, each texel value (T) is a single bit, and the output F is an intensity value that is replicated across the color and alpha channels. 2.2.3 Texture Address Control The [TCX,TCY,TCZ]ControlMode state variables control the access and/or generation of texel data when the specific texture coordinate component falls outside of the normalized texture map coordinate range [0,1). Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 21 Note: For Wrap Shortest mode, the setup kernel has already taken care of correctly interpolating the texture coordinates. Software will need to specify TEXCOORDMODE_WRAP mode for the sampler that is provided with wrap-shortest texture coordinates, or artifacts may be generated along map edges. TC[X,Y,Z] Control Operation TEXCOORDMODE_CLAMP Clamp to the texel value at the edge of the map. TEXCOORDMODE_CLAMP_BORDER Use the texture map’s border color for any texel samples falling outside the map. The border color is specified via a pointer in SAMPLER_STATE. TEXCOORDMODE_HALF_BORDER Similar to CLAMP_BORDER except texels outside of the map are clamped to a value halfway between the edge texel and the border color. TEXCOORDMODE_WRAP Upon crossing an edge of the map, repeat at the other side of the map in the same dimension. TEXCOORDMODE_CUBE Only used for cube maps. Here texels from adjacent cube faces can be sampled along the edges of faces. This is considered the highest quality mode for cube environment maps. TEXCOORDMODE_MIRROR Similar to the wrap mode, though reverse direction through the map each time an edge is crossed. INVALID for use with unnormalized texture coordinates. TEXCOORDMODE_MIRROR_ONCE Similar to the wrap mode, though reverse direction through the map each time an edge is crossed. INVALID for use with unnormalized texture coordinates. Separate controls are provided for texture TCX, TCY, TCZ coordinate components so, for example, the TCX coordinate can be wrapped while the TCY coordinate is clamped. Note that there are no controls provided for the TCW component as it is only used to scale the other 3 components before addressing modes are applied. Maximum Wraps/Mirrors The number of map wraps on a given object is limited to 32. Going beyond this limit is legal, but may result in artifacts due to insufficient internal precision, especially evident with larger surfaces. Precision loss starts at the subtexel level (slight color inaccuracies) and eventually reaches the texel level (choosing the wrong texels for filtering). 2.2.3.1 TEXCOORDMODE_MIRROR Mode TEXCOORDMODE_MIRROR addressing mode is similar to Wrap mode, though here the base map is flipped at every integer junction. For example, for U values between 0 and 1, the texture is addressed normally, between 1 and 2 the texture is flipped (mirrored), between 2 and 3 the texture is normal again, and so on. The second row of pictures in the figure below indicate a map that is mirrored in one direction and then both directions. You can see that in the mirror mode every other integer map wrap the base map is mirrored in either direction. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 22 Texture Wrap vs. Mirror Addressing Mode 2.2.3.2 TEXCOORDMODE_WRAP Mode In TEXCOORDMODE_WRAP addressing mode, the integer part of the texture coordinate is discarded, leaving only a fractional coordinate value. This results in the effect of the base map ([0,1)) being continuously repeated in all (axes-aligned) directions. Note that the interpolation between coordinate values 0.1 and 0.9 passes through 0.5 (as opposed to WrapShortest mode which interpolates through 0.0). 2.2.3.3 TEXCOORDMODE_MIRROR_ONCE Mode The TEXCOORDMODE_MIRROR_ONCE addressing mode is a combination of Mirror and Clamp modes. The absolute value of the texture coordinate component is first taken (thus mirroring about 0), and then the result is clamped to 1.0. The map is therefore mirrored once about the origin, and then clamped thereafter. This mode is used to reduce the storage required for symmetric maps. 2.2.3.4 TEXCOORDMODE_CLAMP Mode The TEXCOORDMODE_CLAMP addressing mode repeats the “edge” texel when the texture coordinate extends outside the [0,1) range of the base texture map. This is contrasted to TEXCOORDMODE_CLAMPBORDER mode which defines a separate texel value for off-map samples. TEXCOORDMODE_CLAMP is also supported for cube maps, where texture samples will only be obtained from the intersecting face (even along edges). The figure below illustrates the effect of clamp mode. The base texture map is shown, along with a texture mapped object with texture coordinates extending outside of the base map region. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 23 Texture Clamp Mode 2.2.3.5 TEXCOORDMODE_CLAMPBORDER Mode For non-cube map textures, TEXCOORDMODE_CLAMPBORDER addressing mode specifies that the texture map’s border value BorderColor is to be used for any texel samples that fall outside of the base map. The border color is specified via a pointer in SAMPLER_STATE. 2.2.3.6 TEXCOORDMODE_CUBE Mode For cube map textures TEXCOORDMODE_CUBE addressing mode can be set to allow inter-face filtering. When texel sample coordinates that extend beyond the selected cube face (e.g., due to intra- level filtering near a cube edge), the correct sample coordinates on the adjoining face will be computed. This will eliminate artifacts along the cube edges, though some artifacts at cube corners may still be present. 2.3 Texel Fetch The Texel Fetch function of the Sampling Engine reads the texture map contents specified by the texture addresses associated with each texel sample. The texture data is read either directly from the memory- resident texture map, or from internal texture caches. The texture caches can be invalidated by the Sampler Cache Invalidate field of the MI_FLUSH instruction or via the Read Cache Flush Enable bit of PIPE_CONTROL. Except for consideration of coherency with CPU writes to textures and rendered textures, the texture cache does not affect the functional operation of the Sampling Engine pipeline. When the surface format of a texture is defined as being a compressed surface, the Sampler will automatically decompress from the stored format into the appropriate [A]RGB values. The compressed texture storage formats and decompression algorithms can be found in the Memory Data Formats chapter. When the surface format of a texture is defined as being an index into the texture palette (format names includiong “Px”), the palette lookup of the index determines the appropriate RGB values. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 24 2.3.1 Texel Chroma Keying ChromaKey is a term used to describe a method of effectively removing or replacing a specific range of texel values from a map that is applied to a primitive, e.g., in order to define transparent regions in an RGB map. The Texel Chroma Keying function of the Sampling Engine pipeline conditionally tests texel samples against a “key” range, and takes certain actions if any texel samples are found to match the key. 2.3.1.1 Chroma Key Testing ChromaKey refers to testing the texel sample components to see if they fall within a range of texel values, as defined by ChromaKey[][High,Low] state variables. If each component of a texel sample is found to lie within the respective (inclusive) range and ChromaKey is enabled, then an action will be taken to remove this contribution to the resulting texel stream output. Comparison is done separately on each of the channels and only if all 4 channels are within range the texel will be eliminated. The Chroma Keying function is enabled on a per-sampler basis by the ChromaKeyEnable state variable. The ChromaKey[][High,Low] state variables define the tested color range for a particular texture map. 2.3.1.2 Chroma Key Effects There are two operations that can be performed to “remove” matching texel samples from the image. The ChromaKeyEnable state variable must first enable the chroma key function. The ChromaKeyMode state variable then specifies which operation to perform on a per-sampler basis. The ChromaKeyMode state variable has the following two possible values: KEYFILTER_KILL_ON_ANY_MATCH: Kill the pixel if any contributing texel sample matches the key KEYFILTER_REPLACE_BLACK: Here the sample is replaced with (0,0,0,0). . The Kill Pixel operation has an effect on a pixel only if the associated sampler is referenced by a sample instruction in the pixel shader program. If the sampler is not referenced, the chroma key compare is not done and pixels cannot be killed based on it. 2.4 Shadow Prefilter Compare When a sample_c message type is processed, a special shadow-mapping precomparison is performed on the texture sample values prior to filtering. Specifically, each texture sample value is compared to the “ref” component of the input message, using a compare function selected by ShadowFunction, and described in the table below. Note that only single-channel texel formats are supported for shadow mapping, and so there is no specific color channel on which the comparison occurs. ShadowFunction Result PREFILTEROP_ALWAYS 0.0 PREFILTEROP_NEVER 1.0 PREFILTEROP_LESS (texel < ref) ? 0.0 : 1.0 PREFILTEROP_EQUAL (texel == ref) ? 0.0 : 1.0 PREFILTEROP_LEQUAL (texel <= ref) ? 0.0 : 1.0 PREFILTEROP_GREATER (texel > ref) ? 0.0 : 1.0 PREFILTEROP_NOTEQUAL (texel != ref) ? 0.0 : 1.0 PREFILTEROP_GEQUAL (texel >= ref) ? 0.0 : 1.0 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 25 The binary result of each comparison is fed into the subsequent texture filter operation (in place of the texel’s value which would normally be used). Software is responsible for programming the ”ref” component of the input message such that it approximates the same distance metric programmed in the texture map (e.g., distance from a specific light to the object pixel). In this way, the comparison function can be used to generate “in shadow” status for each texture sample, and the filtering operation can be used to provide soft shadow edges. Programming Notes:  Refer to the Surface Formats table in the section SURFACE_STATE for most messages for the specific surface formats that are supported with shadow mapping. 2.5 Texel Filtering The Texel Filtering function of the Sampling Engine performs any required filtering of multiple texel values on and possibly between texture map layers and levels. The output of this function is a single texel color value. The state variables MinFilter, MagFilter, and MipFilter are used to control the filtering of texel values. The MipFilter state variable specifies how many mipmap levels are included in the filter, and how the results of any filtering on these separate levels are combined to produce a final texel color. The MinFilter and MagFilter state variables specify how texel samples are filtered within a level. 2.6 Texel Color Gamma Linearization This function is supported to allow pre-gamma-corrected texel RGB (not A) colors to be mapped back into linear (gamma=1.0) gamma space prior to (possible) blending with, and writing to the Color Buffer. This permits higher quality image blending by performing the blending on colors in linear gamma space. This function is enabled on a per-texture basis by use of a surface format with “_SRGB” in its name. If enabled, the pre-filtered texel RGB color to be converted from gamma=2.4 space to gamma=1.0 space by applying a ^(1/2.4) = ^0.4167 exponential function. 2.7 Multisampled Surface Behavior The ld message has added an additional parameter for sample index (si) to support unfiltered loading from a multisampled surface. The sampleinfo message returns specific parameters associated with a multisample surface. The resinfo message returns the height, width, depth, and MIP count of the surface (in units of pixels, not samples). Any of the other messages (sample*, LOD, load4) used with a (4x) multisampled surface would sample a surface with double the height and width as indicated in the surface state. Each pixel position on the original-sized surface is replaced with 2x2 samples that have the following arrangement: sample 0 sample 2 sample 1 sample 3 This behavior is useful when implementing the multisample resolve operation by selecting MAPFILTER_LINEAR and rendering a full-screen rectangle half the size in each dimension of the source texture map (multisampled surface). If pixel offsets are set correctly, each pixel is the average of the four underlying samples. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 26 2.7.1 Multisample Control Surface Three new messages have been defined for the sampling engine, ld_mcs, ld2dms, and ld2dss. A pixel shader kernel sampling from an multisampled surface using an MCS must first sample from the MCS surface using the ld_mcs message. This message behaves like the ld message, except that the surface is defined by the MCS fields of SURFACE_STATE rather than the normal fields. The surface format is effectively R8_UINT for 4x surfaces and R32_UINT for 8x surfaces, thus data is returned in unsigned integer format. Following the ld_mcs, the kernel issues a ld2dms message to sample the surface itself. The integer value from the MCS surface is delivered in the mcs parameter of this messages. Since sample is no longer supported on multisampled surfaces, the multisample resolve must be done using ld2dms. For surfaces with Multisampled Surface Storage Format set to MSFMT_MSS and MCS Enable set to enabled, an optimization is available to enable higher performance for compressed pixels. The ld2dss message can be used to sample from a particular sample slice on the surface. By examining the MCS value, software can determine which sample slices to sample from. A simple optimization with probable large return in performance is to compare the MCS value to zero (indicating all samples are on sample slice 0), and sample only from sample slice 0 using ld2dss if MCS is zero. Sample slice 0 is the pixel color in this case. If MCS is not zero, each sample is then obtained using ld2dms messages and the results are averaged in the kernel after being returned. Refer to the multisample storage format in the GPU Overview volume for more details. 2.8 Denoise/Deinterlacer The Denoise/Deinterlacer function takes a 4:2:0 or 4:2:2 video stream and first applies a denoise filter to it and then deinterlace it. The denoise filter is applied before the deinterlacer. The denoise filter detects and tries to minimize noise in the input field, while the deinterlacer takes a field consisting of every other lines converts a field into a frame. This block also gathers statistics for a global noise estimate made in software at the end of the frame which is used in following frames to tune the denoise filter and image enhancement filter. The deinterlacer takes the top and bottom fields of each frame and converts them into two individual frames. This block also gathers statistics for a film mode detector in software run at the end of the frame. If the film mode detector for the previous frame concludes that the input is progressive rather than interlaced then the fields will be put together in the best order rather than being interlaced. 2.8.1 Introduction 2.8.1.1 Overview This diagram shows how the Denoise/Deinterlacer fits in with the other functions of the video pipe. This is only one possible usage model, other models are possible. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 27 Block Diagram 2.8.1.2 Features  Denoise Filter – detects noise and motion and filters the block with either a temporal filter when little motion is detected or a spatial filter. Noise estimates are kept between frames and blended together. Since the filter is before the deinterlacer it works on individual fields rather than frames. This usually improves the operation since the deinterlacer can take a single pixel of noise and spread it to an adjacent pixel, making it harder to remove. The denoise filter works the same whether deinterlacing or progressive cadence reconstruction is being done.  Block Noise Estimate (BNE) – part of the Global Noise Estimate (GNE) algorithm, this estimates the noise over the entire block. The GNE will be calculated at the end of the frame by combining all the BNEs. The final GNE value is used to control the denoise filter for the next frame.  Film Mode Detection (FMD) Variances – FMD determines if the input fields were created by sampling film and converting it to interlaced video. If so the deinterlacer is turned off in favor of reconstructing the frame from adjacent fields. Various sum-of-absolute differences are calcluated per block. The FMD algorithm is run at the end of the frame by looking at the variances of all blocks for both fields in the frame.  Deinterlacer – Estimates how much motion is occuring across the fields. Low motion scenes are reconstructed by averaging pixels from fields from nearby times (temporal deinterlacer), while high motion scenes are reconstructed by interpolating pixels from nearby space (spatial deinterlacer).  Progressive Cadence Reconstruction – If the FMD for the previous frame determines that film was converted into interlaced video, then this block reconstructs the original frame by directly putting together adjacent fields.  Chroma Upsampling – If the input is 4:2:0 then chroma will be doubled vertically to convert to 4:2:2. Chroma will then either go through it’s own version of the deinterlacer or progressive cadence reconstruction. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 28 When DI is enabled, the output for a 16x4 block is sent to the EU for further processing and writing to memory. When DI is disabled and DN enabled the output for a 16x8 block is sent to the EU. Formats supported are: NV12 is supported for hardware video decode. UYVY, YUY2 and NV12 are required for WHQL. YV12 and I420 are supported for software video decode. IMC3 and IMC4 are supported as internal temporary formats. NV11 and P208 are not supported, since they have been removed from the WHQL logo requirement. 2.8.2 Denoise Algorithm Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 29 2.8.2.1 Motion Detection and Noise History Update This block detection motion for the denoise filter, which it then combines with motion detected in the past in the same part of the screen. The Denoise History is both saved to memory and also used to control the temporal denoise filter. The block calculates a number of values for updating the Denoise History. One value is calculated per 4x4 block (pixels from both fields, interleaved): Block Sum of Temporal Absolute Difference: BK_STAD = Where curr(x,y) and prev(x,y) are lumas from the current and previous field. The previous field should have already been run through the denoise filter. Count of motion pixels: increment BK_Motion_Pixel for every pixel in the 4x4 for which: (abs(curr(x,y) – prev(x,y)) >= temporal_diff_th. Absolute Sum of Temporal Difference sums the differences without the initial absolute value, so that random motions will tend to cancel out: BK_TASD = Sum of Complexity Measure looks for differences in the spatial domain: BK_SHCM = // sum of 12 pixel pairs BK_SVCM = // sum of 12 pixel pairs BK_SCM = BK_SHCM + BK_SVCM Denoise Motion History Update (for an 8-bit motion history): if (BK_STAD>dnmh_stad_th) or (BK_Motion_Pixel > dnmh_mp_th) { // Motion Block motion_block = 1; if (denoise_history >= 128) new_denoise_history = denoise_history / 2; else new_denoise_history = 0; } else { // static block motion_block = 0; if (denoise_history < 128) new_denoise_history = 128; else if (denoise_history < dnmh_history_max) new_denoise_history = denoise_history + dnmh_delta; // default value 8 for delta else new_denoise_history = denoise_history; Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 30 if ((BK_TASD > dnmh_tasd_th) and (BK_SCM < dnmh_scm_th)) new_denoise_history = 128; } 2.8.2.2 Temporal Filter For each pixel we need to filter we look at the noise history for the associated 4x4. temporal_denoised = (new_denoise_history * prev(x,y) + (256 – new_denoise_history) * curr(x,y) +128) >> 8 2.8.2.3 Context Adaptive Spatial Filter For each pixel in the local 3x3, compare it’s luma to the lumas of the pixel to be filtered. Each pixel for which the absolute difference is less than or equal to good_neighbor_th is marked as a “good neighbor”: The filtered pixel is then equal to: spatial_denoised = ∑ Good_neighbor luma / num_good_neighbors The divide is implemented as a multiply by a table lookup: spatial_denoised = ((∑Good_neighbor luma + (num_good_neighbors >>1)) * gn_q_table[num_good_neighbors-1]) >> 11 Note: The number of good neighbors varies from 1 to 9 since the center pixel is always good. Gn_q_table provides the reciprocal: gn_q_table[9] = {2048, 1024, 682, 512, 409, 341, 292, 256, 227}; 2.8.2.4 Denoise Blend The denoise blend combines the temporal and spatial denoise outputs. First we check to see if the temporal is out of the local range, if so we use the average of the denoised and the local limit instead: if (temporal_denoised >= block_max) temporal_denoised=(temporal_denoised+block_max)>>1; if (temporal_denoised < block_min) temporal_denoised=(temporal_denoised+block_min)>>1; Where block_max and block_min are the largest and smallest luma values in the local 3x3 (can be shared with BNE calculation). Next we decide between using the spatial and temporal denoise output: t_diff = abs(curr(x,y) – prev(x,y); if (t_diff < temporal_diff_th) { if (motion_block==1) denoise_out = spatial_denoised; else { if (t_diff < temp_diff_low) Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 31 denoise_out=temporal_denoised; else { denoise_out= (spatial_denoised*(t_diff-temp_diff_low) + temporal_denoised*(temporal_diff_th-t_diff)+ (temporal_diff_th-temp_diff_low)/2 ) * q_table[temporal_diff_th-temp_diff_low-1]) >> 10; } } else { denoise_out = spatial_denoised; } Motion_block is defined in section Denoise Algorithm above. T_diff can be limited to 6-bits to minimize the multipler gates required in the blend. A divide is eliminated by providing the reciprocal of the divisor in the q_table which is defined: q_table[16] = {1024,512,341,256,205,171,146,128,114,102,93,85,79,73,68,64} The following restrictions also apply: 1. Temporal_diff_th – temp_diff_low is limited in the state variable definition to the range 16 to 1. 2. Since t_diff=temp_diff_low; (temporal_diff_th-t_diff) is less then or equal to 16. The precision needed for spatial_denoised*(t_diff-temp_diff_low) is 8-bit times 4-bits to produce 12-bits. The other multiply is 8 by 5 to produce 13-bits; the extra bit is needed for 16. The multiplier to implement the divide will be a 13-bit times the 11-bit number out of q_table, but this could be reduced by implementing a 13x9 bit multiplier with the top 2 bits controlling a mux since the only table entries that use them are 1024 and 512. 2.8.3 Block Noise Estimate (part of Global Noise Estimate) Edge detection is done on every pixel in the 16x4 (DI enabled) or 16x8 (DN only) by estimating a gradient on the 3x3 neighborhood of pixels in the current field. The calculation only uses a multiply of 2, so shifts and add are all that is needed. Currently only vertical and horizontal edges are detected, 45 degrees is a potential improvement. Hrz Edge = abs(c(x-1,y-1) +2*c(x,y-1) +c(x+1,y-1) –c(x-1,y+1) –2*c(x,y+1) –c(x+1,y+1)) Vrt Edge = abs(c(x-1,y-1) +2*c(x-1,y) +c(x-1,y+1) –c(x+1,y-1) –2*c(x+1,y) –c(x+1,y+1)) The Hrz_Edge and Vrt_Edge are added together and if the sum is greater than bne_edge_th then an edge is detected: ED = (Hrz_Edge +Vrt_Edge) >> 3  median9 – the median of the 9 luma values for the 3x3 neighborhood pixels is used. Median5, the median of the pixels above/below/right/left/center may be satisfactory as a lower gate count solution.  for each pixel luma “y” in 3x3: noise_metric = sum(y – median9)  noise_min = min(abs(y-median9)) - min of all 9 ys in 3x3 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 32  noise_max = max(abs(y-median9)) – max of all 9 ys in 3x3  noise_min_max = noise_max(x,y) – noise_min(x,y)  pixel_noise_metric = noise_metric if (ED(x,y) < bne_edge_th) and (noise_max_min(x,y) < bne_nn_th) block_noise_estimate = min of all pixel_noise_metrics that pass the if test in the 16x4 (use 255 if no pixels pass the test) If the block_noise_estimate is less than 255 then it is added to a sum gathered across the entire frame. The summation will need to be 23-bits wide to be able to sum 8-bit values for all 32,400 blocks in a 1920x1080 frame. In addition, there will be a count of the number of blocks in the sum. The data will be written to memory at the end of the frame. Two sets of counters are needed to support 2 simultaneous streams. The streams are distinguished by the dndi_stream_id state variable in the DI state. The per block block_noise_estimate is also sent to the EU in the output message for possible use by the video encoder. 2.8.4 Deinterlacer Algorithm The overall goal of the motion adaptive deinterlacer is to convert an interlaced video stream made of fields of alternating lines into a progressive video stream made of frames in which every line is provided. If there is no motion in a scene, then the missing lines can be provided by looking at the previous or next fields, both of which have the missing lines. If there is a great deal of motion in the scene, then objects in the previous and next fields will have moved, so we can’t use them for the missing pixels. Instead we have to interpolate from the neighboring lines to fill in the missing pixels. This can be thought of as interpolating in time if there is no motion and interpolating in space if there is motion. This idea is implemented by creating a measure of motion on a per 2 pixel basis called the Spatial- Temporal Motion Measure (STMM). If this measure shows that there is little motion in an area around the pixels, then the missing pixels are created by averaging the pixel values from the previous and next frame. If the STMM shows that there is motion, then the missing pixels are filled in by interpolating from neighboring lines with the Spatial Deinterlacer (SDI). The two different ways to interpolate the missing pixels are blended for intermediate values of STMM to prevent sudden transitions. The Deinterlacer uses two frames for reference. The current frame contains the field that we are deinterlacing. The reference frame is the closest frame in time to the field that we are deinterlacing – if we are working on the 1st field then it is the previous frame, if it is the 2nd field then it is the next frame. 2.8.4.1 Spatial-Temporal Motion Measure This algorithm combines a complexity measure with a estimate of motion. This prevents high complexity scenes from incorrectly causing motion to be detected. It is calculated for a set of pixels 2 wide by 1 high. Complexity is measured in the vertical and horizontal directions with the SVCM and SHCM. For each set of 2 pixels which need to be interpolated, a window of pixels is used that is 4 wide and 5 high - +/-1 pixel in X and +/- 2 pixels in Y. The pixels values are taken from both the current and previous field - for example, if we are deinterlacing the top field then lines y+2,y, and y-2 will come from the top field; while line y+1 and y-1 will come from the bottom field. Spatial vertical complexity measure (SVCM) is a sum of all the differences in the vertical direction for a window around the current pixels. If we take x,y=0,0 as the left pixel of our 2x1 then: SVCM = Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 33 Where c(x,y) is the luma value at that x,y location in the current frame. Note that we are skipping by 2 in the Y direction to ensure that the compares are only done with lines from the same field. Spatial horizontal complexity measure (SHCM) is a sum of differences in the horizontal direction. SHCM = The vertical edge complexity measure (VECM) is a sum of difference in the horizontal direction similar to SHCM, but uses different pixels from the window. VECM = >>5 Temporal Difference Measure (TDM) is a measure of differences between pairs of fields with the same lines. It uses filtered versions of c(x,y) from the current frame and r(x,y) from the reference frame (either the previous or next frame). The filter used is a cross filter which uses the pixels above, below, to the right and to the left of the needed pixel in the same field. When denoise filter is enabled, the filter input c(x,y) is a denoised pixel only if -2<=y<=6 for dndi_topfirst=1, and -3<=Y<=5 for dndi_topfirst=0. Note that r(x,y) is a denoised pixel regardless of y. c’(x,y) = (2*c(x,y) +c(x-1,y) +c(x+1,y) +2*c(x,y-2) +2*c(x,y+2)) >> 3 (Done for both c(x,y) and r(x,y)) TDM = STMM is then calculated by : STMM = ((TDM >>tdm_shift1)<> 4) + stmm_c2) where SCM = max(0, SVCM+SHCM-VECM). Tdm_shift1 is used to quantize the STMM result, while Tdm_shift2 is used to set the STMM range. Tdm_shift1 can range from 4 to 6; since TDM has 13 bits this results in between 9 and 7 bits of precision. Tdm_shift2 can range from 6 to 8, producing a value between 17 and 13 bits, of which only 9-bits are non-zero. The divide can be implemented by a 8-bit reciprocal table followed by an 9 -bit x 8-bit multiply by the TDM value, which finally produces an output of 8-bits. STMM is then smoothed with an exponential moving average with the STMM saved from the previous field: if (STMM > stmm_md_th) STMM2 = (stmm_trc1 * STMM_s + (256-stmm_trc1)*STMM) / 256 else STMM2 = (stmm_trc2 * STMM_s + (256-stmm_trc2)*STMM) / 256 with state variables stmm_trc1 (typical value 64), stmm_trc2 (typical value 200), and stmm_md_th. This process prevent sudden changes in STMM, though STMM over a certain value uses a smaller smoothing constant (c1) which allows it to change faster. STMM2 is stored to memory to be read as STMM_s by the next frame. One final step is used to prevent sudden drops in STMM in the horizontal direction – taking the maximum of the STMM on the right and left sides: STMM3(x) = max (STMM2(x-2), STMM2(x), STMM2(x+2)) Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 34 The resulting STMM3 will be used as a blending factor between the spatial and temporal deinterlacer. 2.8.4.2 Spatial Deinterlacer Angle Detection Deciding the best pixels to interpolate in the current field is the job of the spatial deinterlacer. The simplest method would be to interpolate directly from the pixels above and below the missing pixels, but this can look bad; edges and lines particularly look jagged with this solution. A better solution is to detect the direction of edges in the pixel neighborhood and interpolate along the edge direction. Edge detection is done per 2 pixels to lower the compute needed (may change in this implementation depending on quality). Edge detection is done by taking a window of pixels around the pixels of interest and comparing with a window offset in the direction being tested. The more simularity between the windows the more likely it is that the movement is in the direction of an edge. We test 9 different directions to pick the best edge: vertical, +/-45°, +/-27°, +/-18° and +/-11 degrees. The window offset for 45° x+/-1, likewise the offset of 27° is x+/-2, 18° is x+/-3, and 11° is x+/-5. X+4 is not used because the gap between 18° and 11° is too small to make it worth checking. Use x,y=0,0 for the left pixel of the pair that we want to interpolate, and xoffset is the offset described in the above paragraph. The equation for each angle checked is: AngleCost_6x3 = Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 35 The above picture illustrates the 45 degree angle compution – taking the sum-of-absolute differences of the two 6x3 blocks around the 2 pixels that need an angle estimated. Each block is offset by 1 in Y and X in opposite direction. The offset in X is larger for the other angles, of course. Angle detection requires up to 7 pixels (offset of 5 plus 2 to get all the pixels in the 6x3) on the right and left of the output block, requiring the input to the deinterlacer from the denoise to be 16 + 7 + 7, or 30 pixels. Once we have all the angle values, the final decision is done by comparing them with each other. In the following diagram N45 indicates the AngleCost_6x3 for -45°, likewise P27 is the value for +27°, etc. Th and D are constants used to fine tune the algorithm. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 36 Any missing arcs in the above diagram use the default edge of 90 degrees; for example if the lower left box has P11 >= Th then the default will be used. 2.8.4.3 Angle Robustness Check Three special checks are made to eliminate incorrect angle detection. Fallback Mode 1 Moving regions with fine details can confuse the angle detection. This fallback mode will detect fine details and fall back to 90 degrees if they are detected. SUM_H1(x,y) = This sum is similar to SHCM, but over a horizontal line of -2 to +3 only. SUM_H2(x,y) = Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 37 if (SUM_H1(y-1) + SUM_H1(y+1) > SUM_H2(y-1) + SUM_H2(y+1) + sdi_t1 && SUM_H1(y-1) + SUM_H1(y+1) >= sdi_t2)Then use 90 degree The final decision for each pixel is done using the sums from above and below the current Y. Fallback Mode 2 Sometimes the 6x3 angle detection window makes mistakes due to pixels on the edge of the window. Adding a check using a 2x1 window fixes these problems: If( AngleCost_6x3(90 degree) + (AngleCost_2x1(90 degree)<<3) < AngleCost_6x3(best angle) + ((AngleCost_2x1(best angle) + sdi_angle2x1)<<3)) then use 90 degree AngleCost_2x1 is the same as AngleCost_6x3 with a much smaller window: AngleCost_2x1 = AngleCost_2x1 can be collected during the calculation of AngleCost_6x3. Horizontal Median One final step is used to prevent sudden angle changes – the angle detected for the pixel pair is compared to the angle detected for the pixels to the right and left and the median of the 3 is the angle finally used: angle_final(x) = median3(angle(x-2), angle(x), angle(x+2)) 2.8.4.4 Spatial Deinterlacer Interpolation Once the best angle is picked, the interpolation is done on a per pixel basis. Both the chroma and luma need to be interpolated (see section Chroma Up Sampler for chroma). Only 422 output is needed, so there will be a chroma pair for each 2 lumas. The interpolation itself is very simple: take a pixel from the line above and the line below along one of the 9 possible angles, and average the 8-bit luma and chroma values to get the result pixel. We will do 2 lumas per clock to get enough performance. 2.8.4.5 Chroma Up-Sampler The DN/DI block supports 4:2:0, 4:1:1 and 4:2:2 inputs, but only outputs 4:2:2. For 4:2:0 and 4:1:1 the chroma needs to be up-sampled to 4:2:2 before interpolation. The 4:2:0 input has chroma at ¼ the rate of the luma; ½ in the horizontal and ½ in the vertical directions. The output needs to be 4:2:2, where chroma is ½ the rate of luma; ½ the horizontal but the same in the vertical direction. Then chroma can be de-interlaced in the vertical direction. For luma we are working with 16x4 blocks, so for chroma we will have 8x2 in 4:2:0 and 8x4 in 4:2:2. The 4:2:0 to 4:2:2 conversion requires doubling the chroma in the vertical direction to match the luma: Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 38 The chroma is doubled by a simple interpolation in both time and space. In the following equations, pixel locations are specified as u(field, x_location, y_location). Field=n would be from the current field, n-1 is from the previous field, and n+1 is from the next field. The Cr and Cb X and Y values are ½ the luma values to map to the smaller area. temporal_cr = (cr(n-1,x,y) + cr(n+1,x,y)) / 2// Simple average in time spatial_cr = (cr(n,x,y-1) + cr(n,x,y+1)) / 2// Simple average in vertical space if (STMM3 < stmm_min) new_cr = temporal_cr else if (STMM > stmm_max) new_cr = spatial_cr else new_cr = ((STMM3 – stmm_min) * spatial_cr + (stmm_max - STMM3) * temporal_cr) >> stmm_shift Note that this simple chroma interpolation is not correct, since the chroma sample position is ¼ of a pixel different between 420 and 422. The polyphase filter in the scaler will be used to correct this inprecision by modifying the filter coefficients in software. For performance a single Cr and Cb has to be produce per clock in this stage to match the 2 pixel per clock performance goal. 4:1:1 also has chroma at ¼ the rate of luma; ¼ in the horizontal direction and the same in the vertical direction. To convert to 4:2:2 we need to double the chroma horizontally. This will be done by averaging the chromas to the right and left to produce the new chroma. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 39 The above diagram shows how the existing chroma values (both U and V) are averaged between C0 and C1 to produce the new C½. C0 is the chroma asociated with lumas L0 through L3, while C1 is associated with L4 through L7. 2.8.4.6 Chroma Deinterlace The next step is to do the deinterlacing. Chroma uses the output of the luma angle decision, but reduces the number of angles. The actual spatial deinterlace algorithm is a little different for chroma, since there are only 1 chroma per 2 lumas: some of the chromas are missing and must be filled in. The diagram shows the chromas used in red. Only 90°, -27° and 27° are directly available. The chromas for +/-45° are derived by a simple average of the 90° and 27° chromas. +/-18° and +/-11° both use the chroma for +/-27°. 2.8.4.6.1 Static Image Fallback Mode This algorithm has a problem with static images – alternate fields use different luma angle detections and can select different angles, causing noticable flicker. Rather than calculating a separate set of angles for chroma, we instead will blend with STMM so that a static image will use 90 degrees. if (STMM3 < stmm_min) chroma_sdi = chroma90degree else if (STMM > stmm_max) chroma_sdi = chroma_3angle else chroma_sdi = (chroma90degree * (stmm_max – STMM3) + chroma_3angle * (STMM3 – stmm_min)) >> stmm_shift Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 40 2.8.4.7 Temporal Deinterlacer and Final Deinterlacer Blend The temporal deinterlacer is a simple average between the previous and next field; when deinterlacing the 1st field of current the average will be between the 2nd field of previous and the 2nd field of current. The interpolation between spatial and temporal: if (STMM3 < stmm_min) deinterlace_out = tdi; else if (STMM3 > stmm_max) deinterlace_out = sdi; else deinterlace_out = (sdi * (STMM3 – stmm_min) + tdi * (stmm_max – STMM3)) >> stmm_shift 2.8.4.8 Progressive Cadence Reconstruction When the FMD for the previous frame indicates that a progressive mode is being used rather than interlaced, the luma and chroma will be taken from adjacent fields rather than spatially interpolated. The exact fields needed depend on state variables written to memory by a thread at the end of the previous frame. The thread will use the FMD variances written to memory via CSunit on the flush at the end of a frame. Since we are deinterlacing 2 fields at a time – one from the previous frame and one from the current frame (see section Implementation Overview) we will need a state variable which says how each one should be put together. In each case there are only two possibilities – either the field should be put together with the matching field in the same frame or it should be put together with the adjacent field in the other frame. If we are deinterlacing the 2nd field from frame N and the 1st field from frame N+1, then the FMD decision (which is made on frame boundaries) will be from frame N-1. Chroma is reconstructed the same as luma – only the first step of doubling chroma is done in the chroma upsampling block for the two needed fields. 2.8.4.9 Motion Search Motion will be estimated independently for each horizontal pair of pixels in the 16x4 block. The area around each pixel pair will be compared to areas in adjacent fields with different X/Y offsets. 16 different offsets, or motion vectors, will be examined in this order: Y= -2, X = -1, 0, 1 Y = 0, X = -6, -5, -4, -3, -2, 2, 3, 4, 5, 6 Y = 2, X = -1, 0, 1 The area to be compared around the pixel pair is a 6 wide by 5 high window - 2 pixels on right and left and 2 lines above and below. The lines above and below are from both fields, so a total of 3 lines from the same field and 2 lines from the complement field are compared to lines in 2 fields from an adjacent frame. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 41 The motion estimation equation for a pixel pair is: Mx, My is the motion vector offset being tested, and x,y is the location of the leftmost pixel of the pair. The motion vector with the smallest SAD is kept as the best motion estimate; if two motion vectors have the same SAD then the last one tested will be kept. 2.8.4.10 Robustness Checks The motion estimate output goes through 2 checks to make sure it is not an aberration – a smoothness check and a consistency check. 2.8.4.10.1 Consistency Check The consistency check is done per pixel and makes sure that the pixels we are interpolating for MC have a lower delta than the ones that would be interpolated for spatial DI: Here Edge is the delta found by SDI which corresponds to the best angle. MC_pixel_consistency_TH (U6)is a state parameter. PDI_cur is defined as: (same definition as in the motion compensation section) Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 42 2.8.4.10.2 Smoothness Check The smoothness check compares the motion vector found for neighboring pixel pairs. The neighbors are different for different locations to make sure it stays within the local 4x4. Each pixel pair has 3 sets of comparison with neighbor pixel pair within the 4 by 4: 2 sets of X/Y comparisons for the vertical direction and one set of X/Y comparisons for the horizontal direction. For lines 1 and 2 in the 16x4: Where smooth_mv_th(U2) is a state parameter. This equation ensures that the pixel pair 1 and 2 lines below have motion vector X and Y components (MVx & MVy) that are within a threshold of the best motion vector for the current pixel pair. The compares with y+1 use “+” rather than “-“ since they are comparing motion vectors in the opposite field, which have motion vectors pointing in the opposite direction, since they are using the current field as their reference. For example, if the current pixel has a motion vector of (4,2), the motion vector of x,y+1 would be the same if it is (-4,-2). For lines 3 and 4 in the 16x4: For pixel pairs with the first pixel location x%4 == 0 (low X in the 4x4): Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 43 For pixel pairs with the first pixel location x%4 != 0 (high X in 4x4): When all 3 comparisons pass the threshold, the smoothness check is passed. 2.8.4.11 Motion Comp The MCDI output is an average done per pixel on pixels chosen from adjacent field. There are 4 different equations depending on the motion vector (Mx, My): If (Mx%2 ==0) && (My == 0) then If (Mx%2 ==1) && (My == 0) then If (Mx%2==0) && abs(My) == 2 then If (Mx%2==1) & abs(My) == 2 then For all these equations, if more vareties of My are used than -2,0,2 then we need to use (My/2)%2==0) instead of My==0, and (My/2)%2==1 instead of abs(My)==2. 2.8.4.12 Merge with TDI & SDI The MADI equation used in Gen6 was: if (STMM3 < stmm_min) deinterlace_out = tdi; else if (STMM3 > stmm_max) Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 44 deinterlace_out = sdi; Else deinterlace_out = ((STMM3 – stmm_min) * sdi + (stmm_max - STMM3) * tdi) >> stmm_shift Where STMM3 is a measure of the complexity of the scene and how much motion is in it. The equation with MCDI is: if (STMM3 < stmm_min) Deinterlace_out = tdi; else if (STMM3 > stmm_max) deinterlace_out = DItemp; else deinterlace_out = ((STMM3 – stmm_min) * DItemp + (stmm_max - STMM3) * tdi) >> stmm_shift Where DItemp is defined below: Content Adaptive Thresholding: We denote the best_ME_SAD as the minimal SAD value for the MV candidates. Best_ME_SAD and Best_SAD_Angle_cost are measured based on the block of pixels. The new control equation with MCDI is calculated per pixel: If ((best_ME_SAD <= CAT_TH1) If (Consistency check is passed && Smoothness check is passed) DItemp = MCDI; Else DItemp = sdi; Else if (CAT_TH1 SCM_B) CAT_TH2 = SAD_THB; Else CAT_TH2 = SCM / CAT_slope; Where CAT_slope (U4: default value 10). SAD_THA (U4, default 5) and SAD_THB (U4, default 10) are state parameters, and SCM_A and SCM_B are derived parameters: SCM_A = CAT_slope * SAD_THA;// 4-bit * 4-bit to produce 8-bit value SCM_B = CAT_slope * SAD_THB;// 4-bit * 4-bit to produce 8-bit value 2.8.5 Field Motion Detector The Field Motion Detector is generated in either the EU or in the driver with a set of differences gathered across entire fields. It is used to detect when a non-interlaced source like a film has been converted to interlaced video – in this case there will be pairs of fields which can be put back together to make frames rather than interpolating. The variances for the block are sent to the VSCunit to be summed across the entire frame. The results are available in MMIO registers. 2.8.5.1 Simple Differences The first set of variances are simply a sum of absolute pixel differences. The equations are done for every pixel with an even y coordinate: variance[0] += Diff_cTpT = (c(x,y) – p(x,y)) ^ 2; – difference between pixels from the top fields of the current and previous frame. variance[1] += Diff_cBpB = (c(x,y+1) – p(x,y+1)) ^ 2; – difference between pixels from the bottom fields of the current and previous frame. variance[2] += Diff_cTcB = (c(x,y) – c(x,y+1)) ^ 2; – difference between pixels from the top field and bottom field in the current frame. variance[3] += Diff_cTpB = (c(x,y) – p(x,y+1)) ^ 2; – difference between pixels from the top field of the current frame and bottom field of previous frame. variance[4] += Diff_cBpT = (c(x,y+1) – p(x,y)) ^ 2; – difference between pixels from the bottom field of the current frame and top field of previous frame. The variances summed for each 16x4 block are divided by 16 before adding them to the sum for the frame to make sure the frame-level sum fits in a 32-bit register. 2.8.5.2 Counter Variances The rest of the variances are counters for variance conditions as described in the following code: // Same field difference of the current frame diff_cTcT = (c(x,y) – c(x,y+2)) ^ 2; Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 46 diff_cBcB = (c(x,y-1) – c(x,y+1)) ^ 2; // Same field difference of the previous frame diff_pTpT = (p(x,y) – p(x,y+2)) ^ 2; diff_pBpB = (p(x,y-1) – p(x,y+1)) ^ 2; // Same field vertical smoothness of the current frame diff_cT = ABS(c(x,y) – c(x,y-2)) + ABS(c(x,y) – c(x,y+2)) – ABS(c(x,y-2) + c(x,y+2)); diff_cB = ABS( c(x,y+1) – c(x,y-1) ) + ABS( c(x,y+1) – c(x,y+3) ) – ABS( c(x,y-1) + c(x,y+3) ); if( diff_cTpT + diff_cBpB > fmd_tdiff ) {// if moving pixels, // Fine tears for cadence detection except 2-2 detection if( diff_cTcB > diff_cTcT + diff_cBcB)variance[5]++; elsevariance[6]++; // Find tears for 2-2 cadence detection if( diff_cT < fmd_vdiff1 && diff_cB < fmd_vdiff1) {// if fields are vertically smooth, variance[7]++;// total moving pixels // Find tears. (1st condition is to exclude very small variations) if(diff_cTcB >=fmd_vdiff2 && diff_cTcB > diff_cTcT + diff_cBcB) TEAR1(x,y) = 1 if(diff_cTpB >=fmd_vdiff2 && diff_cTpB > diff_cTcT + diff_pBpB) TEAR_2(x,y) = 1 if(diff_cBpT>=fmd_vdiff2 && diff_cBpT > diff_pTpT + diff_cBcB) TEAR_3(x,y) = 1 } } 2.8.5.3 Tear Variances The all 3 TEAR_N variables are compared to neighbors to eliminate strays: if(TEAR_N(x-1,y) == 0 && TEAR_N(x+1,y) == 0 && TEAR_N(x,y-2) == 0 && TEAR_N(x,y+2) == 0)TEAR_N(x,y) = 0;where N=1,2,3. variance[8] = sum of TEAR1(x,y) variance[9] = sum of TEAR_2(x,y) variance[10] = sum of TEAR_3(x,y) if (variance[8] > variance[9] && variance[8] > variance[10]) variance[7] = variance[8] = variance[9] = variance[10] = 0 if (variance[8] < fmd_thr_tear) variance[8] = 0 if (variance[9] < fmd_thr_tear) variance[9] = 0 if (variance[10] < fmd_thr_tear) variance[10] = 0 The variances are summed for each block across the frame. The accumulators may require 24-bit adders if the differences are 8-bits and there can be 128 (horizontally) * 256 (vertically) of them. The sums are written to memory at the end of the frame. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 47 Two sets of FMD variances are needed to support 2 simultaneous streams. The streams are distinguished by the dndi_stream_id state variable in the DI state. A-Stepping Erratum: TEAR_N compute doesn’t follow the equation above. Two signals were missing, thus, it is incorrectly calculated as the following. Without the added protection of the N=-2 & N=4 collection of feature, the robustness of 2:2 detection suffers. if(TEAR_N(x-1,y) == 0 && TEAR_N(x+1,y) == 0 && )TEAR_N(x,y) = 0;where N=1,2,3. 2.8.6 Implementation Overview 2.8.6.1 Input and Output Frames Two frames are needed to do deinterlacing, but for any two frames, two fields can be deinterlaced, doubling the output for the same input bandwidth. This also allows the denoise filter to only filter a frame once. The above picture shows that two frames are read in, called current and previous. The two fields of the next frame are denoised using adjacent fields. The 2nd field of previous can be deinterlaced using current as the reference, and the 1st field of current can be deinterlaced using previous as reference. Since we are producing 2 16x4 outputs, and the performance goal is to output 2 pixels per clock, we have 64 clocks to run 2 denoise filters and 2 deinterlacers. The fields are referred to as 1st and 2nd because either the top or bottom field can be the first in the sequence depending on a state variable. 2.8.6.2 Statistics Surface Memory Format The statistics memory page is used to store both STMM and Denoise history. The STMM and Denoise history are stored in separate areas addressed by a single base address pointer: Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 48 The STMM for any pixel pair is addressed by: STMM_X = pixelX / 2 STMM_Y = pixelY The Denoise History for any 4x4 block is addressed by DH_X = Pitch/2 + pixelX/4 DH_Y = pixelY/4 Where the pixelX/Y comes from the address of the left pixel for STMM and the upper-left pixel for the Denoise History. The Pitch is from the surface state. The read and write surfaces for each frame must be separate, since any individual block will not know if the neighbor blocks have been updated yet. This can be implemented as a ping-pong buffer pair with the write surface for each frame becoming the read surface for the next. 2.8.6.3 First Frame Special Case The first frame in the sequence is a special case for both denoise and deinterlace. Only data from the current frame address is read, the previous frame, clean previous, statistics and control addresses are ignored. Behavior for each function is as follows: 1. Denoise – The denoise filter needs to use the spatial filter, since there is no previous frame from which to do a temporal filter. a. The Denoise Motion History is not read. b. The blend between the temporal and spatial is forced to 100% spatial. c. The Denoise Motion History output values are written to 0. 1. BNE – The Block Noise Estimate only uses current frame values and so works normally. 2. Deinterlacer – Only the 1st field of the current frame frame is deinterlaced in this case – the 2nd of previous does not exist. a. The spatial deinterlacer is used to produce the output. b. The STMM input values are not read. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 49 c. The STMM output values are written as a the maximum 255 value so that the next frame is correctly told that spatial deinterlacing was used in this frame. 3. FMD – variances between the top and bottom of the current field should be output correctly. Variances that read from the previous field should indicate a maximum difference. 4. Progressive Cadence Reconstruction – the FMD input is not read, so always assume interlaced. 2.9 Adaptive Video Scaler The adaptive video scaler consists of a pair of filters. The sharp filter is an 8x8 and the smooth filter is bilinear. The results of the two filters are alpha blended together using an alpha factor determined separately from an algorithm that examines the pixel values in the each vector. There are a total of four different coefficient tables with two in each direction. For both directions is it possible to use either of the two tables that are assigned to it or use both at once with one table for the Y and the other table for the U/V. The coefficients are programmable by software and loaded via a new command streamer instruction. The coefficients are considered to be nonpipelined state, with a full pipeline flush being required before a new set of coefficients is loaded. The above diagram shows two pixels (red and green) mapped onto a texture map, with the texel centers blue. The red/green boxes around the pixels indicate the area where the pixel would choose the same 8x8 footprint for its filter, while the large transparent box indicates the footprint for each pixel. The u/v addresses for each pixel (in texel space) are as follows: red pixel: u=3.3, v=3.3 (betau=0.3, betav=0.3) green pixel: u=4.3, v=4.7 (betau=0.3, betav=0.7) The integer u/v address of the upper left pixel of the footprint is a function of the pixel u/v address as follows: Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 50 u(UL) = floor(u(pix)) – 3 v(UL) = floor(v(pix)) – 3 When the 8x8 filter is selected, the 8x8 texel block surrounding the pixel sample point is selected. The blend factors "beta" (horizontal and vertical) are determined by the relative distance between the pixel center and the nearest 4 texels (2x2). The betas are first truncated to 5 bits (i). The beta value is used to look up two sets of 8 coefficients, one set of 8 for horizontal (called K h0..7), and one set of 8 for vertical (called Kv0..7). 2.9.1 Filtering Operations There are two separate filters, sharp and smooth, which are blended in an adaptive manner. 2.9.1.1 Sharp The following formula is used to compute the filtered texture color for the sharp filter: R0 = T00*Kh0 + T01*Kh1 + T02*Kh2 + T03*Kh3 + T04*Kh4 + T05*Kh5 + T06*Kh6 + T07*Kh7 R1 = T10*Kh0 + T11*Kh1 + T12*Kh2 + T13*Kh3 + T14*Kh4 + T15*Kh5 + T16*Kh6 + T17*Kh7 R2 = T20*Kh0 + T21*Kh1 + T22*Kh2 + T23*Kh3 + T24*Kh4 + T25*Kh5 + T26*Kh6 + T27*Kh7 R3 = T30*Kh0 + T31*Kh1 + T32*Kh2 + T33*Kh3 + T34*Kh4 + T35*Kh5 + T36*Kh6 + T37*Kh7 R4 = T40*Kh0 + T41*Kh1 + T42*Kh2 + T43*Kh3 + T44*Kh4 + T45*Kh5 + T46*Kh6 + T47*Kh7 R5 = T50*Kh0 + T51*Kh1 + T52*Kh2 + T53*Kh3 + T54*Kh4 + T55*Kh5 + T56*Kh6 + T57*Kh7 R6 = T60*Kh0 + T61*Kh1 + T62*Kh2 + T63*Kh3 + T64*Kh4 + T65*Kh5 + T66*Kh6 + T67*Kh7 R7 = T70*Kh0 + T71*Kh1 + T72*Kh2 + T73*Kh3 + T74*Kh4 + T75*Kh5 + T76*Kh6 + T77*Kh7 F’ = R0*Kv0 + R1*Kv1 + R2*Kv2 + R3*Kv3 + R4*Kv4 + R5*Kv5 + R6*Kv6 + R7*Kv7 F_sharp = Clamp F’ to [0.0, 1.0) where:  Trc is the texel color in row r ([0..3]) and column c ([0..3]) of the 8x8 array of neighboring texel colors  F_sharp is the final output color of the sharp filter. 2.9.1.2 Smooth The following formula is used to compute the filtered texture color for the smooth filter: F_smooth = (T33 * (1-betaU) + T34 * betaU) * (1-betav) + (T43 * (1-betaU) + T44 * betaU) * betav 2.9.1.3 Adaptive Filtering The adaptive filter only supports RGB or YUV packed formats. For YUV formats, the alpha value is determined only by the Y channel (green), with this alpha value being applied to all three channels. For the RGB formats the alpha value is determined based on an average of all three channels with G having double the weight as the other channels. Each horizontal or vertical filter has 8 texels input which feeds into an eight tap filter. On the center two there is a linear blend using the betaV. Then using the Y channel an adaptive part weight is calculated Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 51 and the two filters are alpha blended. The adaptive part calculated on the Y channel is used on all three channels. Only the 8 MSBs are used in these calculations. The adaptive part is done to classify a pixel as prone to ringing or not. This is done by analyzing the 8 Y samples from the interpolation window (Wy0… Wy7). 2.10 Image Enhancement Filter and Video Signal Analysis The IEF module takes in the YUV 444 color space with 10 bit components. The IEF can be configured to operate either detail filtering or smooth filtering. A 3x3 and a 5x5 programmable filter are involved to achieve detail-enhanced or smooth effect. VSA – Video Signal Analysis – analyzes the local Y environment of each pixel and outputs several values that describe its nature (smooth, detailed, sharpening). Those values will be used by the IEF to decide how the filter should be applied at each pixel location. IEF – Image Enhancement Filter – The operations this filter performs are detail filter, smoothing and sharpening on the Y component, according to the VSA outputs. The IEF throughput is 2 pixels per clock. Block Diagram Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 52 2.10.1 Detail Filter Algorithm 2.10.1.1 VSA for Detail Filter VSA in IEF aims to analyze the local property of the content and it is achieved with the usage of Sobel edge detection. For example, below detection kernel can be used to analyze 3x3 neighborhoods. Statistics from Sobel filtering outputs are taken for setting different weights to the detail added. EM(x) = |NH9(x) * E_h| + |NH9(x) * E_v| // where the input is 10 bits, EM is 6 bits (CLIP( (|NH9(x) * E_h| + |NH9(x) * E_v|+4) >> 3 , 0 ,63)) If (EM(x) > Strong_Edge_Threshold) local_adjust = Strong_Edge_Weight // local_adjust is 3bits Else if (EM(x) > Weak_Edge_Threshold) local_adjust = Regular_Weight Else local_adjust = Non_Edge_Weight The Strong_Edge_Threshold, Weak_Edge_Threshold, Strong_Edge_Weight, Non_Edge_Weight and Regular_Weight are the pipelined state variables to be specified by driver. Strong_Edge_Threshold & Weak_Edge_Threshold are 6-bit length variables. 2.10.1.2 Detail IEF A programmable 3x3 and a 5x5 filter are provided to extract the detail information of the image. The detail extracted is the combination of the convolution results from the 3x3 and the 5x5 filter. The amount of detail added upon each pixel is determined by the weighting obtained from the VSA. 2.10.2 Skin-Tone Tuned IEF The operation of IEF can be enhanced with the skin tone detection (STD). The STD unit detects the skin- tone like colors and passes a grade of skin tone color to the IEF. The skin tone operation on the YUV space, and the detected skin tone score will be recorded as a 5-bit number as per-pixel basis. The IEF modifies the pixel value by adjusting the delta signal according to the detected skin tone score. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 53 2.10.2.1 Skin Tone Detection 2.10.2.1.1 STD - Detection in the (U,V) sub-space The STD operates on digital images in the YUV color space. In these spaces, the skin-tone region is represented by the ellipse in the (U,V) subspace (chroma components), by a trapeze membership function in the Y direction (luma component) and by a piece-wise linear classifier in the (V,Y) subspace. The detection in each sub-space outputs a likelihood score (i.e., det_UV, det_Y, and det_VY) representing how likely a pixel being a skin-tone pixel in that sub-space. Each score is represented with 5 bits, and the final skin-tone detection score SkinToneFactor is taken as the minimum of (det_UV, det_Y, det_VY). 2.10.3 Video Analytics Functions – Functional Description 2.10.3.1 Convolve The CONVOLVE instruction performs a convolution on the source matrix, using the specified kernel, and stores the result in the destination matrix. The source input can either be 8bit UINT or 16bit UINT/SINT. The floating point coefficient (i.e., each element within mentioned in Sec. 1.3.1) could be scaled up by before being loaded as the fixed point kernel for the convolve. The final result would need to be scaled down by the same amount before clamping the result to the fixed point 16 bit format. This scaling is helpful in getting more precision and hence near to accurate result of the floating point math. The scaling supported is only in powers of 2, and this could be found as follows: Assuming all coefficients will be less than the value 8. In case it is greater they would need to be scaled down such that the max value is lesser than 8 before doing the following calculation. The scale up of the resultant convolve value then would need to be done in the EUs appropriately. In case all coefficients are Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 54 less than 1/2^7, then coefficients can be upscaled by driver and later the result from the convolve operation will be down scaled by EU. If((MAX(ABS(C[i])) <= 8) && (MAX(ABS(C[i])) >= 1/2^7) Scale = Max_power_of_2(8/MAX(ABS(C[i]))) C[i] = 2^(scale) * C[i] Where the following are the functions: MAX – Is the max of all the coefficients Max_power_of_2 – Finds the Max power of 2 lower or equal to the input value. The Max_power_of_2 output cannot be greater than 512. CONVOLVE(src, kernel, scale, dest) Src - 8bit UINT/ 16bit SINT/ 16bit UINT Kernel - 16bit S3.12 Dest – 16bit SINT Scale – Range 0 to 10. The final result is shifted by this amount. Pseudo Code: // Example for kernel_widthxkernel_height below: CONVOLVE src, kernel, dest { (( real tmp = 0; for (m = 0; m < kernel_width; m++) { for (n = 0; n < kernel_height; n++) { int ii = i + m – ((kernel_width-1)>>1); int jj = j + n – ((kernel_height-1)>>1); if (ii < 0) { if(clamp) ii = 0; else ii = -ii - 1; // mirror } else if (ii > src.width - 1) { if(clamp) ii = src.width – 1; Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 55 else ii = 2*src.width - ii - 1; //mirror } if (jj < 0) { if(clamp) jj = 0; else jj = -jj - 1; // mirror } else if (jj > src.height - 1) { if(clamp) jj = src.height – 1; else jj = 2*src.height - jj - 1; //mirror } // handle matrix sizes smaller than the kernel, use null value in place of src[ii,jj] if (ii < 0 || ii > src.width - 1 || jj < 0 || jj > src.height - 1) val = 0; else val = src[jj,ii]; //Note: that the driver does the kernel flipping already and hardware does the following operation: tmp += val * kernel[n,m]; } } tmp = tmp <<1; tmp = INT(tmp) >> scale tmp = (tmp + 1)>>1; dest[i,j] = Clamp(tmp, -2^16, 2^16-1); )) } Even though the convolve is suppose to do kernel flipping, the kernel is actually flipped by driver, and the hardware does not do any kernel flipping and operates using the kernel directly. Also the kernel is always starting from (0,0) and depending on the kernel width and height the appropriate coefficients are picked from the kernel coefficient stored. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 56 2.11 Mirror pixel at boundary edges for Media (sample_8x8 messages) Presently we support only Clamp mode for sample_8x8 messages. This is to extend mirror mode as supported for 3D messages for sample_8x8 messages. The restriction here would be that the surface width is in multiples of DWords in native L1 storage format. The following are the surfaces which would need to be covered here: 1. 32bpp format in Memory and L1 (for AVS only and sample_unorm): a. 8: R10G10B10A2_UNORM b. 9: R8G8B8A8_UNORM c. 13: A8Y8U8V8_UNORM d. 14: B8G8R8A8_UNORM Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 57 2. 16bpp format in Memory and 16bpp in L1 (for AVS only and sample_unorm): a. 0: YCRCB_NORMAL b. 1: YCRCB_SWAPUVY c. 2: YCRCB_SWAPUV d. 3: YCRCB_SWAPY e. 10: R8B8_UNORM (CrCb) Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 58 3. 8bpp format in Memory and 16bpp in L1 (for AVS only): The pixel when read out from L1 would be replicated as what is shown above in the diagram for 16bpp. a. 4: PLANAR_420_8 b. 11: R8_UNORM (Cr/Cb) c. 12:Y8_UNORM 4. 64bpp format in Memory and L1 (for AVS only): 15: R16G16B16A16 This would be similar to the 32bpp except each pixel is 64bpp instead. 5. 8bpp format in Memory and L1 (for VA only): a. 5: PLANAR_Y8_UNORM Each cell in the below figure is 8bits. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 59 6. 16bpp format in Memory and L1 (for VA only): Same as the above except each cell is 16bpp. a. 7:PLANAR_Y16_UNORM b. 6 : PLANAR_Y16_SNORM 7. 1bpp format (Boolean) in Memory and 32bpp in L1(for VA only) : Will not support Mirror on this surface. Clamp will still happen on vertical direction. Clamp on horizontal direction will not be taken care of in sampler for 1bpp format, but will be done in AVS unit. a. 16: PLANAR_Y32_UNORM 2.11.1 Restriction when Mirror mode is enabled for Sample_8x8 messages When Function=AVS, ChromaKey is not supported with Mirror mode. In case ChromaKey needs to be enabled, then the Address control needs to be Clamp mode only. 2.11.1.1 For AVS For AVS scaling, the following are the restrictions on the input image size: Image Width > MAX((19*deltaU_nn + 139*ddu_nn + 7), 32) Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 60 Image Height > MAX((19*deltaV_nn + 139*ddv_nn + 7), 32) The non-normalized input co-ordinate should be in the following range: -width < (U_nn+2*deltaU_nn+3*ddu_nn) < (2*width – U – 17*deltaU_nn – 136*ddu_nn – 7) -height < (V_nn+2*deltaV_nn+3*ddv_nn) < (2*height – 17*deltaV_nn – 136*ddv_nn – 7) Where U_nn = U_normaized * width V_nn = V_normaized * height deltaU_nn = deltaU_normaized * width deltaV_nn = deltaV_normaized * height ddU_nn = ddU_normaized * width ddV_nn = ddV_normaized * height 2.11.1.2 For VA For VA message (other than AVS scaling mode) the restriction is that the minimum input image size should be 32x32. The normalized input co-ordinate should not be in the range of -1 to 2 not inclusive. 2.12 State 2.12.1 BINDING_TABLE_STATE BINDING_TABLE_STATE Default Value: 0x00000000 The binding table binds surfaces to logical resource indices used by shaders and other compute engine kernels. It is stored as an array of up to 256 elements, each of which contains one dword as defined here. The start of each element is spaced one dword apart. The first element of the binding table is aligned to a 32-byte boundary. DWord Bit Description 0 31:5 Surface State Pointer Format: SurfaceStateOffset[31:5] This 32-byte aligned address points to a surface state block. This pointer is relative to the Surface State Base Address. 4:0 Reserved Format: MBZ 2.12.2 SURFACE_STATE The surface state is stored as individual elements, each with its own pointer in the binding table. Each surface state element is aligned to a 32-byte boundary. Surface state defines the state needed for the following objects: Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 61  texture maps (1D, 2D, 3D, cube) read by the sampling engine  buffers read by the sampling engine  constant buffers read by the data cache via the data port  render targets read/written by the render cache via the data port  streamed vertex buffer output written by the render cache via the data port  media surfaces read from the texture cache or render cache via the data port  media surfaces written to the render cache via the data port 2.12.2.1 SURFACE_STATE for most messages RENDER_SURFACE_STATE Exists If: (MessageType != 'Deinterlace') && (MessageType != 'Sample_8x8') Default 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, Value: 0x00000000 This is the normal surface state used by all messages that use SURFACE_STATE except deinterlace and sample_8x8. DWord Bit Description 0 31:29 Surface Type Project: All Format: U3 enumerated type This field defines the type of the surface. Value Name Description Project 0h SURFTYPE_1D Defines a 1-dimensional map or array of maps All 1h SURFTYPE_2D Defines a 2-dimensional map or array of maps. All 2h SURFTYPE_3D Defines a 3-dimensional (volumetric) map. All 3h SURFTYPE_CUBE Defines a cube map or array of cube maps. All 4h SURFTYPE_BUFFER Defines an element in a buffer. All 5h SURFTYPE_STRBUF Defines a structured buffer surface. All 6h Reserved All 7h SURFTYPE_NULL Defines a null surface. All Programming Notes A null surface is used in instances where an actual surface is not bound. When a write message is generated to a null surface, no actual surface is written to. When a read message (including any sampling engine message) is generated to a null surface, the result is all zeros. Note that a null surface type is allowed to be used with all messages, even if it is not specificially indicated as supported. All of the remaining fields in surface state are ignored for null surfaces, with the following exceptions: Width, Height, Depth, LOD, and Render Target View Extent fields must match the depth buffer’s corresponding state for all render target surfaces, including null.All sampling engine and data port messages support null surfaces with the above behavior, even if not mentioned as specifically supported, except for the following: Data Port Media Block Read/Write messages. The Surface Type of a surface used as a render target (accessed via the Data Port’s Render Target Write message) must be the same as the Surface Type of all other render targets and of the depth buffer (defined in 3DSTATE_DEPTH_BUFFER), unless either the depth buffer or render targets are Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 62 RENDER_SURFACE_STATE SURFTYPE_NULL. 28 Surface Array Project: All Format: Enable This field, if enabled, indicates that the surface is an array. If this field is enabled, the Surface Type must be SURFTYPE_1D, SURFTYPE_2D, or SURFTYPE_CUBE. If this field is disabled and Surface Type is SURFTYPE_1D, SURFTYPE_2D, or SURFTYPE_CUBE, the Depth field must be set to zero. 27 Reserved Project: All Format: MBZ 26:18 Surface Format Project: All Format: SURFACE_FORMAT Specifies the format of the surface or element within this surface. Refer to the table in section 1.12.4.1.2 for the formats supported and their encodings. Programming Notes YUV (YCRCB) surfaces used as render targets can only be rendered to using 3DPRIM_RECTLIST with even X coordinates on all of its vertices, and the pixel shader cannot kill pixels. If Number of Multisamples is set to a value other than MULTISAMPLECOUNT_1, this field cannot be set to the following formats: any format with greater than 64 bits per element, if Number of Multisamples is MULTISAMPLECOUNT_8, any compressed texture format (BC*), and any YCRCB* format. This field cannot be a YUV (YCRCB*) format if the Surface Type is SURFTYPE_BUFFER or SURFTYPE_STRBUF. 17:16 Surface Vertical Alignment Format: U2 enumerated type Description Project For Sampling Engine Uncompressed and Render Target Surfaces: This field specifies the vertical alignment requirement for the surface. Refer to the “Memory Data Formats” chapter for details on how this field changes the layout of the surface in memory. This field applies to surface formats other than compressed formats. For other surfaces this field is ignored. A value of 1 is not supported for formats YCRCB_NORMAL (0x182), YCRCB_SWAPUVY (0x183), YCRCB_SWAPUV (0x18f), or YCRCB_SWAPY (0x190). Value Name Description 2h-3h Reserved Reserved Programming Notes Project This field is intended to be set to VALIGN_4 if the surface was rendered as a depth buffer, for a Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 63 RENDER_SURFACE_STATE multisampled (4x) render target, or for a multisampled (8x) render target, since these surfaces support only alignment of 4. Use of VALIGN_4 for other surfaces is supported, but uses more memory. This field must be set to VALIGN_4 for all tiled Y Render Target surfaces. Value of 1 is not supported for format YCRCB_NORMAL (0x182), YCRCB_SWAPUVY (0x183), YCRCB_SWAPUV (0x18f), YCRCB_SWAPY (0x190) If Number of Multisamples is not MULTISAMPLECOUNT_1, this field must be set to VALIGN_4. Errata Description Project VALIGN_4 is not supported for surface format R32G32B32_FLOAT. 15 Surface Horizontal Alignment Project: All Format: U2 enumerated type U2 enumerated type For Sampling Engine Uncompressed and Render Target Surfaces: This field specifies the horizontal alignment requirement for the surface. Refer to the “Memory Data Formats” chapter for details on how this field changes the layout of the surface in memory. This field applies to surface formats other than compressed formats. For other surfaces, this field is ignored. Value Name Description Project 0h HALIGN_4 Horizontal alignment factor j = 4 All 1h HALIGN_8 Horizontal alignment factor j = 8 All Programming Notes This field is intended to be set to HALIGN_8 only if the surface was rendered as a depth buffer with Z16 format or a stencil buffer, since these surfaces support only alignment of 8. Use of HALIGN_8 for other surfaces is supported, but uses more memory. This field must be set to HALIGN_4 if the Surface Format is BC*. This field must be set to HALIGN_8 if the Surface Format is FXT1. 14 Tiled Surface Project: All Format: U1 enumerated type This field specifies whether the surface is tiled. Value Name Description Project 0h FALSE Linear surface All 1h TRUE Tiled surface All Programming Notes Linear surfaces can be mapped to Main Memory (uncached) or System Memory (cacheable, snooped). Tiled surfaces can only be mapped to Main Memory. The corresponding cache(s) Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 64 RENDER_SURFACE_STATE must be invalidated before a previously accessed surface is accessed again with an altered state of this bit. If Surface Type is SURFTYPE_BUFFER, this field must be FALSE (because buffers are supported only in linear memory). If Surface Type is SURFTYPE_NULL, this field must be TRUE. 13 Tile Walk Project: All Format: U2 enumerated type This field specifies the type of memory tiling (XMajor or YMajor) used to tile this surface. See Memory Interface Functions for details on memory tiling and restrictions. Value Name Description Project 0b TILEWALK_XMAJOR X major tiling. All 1b TILEWALK_YMAJOR Y major tiling. All Programming Notes Refer to Memory Data Formats for restrictions on TileWalk direction for the various buffer types. (Of particular interest is the fact that YMAJOR tiling is not supported for display/overlay buffers). The corresponding caches must be invalidated before a previously accessed surface is accessed again with an altered state of this bit.This field is ignored when the surface is linear. Errata Description Project Set Tile Walk to TILEWALK_XMAJOR if Tiled Surface is False. 12 Vertical Line Stride Project: All Format: U1 in lines to skip between logically adjacent lines For 2D non-array surfaces accessed via the Sampling Engine or Data Port: Specifies the number of lines (0 or 1) to skip between logically adjacent lines and supports interleaved (field) surfaces as textures. For other surfaces, Vertical Line Stride must be zero. Programming Notes This bit must not be set if the surface format is a compressed type (BCn*). If this bit is set on a sampling engine surface, the mip mode filter must be set to MIPFILTER_NONE. 11 Vertical Line Stride Offset Project: All Format: U1 in lines of initial offset (when Vertical Line Stride == 1) For 2D non-array Surfaces accessed via the Sampling Engine or Data Port: Specifies the offset of the initial line from the beginning of the buffer. Ignored when Vertical Line Stride is 0. For other surfaces, Vertical Line Stride Offset must be zero. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 65 RENDER_SURFACE_STATE 10 Surface Array Spacing Project: All Format: U1 enumerated type For 1D Array, 2D Array, Cube, and 2D Multisampled Surfaces: This field specifies whether space is reserved between array slices for additional LODs beyond LOD 0. Refer to the “Memory Data Formats” chapter for details on how this field changes the QPitch equation used to determine spacing between array slices in memory. For other surfaces, this field is ignored. Value Name Description Project 0h ARYSPC_FULL Memory space between array slices is reserved for all possible All LOD’s. 1h ARYSPC_LOD0 Memory space is optimized for surfaces which contain only LOD All 0. Programming Notes If Multisampled Surface Storage Format is MSFMT_MSS and Number of Multisamples is not MULTISAMPLECOUNT_1, this field must be set to ARYSPC_LOD0. 9 Reserved Project: All Format: MBZ 8 Render Cache Read Write Mode Project: All Format: U1 enumerated type For Surfaces accessed via the Data Port to Render Cache: This field specifies the way Render Cache treats a write request. If clear, Render Cache allocates a write-only cache line for a write miss. If set, Render Cache allocates a read-write cache line for a write miss. For Surfaces accessed via the Sampling Engine or Data Port to Texture Cache or Data Cache: This field is reserved and MBZ. Value Name Description Project 0h Allocating write-only cache for a write miss All 1h Allocating read-write cache for a write miss All Programming Notes This field is provided for performance optimization for Render Cache read/write accesses (from EU’s point of view). 7:6 Media Boundary Pixel Mode Project: All Format: U2 enumerated type For 2D Non-Array Surfaces accessed via the Data Port Media Block Read Message: This field enables control of which rows are returned on vertical out-of-bounds reads using the Data Port Media Block Read Message. In the description below, frame mode refers to Vertical Line Stride = 0, field mode is Vertical Line Stride = 1 in which only the even or odd rows are addressable. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 66 RENDER_SURFACE_STATE The frame refers to the entire surface, while the field refers only to the even or odd rows within the surface. For other surfaces this field is reserved and MBZ. Value Name Description Project 0h NORMAL_MODE the row returned on an out-of-bound access is the All closest row in the frame or field. Rows from the opposite field are never returned. 1h Reserved All 2h PROGRESSIVE_FRAME the row returned on an out-of-bound access is the All closest row in the frame, even if in field mode. 3h INTERLACED_FRAME In field mode, the row returned on an out-of-bound All access is the closest row in the field. In frame mode, even out-of-bound rows return the nearest even row while odd out-of-bound rows return the nearest odd row. 5:0 Cube Face Enables Project: All Format: U6 bit mask of enables For SURFTYPE_CUBE Surfaces accessed via the Sampling Engine: Bits 5:0 of this field enable the individual faces of a cube map. Enabling a face indicates that the face is present in the cube map, while disabling it indicates that that face is represented by the texture map’s border color. Refer to Memory Data Formats for the correlation between faces and the cube map memory layout. Note that storage for disabled faces must be provided. For other surfaces this field is reserved and MBZ. Value Name 1xxxxxb -X face x1xxxxb +X face xx1xxxb -Y face xxx1xxb +Y face xxxx1xb -Z face xxxxx1b +Z face Programming Notes When TEXCOORDMODE_CLAMP is used when accessing a cube map, this field must be programmed to 111111b (all faces enabled). This field is ignored unless the Surface Type is SURFTYPE_CUBE. 1 31:0 Surface Base Address Project: All Format: GraphicsAddress[31:0] Specifies the byte-aligned base address of the surface. Programming Notes  For SURFTYPE_BUFFER render targets, this field specifies the base address of first element of the surface. The surface is interpreted as a simple array of that single element type. The address must be naturally-aligned to the element size (e.g., a buffer containing R32G32B32A32_FLOAT elements must be 16-byte aligned)  For SURFTYPE_BUFFER non-rendertarget surfaces, this field specifies the base address of the first element of the surface, computed in software by adding the surface base address to Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 67 RENDER_SURFACE_STATE the byte offset of the element in the buffer.  Mipmapped, cube and 3D sampling engine surfaces are stored in a "monolithic" (fixed) format, and only require a single address for the base texture.  The Base Address for linear render target surfaces and surfaces accessed with the typed surface read/write data port messages must be element-size aligned, for non-YUV surface formats, or a multiple of 2 element-sizes for YUV surface formats. Other linear surfaces have no alignment requirements (byte alignment is sufficient).  Linear depth buffer surface base addresses must be 64-byte aligned. Note that while render targets (color) can be SURFTYPE_BUFFER, depth buffers cannot.  Tiled surface base addresses must be 4KB-aligned. Note that only the offsets from Surface Base Address are tiled, Surface Base Address itself is not transformed using the tiling algorithm.  For tiled surfaces, the actual start of the surface can be offset from the Surface Base Address by the X Offset and Y Offset fields.  Certain message types used to access surfaces have more stringent alignment requirements. Please refer to the specific message documentation for additional restrictions. 31:30 Reserved 2 Project: All Format: MBZ 29:16 Height Project: All Format: U14 This field specifies the height of the surface. If the surface is MIP-mapped, this field contains the height of the base MIP level. For buffers, this field specifies a portion of the buffer size. Value Name Description 0 SURFTYPE_1D: must be zero [0,16383] SURFTYPE_2D: height of surface – 1 (y/v dimension) [0,2047] SURFTYPE_3D: height of surface – 1 (y/v dimension) [0,16383] SURFTYPE_CUBE: height of surface – 1 (y/v dimension) [0,16383] SURFTYPE_BUFFER/STRBUF: contains bits [20:7] of the number of entries in the buffer – 1 Programming Notes For typed buffer and structured buffer surfaces, the number of entries in the buffer ranges from 1 to 227. For raw buffer surfaces, the number of entries in the buffer is the number of bytes which can range from 1 to 230. After subtracting one from the number of entries, software must place the fields of the resulting 27-bit value into the Height, Width, and Depth fields as indicated, right-justified in each field. Unused upper bits must be set to zero.If Vertical Line Stride is 1, this field indicates the height of the field, not the height of the frameThe Height of a render target must be the same as the Height of the other render targets and the depth buffer (defined in 3DSTATE_DEPTH_BUFFER), unless Surface Type is SURFTYPE_1D or SURFTYPE_2D with Depth = 0 (non-array) and LOD = 0 (non-mip mapped). Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 68 RENDER_SURFACE_STATE If this surface in memory is accessed with Vertical Line Stride set to both 0 and 1, this field must be an even value when Vertical Line Stride is 0. If Media Pixel Boundary Mode is not set to NORMAL_MODE, this field must be an even value. 15:14 Reserved Project: All Format: MBZ 13:0 Width Project: All Format: U14-1 This field specifies the width of the surface. If the surface is MIP-mapped, this field specifies the width of the base MIP level. The width is specified in units of pixels or texels. For buffers, this field specifies a portion of the buffer size. For surfaces accessed with the Media Block Read/Write message, this field is in units of DWords except when used for IECP and the output surface format is NV12 (R16_UNORM), this field is in units of Words. Value Name Description [0, SURFTYPE_1D: width of surface – 1 (x/u dimension) 16383] [0, SURFTYPE_2D: width of surface – 1 (x/u dimension) 16383] [0, 2047] SURFTYPE_3D: width of surface – 1 (x/u dimension) [0, SURFTYPE_CUBE: width of surface – 1 (x/u dimension) 16383] [0, 127] SURFTYPE_BUFFER/STRBUF: contains bits [6:0] of the number of entries in the buffer – 1 Programming Notes For surface types other than SURFTYPE_BUFFER or STRBUF The Width specified by this field must be less than or equal to the surface pitch (specified in bytes viathe Surface Pitch field).For cube maps, Width must be set equal to the Height.For MONO8 textures, Width must be a multiple of 32 texels.The Width of a render target must be the same as the Width of the other render target(s) and the depth buffer (defined in 3DSTATE_DEPTH_BUFFER), unless Surface Type is SURFTYPE_1D or SURFTYPE_2D with Depth = 0 (non-array) and LOD = 0 (non-mip mapped).The Width of a render target with YUV surface format must be a multiple of 2.For SURFTYPE_BUFFER: The low two bits of this field must be 11 if the Surface Format is RAW (the size of the buffer must be a multiple of 4 bytes). 3 31:21 Depth Project: All Format: U11 This field specifies the total number of levels for a volume texture or the number of array elements allowed to be accessed starting at the Minimum Array Element for arrayed surfaces. If the volume texture is MIP-mapped, this field specifies the depth of the base MIP level. For buffers, this field specifies a portion of the buffer size. Value Name Description [0,2047] SURFTYPE_1D: number of array elements – 1 [0,2047] SURFTYPE_2D: number of array elements – 1 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 69 RENDER_SURFACE_STATE [0,2047] SURFTYPE_3D: depth of surface – 1 (z/r dimension) [0,2047] SURFTYPE_CUBE: number of array elements – 1 [see programming notes for range] [0,1023] SURFTYPE_BUFFER: contains bits [30:21] of the number of entries in the buffer – 1 for Surface Format RAW. [0,127] SURFTYPE_BUFFER: Contains bits [27:21] of the number of entries in the buffer – 1 for other surface formats. [0,63] SURFTYPE_STRBUF: contains bits [26:21] of the number of entries in the buffer – 1 Programming Notes The Depth of a render target must be the same as the Depth of the other render target(s) and of the depth buffer (defined in 3DSTATE_DEPTH_BUFFER).For SURFTYPE_CUBE:For Sampling Engine Surfaces, the range of this field is [0,340], indicating the number of cube array elements (equal to the number of underlying 2D array elements divided by 6). For other surfaces, this field must be zero.For SURFTYPE_BUFFER: The range of this field is [0,63] unless the Surface Format is RAW and Surface Ptich is 1 byte. Errata Description Project Errata: For SURFTYPE_CUBE sampling engine surfaces, the range of this field is limited to [0,85]. Errata: If Surface Array is enabled, and Depth is between 1024 and 2047, an incorrect array slice may be accessed if the requested array index in the message is greater than or equal to 4096. 20:18 Reserved Format: MBZ 17:0 Surface Pitch Project: All Format: U18 pitch in (#Bytes – 1) This field specifies the surface pitch in (#Bytes - 1).For surfaces of type SURFTYPE_BUFFER and SURFTYPE_STRBUF, this field indicates the size of the structure. Value Name Description [0,2047] For surfaces of type SURFTYPE_BUFFER: representing [1B, 2048B] [0,2047] For surfaces of type SURFTYPE_STRBUF: representing [1B, 2048B] [0,262143] For other linear surfaces: representing [1B, 256KB] [511,262143] For X-tiled surface: representing [512B, 256KB] = [1 tile, 512 tiles] [127,262143] For Y-tiled surfaces: representing [128B, 256KB] = [1 tile, 2048 tiles] Programming Notes For linear render target surfaces and surfaces accessed with the typed data port messages, the pitch must be a multiple of the element size for non-YUV surface formats. Pitch must be a multiple of 2 * element size for YUV surface formats. For linear surfaces with Surface Type of SURFTYPE_STRBUF, the pitch must be a multiple of 4 bytes.For other linear surfaces, the pitch can be any multiple of bytes.For tiled surfaces, the pitch must be a multiple of the tile width. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 70 RENDER_SURFACE_STATE Errata Description Project Maximum pitch supported is 128KB for all surfaces 4 31 Reserved Project: All Exists If: [Surface Type] != SURFTYPE_STRBUF Format: MBZ 30:29 Render Target Rotation Project: All Exists If: [Surface Type] != SURFTYPE_STRBUF Format: U2 enumerated type For Render Target Surfaces: This field specifies the rotation of this render target surface when being written to memory.For Other Surfaces:This field is ignored. Value Name Description Project 0h RTROTATE_0DEG No rotation (0 degrees) All 1h RTROTATE_90DEG Rotate by 90 degrees All 2h Reserved All 3h RTROTATE_270DEG Rotate by 270 degrees All Programming Notes Rotation is not supported for render targets of any type other than simple, non-mip-mapped, non-array 2D surfaces. The surface must be using tiled with X major.Width and Height fields apply to the dimensions of the surface before rotation.For 90 and 270 degree rotated surfaces, the Height (rather than the Width) must be less than or equal to the Surface Pitch (specified in bytes).For 90 and 270 degree rotated surfaces, the actual Height and Width of the surface in pixels (not the field value which is decremented) must both be even.Rotation is supported only for surfaces with the following surface formats: B5G6R5_UNORM, B5G6R5_UNORM_SRGB, R8G8B8[A|X]8_UNORM, R8G8B8[A|X]8_UNORM_SRGB, B8G8R8[A|X]8_UNORM, B8G8R8[A|X]8_UNORM_SRGB, B10G10R10[A|X]2_UNORM, B10G10R10A2_UNORM_SRGB, R10G10B10A2_UNORM, R10G10B10A2_UNORM_SRGB, R16G16B16A16_FLOAT, R16G16B16X16_FLOAT.Rotation is not supported for typed UAV messages 31:27 Reserved Project: All Exists If: [Surface Type] == SURFTYPE_STRBUF Format: MBZ 28:18 Minimum Array Element Project: All Exists If: [Surface Type] != SURFTYPE_STRBUF Format: U11 For Sampling Engine, Render Target, and Typed 1D and 2D Surfaces:This field indicates the minimum array element that can be accessed as part of this surface. This field is added to the delivered array index before it is used to address the surface.For Render Target 3D Surfaces:This field indicates the minimum ‘R’ coordinate on the LOD currently being rendered to. This field is added to the delivered array index before it is used to address the surface.For Sampling Engine Cube Surfaces:This field indicates the minimum array element in the Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 71 RENDER_SURFACE_STATE underlying 2D surface array that can be accessed as part of this surface (the cube array index is multipled by 6 to compute this value, although this field is not restricted to only multiples of 6). This field is added to the delivered array index before it is used to address the surface. For Other Surfaces:This field must be set to zero. Value Name Description [0,2047] 1D/2D/cube surfaces [0,2047] 3D surfaces Errata Description Project If Number of Multisamples is not MULTISAMPLECOUNT_1, this field must be set to zero if this surface is used with sampling engine messages. 17:7 Render Target View Extent Project: All Exists If: [Surface Type] != SURFTYPE_STRBUF Format: U11 For Render Target 3D Surfaces:This field indicates the extent of the accessible ‘R’ coordinates minus 1 on the LOD currently being rendered to.For Render Target 1D and 2D Surfaces:This field must be set to the same value as the Depth field.For Other Surfaces:This field is ignored. Value Name Description [0,2047] to indicate extent of [1,2048] 6 Multisampled Surface Storage Format Project: All Exists If: [Surface Type] != SURFTYPE_STRBUF Format: U1 enumerated type This field indicates the storage format of the multisampled surface. Value Name Description Project 0h MSFMT_MSS Multsampled surface was/is rendered as a render All target 1h MSFMT_DEPTH_STENCIL Multisampled surface was rendered as a depth or All stencil buffer Programming Notes All multisampled render target surfaces must have this field set to MSFMT_MSSIF this field is MSFMT_DEPTH_STENCIL, the only sampling engine messages allowed are “ld2dms”, “resinfo”, and “sampleinfo”. This field is ignored if Number of Multisamples is MULTISAMPLECOUNT_1 Errata Description Project If the surface’s Number of Multisamples is MULTISAMPLECOUNT_8, Width is >= 8192 (meaning the actual surface width is >= 8193 pixels), this field must be set to MSFMT_MSS. If the surface’s Number of Multisamples is MULTISAMPLECOUNT_8, ((Depth+1) * (Height+1)) is > 4,194,304, OR if the surface’s Number of Multisamples is MULTISAMPLECOUNT_4, ((Depth+1) * (Height+1)) is > 8,388,608, this field must be set to MSFMT_DEPTH_STENCIL.This field must be set to MSFMT_DEPTH_STENCIL if Surface Format is one of the following: Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 72 RENDER_SURFACE_STATE I24X8_UNORM, L24X8_UNORM, A24X8_UNORM, or R24_UNORM_X8_TYPELESS. 5:3 Number of Multisamples Project: All Exists If: [Surface Type] != SURFTYPE_STRBUF Format: U3 enumerated type This field indicates the number of multisamples on the surface. Value Name Project 0h MULTISAMPLECOUNT_1 All 1h Reserved All 2h MULTISAMPLECOUNT_4 All 3h MULTISAMPLECOUNT_8 All 4h-7h Reserved All Programming Notes If this field is any value other than MULTISAMPLECOUNT_1, the Surface Type must be SURFTYPE_2D This field must be set to MULTISAMPLECOUNT_1 unless the surface is a Sampling Engine surface or Render Target surface. This field must be set to MULTISAMPLECOUNT_1 for SINT MSRTs when all RT channels are not written If this field is any value other than MULTISAMPLECOUNT_1, Surface Min LOD, Mip Count / LOD, and Resource Min LOD must be set to zero 26:0 Minimum Array Element Project: All Exists If: [Surface Type] == SURFTYPE_STRBUF This field indicates the minimum array element that can be accessed as part of this surface. This field is added to the delivered array index before it is used to address the surface. Value Name [0,226] 2:0 Multisample Position Palette Index Exists If: [Surface Type] != SURFTYPE_STRBUF Format: U3 This field indicates the index into the sample position palette that the multisampled surface is using. This field is only used as a return value for the sampleinfo message, and is otherwise not used by hardware. Value Name [0,7] 5 31:25 X Offset Project: All Format: PixelOffset[8:2] This field specifies the horizontal offset in pixels from the Surface Base Address to the start (origin) of the surface. This field effectively loosens the alignment restrictions on the origin of tiled surfaces. Previously, tiled surface origin was (by definition) located at the base address, and thus needed to satisfy the 4KB base address alignment restriction. Now the origin can be specified at a finer (4-wide x 2-high pixel) resolution. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 73 RENDER_SURFACE_STATE Value Name Description [0,508] in multiples of 4 (low 2 bits missing) Programming Notes For linear surfaces, this field must be zero. For surfaces accessed with the Data Port Media Block Read/Write message, the pixel size is assumed to be 32 bits in width. For Surface Format with other than 8, 16, 32, 64, or 128 bits per pixel, this field must be zero. If Render Target Rotation is set to other than RTROTATE_0DEG, this field must be zero. If Surface Type is SURFTYPE_STRBUF, this field must be zero. This field must be zero if Surface Format is PLANAR*. For all other surfaces, Xoffset must be programmed such that (max X of the draw rectangle)+Xoffset < 16K (max surface width) For YUV422 surfaces, the pixel offset is in multiples of 2. Pixel offset specified in this case is PixelOffset[7:1] 24 Reserved Project: All Format: MBZ 23:20 Y Offset Project: All Format: RowOffset[4:1] This field specifies the vertical offset in rows from the Surface Base Address to the start of the surface. (See additional description in the X Offset field) Value Name Description [0,30] in multiples of 2 (low bit missing) Programming Notes For linear surfaces, this field must be zero. For render targets in which the Render Target Array Index is not zero, this field must be zero. For Surface Format with other than 8, 16, 32, 64, or 128 bits per pixel, this field must be zero. If Render Target Rotation is set to other than RTROTATE_0DEG, this field must be zero. For surfaces accessed in field mode (Vertical Line Stride = 1 or equivalent Media Block Read/Write message override), this field must be set to a multiple of 4. If Surface Type is SURFTYPE_STRBUF, this field must be zero. This field must be zero if Surface Format is PLANAR*. For all other surfaces, Yoffset must be programmed such that (Maximum Yof draw rectangle) + Yoffset < 16K (max surface height) 19:16 Surface Object Control State Project: All Format: MEMORY_OBJECT_CONTROL_STATE Specifies the memory object control state for this surface. 15:14 Reserved Format: MBZ 13:8 Reserved Project: All Format: MBZ 7:4 Surface Min LOD Project: All Format: U4 in LOD units Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 74 RENDER_SURFACE_STATE For Sampling Engine and Typed Surfaces:This field indicates the most detailed LOD that can be accessed as part of this surface. This field is added to the delivered LOD (sample_l, ld, or resinfo message types) before it is used to address the surface.For Other Surfaces:This field is ignored. Value Name [0,14] Programming Notes This field must be zero if the Surface Format is MONO8 3:0 MIP Count / LOD Project: All Format: Sampling Engine and Typed Surfaces: U4 in (LOD units – 1)Render Target Surfaces: U4 in LOD units For Sampling Engine and Typed Surfaces:This field indicates the number of MIP levels allowed to be accessed starting at Surface Min LOD, which must be less than or equal to the number of MIP levels actually stored in memory for this surface. Force the mip map access to be between the mipmap specified by the integer bits of the Min LOD and the ceiling of the value specified here.For Render Target Surfaces:This field defines the MIP level that is currently being rendered into. This is the absolute MIP level on the surface and is not relative to the Surface Min LOD field, which is ignored for render target surfaces.For Other Surfaces:This field is reserved : MBZ Value Name Description Project [0,14] Sampling Engine and Typed Surfaces: representing [1,15] MIP levels [0,14] Render Target Surfaces: representing LOD 0 Other Surfaces 0h Disable All 1h Enable All Programming Notes The LOD of a render target must be the same as the LOD of the other render target(s) and of the depth buffer (defined in 3DSTATE_DEPTH_BUFFER). For render targets with YUV surface formats, the LOD must be zero. It is not legal to have more than one 1x1 mipmap. Software must ensure that MIP Count is set to end on the first 1x1 mipmap (or before). 6 31:30 Reserved: MBZ Project: All This DW6 Exists If: [Surface Format] == PLANAR appllies only if Format: MBZ Surface 29:16 X Offset for UV Plane Format is not Exists If: [Surface Format] == PLANAR PLANAR* Format: U14 Row Offset This field specifies the horizontal offset in pixels from the Surface Base Address to the start Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 75 RENDER_SURFACE_STATE (origin) of the interleaved UV plane. This field is only used for PLANAR surface formats. Programming Notes This field must indicate an even number of pixels. 15:14 Reserved Project: All Exists If: [Surface Format] == PLANAR Format: MBZ 31:12 MCS Base Address Project: All Exists If: ([Surface Format] != 'PLANAR') && ([MCS Enable] == 'Enabled') Format: GraphicsAddress[31:12] Specifies the 4kbyte-aligned base address of the MCS surface associated with the MSS surface specified in other 32 fields. Programming Notes The MCS surface must be stored as Tile Y. The MCS surface shares Height, Width, Depth, Surface Min LOD, MIP Count / LOD, Surface Object Control State, Surface Array Spacing, and Minimum Array Element with the primary surface. 31:6 Append Counter Address Project: All Exists If: ([Surface Format] != 'PLANAR') && ([MCS Enable] == 'Disabled') Format: GraphicsAddress[31:6] Specifies the 64byte-aligned base address of the Append counter associated with this surface specified in other SURFACE_STATE fields. 11:3 MCS Surface Pitch Project: All Exists If: ([Surface Format] != 'PLANAR') && ([MCS Enable] == 'Enabled') Format: U9-1 pitch in #Tiles This field specifies the MCS surface pitch in (#Tiles – 1). Value Name Description [0,511] representing [1 tile, 512 tiles] 5:2 Reserved Project: All Exists If: ([Surface Format] != 'PLANAR') && ([MCS Enable] == 'Disabled') Format: MBZ 2:1 Reserved Project: All Exists If: ([Surface Format] != 'PLANAR') && ([MCS Enable] == 'Enabled') Format: MBZ 1 Append Counter Enable Project: All Exists If: ([Surface Format] != 'PLANAR') && ([MCS Enable] == 'Disabled') Format: Enable Enables the use of the Append Counter with this surface. If disabled, all other Append counter fields are ignored. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 76 RENDER_SURFACE_STATE 13:0 Y Offset for UV Plane Exists If: [Surface Format] == PLANAR Format: 14 Row Offset This field specifies the vertical offset in rows from the Surface Base Address to the start (origin) of the interleaved UV plane. This field is only used for PLANAR surface formats. Programming Notes This field must indicate an even number (bit 0 = 0). 0 MCS Enable Project: All Format: Enable Enables the use of the MCS with this surface. If disabled, all other MCS fields are ignored. For Render Target and Sampling Engine Surfaces:If the surface is multisampled (Number of Multisamples any value other than MULTISAMPLECOUNT_1), this field must be enabled. For Other Surfaces:This field and the other MCS fields are ignored. Programming Notes When accessing a multisampled surface using the sampling engine, the MCS surface is read in a separate pass and is considered by hardware to be an independent surface. This same bitfield is used when MCS is enabled; also when disabled. Errata Description Project If this field is disabled and the sampling engine ld_mcs message is issued on this surface, the MCS surface may be accessed. Software must ensure that the surface is defined to avoid GTT errors. This same bitfield is used when MCS is enabled; also when disabled. This field must be set to 0 for all SINT MSRTs when all RT channels are not written When ld2dms from MCS on a subspan that some of the pixel on the pixel are not valid, can lead to data corruption. 7 31 Red Clear Color Format: U1 enumerated type For Sampling Engine Multisampled Surfaces and Render Targets:Specifies the clear value for the red channel.For Other Surfaces:This field is ignored. Value Name Description Project 0 CC_ZERO Clear color value is 0.0, correctly interpreted based on surface format. All 1 CC_ONE Clear color value is 1.0, correctly interpreted based on surface format. All 30 Green Clear Color Format: U1 enumerated type For Sampling Engine Multisampled Surfaces and Render Targets:Specifies the clear value for the green channel.For Other Surfaces:This field is ignored. Value Name Description Project Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 77 RENDER_SURFACE_STATE 0 CC_ZERO Clear color value is 0.0, correctly interpreted based on surface format. All 1 CC_ONE Clear color value is 1.0, correctly interpreted based on surface format. All 29 Blue Clear Color Format: U1 enumerated type For Sampling Engine Multisampled Surfaces and Render Targets:Specifies the clear value for the blue channel.For Other Surfaces:This field is ignored. Value Name Description Project 0 CC_ZERO Clear color value is 0.0, correctly interpreted based on surface format. All 1 CC_ONE Clear color value is 1.0, correctly interpreted based on surface format. All 28 Alpha Clear Color Format: U1 enumerated type For Sampling Engine Multisampled Surfaces and Render Targets:Specifies the clear value for the alpha channel.For Other Surfaces:This field is ignored. Value Name Description Project 0 CC_ZERO Clear color value is 0.0, correctly interpreted based on surface format. All 1 CC_ONE Clear color value is 1.0, correctly interpreted based on surface format. All 15:12 Reserved Project: All Format: MBZ 11:0 Resource Min LOD Project: All Format: U4.8 in LOD units For Sampling Engine Surfaces:This field indicates the most detailed LOD that is present in the resource underlying the surface. Refer to the “LOD Computation Pseudocode” section for the use of this field.For Other Surfaces:This field is ignored. Value Name [0,14] Programming Notes This field must be zero if the Surface Format is MONO8 This field must be zero if the ChromaKey Enable is enabled in the associated sampler. 2.12.2.1.1 Surface Formats The following table is used ONLY when ASTC_ENABLE is set to 0, which indicates the supported surface formats and the 9-bit encoding for each. Note that some of these formats are used not only by the Sampling Engine, but also by the Data Port and the Vertex Fetch unit. When ASTC_ENABLE is set to 1, please refer to SURFACE_STATE table on the surface format value and description. The name for all the ASTC texture format is ASTC. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 78 SURFACE_FORMAT Project: All Size (in bits): 9 The following table indicates the supported surface formats and the 9-bit encoding for each. Note that some of these formats are used not only by the Sampling Engine, but also by the Data Port and the Vertex Fetch unit. Bits Per Element Value Name (BPE) Description 000h R32G32B32A32_FLOAT 128 001h R32G32B32A32_SINT 128 002h R32G32B32A32_UINT 128 003h R32G32B32A32_UNORM 128 004h R32G32B32A32_SNORM 128 005h R64G64_FLOAT 128 006h R32G32B32X32_FLOAT 128 007h R32G32B32A32_SSCALED 128 008h R32G32B32A32_USCALED 128 020h R32G32B32A32_SFIXED 128 021h R64G64_PASSTHRU 128 040h R32G32B32_FLOAT 96 041h R32G32B32_SINT 96 042h R32G32B32_UINT 96 043h R32G32B32_UNORM 96 044h R32G32B32_SNORM 96 045h R32G32B32_SSCALED 96 046h R32G32B32_USCALED 96 050h R32G32B32_SFIXED 96 080h R16G16B16A16_UNORM 64 081h R16G16B16A16_SNORM 64 082h R16G16B16A16_SINT 64 083h R16G16B16A16_UINT 64 084h R16G16B16A16_FLOAT 64 085h R32G32_FLOAT 64 086h R32G32_SINT 64 087h R32G32_UINT 64 088h R32_FLOAT_X8X24_TYPELESS 64 089h X32_TYPELESS_G8X24_UINT 64 08Ah L32A32_FLOAT 64 08Bh R32G32_UNORM 64 08Ch R32G32_SNORM 64 08Dh R64_FLOAT 64 08Eh R16G16B16X16_UNORM 64 08Fh R16G16B16X16_FLOAT 64 090h A32X32_FLOAT 64 091h L32X32_FLOAT 64 092h I32X32_FLOAT 64 093h R16G16B16A16_SSCALED 64 094h R16G16B16A16_USCALED 64 095h R32G32_SSCALED 64 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 79 SURFACE_FORMAT 096h R32G32_USCALED 64 0A0h R32G32_SFIXED 64 0A1h R64_PASSTHRU 64 0C0h B8G8R8A8_UNORM 32 0C1h B8G8R8A8_UNORM_SRGB 32 0C2h R10G10B10A2_UNORM 32 0C3h R10G10B10A2_UNORM_SRGB 32 0C4h R10G10B10A2_UINT 32 0C5h R10G10B10_SNORM_A2_UNORM 32 0C7h R8G8B8A8_UNORM 32 0C8h R8G8B8A8_UNORM_SRGB 32 0C9h R8G8B8A8_SNORM 32 0CAh R8G8B8A8_SINT 32 0CBh R8G8B8A8_UINT 32 0CCh R16G16_UNORM 32 0CDh R16G16_SNORM 32 0CEh R16G16_SINT 32 0CFh R16G16_UINT 32 0D0h R16G16_FLOAT 32 0D1h B10G10R10A2_UNORM 32 0D2h B10G10R10A2_UNORM_SRGB 32 0D3h R11G11B10_FLOAT 32 0D6h R32_SINT 32 0D7h R32_UINT 32 0D8h R32_FLOAT 32 0D9h R24_UNORM_X8_TYPELESS 32 0DAh X24_TYPELESS_G8_UINT 32 0DDh L32_UNORM 32 0DEh A32_UNORM 32 0DFh L16A16_UNORM 32 0E0h I24X8_UNORM 32 0E1h L24X8_UNORM 32 0E2h A24X8_UNORM 32 0E3h I32_FLOAT 32 0E4h L32_FLOAT 32 0E5h A32_FLOAT 32 0E6h X8B8_UNORM_G8R8_SNORM 32 0E7h A8X8_UNORM_G8R8_SNORM 32 0E8h B8X8_UNORM_G8R8_SNORM 32 0E9h B8G8R8X8_UNORM 32 0EAh B8G8R8X8_UNORM_SRGB 32 0EBh R8G8B8X8_UNORM 32 0ECh R8G8B8X8_UNORM_SRGB 32 0EDh R9G9B9E5_SHAREDEXP 32 0EEh B10G10R10X2_UNORM 32 0F0h L16A16_FLOAT 32 0F1h R32_UNORM 32 0F2h R32_SNORM 32 0F3h R10G10B10X2_USCALED 32 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 80 SURFACE_FORMAT 0F4h R8G8B8A8_SSCALED 32 0F5h R8G8B8A8_USCALED 32 0F6h R16G16_SSCALED 32 0F7h R16G16_USCALED 32 0F8h R32_SSCALED 32 0F9h R32_USCALED 32 100h B5G6R5_UNORM 16 101h B5G6R5_UNORM_SRGB 16 102h B5G5R5A1_UNORM 16 103h B5G5R5A1_UNORM_SRGB 16 104h B4G4R4A4_UNORM 16 105h B4G4R4A4_UNORM_SRGB 16 106h R8G8_UNORM 16 107h R8G8_SNORM 16 108h R8G8_SINT 16 109h R8G8_UINT 16 10Ah R16_UNORM 16 10Bh R16_SNORM 16 10Ch R16_SINT 16 10Dh R16_UINT 16 10Eh R16_FLOAT 16 10Fh A8P8_UNORM_PALETTE0 16 110h A8P8_UNORM_PALETTE1 16 111h I16_UNORM 16 112h L16_UNORM 16 113h A16_UNORM 16 114h L8A8_UNORM 16 115h I16_FLOAT 16 116h L16_FLOAT 16 117h A16_FLOAT 16 118h L8A8_UNORM_SRGB 16 119h R5G5_SNORM_B6_UNORM 16 11Ah B5G5R5X1_UNORM 16 11Bh B5G5R5X1_UNORM_SRGB 16 11Ch R8G8_SSCALED 16 11Dh R8G8_USCALED 16 11Eh R16_SSCALED 16 11Fh R16_USCALED 16 122h P8A8_UNORM_PALETTE0 16 123h P8A8_UNORM_PALETTE1 16 124h A1B5G5R5_UNORM 16 125h A4B4G4R4_UNORM 16 126h L8A8_UINT 16 127h L8A8_SINT 16 140h R8_UNORM 8 141h R8_SNORM 8 142h R8_SINT 8 143h R8_UINT 8 144h A8_UNORM 8 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 81 SURFACE_FORMAT 145h I8_UNORM 8 146h L8_UNORM 8 147h P4A4_UNORM_PALETTE0 8 148h A4P4_UNORM_PALETTE0 8 149h R8_SSCALED 8 14Ah R8_USCALED 8 14Bh P8_UNORM_PALETTE0 8 14Ch L8_UNORM_SRGB 8 14Dh P8_UNORM_PALETTE1 8 14Eh P4A4_UNORM_PALETTE1 8 14Fh A4P4_UNORM_PALETTE1 8 150h Y8_UNORM 8 152h L8_UINT 8 153h L8_SINT 8 154h I8_UINT 8 155h I8_SINT 8 180h DXT1_RGB_SRGB 0 181h R1_UNORM 1 182h YCRCB_NORMAL 0 183h YCRCB_SWAPUVY 0 184h P2_UNORM_PALETTE0 2 185h P2_UNORM_PALETTE1 2 186h BC1_UNORM 0 (DXT1) 187h BC2_UNORM 0 (DXT2/3) 188h BC3_UNORM 0 (DXT4/5) 189h BC4_UNORM 0 18Ah BC5_UNORM 0 18Bh BC1_UNORM_SRGB 0 (DXT1_SRGB) 18Ch BC2_UNORM_SRGB 0 (DXT2/3_SRGB) 18Dh BC3_UNORM_SRGB 0 (DXT4/5_SRGB) 18Eh MONO8 1 18Fh YCRCB_SWAPUV 0 190h YCRCB_SWAPY 0 191h DXT1_RGB 0 192h FXT1 0 193h R8G8B8_UNORM 24 194h R8G8B8_SNORM 24 195h R8G8B8_SSCALED 24 196h R8G8B8_USCALED 24 197h R64G64B64A64_FLOAT 256 198h R64G64B64_FLOAT 192 199h BC4_SNORM 0 19Ah BC5_SNORM 0 19Bh R16G16B16_FLOAT 48 19Ch R16G16B16_UNORM 48 19Dh R16G16B16_SNORM 48 19Eh R16G16B16_SSCALED 48 19Fh R16G16B16_USCALED 48 1A1h BC6H_SF16 0 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 82 SURFACE_FORMAT 1A2h BC7_UNORM 0 1A3h BC7_UNORM_SRGB 0 1A4h BC6H_UF16 0 1A5h PLANAR_420_8 0 1A8h R8G8B8_UNORM_SRGB 24 1A9h ETC1_RGB8 0 1AAh ETC2_RGB8 0 1ABh EAC_R11 0 1ACh EAC_RG11 0 1ADh EAC_SIGNED_R11 0 1AEh EAC_SIGNED_RG11 0 1AFh ETC2_SRGB8 0 1B0h R16G16B16_UINT 48 1B1h R16G16B16_SINT 48 1B2h R32_SFIXED 32 1B3h R10G10B10A2_SNORM 32 1B4h R10G10B10A2_USCALED 32 1B5h R10G10B10A2_SSCALED 32 1B6h R10G10B10A2_SINT 32 1B7h B10G10R10A2_SNORM 32 1B8h B10G10R10A2_USCALED 32 1B9h B10G10R10A2_SSCALED 32 1BAh B10G10R10A2_UINT 32 1BBh B10G10R10A2_SINT 32 1BCh R64G64B64A64_PASSTHRU 256 1BDh R64G64B64_PASSTHRU 192 1C0h ETC2_RGB8_PTA 0 1C1h ETC2_SRGB8_PTA 0 1C2h ETC2_EAC_RGBA8 0 1C3h ETC2_EAC_SRGB8_A8 0 1C8h R8G8B8_UINT 24 1C9h R8G8B8_SINT 24 1FFh RAW 0 NOTE: “RAW” is supported only with buffers and structured buffers accessed via the untyped surface read/write and untyped atomic operation messages, which do not have a column in the table. Errata : RT format of A8_UNORM, R32_UINT, R32_SINT, R32G32_SINT,R32G32_UINT are not supported in MSAA 4x/8x mode. Errata : BC6H_SF16, BC6H_UF16, and BC7_SRGB are not supported and may result in data corruption if used. 2.12.2.1.2 Sampler Output Channel Mapping The following table indicates the mapping of the channels from the surface to the channels output from the sampling engine. Formats with all four channels (R/G/B/A) in their name map each surface channel to the corresponding output, thus those formats are not shown in this table. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 83 Some formats are supported only in DX10/OGL Border Color Mode. Those formats have only that mode indicated. Formats that behave the same way in both Border Color Modes are indicated by that column being blank. Borde Border r Filterin Shado Chrom Color Color Surface Format Name g w Map a Key Mode R G B A Mode R G B A R32G32B32A32_FLOAT R G B A R32G32B32A32_SINT R G B A R32G32B32A32_UINT R G B A R32G32B32X32_FLOAT R G B 1.0 R32G32B32_FLOAT R G B 1.0 R32G32B32_SINT R G B 1.0 R32G32B32_UINT DX10/O R G B 1.0 GL R16G16B16A16_UNORM R G B A R16G16B16A16_SNORM R G B A R16G16B16A16_SINT R G B A R16G16B16A16_UINT R G B A R16G16B16A16_FLOAT R G B A R32G32_FLOAT DX10/O R G 0.0 1.0 DX9 R G 1.0 1.0 GL R32G32_SINT DX10/O R G 0.0 1.0 GL R32G32_UINT DX10/O R G 0.0 1.0 GL R32_FLOAT_X8X24_TYPELE DX10/O R 0.0 0.0 1.0 SS GL X32_TYPELESS_G8X24_UIN DX10/O 0.0 G 0.0 1.0 T GL L32A32_FLOAT DX10/O L L L A GL R16G16B16X16_UNORM R G B 1.0 R16G16B16X16_FLOAT R G B 1.0 A32X32_FLOAT 0.0 0.0 0.0 A L32X32_FLOAT L L L 1.0 I32X32_FLOAT I I I I B8G8R8A8_UNORM R G B A B8G8R8A8_UNORM_SRGB R G B A R10G10B10A2_UNORM R G B A R10G10B10A2_UNORM_SRG R G B A B R10G10B10A2_UINT R G B A R10G10B10_SNORM_A2_UN R G B A ORM R8G8B8A8_UNORM R G B A R8G8B8A8_UNORM_SRGB R G B A R8G8B8A8_SNORM R G B A R8G8B8A8_SINT R G B A R8G8B8A8_UINT R G B A R16G16_UNORM DX10/O R G 0.0 1.0 DX9 R G 1.0 1.0 GL R16G16_SNORM DX10/O R G 0.0 1.0 DX9 R G 1.0 1.0 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 84 Borde Border r Filterin Shado Chrom Color Color Surface Format Name g w Map a Key Mode R G B A Mode R G B A GL R16G16_SINT DX10/O R G 0.0 1.0 GL R16G16_UINT DX10/O R G 0.0 1.0 GL R16G16_FLOAT DX10/O R G 0.0 1.0 DX9 R G 1.0 1.0 GL B10G10R10A2_UNORM R G B A B10G10R10A2_UNORM_SRG R G B A B R11G11B10_FLOAT R G B 1.0 R32_SINT DX10/O R 0.0 0.0 1.0 GL R32_UINT DX10/O R 0.0 0.0 1.0 GL R32_FLOAT DX10/O R 0.0 0.0 1.0 DX9 R 1.0 1.0 1.0 GL R24_UNORM_X8_TYPELESS DX10/O R 0.0 0.0 1.0 GL X24_TYPELESS_G8_UINT DX10/O 0.0 G 0.0 1.0 GL L16A16_UNORM L L L A I24X8_UNORM I I I I L24X8_UNORM L L L 1.0 A24X8_UNORM 0.0 0.0 0.0 A I32_FLOAT I I I I L32_FLOAT L L L 1.0 A32_FLOAT 0.0 0.0 0.0 A B8G8R8X8_UNORM R G B 1.0 B8G8R8X8_UNORM_SRGB R G B 1.0 R8G8B8X8_UNORM R G B 1.0 R8G8B8X8_UNORM_SRGB R G B 1.0 R9G9B9E5_SHAREDEXP R G B 1.0 B10G10R10X2_UNORM R G B 1.0 L16A16_FLOAT L L L A B5G6R5_UNORM R G B 1.0 B5G6R5_UNORM_SRGB R G B 1.0 B5G5R5A1_UNORM R G B A B5G5R5A1_UNORM_SRGB R G B A B4G4R4A4_UNORM R G B A B4G4R4A4_UNORM_SRGB R G B A R8G8_UNORM DX10/O R G 0.0 1.0 DX9 R G 1.0 1.0 GL R8G8_SNORM DX10/O R G 0.0 1.0 DX9 R G 1.0 1.0 GL R8G8_SINT DX10/O R G 0.0 1.0 GL R8G8_UINT DX10/O R G 0.0 1.0 GL Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 85 Borde Border r Filterin Shado Chrom Color Color Surface Format Name g w Map a Key Mode R G B A Mode R G B A R16_UNORM DX10/O R 0.0 0.0 1.0 GL R16_SNORM DX10/O R 0.0 0.0 1.0 GL R16_SINT DX10/O R 0.0 0.0 1.0 GL R16_UINT DX10/O R 0.0 0.0 1.0 GL R16_FLOAT DX10/O R 0.0 0.0 1.0 DX9 R 1.0 1.0 1.0 GL A8P8_UNORM_PALETTE0 R G B A A8P8_UNORM_PALETTE1 R G B A I16_UNORM I I I I L16_UNORM L L L 1.0 A16_UNORM 0.0 0.0 0.0 A L8A8_UNORM L L L A I16_FLOAT I I I I L16_FLOAT L L L 1.0 A16_FLOAT 0.0 0.0 0.0 A L8A8_UNORM_SRGB L L L A R5G5_SNORM_B6_UNORM R G B 1.0 P8A8_UNORM_PALETTE0 R G B A P8A8_UNORM_PALETTE1 R G B A R8_UNORM DX10/O R 0.0 0.0 1.0 GL R8_SNORM DX10/O R 0.0 0.0 1.0 GL R8_SINT DX10/O R 0.0 0.0 1.0 GL R8_UINT DX10/O R 0.0 0.0 1.0 GL A8_UNORM 0.0 0.0 0.0 A I8_UNORM I I I I L8_UNORM L L L 1.0 P4A4_UNORM_PALETTE0 R G B A A4P4_UNORM_PALETTE0 R G B A P8_UNORM_PALETTE0 R G B A L8_UNORM_SRGB L L L 1.0 P8_UNORM_PALETTE1 R G B A P4A4_UNORM_PALETTE1 R G B A A4P4_UNORM_PALETTE1 R G B A DXT1_RGB_SRGB R G B 1.0 R1_UNORM R 0.0 0.0 1.0 YCRCB_NORMAL Cr Y Cb 1.0 YCRCB_SWAPUVY Cr Y Cb 1.0 P2_UNORM_PALETTE0 R G B A P2_UNORM_PALETTE1 R G B A BC1_UNORM R G B A BC2_UNORM R G B A Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 86 Borde Border r Filterin Shado Chrom Color Color Surface Format Name g w Map a Key Mode R G B A Mode R G B A BC3_UNORM R G B A BC4_UNORM DX10/O R 0.0 0.0 1.0 GL BC5_UNORM DX10/O R G 0.0 1.0 GL BC1_UNORM_SRGB R G B A BC2_UNORM_SRGB R G B A BC3_UNORM_SRGB R G B A MONO8 N/ N/ N/ N/ A A A A YCRCB_SWAPUV Cr Y Cb 1.0 YCRCB_SWAPY Cr Y Cb 1.0 DXT1_RGB R G B 1.0 FXT1 R G B A BC4_SNORM DX10/O R 0.0 0.0 1.0 GL BC5_SNORM DX10/O R G 0.0 1.0 GL R16G16B16_FLOAT R G B 1.0 BC6H_SF16 R G B 1.0 BC7_UNORM R G B A BC7_UNORM_SRGB R G B A BC6H_UF16 R G B 1.0 2.12.2.2 SURFACE_STATE for deinterlace, sample_8x8, and VME MEDIA_SURFACE_STATE Exists If: (MessageType == 'Deinterlace') || (MessageType == 'Sample_8x8') Default Value: 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 This is the SURFACE_STATE used by only deinterlace, sample_8x8, and VME messages. DWord Bit Description 0 31:0 Surface Base Address Format: GraphicsAddress[31:0] Specifies the byte-aligned base address of the surface Programming Notes For SURFTYPE_BUFFER render targets, this field specifies the base address of first element of the surface. The surface is interpreted as a simple array of that single element type. The address must be naturally-aligned to the element size (e.g., a buffer containing R32G32B32A32_FLOAT elements must be 16-byte aligned).For SURFTYPE_BUFFER non-rendertarget surfaces, this field specifies the base address of the first element of the surface, computed in software by adding the surface base address to the byte offset of the element in the buffer. Mipmapped, cube and 3D sampling engine surfaces are stored in a “monolithic” (fixed) format, and only require a single address for the base texture.Linear render target surface base addresses must be element-size aligned, for non-YUV surface formats, or a multiple of 2 element-sizes for YUV surface formats. Other linear surfaces have no alignment requirements (byte alignment is sufficient.)Linear depth buffer surface base addresses must be 64-byte Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 87 MEDIA_SURFACE_STATE aligned. Note that while render targets (color) can be SURFTYPE_BUFFER, depth buffers cannot.Tiled surface base addresses must be 4KB-aligned. Note that only the offsets from Surface Base Address are tiled, Surface Base Address itself is not transformed using the tiling algorithm.Tiled surface base addresses must be 4KB-aligned. Note that only the offsets from Surface Base Address are tiled, Surface Base Address itself is not transformed using the tiling algorithm.For tiled surfaces, the actual start of the surface can be offset from the Surface Base Address by the X Offset and Y Offset fields.Certain message types used to access surfaces have more stringent alignment requirements. Please refer to the specific message documentation for additional restrictions. 1 31:18 Height Format: U14 This field specifies the height of the surface in units of pixels. For PLANAR surface formats, this field indicates the height of the Y (luma) plane. Value Name Description [0,16383] representing heights [1,16384] Programming Notes Height (field value + 1) must be a multiple of 2 for PLANAR_420 surfaces.If Vertical Line Stride is 1, this field indicates the height of the field, not the height of the frame. 17:4 Width Format: U14 This field specifies the width of the surface in units of pixels. For PLANAR surface formats, this field indicates the width of the Y (luma) plane. Value Name Description [0,16383] representing widths [1,16384] Programming Notes  The Width specified by this field multiplied by the pixel size in bytes must be less than or equal to the surface pitch (specified in bytes via the Surface Pitch field).  Width (field value + 1) must be a multiple of 2 for PLANAR_420, PLANAR_422, and all YCRCB_* and PLANAR_Y16_UNORM surfaces, and must be a multiple of 4 for PLANAR_411 and PLANAR_Y8_UNORM surfaces.  For deinterlace messages, the Width (field value + 1) must be a multiple of 8. 3:2 Picture Structure Specifies the encoding of the current picture. Value Name 00b Frame Picture 01b Top Field Picture 10b Bottom Field Picture 11b Invalid, not allowed 1:0 Cr(V)/Cb(U) Pixel Offset V Direction Format: U0.2 Specifies the distance to the U/V values with respect to the even numbered Y channels in the V direction Programming Notes This field is ignored for all formats except PLANAR_420_8 2 31:28 Surface Format Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 88 MEDIA_SURFACE_STATE Specifies the format of the surface. All of the Y and G channels will use table 0 and all of the Cr/Cb/R/B channels will use table 1 Value Name Description 0 YCRCB_NORMAL 1 YCRCB_SWAPUVY 2 YCRCB_SWAPUV 3 YCRCB_SWAPY 4 PLANAR_420_8 5 PLANAR_411_8 Deinterlace only 6 PLANAR_422_8 Deinterlace only 7 STMM_DN_STATISTICS Deinterlace only 8 R10G10B10A2_UNORM Sample_8x8 only 9 R8G8B8A8_UNORM Sample_8x8 only 10 R8B8_UNORM (CrCb) Sample_8x8 only 11 R8_UNORM (Cr/Cb) Sample_8x8 only 12 Y8_UNORM 15 Reserved 27 Interleave Chroma Format: Enable This field indicates that the chroma fields are interleaved in a single plane rather than stored as two separate planes. This field is only used for PLANAR surface formats. 26 Reserved Format: MBZ 25:22 Surface Object Control State (MEMORY_OBJECT_CONTROL_STATE) This 4-bit field is used in various state commands and indirect state objects to define LLC cacheability including graphics data type for memory objects. 21 Reserved Format: MBZ 20:3 Surface Pitch Format: U18-1 pitch in Bytes This field specifies the surface pitch in (#Bytes - 1). Value Name Description [0,2047] For surfaces of type SURFTYPE_BUFFER: representing [1B, 2048B] [0,2047] For surfaces of type SURFTYPE_STRBUF: representing [1B, 2048B] [0,524287] For other linear surfaces: representing [1B, 256KB] [511, 131071] For X-tiled surface: representing [512B, 256KB] = [1 tile, 512 tiles] [127, 131071] For Y-tiled surfaces: representing [128B, 256KB] = [1 tile, 2048 tiles] Programming Notes For tiled surfaces, the pitch must be a multiple of the tile widthIf Half Pitch for Chroma is set, this field Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 89 MEDIA_SURFACE_STATE must be a multiple of two tile widths for tiled surfaces, or a multiple of 2 bytes for linear surfaces.The Surface Pitches of current picture and reference picture should be declared as the identical type in VDI mode with identical Height, Width and Format. 2 Half Pitch for Chroma Format: Enable This field indicates that the chroma plane(s) will use a pitch equal to half the value specified in the Surface Pitch field. This field is only used for PLANAR surface formats. 1:0 Tile Mode Format: U2 enumerated type This field specifies the type of memory tiling (Linear, WMajor, XMajor, or YMajor) employed to tile this surface. See Memory Interface Functions for details on memory tiling and restrictions. Value Name Description Project 0h TILEMODE_LINEAR Linear mode (no tiling) All 1h Reserved Reserved All 2h TILEMODE_XMAJOR X major tiling All 3h TILEMODE_YMAJOR Y major tiling All Programming Notes  Refer to Memory Data Formats for restrictions on TileMode direction for the various buffer types. (Of particular interest is the fact that YMAJOR tiling is not supported for display/overlay buffers).  The corresponding cache(s) must be invalidated before a previously accessed surface is accessed again with an altered state of this field.  Linear surfaces can be mapped to Main Memory (uncached) or System Memory (cacheable, snooped). Tiled (X/Y/W) surfaces can only be mapped to Main Memory. 3 31:30 Reserved Project: All Format: MBZ 29:16 X Offset for U(Cb) Format: U14 Pixel Offset For Planar surfaces this field specifies the horizontal offset in pixels from the Surface Base Address to the start (origin) of the U(Cb) plane or the interleaved UV plane if Interleave Chroma is enabled. For non planar surfaces this field specifies the horizontal offset in pixels from the Surface Base Address to the start (origin) of the surface Programming Notes For PLANAR_420 and PLANAR_422 surface formats, this field must indicate an even number of pixels. 15 Reserved Format: MBZ 14:0 Y Offset for U(Cb) Format: U15 Row Offset Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 90 MEDIA_SURFACE_STATE For Planar surfaces this field specifies the vertical offset in rows from the Surface Base Address to the start (origin) of the U(Cb) plane or the interleaved UV plane if Interleave Chroma is enabled. For non planar surfaces this field specifies the vertical offset in pixels from the Surface Base Address to the start (origin) of the surface Programming Notes Project This field must indicate an even number (bit 0 = 0). 4 31:30 Reserved Project: All Format: MBZ 29:16 X Offset for V(Cr) Format: U14 Pixel Offset Programming Notes For PLANAR_420 and PLANAR_422 surface formats, this field must indicate an even number of pixels. 15 Reserved Project: All Format: MBZ 14:0 Y Offset for V(Cr) Format: U15 Row Offset This field specifies the veritical offset in rows from the Surface Base Address to the start (origin) of the V(Cr) plane. This field is only used for PLANAR surface formats with Interleave Chroma disabled. Value Name 0,16380 Programming Notes Project This field must indicate an even number (bit 0 = 0). 5 31:30 Reserved Project: Format: MBZ 29:7 Reserved Format: MBZ 6:0 Reserved Format: MBZ 2.12.3 SAMPLER_STATE SAMPLER_STATE has different formats, depending on the message type used:  For , the sample_8x8 and deinterlace messages use a different format of SAMPLER_STATE as detailed in the corresponding sections. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 91  For The Min LOD and Max LOD fields need range increased from [0.0,13.0] to [0.0,14.0] and fractional bits increased from 6 to 8. This requires a few fields to be moved as indicated in the text. 2.12.3.1 Sampler_State for Most Messages SAMPLER_STATE Exists If: (MessageType != 'Deinterlace') && (MessageType != 'Sample_8x8') Default Value: 0x00000000, 0x00000000, 0x00000000, 0x00000000 This is the normal sampler state used by all messages that use SAMPLER_STATE except sample_8x8 and deinterlace. The sampler state is stored as an array of up to 16 elements, each of which contains the dwords described here. The start of each element is spaced 4 dwords apart. The first element of the sampler state array is aligned to a 32-byte boundary. DWord Bit Description 0 31 Sampler Disable Project: All Format: Disable This field allows the sampler to be disabled. If disabled, all output channels will return 0. 30 Reserved Project: All Format: MBZ 29 Texture Border Color Mode Project: All Format: U1 enumerated type For some surface formats, the 32 bit border color is decoded differently based on the border color mode. In addition, the default value of channels not included in the surface may be affected by this field. Refer to the “Sampler Output Channel Mapping” table for the values of these channels, and for surface formats that may only support one of these modes. Also refer to the definition of SAMPLER_BORDER_COLOR_STATE for more details on the behavior of the two modes defined by this field. Value Name Description Project 0h DX10/OGL DX10/OGL mode for interpreting the border color All 1h DX9 DX9 and earlier mode for interpreting the border color All Programming Notes If this bit changes for a given map with surface format R8G8_SNORM or R16_FLOAT, there must be two different SURFACE_STATE pointers for Texture Border Color Mode = 0 and 1. This is done to prevent an aliasing problem in the L1 cache with the default value for the missing channels changing. Alternately there could be a flush every time this changes. This field must be set to DX9 mode when used with surfaces that have Surface Format P4A4_UNORM or A4P4_UNORM. This field must be set to DX10/OGL mode when used with surfaces that have Surface Format YCRCB_SWAPUV or YCRCB_SWAPY. This field must be set to DX10/OGL mode if Surface Format for the associated surface is UINT OR SINT. This field must be set to DX10/OGL mode if REDUCTION_MINIMUM or REDUCTION_MAXIMUM or message type is sample_min or sample_max. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 92 SAMPLER_STATE This field must be set to DX10/OGL mode if either Min or Mag Mode Filter is set to MAPFILTER_FLEXIBLE. 28 LOD PreClamp Enable Format: U1 enumerated type When enabled, the computed LOD is clamped to [max,min] mip level before the mag-vs-min determination is performed. This is how the OpenGL API currently performs min/mag determination, and therefore it is expected that an OpenGL driver would need to set this bit. Value Name Description 1h OGL OGL Mode (LOD PreClamp enabled) 27 Reserved Format: MBZ 26:22 Base Mip Level Format: U4.1 Range: [0.0, 14.0] Specifies which mip level is considered the “base” level when determining mag-vs-min filter and selecting the “base” mip level. 21:20 Mip Mode Filter Project: All Format: U2 enumerated type This field determines if and how mip map levels are chosen and/or combined when texture filtering. Value Name Description Project 0h MIPFILTER_NONE Disable mip mapping – force use of the mipmap level All corresponding to Min LOD. 1h MIPFILTER_NEAREST Nearest, Select the nearest mip map All 2h Reserved All 3h MIPFILTER_LINEAR Linearly interpolate between nearest mip maps (combined with All linear min/mag filters this is analogous to “Trilinear” filtering). Programming Notes MIPFILTER_LINEAR is not supported for surface formats that do not support “Sampling Engine Filtering” as indicated in the Surface Formats table unless using the sample_c message type or minimum/maximum operation. 19:17 Mag Mode Filter Project: All Format: U2 enumerated type This field determines how texels are sampled/filtered when a texture is being “magnified” (enlarged). For volume maps, this filter mode selection also applies to the 3rd (inter-layer) dimension. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 93 SAMPLER_STATE Value Name Description Project 0h MAPFILTER_NEAREST Sample the nearest texel All 1h MAPFILTER_LINEAR Bilinearly filter the 4 nearest texels All 2h MAPFILTER_ANISOTROPIC Perform an “anisotropic” filter on the chosen mip level All 4h-5h Reserved All 6h MAPFILTER_MONO Perform a monochrome convolution filter All 7h Reserved All Programming Notes Only MAPFILTER_NEAREST and MAPFILTER_LINEAR are supported for surfaces of type SURFTYPE_3D. Only MAPFILTER_NEAREST is supported for surface formats that do not support “Sampling Engine Filtering” as indicated in the Surface Formats table unless using the sample_c message type or minimum/maximum operation. MAPFILTER_MONO: Only CLAMP_BORDER texture addressing mode is supported. . Both Mag Mode Filter and Min Mode Filter must be programmed to MAPFILTER_MONO. Mip Mode Filter must be MIPFILTER_NONE. Only valid on surfaces with Surface Format MONO8 and with Surface Type SURFTYPE_2D. MAPFILTER_FLEXIBLE: The Surface Type of the surface being sampled must be SURFTYPE_2D. MAPFILTER_ANISOTROPIC may cause artifacts at cube edges if enabled for cube maps with the TEXCOORDMODE_CUBE addressing mode. MAPFILTER_ANISOTROPIC will be overridden to MAPFILTER_LINEAR when using a sample_l or sample_l_c message type or when Force LOD to Zero is set in the message header. Errata Description Project MAPFILTER_ANISOTROPIC may have data corruption when sampled from surface with BC6H_UF16 or BC6H_SF16 16:14 Min Mode Filter Project: All Format: U2 enumerated type This field determines how texels are sampled/filtered when a texture is being “minified” (shrunk). For volume maps, this filter mode selection also applies to the 3rd (inter-layer) dimension.See Mag Mode Filter 13:1 Texture LOD Bias Project: All Format: S4.8 2’s complement Range: [-16.0, 16.0) This field specifies the signed bias value added to the calculated texture map LOD prior to min-vs-mag determination and mip-level clamping. Assuming mipmapping is enabled, a positive LOD bias will result in a somewhat blurrier image (using less-detailed mip levels) and possibly higher performance, while a negative bias will result in a somewhat crisper image (using more-detailed mip levels) and may lower performance. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 94 SAMPLER_STATE Programming Notes There is no requirement or need to offset the LOD Bias in order to produce a correct LOD for texture filtering (as was required for correct bilinear and anisotropic filtering in some legacy devices). 0 Anisotropic Algorithm Project: All Format: U1 enumerated type Controls which algorithm is used for anisotropic filtering. Generally, the EWA approximation algorithm results in higher image quality than the legacy algorithm. Value Name Description Project 0h LEGACY Use the legacy algorithm for anisotropic filtering All 1h EWA Approximation Use the new EWA approximation algorithm for anisotropic filtering All 1 31:20 Min LOD Project: All Format: U4.8 in LOD units Range: [0.0, 14.0], where the upper limit is also bounded by the Max LOD. This field specifies the minimum value used to clamp the computed LOD after LOD bias is applied. Note that the minification-vs.-magnification status is determined after LOD bias and before this maximum (resolution) mip clamping is applied.The integer bits of this field are used to control the “maximum” (highest resolution) mipmap level that may be accessed (where LOD 0 is the highest resolution map). The fractional bits of this value effectively clamp the inter-level trilinear blend factor when trilinear filtering is in use. Programming Notes If Min LOD is greater than Max LOD, Min LOD takes precedence, i.e. the resulting LOD will always be Min LOD. This field must be zero if the Min or Mag Mode Filter is set to MAPFILTER_MONO 19:8 Max LOD Project: All Format: U4.8 in LOD units Range: [0.0, 14.0] This field specifies the maximum value used to clamp the computed LOD after LOD bias is applied. Note that the minification-vs.-magnification status is determined after LOD bias and before this minimum (resolution) mip clamping is applied.The integer bits of this field are used to control the “minimum” (lowest resolution) mipmap level that may be accessed.The fractional bits of this value effectively clamp the inter-level trilinear blend factor when trilinear filtering is in use.Force the mip map access to be between the mipmap specified by the integer bits of the Min LOD and the ceiling of the value specified here. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 95 SAMPLER_STATE 7:4 Reserved Format: MBZ 3:1 Shadow Function Project: All Format: U3 enumerated type This field is used for shadow mapping support via the sample_c message type, and specifies the specific comparison operation to be used. The comparison is between the texture sample red channel (except for alpha-only formats which use the alpha channel), and the “ref” value provided in the input message. Value Name Project 0h PREFILTEROP_ALWAYS All 1h PREFILTEROP_NEVER All 2h PREFILTEROP_LESS All 3h PREFILTEROP_EQUAL All 4h PREFILTEROP_LEQUAL All 5h PREFILTEROP_GREATER All 6h PREFILTEROP_NOTEQUAL All 7h PREFILTEROP_GEQUAL All 0 Cube Surface Control Mode Project: All Format: U1 enumerated type When sampling from a SURFTYPE_CUBE surface, this field controls whether the TC* Address Control Mode fields are interpreted as programmed or overridden to TEXCOORDMODE_CUBE. Value Name Project 0h CUBECTRLMODE_PROGRAMMED All 1h CUBECTRLMODE_OVERRIDE All Programming Notes This field must be set to CUBECTRLMODE_PROGRAMMED 2 31:5 Border Color Pointer Format: DynamicStateOffset[31:5] Description Project This field specifies the pointer to SAMPLER_BORDER_COLOR_STATE, which contains the “border” color to be used when accessing texels not contained within the texture map. This pointer is relative to the Dynamic State Base Address. Field definition if Flexible Filter Mode = FLEX_NONSEP: Errata Description Project In order to ensure correct data sampling, it must be ensured that the bits of this field with three LSBs of zero appended do not match the offset (without base address added) of Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 96 SAMPLER_STATE any instance of BINDING_TABLE_STATE (includes each 32-bit entry) used by the sampling engine between texture cache invalidations. 4:0 Reserved Format: MBZ 3 31:26 Reserved Format: MBZ 25 ChromaKey EnableFormat: Enable This field enables the chroma key function. Programming Notes Supported only on a specific subset of surface formats. See section “Surface Formats” for supported formats.This field must be disabled if min or mag filter is MAPFILTER_MONO or MAPFILTER_ANISOTROPIC.This field must be disabled if used with a surface of type SURFTYPE_3D. 24:23 ChromaKey Index Format: U2 This field specifies the index of the ChromaKey Table entry associated with this Sampler. This field is a “don’t care” unless ChromaKey Enable is ENABLED. Value Name [0,3] 22 ChromaKey Mode Format: U1 Enumerated Type This field specifies the behavior of the device in the event of a ChromaKey match. This field is ignored if ChromaKey is disabled.KEYFILTER_KILL_ON_ANY_MATCH:In this mode, if any contributing texel matches the chroma key, the corresponding pixel mask bit for that pixel is cleared. The result of this operation is observable only if the Killed Pixel Mask Return flag is set on the input message. KEYFILTER_REPLACE_BLACK:In this mode, each texel that matches the chroma key is replaced with (0,0,0,0) (black with alpha=0) prior to filtering. For YCrCb surface formats, the black value is A=0, R(Cr)=0x80, G(Y)=0x10, B(Cb)=0x80. This will tend to darken/fade edges of keyed regions. Note that the pixel pipeline must be programmed to use the resulting filtered texel value to gain the intended effect, e.g., handle the case of a totally keyed-out region (filtered texel alpha==0) through use of alpha test, etc. Value Name Project 0h KEYFILTER_KILL_ON_ANY_MATCH All 1h KEYFILTER_REPLACE_BLACK All 21:19 Maximum Anisotropy Project: All Format: U3 enumerated type This field clamps the maximum value of the anisotropy ratio used by the MAPFILTER_ANISOTROPIC filter (Min or Mag Mode Filter). Value Name Description Project 0h ANISORATIO_2 At most a 2:1 aspect ratio filter is used All Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 97 SAMPLER_STATE 1h ANISORATIO_4 At most a 4:1 aspect ratio filter is used All 2h ANISORATIO_6 At most a 6:1 aspect ratio filter is used All 3h ANISORATIO_8 At most a 8:1 aspect ratio filter is used All 4h ANISORATIO_10 At most a 10:1 aspect ratio filter is used All 5h ANISORATIO_12 At most a 12:1 aspect ratio filter is used All 6h ANISORATIO_14 At most a 14:1 aspect ratio filter is used All 7h ANISORATIO_16 At most a 16:1 aspect ratio filter is used All 18:13 Address Rounding Enable Project: All Format: 6-bit mask of enables Controls whether the U/V/R texture address is rounded or truncated before being used to select texels to sample. Each bit provides independent control of rounding on one texture address dimension (U/V/R) in either mag or min filter mode. Value Name 1xxxxxb U address mag filter x1xxxxb U address min filter xx1xxxb V address mag filter xxx1xxb V address min filter xxxx1xb R address mag filter xxxxx1b R address min filter Programming Notes Project Hardware will force rounding enable to 0 when message is gather4, gather4_po, gather4_c, or gather4_po_c. 12:11 Trilinear Filter Quality Project: All Format: U2 enumerated type Selects the quality level for the trilinear filter. Value Name Description Project 0 TRIQUAL_FULL Full Quality. Both mip maps are sampled under all circumstances. All 2 TRIQUAL_MED Medium Quality. If the contribution of one mip map is less than 25%, All only the other mip map contributes. 3 TRIQUAL_LOW Low Quality. If the contribution of one mip map is less than 37.5%, only All the other mip map contributes. 10 Non-normalized Coordinate Enable Project: All Format: Enable This field, if enabled, specifies that the input coordinates (U/V/R) are in non-normalized space, where each integer increment is one texel on LOD 0. If disabled, coordinates are normalized, where the range 0 to 1 spans the entire surface. Programming Notes The following state must be set as indicated if this field is enabled:  TCX/Y/Z Address Control Mode must be TEXCOORDMODE_CLAMP, TEXCOORDMODE_HALF_BORDER, or TEXCOORDMODE_CLAMP_BORDER. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 98 SAMPLER_STATE  Surface Type must be SURFTYPE_2D or SURFTYPE_3D.  Mag Mode Filter must be MAPFILTER_NEAREST or MAPFILTER_LINEAR.  Min Mode Filter must be MAPFILTER_NEAREST or MAPFILTER_LINEAR.  Mip Mode Filter must be MIPFILTER_NONE.  Min LOD must be 0.  Max LOD must be 0.  MIP Count must be 0.  Surface Min LOD must be 0.  Texture LOD Bias must be 0. 9 Reserved Format: MBZ 8:6 TCX Address Control Mode Project: All Format: U3 enumerated type Controls how the 1st (TCX, aka U) component of input texture coordinates are mapped to texture map addresses – specifically, how coordinates “outside” the texture are handled (wrap/clamp/mirror). The setting of this field is subject to being overridden by the Cube Surface Control Mode field when sampling from a SURFTYPE_CUBE surface. Value Name Description Project 0h TEXCOORDMODE_WRAP Map is repeated in the U direction All 1h TEXCOORDMODE_MIRROR Map is mirrored in the U direction All 2h TEXCOORDMODE_CLAMP Map is clamped to the edges of the accessed All map 3h TEXCOORDMODE_CUBE For cube-mapping, filtering in edges access All adjacent map faces 4h TEXCOORDMODE_CLAMP_BORDER Map is infinitely extended with the border color All 5h TEXCOORDMODE_MIRROR_ONCE Map is mirrored once about origin, then clamped All 7h Reserved All Programming Notes Project When using cube map texture coordinates, only TEXCOORDMODE_CLAMP and TEXCOORDMODE_CUBE settings are valid, and each TC component must have the same Address Control mode. When TEXCOORDMODE_CUBE is not used accessing a cube map, the map’s Cube Face Enable field must be programmed to 111111b (all faces enabled). MAPFILTER_MONO: Texture addressing modes must all be set to TEXCOORDMODE_CLAMP_BORDER. The Border Color is ignored in this mode, a constant value of 0 is used for border color. Software must pad the border texels within the map itself with 0. 5:3 TCY Address Control Mode Project: All Format: U3 enumerated type Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 99 SAMPLER_STATE Controls how the 2nd (TCY, aka V) component of input texture coordinates are mapped to texture map addresses – specifically, how coordinates “outside” the texture are handled (wrap/clamp/mirror). See Address TCX Control Mode above for details Programming Notes If this field is set to TEXCOORDMODE_CLAMP_BORDER or TEXCOORDMODE_HALF_BORDER and a 1D surface is sampled, incorrect blending with the border color in the vertical direction may occur. 2:0 TCZ Address Control Mode Project: All Format: U3 enumerated type Description Project Controls how the 3rd (TCZ) component of input texture coordinates are mapped to texture map addresses – specifically, how coordinates “outside” the texture are handled (wrap/clamp/mirror).See Address TCX Control Mode above for details If this field is set to TEXCOORDMODE_CLAMP_BORDER for 3D maps on formats without an alpha channel, samples straddling the map in the Z direction may have their alpha channels off by 1. 2.12.3.2 SAMPLER_STATE for Sample_8x8 Message SAMPLER_STATE for Sample_8x8 Message Default Value: 0x00000000, 0x00000000, 0x0D090801, 0x721A03C6 . This state definition is used only by the sample_8x8 message. This state is stored as an array of up to 16 elements, each of which contains the dwords described here. The start of each element is spaced 4 dwords apart. The first element of the array is aligned to a 32-byte boundary. The index with range 0-15 that selects which element is being used to determine the Sampler Index in the message descriptor. Programming Notes  IEF Filter Type was dropped and is assumed to be Detailed filter  IEF Filter Size was dropped and assumed to be 5x5.  IEF bypass must always be forced to 1, if Y/G-channel is masked. DWord Bit Description 0 31:30 Reserved Format: MBZ 29 IEF Bypass Format: MBZ Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 100 SAMPLER_STATE for Sample_8x8 Message Causes IEF function to be bypassed, VSA will output neutral values. 28:19 Reserved Format: MBZ 18 ChromaKey Enable Format: Enable This field enables chroma keying when accessing this particular texture map. Programming Notes  For sample_8x8 instructions KEYFILTER_REPLACE_BLACK is assumed if chromakey is enabled.  For 10 bit formats only the 8 MSBs will be compared. 17:16 ChromaKey Index Format: U2 This field specifies the index of the ChromaKey Table entry associated with this Sampler. This field is a “don’t care” unless ChromaKey Enable is ENABLED. Value Name [0,3] 15:8 Reserved Format: MBZ 7:0 Global Noise Estimation Format: U8 Global noise estimation of previous frame. 1 31:5 Sampler 8x8 State Pointer Format: DynamicStateOffset[31:5] This field specifies the pointer to the SAMPLER_8x8_STATE structure. This pointer is relative to the Dynamic State Base Address. Programming Notes  This field must be set to the same value in all sample_8x8 type SAMPLER_STATE instances applied to a given primitive.  PIPE_CONTROL with State/Instruction Cache Invalidate set and the CS Stall field set is required between primitives that use different values of this field. 4:0 Reserved Format: MBZ 2 31 Reserved Format: MBZ 30:26 R5c Coefficient Default Value: 3 Format: U0.5 IEF smoothing coefficient, see IEF map. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 101 SAMPLER_STATE for Sample_8x8 Message 25:21 R5x Coefficient Default Value: 8 Format: U0.5 IEF smoothing coefficient, see IEF map. 20:16 R5c Coefficient Default Value: 9 Format: U0.5 IEF smoothing coefficient, see IEF map. 15:14 Reserved Format: MBZ 13:8 Strong Edge Threshold Default Value: 8 Format: U6 If EM > Strong Edge Threshold, the basic VSA detects a strong edge. 7:6 Reserved Format: MBZ 5:0 Weak Edge Threshold Default Value: 1 Format: U6 If Strong Edge Threshold > EM > Weak Edge Threshold, the basic VSA detects a weak edge. 3 31 IEF4Smooth Enable Value Name Description 1 IEF is operating as a content adaptive smooth filter based on 3x3 region 0 [Default] IEF is operating as a content adaptive detail filter based on 5x5 region 30:28 Strong Edge Weight Default Value: 7 Format: U3 Sharpening strength when a strong edge is found in basic VSA.. 27 Reserved Format: MBZ 26:24 Regular Weight Default Value: 2 Format: U3 Sharpening strength when a weak edge is found in basic VSA. 23 Reserved Format: MBZ 22:20 Non Edge Weight Default Value: 1 Format: U3 Sharpening strength when no edge is found in basic VSA. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 102 SAMPLER_STATE for Sample_8x8 Message 19:14 Gain Factor Default Value: 40 Format: U6 User control sharpening strength. 13:11 Reserved Format: MBZ 10:6 R3c Coefficient Default Value: 15 Format: 0.5 IEF smoothing coefficient, see IEF map. 5 Reserved Format: MBZ 4:0 R3x Coefficient Default Value: 6 Format: U6 IEF smoothing coefficient, see IEF map. 2.12.3.3 For Deinterlace Message DEINTERLACE_SAMPLER_STATE Exists If: MessageType == 'Deinterlace' Default 0x00000800, 0x00000000, 0x04950100, 0x407D0000, 0x00000000, 0x00000000, 0x00000000, Value: 0x005064A5 This state definition is used only by the deinterlace message. This state is stored as an array of up to 8 elements, each of which contains the dwords described here. The start of each element is spaced 8 dwords apart. The first element of the array is aligned to a 32-byte boundary. The index with range 0-7 that selects which element is being used is multiplied by 2 to determine the Sampler Index in the message descriptor. DWord Bit Description 0 31:24 Denoise STAD Threshold Threshold for denoise sum of temporal absolute differences. 23:16 Denoise Maximum History Maximum allowed value for denoise history. Value Name Description 128-240 15 Reserved Format: MBZ 14 VDI Walker Frame Sharing Enable Format: U1 enumerated type For a GT2 system with 2 half-slices, this field controls how the frame is shared by the two deinterlacer Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 103 DEINTERLACE_SAMPLER_STATE walkers. Value Name 0 There is only a single deinterlacer which must walk the entire frame. VDI Walker Y Stride is ignored. 1 The screen is shared by the two deinterlacers as controlled by the VDI Walker Y Stride 13:12 VDI Walker Y Stride Format: U2 enumerated type This field controls if the VDI walker skips pixels as it goes down the screen. This is used when a pair of VDI'S are splitting the frame between them. The stride also implies the offset used by the 2nd half- slice. Value Name 0 Stride of 1 block (where a block is 4x4 when DI is enabled and 4x8 when DN only), offset for the 2nd half-slice is � the surface height. 1 Stride of 2 blocks (every other row of blocks calculated by this VDI), offset for the 2nd half-slice is 1 block. 2 Stride of 4 blocks (2 vertical blocks calclated by this VDI, then skip 2), offset for the 2nd half- slice is 2 blocks. 3 Stride of 8 blocks (4 vertical blocks calculated by this VDI, then skip 4), offset for the 2nd half- slice is 4 blocks. 11:8 Denoise History Delta Default Value: 8 Amount that denoise_history is increased. 7:0 Denoise ASD Threshold Threshold for denoise absolute sum of differences. Value Name Description 0-63 1 31:30 Reserved Format: MBZ 29:24 Temporal Difference Threshold Programming Notes The difference between Temporal Difference Threshold and Low Temporal Difference Threshold must be larger than 0 and less than or equal to 16, except when both thresholds are set to 0. 23:22 Reserved Format: MBZ 21:16 Low Temporal Difference Threshold Programming Notes The difference between Temporal Difference Threshold and Low Temporal Difference Threshold must be larger than 0 and less than or equal to 16, except when both thresholds are set to 0. 15:13 STMM C2 Bias for divisor in STMM equation. The range represents values [1,8] Value Name Description 0-7 12:8 Denoise Moving Pixel Threshold Threshold for number of moving pixels to declare a block to be moving. Value Name Description 0-16 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 104 DEINTERLACE_SAMPLER_STATE 7:0 Denoise Threshold for Sum of Complexity Measure 2 31:30 Reserved Format: MBZ 29:24 Good Neighbor Threshold Maximum difference from current pixel for neighboring pixels to be considered a good neighbor. Value Name Description 4 [Default] depending on GNE of previous frame 23:20 CAT Slope Format: U4-1 Determines the slope of the Content Adaptive Threshold. +1 added internally to get CAT_slope. Value Name Description 9 [Default] CAT_slope value = 10 19:16 SAD Tight Threshold Default Value: 5 Format: U4 15:14 Smooth MV Threshold Format: U2 13:12 Reserved Format: MBZ 11:8 BNE Edge Threshold Default Value: 1 Format: U4 Threshold for detecting an edge in block noise estimate. 7:0 Block Noise Estimate Noise Threshold Format: U8 Threshold for noise maximum/minimum. Value Name Description 0-31 3 31 STMM Blending Constant Select Format: U1 Value Name 0 Use Minimum STMM for stmm_md_th 1 Use Maximum STMM for stmm_md_th 30:24 Blending constant across time for large values of STMM Default Value: 64 Format: U7 23:16 Blending constant across time for small values of STMM Default Value: 125 Format: U8 15:14 Reserved Format: MBZ 13:8 Multiplier for VECM Format: U6 Determines the strength of the vertical edge complexity measure. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 105 DEINTERLACE_SAMPLER_STATE 7:0 Maximum STMM Format: U8 Largest allowed STMM in blending equations 4 31:24 Minimum STMM Format: U8 Smallest allowed STMM in blending equations 23:22 STMM Shift Down Format: U2 Amount to shift STMM down (quantize to fewer bits) Value Name 0 Shift by 4 1 Shift by 5 2 Shift by 6 3 Reserved 21:20 STMM Shift Up Format: U2 Amount to shift STMM up (set range). Value Name 0 Shift by 6 1 Shift by 7 2 Shift by 8 3 Reserved 19:16 STMM Output Shift Format: U4 Amount to shift output of STMM blend equation Value Name Description 0-16 Programming Notes The value of this field must satisfy the following equation: stmm_max – stmm_min = 2 ^ stmm_output_shift 15:8 SDI Threshold Format: U8 Threshold for angle detection in SDI algorithm. 7:0 SDI Delta Format: U8 Delta value for angle detection in SDI algorithm. 5 31:24 SDI Fallback Mode 1 T1 Constant Format: U8 23:16 SDI Fallback Mode 1 T2 Constant Format: U8 15:8 SDI Fallback Mode 2 Constant (Angle2x1) Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 106 DEINTERLACE_SAMPLER_STATE Format: U8 7:0 FMD Temporal Difference Threshold Format: U8 6 31:24 FMD #1 Vertical Difference Threshold Format: U8 23:16 FMD #2 Vertical Difference Threshold Format: U8 15:14 CAT Threshold 1 Default Value: 0 Format: U2 13:8 FMD Tear Threshold Format: U6 7 MCDI Enable Use Motion Compensated Deinterlace algorithm. Ignored if DI Enable is off. 6 Progressive DN Format: Enable Indicates that the denoise algorithm should assume progressive input when filtering neighboring pixels. DI Enable must be disabled when this field is enabled Value Name 0 DN assumes interlaced video and filters alternate lines together 1 DN assumes progressive video and filters neighboring lines together 5 DN/DI First Frame Format: Enable Indicates that this is the first frame of the stream, so previous clean is not available Value Name 0 Not first field; previous clean surface state is valid 1 First field; previous clean surface state is invalid 4 DN/DI Stream ID Format: U1 Distinguishes between the two simultaneous streams that are supported. Used to update the GNE and FMD counters for that stream. 3 DN/DI Top First Format: Enable Indicates the top field is first in sequence, otherwise bottom is first Value Name 0 Bottom field occurs first in sequence 1 Top field occurs first in sequence 2 DI Partial Format: Enable If DI Enable and DI Partial are both enabled, the deinterlacer will output the partial VDI writeback message. Value Name 0 Output normal VDI writeback message (only if DI Enable is enabled also) 1 Output partial VDI writeback message (only if DI Enable is enabled also) 1 DI Enable Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 107 DEINTERLACE_SAMPLER_STATE Format: Enable Deinterlacer is bypassed if this is disabled: the output is the same as the input (same as a 2:2 cadence). FMD and STMM are not calculated and the values in the response message are 0. Value Name 0 Do not calculate DI 1 Calculate DI Programming Notes DI Enable and DN Enable cannot both be disabled 0 DN Enable Format: Enable Denoise is bypassed if this is low � BNE is still calculated and output, but the denoised fields are not. VDI does not read in the denoised previous frame but uses the pointer for the original previous frame. Value Name 0 Do not denoise frame 1 Denoise frame Programming Notes DI Enable and DN Enable cannot both be disabled 7 31:23 Column Width Minus 1 Format: U9 This field specifies the (column width-1) / stride in units of blocks (Each blocks has width 16 pixels). A column width * 16 that equals the width of the frame means the walker will walk to the end of the frame. The value of this field is interpreted as binary value + 1, so the range represents column widths of [1,512]. Value Name Description 0-511 22:19 Neighbor Pixel Threshold Default Value: 10 Format: U4 18 VDI Walker Enable Format: U1 Value Name 0 Walker Disabled. Use XY generated by Driver. 1 Walker Enabled. Use XY generated by VDIunit. Programming Notes When enabled frame size should be aligned to 16x8 in DN only mode and 16x4 in DI enabled mode When walker is enabled in a GT2 system, the MEDIA_OBJECT commands dispatching work to the VDI must use the Half-Slice Destination Select field to split the work between the two half-slices; the Half-Slice Destination Select must never be set to 00 (either half-slice). 17:16 FMD for 2nd field of previous frame Format: U2 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 108 DEINTERLACE_SAMPLER_STATE Value Name 0 Deinterlace (not progressive output) 1 Put together with previous field in sequence (1st field of previous frame) 2 Put together with next field in sequence (1st field of current frame) 15:10 MC Pixel Consistency Threshold Default Value: 25 Format: U6 9:8 FMD for 1st field of current frame Format: U2 Value Name 0 Deinterlace (not progressive output) 1 Put together with previous field in sequence (2nd field of previous frame) 2 Put together with next field in sequence (2nd field of current frame) 7:4 SAD Threshold B Default Value: 10 Format: U4 3:0 SAD Threshold A Default Value: 5 Format: U4 This state definition is used only by the deinterlace message. This state is stored as an array of up to 8 elements, each of which contains the dwords described here. The start of each element is spaced 8 dwords apart. The first element of the array is aligned to a 32-byte boundary. The index with range 0-7 that selects which element is being used is multiplied by 2 to determine the Sampler Index in the message descriptor. 2.12.3.3.1 Restrictions 1. VDIWalker can be enabled only when frame is aligned to block size of 16x4 if DI is enabled (interlaced) and 16x8 if DN only (Progressive). 2. When VDIWalker Frame Sharing is enabled driver should dispatch same number of Media Objects to both half slice by explicitly programming half slice destination select as 01 and 10 alternately (Note: Dispatch of threads should be in ping pong fashion to have load balance between both Halfslice and better L3 utilization). 3. For VDIWalker disabled mode (when frame size is not aligned to 16x4 or 16x8) it is recommended to have a simplified SW walker. Using Half Slice Destination Select 00 will affect performance significantly. 2.12.3.3.2 Dispatch of Media Object Commands for VDIWalker Enabled 1. Frame Sharing is Disabled: a. Program all MO commands to have Half Slice destination select as either “01” or “10” b. Y_stride programmed in Sampler State will be ignored Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 109 2. Frame Sharing Enabled: a. if Frame_height (in blocks) % 2 = 0 (where block height = 4 when DI enabled, 8 when DN only) dispatch MO in ping pong fashion b. Y_Stride of 0,1,2,3 is valid and VDIwalker will divide frame into multiple slices based on stride value c. if Frame_height (in blocks) % 2 > 0, then dispatch MO in ping pong fashion and all threads for blocks from residual row to be sent to Half Slice0 2.12.3.3.3 Psuedo Code for Media Object Dispatch //Variables Frame Height in pixels => frame_height Frame Width in pixels => frame_width Frame Height in Blocks => fh Frame Width in Blocks => fw Block Height in Pixels => block_height = Interlaced? 4 : 8 //Code fw = frame_width / 16; fh = frame_height / block_height; 2.12.3.3.4 Calculate Residual Blocks If ( fh % (2**stride) ) ≠ 0 { Y_Blocks_Remainder = (fh % (2**stride)) If (Y_Blocks_Remainder > (2**stride) / 2) { Y_Blocks_Remainder_HS1 = (2**stride) / 2 Y_Blocks_Remainder_HS2 = Y_Blocks_Remainder - (2**stride) / 2 } Else { Y_Blocks_Remainder_HS1 = Y_Blocks_Remainder Y_Blocks_Remainder_HS2 = 0 } } Else { Y_Blocks_Remainder_HS1 = 0 Y_Blocks_Remainder_HS2 = 0 } 2.12.3.3.5 Dispatch Media Object total_media_obj_cnt = fw * fh; reminder_media_obj_cnt_HS1 = fw * Y_Blocks_Remainder_HS1; reminder_media_obj_cnt_HS2 = fw * Y_Blocks_Remainder_HS2; ping_pong_media_obj_cnt = total_media_obj_cnt – (reminder_media_obj_cnt_HS1 + reminder_media_obj_cnt_HS1); Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 110 for ( i = 0; i < ping_pong_media_obj_cnt; i++) { if ( i % 2 == 0) { dispatch_media_object_hs1; } else { dispatch_media_object_hs2; } } for ( i = 0; i < reminder_media_obj_cnt_HS1; i++) { dispatch_media_object_hs1; } for ( i = 0; i < reminder_media_obj_cnt_HS2; i++) { dispatch_media_object_hs2; } 2.12.4 SAMPLER_8x8_STATE SAMPLER_8x8_STATE Exists If: MessageType == 'Sample_8x8' Default 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, Value: 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 The 8x8 coefficients and other state used by the sample_8x8 message are stored as indirect state, pointed to by a field in SAMPLER_STATE. There are four different tables loaded using this structure (0X, 0Y, 1X, and 1Y). Each table is stored as an array of 17 elements, each with either 4 or 8 coefficients. DWord Bit Description 0 31:24 Table 0X Filter Coefficient[0,3] Format: S1.6 In 2’s complement format Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 111 SAMPLER_8x8_STATE Description Project Range: [-2.0, +2.0) 23:16 Table 0X Filter Coefficient[0,2] Format: S1.6 In 2’s complement format Range: [-1, +1) 15:8 Table 0X Filter Coefficient[0,1] Format: S1.6 In 2’s complement format Range = [-2-1, +2-1) Programming Notes Must be zero if the format is R10G10B10A2_UNORM or R8G8B8A8_UNORM. 7:0 Table 0X Filter Coefficient[0,0] Format: S1.6 In 2's complement format Range = [-2-2, +2-2) Programming Notes Must be zero if the format is R10G10B10A2_UNORM or R8G8B8A8_UNORM 1 31:24 Table 0X Filter Coefficient[0,7] Format: S1.6 In 2's complement format Range = [-2-2, +2-2) 23:16 Table 0X Filter Coefficient[0,6] Format: S1.6 In 2's complement format Range = [-2-1, +2-1) 15:8 Table 0X Filter Coefficient[0,5] Format: S1.6 In 2's complement format Range: [-1, +1) 7:0 Table 0X Filter Coefficient[0,4] Format: S1.6 In 2's complement format Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 112 SAMPLER_8x8_STATE Description Project Range: [-2.0, +2.0) 2..3 31:24 Table 0Y Filter Coefficient[0,7] Format: S1.6 In 2's complement format Range = [-2-2, +2-2) 23:16 Table 0Y Filter Coefficient[0,6] Format: S1.6 In 2's complement format Range = [-2-1, +2-1) 15:8 Table 0Y Filter Coefficient[0,5] Format: S1.6 In 2's complement format Range: [-1, +1) 7:0 Table 0Y Filter Coefficient[0,4] Format: S1.6 In 2's complement format Description Project Range: [-2.0, +2.0) 4 31:24 Table 1X Filter Coefficient[0,3] Format: S1.6 In 2's complement format Range: [0.0, +2.0) 23:16 Table 1X Filter Coefficient[0,2] Format: S1.6 In 2's complement format Range: [-1, +1) 15 Adaptive Filter for all channels Only to be enabled if 8-tap Adaptive filter mode is on. Else it should be disabled. Value Name 1 Enable adaptive filter on UV/RB channels 0 Disable adaptive filter on UV/RB channels 14 Enable RGB Adaptive for RGB input only : This should be always set to 0 for YUV input and can be enabled/disabled for RGB input. This should be enabled only if we enable 8-tap adaptive filter for RGB input Value Name 1 Enable the RGB Adaptive filter using the equation (Y=(R+2G+B)>>2) Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 113 SAMPLER_8x8_STATE 0 Disable the RGB Adaptive equation and use G-Ch directly for adaptive filter 13:0 Reserved Format: MBZ 5 31:16 Reserved Format: MBZ 15:8 Table 1X Filter Coefficient[0,5] Format: S1.6 In 2's complement format Range: [-1, +1) 7:0 Table 1X Filter Coefficient[0,4] Format: S1.6 In 2's complement format Range: [0.0, +2.0) 6..7 31:16 Reserved Format: MBZ 15:8 Table 1Y Filter Coefficient[0,5] Format: S1.6 In 2's complement format Range: [-1, +1) 7:0 Table 1Y Filter Coefficient[0,4] Format: S1.6 In 2's complement format Range: [0.0, +2.0) 8..15 31:0 Filter Coefficient[1,7:0] 16..23 31:0 Filter Coefficient[2,7:0] 24..31 31:0 Filter Coefficient[3,7:0] 32..39 31:0 Filter Coefficient[4,7:0] 40..47 31:0 Filter Coefficient[5,7:0] 48..55 31:0 Filter Coefficient[6,7:0] 56..63 31:0 Filter Coefficient[7,7:0] 64..71 31:0 Filter Coefficient[8,7:0] 72..79 31:0 Filter Coefficient[9,7:0] 80..87 31:0 Filter Coefficient[10,7:0] 88..95 31:0 Filter Coefficient[11,7:0] 96..103 31:0 Filter Coefficient[12,7:0] 104..111 31:0 Filter Coefficient[13,7:0] 112..119 31:0 Filter Coefficient[14,7:0] 120..127 31:0 Filter Coefficient[15,7:0] 128..135 31:0 Filter Coefficient[16,7:0] 136 31:24 Default Sharpness Level Format: U8 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 114 SAMPLER_8x8_STATE When adaptive scaling is off, determines the balance between sharp and smooth scalers. Value Name 0 Contribute 1 from the smooth scalar 255 Contribute 1 from the sharp scalar 23:16 Max Derivative 4 Pixels Format: U8 Used in adaptive filtering to specify the lower boundary of the smooth 8 pixel area. 15:8 Max Derivative 8 Pixels Format: U8 Used in adaptive filtering to specify the lower boundary of the smooth 8 pixel area. 7 Reserved Format: MBZ 6:4 Transition Area with 4 Pixels Format: U3 Used in adaptive filtering to specify the width of the transition area for the 4 pixel calculation. 3 Reserved Format: MBZ 2:0 Transition Area with 8 Pixels Format: U3 Used in adaptive filtering to specify the width of the transition area for the 8 pixel calculation. 137 31:23 Reserved Format: MBZ 22 Bypass X Adaptive Filtering Format: Disable When disabled, the X direction will use Default Sharpness Level to blend between the smooth and sharp filters rather than the calculated value. Value Name 1 Disable X adaptive filtering 0 Enable X adaptive filtering 21 Bypass Y Adaptive Filtering Format: Disable When disabled, the Y direction will use Default Sharpness Level to blend between the smooth and sharp filters rather than the calculated value. Value Name 1 Disable X adaptive filtering 0 Enable X adaptive filtering 20:2 Reserved Format: MBZ 1 Reserved Project: Format: MBZ 0 Reserved Project: Format: MBZ Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 115 2.12.5 SAMPLER_BORDER_COLOR_STATE SAMPLER_BORDER_COLOR_STATE Default Value: 0x00000000, 0x00000000, 0x00000000, 0x00000000 This structure is pointed to by a field in SAMPLER_STATE. The interpretation of the border color depends on the Texture Border Color Mode field in SAMPLER_STATE as follows:In DX9 mode, the border color is 8-bit UNORM format, regardless of the surface format chosen. For surface formats with one or more channels missing (i.e. R5G6R5_UNORM is missing the alpha channel), the value from the border color, if selected, will be used even for the missing channels.In DX10/OGL mode, the format of the border color is R32G32B32A32_FLOAT, regardless of the surface format chosen. For surface formats with one or more channels missing, the value from the border color is not used for the missing channels, resulting in these channels resulting in the overall default value (0 for colors and 1 for alpha) regardless of whether border color is chosen. The surface formats with “L” and “I” have special behavior with respect to the border color. The border color value used for the replicated channels (RGB for “L” formats and RGBA for “I” formats) comes from the red channel of border color. In these cases, the green and blue channels, and also alpha for “I”, of the border color are ignored.The format of this state depends on the Texture Border Color Mode field. Programming Notes  DX9 mode is not supported for surfaces with more than 16 bits in any channel, other than 32-bit float formats which are supported.  The conditions under which this color is used depend on the Surface Type – 1D/2D/3D surfaces use the border color when the coordinates extend beyond the surface extent; cube surfaces use the border color for “empty” (disabled) faces.  The border color itself is accessed through the texture cache hierarchy rather than the state cache hierarchy. Thus, if the border color is changed in memory, the texture cache must be invalidated and the state cache does not need to be invalidated.  MAPFILTER_MONO: The border color is ignored. Border color is fixed at a value of 0 by hardware. DWord Bit Description 0 31:24 Border Color Alpha Format: UNORM8 Texture Border Color Mode = DX9 23:16 Border Color Blue Format: UNORM8 Texture Border Color Mode = DX9 15:8 Border Color Green Format: UNORM8 Texture Border Color Mode = DX9 31:0 Border Color Red Format: IEEE_FP Texture Border Color Mode = DX10/OGL 7:0 Border Color Red Format: UNORM8 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 116 SAMPLER_BORDER_COLOR_STATE Texture Border Color Mode = DX9 1 31:0 Border Color Green Format: IEEE_FP Texture Border Color Mode = DX10/OGL 2 31:0 Border Color Blue Format: IEEE_FP Texture Border Color Mode = DX10/OGL 3 31:0 Border Color Alpha Format: IEEE_FP Texture Border Color Mode = DX10/OGL 2.12.5.1 SAMPLER_BORDER_COLOR_STATE For, if border color is used, all formats must be provided. Hardware will choose the appropriate format based on Surface Format and Texture Border Color Mode. The values represented by each format should be the same (other than being subject to range-based clamping and precision) to avoid unexpected behavior. DWord Bit Description 0 31:24 Border Color Alpha Format = UNORM8 23:16 Border Color Blue Format = UNORM8 15:8 Border Color Green Format = UNORM8 7:0 Border Color Red Format = UNORM8 1 31:0 Border Color Red Format = IEEE_FP 2 31:0 Border Color Green Format = IEEE_FP 3 31:0 Border Color Blue Format = IEEE_FP 4 31:0 Border Color Alpha Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 117 DWord Bit Description Format = IEEE_FP 5 31:16 Border Color Green Format = FLOAT16 15:0 Border Color Red Format = FLOAT16 6 31:16 Border Color Alpha Format = FLOAT16 15:0 Border Color Blue Format = FLOAT16 7 31:16 Border Color Green Format = UNORM16 15:0 Border Color Red Format = UNORM16 8 31:16 Border Color Alpha Format = UNORM16 15:0 Border Color Blue Format = UNORM16 9 31:16 Border Color Green Format = SNORM16 15:0 Border Color Red Format = SNORM16 10 31:16 Border Color Alpha Format = SNORM16 15:0 Border Color Blue Format = SNORM16 11 31:24 Border Color Alpha Format = SNORM8 23:16 Border Color Blue Format = SNORM8 15:8 Border Color Green Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 118 DWord Bit Description Format = SNORM8 7:0 Border Color Red Format = SNORM8 2.12.6 3DSTATE_CHROMA_KEY 3DSTATE_CHROMA_KEY Project: All Source: RenderCS Length Bias: 2 The 3DSTATE_CHROMA_KEY instruction is used to program texture color/chroma-key key values. A table containing four set of values is supported. The ChromaKey Index sampler state variable is used to select which table entry is associated with the map. Texture chromakey functions are enabled and controlled via use of the ChromaKey Enable texture sampler state variable.Texture Color Key (keying on a paletted texture index) is not supported. DWord Bit Description 0 31:29 Command Type Default Value: 3h GFXPIPE Format: Opcode 28:27 Command SubType Default Value: 3h GFXPIPE_3D Format: Opcode 26:24 3D Command Opcode Default Value: 1h 3DSTATE Format: Opcode 23:16 3D Command Sub Opcode Default Value: 04h 3DSTATE_CHROMA_KEY Format: Opcode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 2h Excludes DWord (0,1) Format: =n Total Length - 2 1 31:30 ChromaKey Table Index Project: All Format: U2 index Selects which entry in the ChromaKey table is to be loaded Value Name [0,3] 29:0 Reserved Project: All Format: MBZ Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 119 3DSTATE_CHROMA_KEY 2 31:0 ChromaKey Low Value This field specifies the “low” (minimum) value of the chroma key range. Texel samples are considered “matching the key” if each component of the texel falls within the (inclusive) chroma range.See ChromaKey High Value for further format, programming info. 3 31:0 ChromaKey High Value This field specifies the “high” (maximum) value of the chroma key range. Texel samples are considered “matching the key” if each component of the texel falls within the (inclusive) chroma range. Programming Notes ChromaKey values are specified using 8-bit channels. When using surface formats with less than 8 bits per channel, the device will expand channels by replicating the required number of MSBs into the LSBs of each channel. Software must account for this conversion when it programs Chromakey Low/High Values (e.g., by performing the same replication). For channels that do not exist in the actual surface (e.g., Alpha channel for non-ARGB maps), software must explicitly program full range high/low values (High=FFh, Low=0h for formats using unsigned chroma key values, High=7Fh, Low=FFh for formats using sign magnitude chroma key values) in order to effectively remove the comparison of that field from the ChromaKey function. For channels in SNORM format in the surface format, the value in the high/low value for that channel is interpreted in sign magnitude format. Negative zero value is not supported (use positive zero instead). For channels with mixed UNORM/SNORM formats (i.e. R5G5_SNORM_B6_UNORM), the ChromaKey is programmed as if all channels are SNORM. YUV ChromaKey will use an interpolated chrominance value from the map for comparison to the chroma key values for those texels without chrominance due to downsampling. The chrominance value used is the average of values to the left and right of the texel in question. It is UNDEFINED to program any component of the ChromaKey High Value to be less than the corresponding component of ChromaKey Low Value. Format = interpreted according to associated texel format “class”: Only the surface formats listed as supported for chroma key in the surface formats table can be used with this feature. Use of any other surface format with chroma key enabled is UNDEFINED. Surface Format 31:24 23:15 16:8 7:0 ARGB and BC (DXT) formats A R G B YCrCb formats A Cr Y Cb 2.12.7 3DSTATE_SAMPLER_PALETTE_LOAD0 3DSTATE_SAMPLER_PALETTE_LOAD0 Project: All Source: RenderCS Length Bias: 2 Description Project The 3DSTATE_SAMPLER_PALETTE_LOAD0 instruction is used to load 32-bit values into the first texture palette. The texture palette is used whenever a texture with a paletted format (containing “Px [palette0]”) is referenced by the sampler. This instruction is used to load all or a subset of the 256 entries of the first palette. Partial loads always start from the first (index 0) entry. DWord Bit Description 0 31:29 Command Type Default Value: 3h GFXPIPE Format: Opcode Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 120 3DSTATE_SAMPLER_PALETTE_LOAD0 28:27 Command SubType Default Value: 3h GFXPIPE_3D Format: Opcode 26:24 3D Command Opcode Default Value: 1h 3DSTATE Format: Opcode 23:16 3D Command Sub Opcode Default Value: 02h 3DSTATE_SAMPLER_PALETTE_LOAD0 Format: Opcode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 0h Excludes DWord (0,1) Format: =n Total Length - 2 1..n 31:24 Palette Alpha[0:N-1] Project: All Format: U8 Alpha channel loaded into the Nth entry of the texture color palette. 23:16 Palette Red[0:N-1] Project: All Format: U8 Alpha channel loaded into the Nth entry of the texture color palette. 15:8 Palette Green[0:N-1] Project: All Format: U8 Alpha channel loaded into the Nth entry of the texture color palette. 7:0 Palette Blue[0:N-1] Project: All Format: U8 Alpha channel loaded into the Nth entry of the texture color palette. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 121 2.12.8 3DSTATE_MONOFILTER_SIZE 3DSTATE_MONOFILTER_SIZE Source: RenderCS Length Bias: 2 This state specifies the size of the filter which is used when filtering in MAPFILTER_MONO mode. DWord Bit Description 0 31:29 Command Type Default Value: 3h GFXPIPE Format: OpCode 28:27 Command SubType Default Value: 3h GFXPIPE_3D Format: OpCode 26:24 3D Command Opcode Default Value: 1h 3DSTATE_NONPIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 11h 3DSTATE_MONOFILTER_SIZE Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 0h Excludes DWord (0,1) Project: All Format: =n Total Length - 2 1 31:6 Reserved Project: All Format: MBZ 5:3 Monochrome Filter Width Project: All Format: U3 This field specifies the width of the monochrome filter. It is ignored if the monochrome filter is not enabled. Value Name [1,7] 2:0 Monochrome Filter Height Project: All Format: U3 This field specifies the height of the monochrome filter. It is ignored if the monochrome filter is not enabled. Value Name [1,7] Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 122 2.13 Messages Restrictions:  Use of any message to the Sampling Engine function with the End of Thread bit set in the message descriptor is not allowed. 2.13.1 Initiating Message Execution Mask SIMD16. The 16-bit execution mask forms the valid pixel signals. This determines which pixels are sampled and results returned to the GRF registers. Samples for invalid pixels are not overwritten in the GRF. However, if LOD needs to be computed for a subspan based on the message type and MIP filter mode and at least one pixel in the subspan being valid, the sampling engine assumes that the parameters for the upper left, upper right, and lower left pixels in the subspan are valid regardless of the execution mask, as these are needed for the LOD computation. SIMD8. The lower 8 bits of the execution mask forms the valid pixel signals. If LOD needs to be computed based on MIP filter mode and at least one pixel in the subspan being valid, the sampling engine assumes that the parameters for the upper left, upper right, and lower left pixels in the subspan are valid regardless of the execution mask, since these are needed for the LOD computation. SIMD4x2. The lower 8 bits of the execution mask is interpreted in groups of four. If any of the high 4 bits are asserted, that sample is valid. If any of the low 4 bits are asserted, that sample is valid. The Write Channel Mask rather than the execution mask determines which channels are written back to the GRF. SIMD32. The execution mask is ignored, all pixels are considered valid and all channels are returned regardless of the execution mask. 2.13.1.1 Message Descriptor Bit Description 19 Header Present: Specifies whether the message includes a header phase. If the header is not present (this field is zero), all of the fields normally contained in the header are assumed to be 0. Format = Enable 18:17 SIMD Mode: Specifies the SIMD mode of the message being sent. Format = U2 0 = SIMD4x2 1 = SIMD8 2 = SIMD16 3 = SIMD32/64 16:12 Message Type: Specifies the type of message being sent. Format = U5 Refer to the table in section Payload Parameter Definition for encoding details. 11:8 Sampler Index: Specifies the index into the sampler state table. Ignored for “ld”, “resinfo”, “sampleinfo” and Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 123 Bit Description “cache_flush”type messages. Format = U4 Range = [0,15] Programming Notes:  for the deinterlace message, this field must be a multiple of 2 (even)  for the sample_8x8 message, this field must be a multiple of 4 7:0 Binding Table Index: Specifies the index into the binding table. Ignored for “cache_flush” type messages. Format = U8 Range = [0,255] 2.13.1.2 Message Header The message header for the sampling engine is the same regardless of the message type. If the header is not present (only), behavior is as if the message was sent with all fields in the header set to zero (write channel masks are all enabled and offsets are zero). When Response length is 0 for sample_8x8 message then the data from sampler is directly written out to memory using media write message. DWord Bit Description M0.7 31:0 M0.6 31:0 M0.5 31:5 Reserved 4:0 Reserved M0.4 31:0 Reserved M0.3 31:5 Sampler State Pointer: Specifies the 32-byte aligned pointer to the sampler state table. This field is ignored for “ld” and “resinfo” message types. This pointer is relative to the General State Base Address. Format = GeneralStateOffset[31:5] Ignored 4:0 Ignored M0.2 31:24 Ignored 23 Reserved 21:20 Ignore 19:18 SIMD32/64 Output Format Control The contents of this field are ignored. The “16 bit Full” mode is always selected. 17 17:16 Gather4 Source Channel Select: Selects the source channel to be sampled in the gather4* messages. Ignored for other message types. 0: Red channel 1: Green channel 2: Blue channel 3: Alpha channel Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 124 DWord Bit Description Programming Note:  For gather4*_c messages, this field must be set to 0 (Red channel). 16 Force LOD to Zero: If this bit is enabled, the calculated LOD is replaced with zero. The LOD is replaced just before entering the pseudocode in section LOD Computation Pseudocode, therefore the LOD is still subject to bias, overriding by sample_l delivered LOD, and clamping. Format = Enable Ignored 15 Alpha Write Channel Mask: Enables the alpha channel to be written back to the originating thread. 0: Alpha channel will be written back 1: Alpha channel will not be written back Programming Notes:  a message with all four channels masked is not allowed.  this field is ignored for the sample_unorm*. The write channel mask is generated from the message type itself.  this field is ignored for the deinterlace message.  this field must be set to zero for sample_8x8 in VSA mode. 14 Blue Write Channel Mask: See Alpha Write Channel Mask 13 Green Write Channel Mask: See Alpha Write Channel Mask 12 Red Write Channel Mask: See Alpha Write Channel Mask 11:8 U Offset: the u offset from the _aoffimmi modifier on the “sample” or “ld” instruction in DX10. Must be zero if the Surface Type is SURFTYPE_CUBE or SURFTYPE_BUFFER. Must be set to zero if _aoffimmi is not specified. Format is S3 2’s complement. Programming Note:  this field is ignored for the sample_unorm*, sample_8x8, and deinterlace messages  this field is ignored if the “offu” parameter is included in the gather4* messages 7:4 V Offset: the v offset from the _aoffimmi modifier on the “sample” or “ld” instruction in DX10. Must be zero if the Surface Type is SURFTYPE_CUBE or SURFTYPE_BUFFER. Must be set to zero if _aoffimmi is not specified. Format is S3 2’s complement. Programming Note:  this field is ignored for the sample_unorm*, sample_8x8, and deinterlace messages  this field is ignored if the “offu” parameter is included in the gather4* messages 3:0 R Offset: the r offset from the _aoffimmi modifier on the “sample” or “ld” instruction in DX10. Must be zero if the Surface Type is SURFTYPE_CUBE or SURFTYPE_BUFFER. Must be set to zero if _aoffimmi is not specified. Format is S3 2’s complement. Programming Note:  this field is ignored for the sample_unorm*, sample_8x8, and deinterlace messages M0.1 31:0 Ignored Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 125 DWord Bit Description M0.0 31:0 Ignored 2.13.1.3 Payload Parameter Definition The table below shows all of the messages supported by the sampling engine. The message type field in the message descriptor in combination with the message length determines which message is being sent. The table defines all of the parameters sent for each message type. The position of the parameters in the payload is given in the section following corresponding to the SIMD mode given in the table. The instruction column indicates the DX10 shader instructions expected to be translated to each message type. All parameters are of type IEEE_Float, except those in the ld and resinfo instruction message types, which are of type S31. Any parameter indicated with a blank entry in the table is unused. A message register containing only unused parameters not included as part of the message. The response lengths given below assume all channels are unmasked. SIMD16 messages with masked channels will have reduced response length. 2.13.1.3.1 Payload Parameter Definition The table below shows all of the message types supported by the sampling engine. The Message Type field in the message descriptor determines which message is being sent. The SIMD Mode field determines the number of instances (i.e. pixels) and the formatting of the initiating and writeback messages. The Header Present field determines whether a header is delivered as the first phase of the message or the default header from R0 of the thread’s dispatch is used. The Message Length field is used to vary the number of parameters sent with each message. Higher-numbered parameters are optional, and default to a value of 0 if not sent but needed for the surface being sampled. The message lengths are computed as follows, where “N” is the number of parameters (“N” is rounded up to the next multiple of 4 for SIMD4x2), and “H” is 1 if the header is present, 0 otherwise. The maximum message length allowed to the sampler is 11. SIMD Mode Message Length SIMD4x2 H + (N/4) SIMD8* H+N SIMD16 H + (2*N) The response lengths are computed as follows: SIMD Mode Response Length SIMD4x2 1 sample+killpix 5 SIMD8 all other message types 4 SIMD16 8* * For SIMD16, phases in the response length are reduced by 2 for each channel that is masked. SIMD16 messages with six or more parameters exceed the maximum message length allowed, in which case they are not supported. This includes some forms of sample_b_c, sample_l_c, and gather4_po_c message types. Note that even for these messages, if 5 or fewer parameters are included in the message, the SIMD16 form of the message is allowed. SIMD16 forms of sample_d and sample_d_c are not allowed, regardless of the number of parameters sent. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 126 SIMD8 and SIMD16 Messages: Message Type mnemonic parameters 0 1 2 3 4 5 6 7 8 9 10 00000 sample u v r ai mlod* 00001 sample_b bias u v r ai mlod* 00010 sample_l lod u v r ai 00011 sample_c ref u v r ai mlod* 00100 sample_d u dudx dudy v dvdx dvdy r drdx drdy ai mlod* 00101 sample_b_c ref bias u v r ai 00110 sample_l_c ref lod u v r ai 00111 ld u lod v r 00111 ld † u v lod r 01000 gather4 u v r ai 01001 LOD u v r ai 01010 resinfo lod 01011 sampleinfo 01011 sampleinfo † x 01100 sample+killpix u v r 10000 gather4_c ref u v r ai 10001 gather4_po u v offu offv r 10010 gather4_po_c ref u v offu offv r 10100 sample_d_c ref u dudx dudy v dvdx dvdy r drdx drdy ai 11100 ld2dms_w si mcsl mcsh u v r lod * 10110 sample_min u v 10111 sample_max u v 11101 ld_mcs u v r lod * 11110 ld2dms si mcs u v r lod * 11111 Id2dss ssi u v r lod * 11000 sample_lz u v r ai 11001 sample_c_lz ref u v r ai 11010 ld_lz u v r SIMD4x2 Messages: Message Type mnemonic parameters 0 1 2 3 4 5 6 7 8 9 10 00010 sample_l u v r ai lod 00100 sample_d u v r ai dudx dudy dvdx dvdy drdx drdy mlod* 00110 sample_l_c u v r ai ref lod 00111 ld u v r lod 01000 gather4 u v r ai 01010 resinfo lod 01011 sampleinfo 10000 gather4_c u v r ai ref 10001 gather4_po u v r ai offu offv 10010 gather4_po_c u v r ref offu offv 10100 sample_d_c u v r ai dudx dudy dvdx dvdy drdx drdy ref Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 127 11100 ld2dms_w u v r lod * si mcsl mcsh 11101 ld_mcs u v r lod * 11110 ld2dms u v r lod * si mcs SIMD32/SIMD64 Messages: Message Type mnemonic Payload Layout Message Length Response Length 00000 sample_unorm Pixel Shader H+1 8 ** 00010 sample_unorm+killpix Pixel Shader H+1 9 ** 00011 sample_8x8 Pixel Shader H+1 16 * 01000 deinterlace Pixel Shader H+1 † 01100 sample_unorm Media H+1 8 ** 01010 sample_unorm+killpix Media H+1 9 ** 01011 sample_8x8 Media H+1 16 * 11111 cache_flush no payload 1 1 * For sample_8x8, phases in the response length are reduced by 4 for each channel that is masked. ** For sample_unorm, phases in the response length are reduced by 2 for each channel that is masked. † For deinterlace, response length depending on certain state fields. Refer to writeback message definition for details. 2.13.1.4 Message Types The behavior of each message type is as follows: Message Type Description sample The surface is sampled using the indicated sampler state. LOD is computed using gradients between adjacent pixels. One, two, or three parameters may be specified depending on how many coordinate dimensions the indicated surface type uses. Extra parameters specified are ignored. Missing parameters are defaulted to 0. Programming Notes:  The Surface Type of the associated surface must be SURFTYPE1D, SURFTYPE_2D, SURFTYPE_3D, or SURFTYPE_CUBE.  The Surface Format of the associated surface cannot be MONO8.  If the Surface Format of the associated surface is UINT or SINT, the Surface Type cannot be SURFTYPE_3D or SURFTYPE_CUBE and Address Control Mode cannot be CLAMP_BORDER or HALF_BORDER.  sample is not supported in SIMD4x2 mode.  :Number of Multisamples on the associated surface must be MULTISAMPLECOUNT_1. sample+killpix The surface is sampled as in the sample message type. An additional register is returned after the sample results which contains the kill pixel mask. This message type is required to allow the result of a chroma key enabled sampler in KEYFILTER_KILL_ON_ANY_MATCH mode to affect the final pixel mask. Programming Notes:  The Surface Type of the associated surface must be SURFTYPE1D, SURFTYPE_2D, SURFTYPE_3D, or SURFTYPE_CUBE.  The Surface Format of the associated surface cannot be MONO8.  If the Surface Format of the associated surface is UINT or SINT, the Surface Type cannot be SURFTYPE_3D or SURFTYPE_CUBE and Address Control Mode cannot be Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 128 Message Type Description CLAMP_BORDER or HALF_BORDER.  sample+killpix is supported only in SIMD8 mode.  Number of Multisamples on the associated surface must be MULTISAMPLECOUNT_1. sample_b The surface is sampled using the indicated sampler state. LOD is computed using gradients between adjacent pixels, then the value in the parameter is added to the LOD for each pixel. The LOD bias delivered in the bias parameter is restricted to a range of [-16.0, +16.0). Values outside this range produce undefined results. Programming Notes:  The Surface Type of the associated surface must be SURFTYPE1D, SURFTYPE_2D, SURFTYPE_3D, or SURFTYPE_CUBE.  The Surface Format of the associated surface cannot be MONO8  If the Surface Format of the associated surface is UINT or SINT, the Surface Type cannot be SURFTYPE_3D or SURFTYPE_CUBE and Address Control Mode cannot be CLAMP_BORDER or HALF_BORDER  sample_b is not supported in SIMD4x2 mode.  Number of Multisamples on the associated surface must be MULTISAMPLECOUNT_1. sample_l The surface is sampled using the indicated sampler state. LOD is not computed, but instead is taken from the lod parameter. sample_lz Programming Notes:  The Surface Type of the associated surface must be SURFTYPE1D, SURFTYPE_2D, SURFTYPE_3D, or SURFTYPE_CUBE.  If the Surface Format of the associated surface is UINT or SINT, the Surface Type cannot be SURFTYPE_3D or SURFTYPE_CUBE and Address Control Mode cannot be CLAMP_BORDER or HALF_BORDER.  Number of Multisamples on the associated surface must be MULTISAMPLECOUNT_1. sample_c The surface is sampled using the indicated sampler state. All four coordinates must be specified, however v and r may not be used depending on the indicated surface type. The ai sample_c_lz parameter indicates the array index for a cube surface.The ref parameter specifies the reference value that is compared against the red channel of the sampled surface, and the texel is replaced with either white or black depending on the result of the comparison. The WGF sample_c_lz instruction is implemented by issuing the sample_c message with Force LOD to Zero enabled in the message header or by issuing the sample_l_c message with the LOD parameter set to zero. Programming Notes:  The Surface Type of the associated surface must be SURFTYPE1D, SURFTYPE_2D, or SURFTYPE_CUBE.  The Surface Format of the associated surface must be indicated as supporting shadow mapping as indicated in the surface format table.  With sample_c, MIPFILTER_LINEAR, MAPFILTER_LINEAR, MAPFILTER_ANISOTROPIC are allowed even for surface formats that are listed as not supporting filtering in the surface formats table.  Use of the SIMD4x2 form of sample_c without Force LOD to Zero enabled in the message header is not allowed, as it is not possible for the hardware to compute LOD for Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 129 Message Type Description SIMD4x2 messages. For, sample_c is not supported in SIMD4x2 mode.  Use of sample_c with DX9 Texture Border Color Mode and either of the following is undefined:  any applicable Address Control Mode (depending on Surface Type) is set to TEXCOORDMODE_CLAMP_BORDER or TEXCOORDMODE_HALF_BORDER  Surface Type is SURFTYPE_CUBE and any Cube Face Enable is disabled  Use of sample_c with SURFTYPE_CUBE surfaces is undefined with the following surface formats: I24X8_UNORM, L24X8_UNORM, A24X8_UNORM, I32_FLOAT, L32_FLOAT, A32_FLOAT.  Number of Multisamples on the associated surface must be MULTISAMPLECOUNT_1. sample_b_c This is a combination of sample_b and sample_c. Both the LOD bias and reference values are delivered. All restrictions applying to both sample_b and sample_c must be honored. sample_l_c This is a combination of sample_l and sample_c. Both the LOD and reference values are delivered. All restrictions applying to both sample_l and sample_c must be honored. However, unlike sample_c, sample_l_c is allowed as a SIMD4x2 message. Programming Notes: sample_g The surface is sampled using the indicated sampler state. LOD is computed using the gradients present in the message. The r coordinate and its gradients are required only for surface types sample_d that use the third coordinate. Usage of this message type on cube surfaces assumes that the u, v, and gradients have already been transformed onto the appropriate face, but still in [-1,+1] range. The r coordinate contains the faceid, and the r gradients are ignored by hardware. Programming Notes:  The Surface Type of the associated surface must be SURFTYPE1D, SURFTYPE_2D, SURFTYPE_3D, or SURFTYPE_CUBE.  The Surface Format of the associated surface cannot be MONO8.  If the Surface Format of the associated surface is UINT or SINT, the Surface Type cannot be SURFTYPE_3D or SURFTYPE_CUBE and Address Control Mode cannot be CLAMP_BORDER or HALF_BORDER.  Number of Multisamples on the associated surface must be MULTISAMPLECOUNT_1. This is a combination of sample_g and sample_c. Both the gradients for calculating LOD and sample_g_c reference values are delivered. All restrictions applying to both sample_g and sample_c must be sample_d_c honored. However, unlike sample_c, sample_g_c is allowed as a SIMD4x2 message. resinfo The surface indicated in the surface state is not sampled. Instead, the width, height, depth, and MIP count of the surface are returned as indicated in the table below. The format of the returned data is UINT32 for. The width, height, and depth may be shifted right, per pixel, by the LOD value provided in the lod parameter to give the dimensions of the specified mip level. The lod parameter is an unsigned 32-bit integer in this mode (note that sending a signed 32-bit integer always has the same effect, as negative values are out-of-range when interpreted as unsigned integers). The Sampler State Pointer and Sampler Index are ignored. surface type red green blue alpha Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 130 Message Type Description SURFTYPE1D (Width+1)>>LOD 0 MIPCount Surface Array? Depth+1 : 0 SURFTYPE_2D (Width+1)>>LOD (Height+1)>>LOD MIPCount : Surface Array? Depth+1 : 0 SURFTYPE_3D (Width+1)>>LOD (Height+1)>>LOD (Depth+1)>>LOD MIPCount SURFTYPE_CUBE (Width+1)>>LOD (Height+1)>>LOD MIPCount Depth==0 ? 0 : Depth+1 : Surface Array ? Depth+1 : 0 undefined undefined undefined SURFTYPE_BUFFER undefined SURFTYPE_STRBUF Buffer size (from combined Depth/Height/Width) SURFTYPE_NULL 0 0 0 0 ld The surface is sampled using a default sampler state, indicated below. The lod parameter contains the LOD of the mip map to be sampled. If the message doesn’t include an lod ld2dms parameter, the message samples from LOD 0. The parameter si contains the sample index, Id2dms_w which is clamped to the number of samples on the surface (supported by some messages on ld_mcs only). The v and r channel may be ignored depending on the indicated surface type. All incoming values are unsigned 32-bit integers in this mode. The u, v, and r parameters contain Id2dss integer texel addresses on the LOD indicated in the parameter. The Sampler State Pointer and ld_lz Sampler Index are ignored. For these message types, the sampler state is defaulted as follows: •min, mag, and mip filter modes are “nearest” •all address control modes are “zero” (a special mode in which any texel off the map or outside the MIP range of the surface has a value of zero in all channels, except for surface formats without an alpha channel, which will return a value of one in the alpha channel) Errata:Address offset needs to be zero for ld2dms/ld2dss messages The mcs parameter in the ld2dms message defines the multisample control data and is used only to sample from a multisampled surface. The ld_mcs message uses the MCS Base Address and MCS Surface Pitch fields in SURFACE_STATE to determine the base address and pitch of the surface. Surface Format is overridden to R8_UINT if Number of Multisamples is 4, or R32_UINT if Number of Multisamples is 8. This message cannot be used on a non-multisampled surface. Otherwise, ld_mcs behaves like the ld message. If ld_mcs is issued on a surface with MCS disabled, this message returns zeros in all channels. The ssi parameter in the Id2dss message defines the sample slice that will be sampled from. Refer to the multisample storage format in the GPU Overview volume for more details. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 131 Message Type Description Programming Notes:  The Surface Type of the associated surface must be SURFTYPE1D, SURFTYPE_2D, SURFTYPE_3D, or SURFTYPE_BUFFER for the ld message.  The Surface Type of the associated surface must be SURFTYPE_2D for the ld_mcs , ld2dms , and Id2dss messages.  The Surface Format of the associated surface cannot be MONO8.  Number of Multisamples on the associated surface must be MULTISAMPLECOUNT_1 for the ld message type.  Errata: Surface formats R32G32B32X32_FLOAT, X32_TYPELESS_G8X24_UINT, R16G16B16X16_UNORM, R16G16B16X16_FLOAT, X24_TYPELESS_G8_UINT, L24X8_UNORM, L32_FLOAT, B8G8R8X8_UNORM, B8G8R8X8_UNORM_SRGB, R8G8B8X8_UNORM, R8G8B8X8_UNORM_SRGB, B10G10R10X2_UNORM, B5G6R5_UNORM, B5G6R5_UNORM_SRGB, L16_UNORM, R5G5_SNORM_B6_UNORM, L8_UNORM, L8_UNORM_SRGB, R1_UNORM, BC4_UNORM (DXT4/5) will return zero in the alpha channel, for out of bound case. sampleinfo only: The surface indicated in the surface state is not sampled. Instead, the number of samples (UINT32) and the sample position palette index (UINT32) for the surface are returned in the red and alpha channels respectively as UINT32 values. The sample position palette index returned in alpha is incremented by one from its value in the surface state. The Sampler State Pointer and Sampler Index are ignored. Programming Notes:  The Surface Type of the associated surface must be SURFTYPE_2D or SURFTYPE_NULL LOD only: The surface indicated in the surface state is not sampled. Instead, LOD is computed as if the surface will be sampled, using the indicated sampler state, and the clamped and unclamped LOD values are returned in the red and green channels, respectively, in FLOAT32 format. The blue and alpha channels are undefined, and can be masked to avoid returning them. LOD is computed using gradients between adjacent pixels. Three parameters are always specified, with extra parameters not needed for the surface being ignored. Programming Notes:  The Surface Type of the associated surface must be SURFTYPE1D, SURFTYPE_2D, SURFTYPE_3D, or SURFTYPE_CUBE.  The Surface Format of the associated surface cannot be MONO8  The Surface Format of the associated surface cannot be any UINT or SINT format.  LOD is not supported in SIMD4x2 mode.  Number of Multisamples on the associated surface must be MULTISAMPLECOUNT_1. gather4 The surface is sampled using bilinear filtering, regardless of the filtering mode specified in the sampler state. For SURFTYPE_2D LOD is forced to zero before sampling. The samples are not gather4_po filtered, but instead the four samples are returned directly in the sample’s corresponding four (load4) channels as follows: upper left sample = alpha channel upper right sample = blue channel lower left sample = red channel lower right sample = green channel Two or three parameters may be specified depending on how many coordinate dimensions the Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 132 Message Type Description indicated surface type uses. Extra parameters specified are ignored. Missing parameters default to 0. The gather4_po message has offu and offv parameters, which contain texel-space offsets that override the U/V Offset fields in the message header. Unlike the message header fields however, these offsets have a wider range [-32,+31], and can differ per pixel or sample. The format of the data is 32-bit 2’s complement signed integer, but hardware only interprets the least significant 6 bits of each value, treating it as a 6-bit 2’s complement signed integer. Programming Notes:  The Surface Type of the associated surface must be SURFTYPE_2D or SURFTYPE_CUBE. If the message type is gather4_po, only SURFTYPE_2D is allowed.  The Surface Format of the associated surface cannot be MONO8  The Surface Format of the associated surface cannot be any UINT or SINT format.  The channel selected is determined by the Gather4 Source Channel Select field in the message header.  Mip Mode Filter must be set to MIPFILTER_NONE  Number of Multisamples on the associated surface must be MULTISAMPLECOUNT_1.  Use of gather4 or gather4_po with DX9 Border Color Mode and either of the following is underfined: o any applicable Address Control Mode (depending on Surface Type) is set to TEXCOORDMODE_CLAMP_BORDER or TEXCOORDMODE_HALF_BORDER o Surface Type is SURFTYPE_CUBE and any Cube Face Enable is disabled gather4_c only: The surface is sampled using bilinear filtering, regardless of the filtering mode specified in the sampler state. For SURFTYPE_2D LOD is forced to zero before sampling. The samples are gather4_po_c not filtered, but instead the four samples are returned, after being compared with the ref paramater as in the sample_c message. Each texel is replaced with either white or block depending on the result of the comparison. The four samples are returned in the sample’s corresponding four channels in the same mapping as the gather4 message. The offu and offv parameters in the gather4_po_c message cause offset override behavior as described in the gather4 message. Programming Notes:  The Surface Type of the associated surface must be SURFTYPE_2D or SURFTYPE_CUBE. If the message type is gather4_po_c, only SURFTYPE_2D is allowed.  The Surface Format of the associated surface must be one of the following: R32_FLOAT_X8X24_TYPELESS, R32_FLOAT, R24_UNORM_X8_TYPELESS, R16_UNORM.  The channel selected is determined by the Gather4 Source Channel Select field in the message header.  Mip Mode Filter must be set to MIPFILTER_NONE  Use of gather4_c or gather4_po_c with DX9 Border Color Mode and either of the following is underfined: o Surface Type is SURFTYPE_CUBE and any Cube Face Enable is disabled o any applicable Address Control Mode (depending on Surface Type) is set to Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 133 Message Type Description TEXCOORDMODE_CLAMP_BORDER or TEXCOORDMODE_HALF_BORDER  Number of Multisamples on the associated surface must be MULTISAMPLECOUNT_1. sample_unorm only: The surface is sampled using the indicated sampler state. 32 contiguous pixels in a 8-wide by 4-high arrangement are sampled. The U and V addresses for the upper left pixel is delivered in this message along with a Delta U and Delta V parameter. Given a pixel at (x,y) relative to the upper left pixel (where (0,0) is the upper left pixel), the U and V for that pixel are computed as follows: U(x,y) = U(0,0) + DeltaU * x V(x,y) = V(0,0) + DeltaV * y Programming Notes:  The Surface Type of the associated surface must be SURFTYPE_2D  The Surface Format of the associated surface must be UNORM with <= 8 bits per channel  The MIP Count, Depth, Surface Min LOD, and Min Array Element of the associated surface must be 0  The Min and Mag Mode Filter must be MAPFILTER_NEAREST or MAPFILTER_LINEAR  The Mip Mode Filter must be MIPFILTER_NONE  The TCX and TCY Address Control Mode cannot be TEXCOORDMODE_CLAMP_BORDER TEXCOORDMODE_HALF_BORDER TEXCOORDMODE_MIRROR TEXCOORDMODE_MIRROR_ONCE TEXCOORDMODE_WRAP  DeltaU * Width of the associated surface must be less than or equal to 3.0  DeltaV * Height of the associated surface must be less than or equal to 3.0  Number of Multisamples on the associated surface must be MULTISAMPLECOUNT_1. sample_unorm_R G +killpix sample_unorm only: This message is identical to the sample_unorm message except it returns a kill pixel mask in addition to the selected channels in the writeback message. This message type is required to +killpix allow the result of a chroma key enabled sampler in KEYFILTER_KILL_ON_ANY_MATCH mode to affect the final pixel mask. All restrictions of the sample_unorm message apply to this message also. sample_8x8 only:The surface is sampled using an optional 8x8 filter followed by an optional image enhancement filter, using state defined in SAMPLER_STATE and SAMPLER_8x8_STATE. The input consists of 64 contiguous pixels in an 16-wide by 4-high arrangement. The address control mode behaves as clamp mode. The U and V addresses for the upper left pixel are delivered in this message along with a Delta U and Delta V parameter. Given a pixel at (x,y) relative to the upper left pixel (where (0,0) is the upper left pixel), the U and V for that pixel are Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 134 Message Type Description computed as follows: U(x,y) = U(0,0) + DeltaU * x + U_2nd_Derivative * x * (x - 1)/2 V(x,y) = V(0,0) + DeltaV * y + V_2nd_Derivative * y * (y - 1)/2 Programming Notes:  The Surface Type of the associated surface must be SURFTYPE_2D  The Surface Format of the associated surface must be UNORM with <= 10 bits per channel  DeltaV * Height of the associated surface must be less than 16.0  Map Width must be >= 4  :Errata IEF_OFF YUV |U_2nd_Derivative| < 0.02/MapWidth  :Errata IEF_OFF RGB |U_2nd_Derivative| < 0.05/MapWidth  :Errata for IEF_OFF set DeltaU = DeltaU + 2x U_2nd_Derivative deinterlace to The surface is deinterlaced and/or denoised, using state defined in SAMPLER_STATE. The U and V addresses for the upper left pixel are delivered in this message. Programming Notes: Programming Notes:  For surfaces of type SURFTYPE_CUBE, the sampling engine requires u, v, and r parameters that have already been divided by the absolute value of the parameter (u, v, or r) with the largest absolute value. 2.13.1.5 Parameter Types sample*, LOD, and gather4 messages For all of the sample*, LOD, and gather4 message types, all parameters are 32-bit floating point, except the ‘mcs’, ‘offu’, and ‘offv’ parameters. Usage of the u, v, and r parameters is as follows based on Surface Type. Normalized values range from [0,1] across the surface, with values outside the surface behaving as specified by the Address Control Mode in that dimension. Unnormalized values range from [0,n-1] across the surface, where n is the size of the surface in that dimension, with values outside the surface being clamped to the surface. Surface Type u v r ai SURFTYPE1D normalized ‘x’ unnormalized array ignored ignored coordinate index SURFTYPE_2D normalized ‘x’ normalized ‘y’ unnormalized array ignored coordinate coordinate index SURFTYPE_3D normalized ‘x’ normalized ‘y’ normalized ‘z’ ignored coordinate coordinate coordinate SURFTYPE_CUBE normalized ‘x’ normalized ‘y’ normalized ‘z’ unnormalized array coordinate coordinate coordinate index Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 135 mcs parameter The ‘mcs’ parameter delivers the multisample control data. The format of this parameter is always a 32-bit unsigned integer. Refer to the section titled “Multisampled Surface Behavior” for details on this parameter. Ld* messages For the ld message types, all parameters are 32-bit signed integers, except the ‘mcs’ parameter. Usage of the u, v, and r parameters is as follows based on Surface Type. Unnormalized values range from [0,n- 1] across the surface, where n is the size of the surface in that dimension. Input of any value outside of the range returns zero. Surface Type u v r SURFTYPE1D unnormalized ‘x’ coordinate unnormalized array index ignored SURFTYPE_2D unnormalized ‘x’ coordinate unnormalized ‘y’ coordinate unnormalized array index SURFTYPE_3D unnormalized ‘x’ coordinate unnormalized ‘y’ coordinate unnormalized ‘z’ coordinate SURFTYPE_BUFFER unnormalized ‘x’ coordinate ignored ignored 2.13.1.6 SIMD16 Payload The payload of a SIMD16 message provides addresses for the sampling engine to process 16 entities (examples of an entity are vertex and pixel). The number of parameters required to sample the surface depends on the state that the sampler/surface is in. Each parameter takes two message registers, with 8 entities, each a 32-bit floating point value, being placed in each register. Each parameter always takes a consistent position in the input payload. The length field can be used to send a shorter message, but intermediate parameters cannot be skipped as there is no way to signal this. For example, a 2D map using “sample_b” needs only u, v, and bias, but must send the r parameter as well. DWord Bit Description M1.7 31:0 Subspan 1, Pixel 3 (lower right) Parameter 0 Specifies the value of the pixel’s parameter 0. The actual parameter that maps to parameter 0 is given in the table in section Payload Parameter Definition. Format = IEEE Float for all sample* message types, U32 for ld and resinfo message types. M1.6 31:0 Subspan 1, Pixel 2 (lower left) Parameter 0 M1.5 31:0 Subspan 1, Pixel 1 (upper right) Parameter 0 M1.4 31:0 Subspan 1, Pixel 0 (upper left) Parameter 0 M1.3 31:0 Subspan 0, Pixel 3 (lower right) Parameter 0 M1.2 31:0 Subspan 0, Pixel 2 (lower left) Parameter 0 M1.1 31:0 Subspan 0, Pixel 1 (upper right) Parameter 0 M1.0 31:0 Subspan 0, Pixel 0 (upper left) Parameter 0 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 136 DWord Bit Description M2.7 31:0 Subspan 3, Pixel 3 (lower right) Parameter 0 M2.6 31:0 Subspan 3, Pixel 2 (lower left) Parameter 0 M2.5 31:0 Subspan 3, Pixel 1 (upper right) Parameter 0 M2.4 31:0 Subspan 3, Pixel 0 (upper left) Parameter 0 M2.3 31:0 Subspan 2, Pixel 3 (lower right) Parameter 0 M2.2 31:0 Subspan 2, Pixel 2 (lower left) Parameter 0 M2.1 31:0 Subspan 2, Pixel 1 (upper right) Parameter 0 M2.0 31:0 Subspan 2, Pixel 0 (upper left) Parameter 0 M3 – Repeat packets 1 and 2 to cover all required parameters Mn 2.13.1.7 SIMD8 Payload This message is intended to be used in a SIMD8 thread, or in pairs from a SIMD16 thread. Each message contains sample requests for just 8 pixels. DWord Bit Description M1.7 31:0 Subspan 1, Pixel 3 (lower right) Parameter 0 Specifies the value of the pixel’s parameter 0. The actual parameter that maps to parameter 0 is given in the table in section Payload Parameter Definition. Format = IEEE Float for all sample* message types, U32 for ld and resinfo message types. M1.6 31:0 Subspan 1, Pixel 2 (lower left) Parameter 0 M1.5 31:0 Subspan 1, Pixel 1 (upper right) Parameter 0 M1.4 31:0 Subspan 1, Pixel 0 (upper left) Parameter 0 M1.3 31:0 Subspan 0, Pixel 3 (lower right) Parameter 0 M1.2 31:0 Subspan 0, Pixel 2 (lower left) Parameter 0 M1.1 31:0 Subspan 0, Pixel 1 (upper right) Parameter 0 M1.0 31:0 Subspan 0, Pixel 0 (upper left) Parameter 0 M2 – Repeat packet 1 to cover all required parameters Mn 2.13.1.8 SIMD8D Payload This message is intended to be used in a SIMD8 thread, or in pairs from a SIMD16 thread. Each message contains sample requests for just 8 pixels. The “u” and “v” parameters are delivered in double precision floating point, and thus it takes two message phases to deliver 8 values. These are labeled in Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 137 the Payload Parameter Definition table as “u0”, “u1”, “v0”, and “v1”. The number after the u/v indicate which subspan is contained in that parameter. Parameters “u0”, “u1”, “v0”, or “v1”: DWord Bit Description Mn.7 31:0 Pixel 3 (lower right) Parameter n – upper 32 bits Specifies the value of the pixel’s parameter n. The actual parameter that maps to parameter n is given in the table in section Payload Parameter Definition. Format = Double precision IEEE Float, upper 32 bits Mn.6 31:0 Pixel 3 (lower right) Parameter n – lower 32 bits Format = Double precision IEEE Float, lower 32 bits Mn.5 31:0 Pixel 2 (lower left) Parameter n – upper 32 bits Mn.4 31:0 Pixel 2 (lower left) Parameter n – lower 32 bits Mn.3 31:0 Pixel 1 (upper right) Parameter n – upper 32 bits Mn.2 31:0 Pixel 1 (upper right) Parameter n – lower 32 bits Mn.1 31:0 Pixel 0 (upper left) Parameter n – upper 32 bits Mn.0 31:0 Pixel 0 (upper left) Parameter n – lower 32 bits All other parameters: DWord Bit Description Mn.7 31:0 Subspan 1, Pixel 3 (lower right) Parameter n Specifies the value of the pixel’s parameter n. The actual parameter that maps to parameter n is given in the table in section Payload Parameter Definition. Format = IEEE Float Mn.6 31:0 Subspan 1, Pixel 2 (lower left) Parameter n Mn.5 31:0 Subspan 1, Pixel 1 (upper right) Parameter n Mn.4 31:0 Subspan 1, Pixel 0 (upper left) Parameter n Mn.3 31:0 Subspan 0, Pixel 3 (lower right) Parameter n Mn.2 31:0 Subspan 0, Pixel 2 (lower left) Parameter n Mn.1 31:0 Subspan 0, Pixel 1 (upper right) Parameter n Mn.0 31:0 Subspan 0, Pixel 0 (upper left) Parameter n 2.13.1.9 SIMD4x2 Payload DWord Bit Description M1.7 31:0 Sample 1 Parameter 3 Specifies the value of the pixel’s parameter 3. The actual parameter that maps to parameter 3 is given in the table in section Payload Parameter Definition. Format = IEEE Float for all sample* message types, U32 for ld and resinfo message types. M1.6 31:0 Sample 1 Parameter 2 M1.5 31:0 Sample 1 Parameter 1 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 138 DWord Bit Description M1.4 31:0 Sample 1 Parameter 0 M1.3 31:0 Sample 0 Parameter 3 M1.2 31:0 Sample 0 Parameter 2 M1.1 31:0 Sample 0 Parameter 1 M1.0 31:0 Sample 0 Parameter 0 M2 Parameters 4-7 if present M3 Parameters 8-11 if present 2.13.1.10 SIMD32/64 Payload 2.13.1.10.1 Pixel Shader This position of Delta U/V in the pixel shader payload layout is to allow the register delivered in the pixel shader dispatch containing the coefficients for the texture coordinates to be left in their original position (Delta U = Cxs, Delta V = Cyt). The values for U and V are computed in the pixel shader into the unused positions in this register. DWord Bit Description M1.7 31:0 Ignored M1.6 31:0 Pixel 0 V Address Format: sample_unorm* and sample_8x8: IEEE_Float in normalized space deinterlace: U32 (Range: [0,2046]) M1.5 31:0 Delta V: defines the difference in V for adjacent pixels in the Y direction. Programming Notes:  Delta V multiplied by Height in SURFACE_STATE must be less than or equal to 3 for sample_unorm* message types.  Delta V multiplied by Height in SURFACE_STATE must be less than 16 for the sample_8x8 message type.  This field is ignored for the deinterlace message type. Format = IEEE_Float in normalized space 31:0 Ignored M1.4 M1.3 31:0 Ignored M1.2 31:0 Pixel 0 U Address Format: sample_unorm* and sample_8x8: IEEE_Float in normalized space deinterlace: U32 (Range: [0,4095]) M1.1 31:0 U 2nd Derivative Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 139 DWord Bit Description Defines the change in the delta U for adjacent pixels in the X direction. Programming Notes:  This field is ignored for messages other than sample_8x8. Format = IEEE_Float in normalized space Ignored M1.0 31:0 Delta U: defines the difference in U for adjacent pixels in the X direction. Programming Notes:  Delta U multiplied by Width in SURFACE_STATE must be less than or equal to 3 for sample_unorm* message types.  This field is ignored for the deinterlace message type. Format = IEEE_Float in normalized space 2.13.1.10.2 Media DWord Bits Description M1.7 31:0 Group ID Number Used to group messages for reorder for sample_8x8 messages. All messages with the same Group ID must have the following in common: SURFACE_STATE, SAMPLER_STATE, destination register on send instruction, M0, and M1 except for Horizontal and Vertical Block Number. M1.6 31:0 U 2nd Derivative Defines the change in the delta U for adjacent pixels in the X direction. Programming Notes:  This field is ignored for messages other than sample_8x8.  (64 – (2*du))/35 >= ddu >= -du/18 Format = IEEE_Float in normalized space. 31:0 M1.5 Delta V: defines the difference in V for adjacent pixels in the Y direction. Programming Notes:  Delta V multiplied by Height in SURFACE_STATE must be less than or equal to 3 for sample_unorm* message types.  Delta V multiplied by Height in SURFACE_STATE must be less than 16 for the sample_8x8 message type.  This field is ignored for the deinterlace message type.  Negative Delta V are not supported and should be clamped to 0. Format = IEEE_Float in normalized space. M1.4 31:0 Delta U: defines the difference in U for adjacent pixels in the X direction. Programming Notes:  Delta U multiplied by Width in SURFACE_STATE must be less than or equal to 3 for sample_unorm* message types. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 140 DWord Bits Description  Delta U multiplied by Width in SURFACE_STATE must be less than 16 for the sample_8x8 message type.  This field is ignored for the deinterlace message type.  Negative Delta U are not supported and should be clamped to 0. Format = IEEE_Float in normalized space. M1.3 31:0 Pixel 0 V Address Format: sample_unorm* and sample_8x8: IEEE_Float in normalized space. Deinterlace: U32 (Range: [0,2046]) Specifies the address for the pixel at the top left of the group and not the top of the message block sent in. M1.2 31:0 Pixel 0 U Address Format: sample_unorm* and sample_8x8: IEEE_Float in normalized space. Deinterlace: U32 (Range: [0,4095]) Specifies the address for the pixel at the top left of the group and not the top of the message block sent in. WA for Sample_8x8 messages only: //Only for YUV packed surfaces, NV12 and Y-channel only for Planar surfaces if (((int)(u_left*width + 5.0/256) > (int)(uleft*width)) { modified_u_coord = u_coord – 5.0/(256*width); //floating point } else if(((int)(u_left*width + 255.0/256) == (int)(u_left*width)) { modified_u_coord = u_coord + 1.0/(256*width); //floating point } Else{ modified_u_coord = u_coord; } Where u_left = u – 2*du + 3*ddu for IEF On And u_left = u for IEF Off case u_coord is the intended Pixel 0 U address and Modified_u_coord is what is sent in this field. M1.1 31:0 Vertical Block Number Specifies the vertical block offset for the 8x8 block being sent for the sample_8x8 message. This will be equal to the vertical pixel offset from the given address pixel 0 V address divided by 8. Format: U9 M1.0 31:0 Ignored Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 141 2.13.2 Writeback Message Corresponding to the four input message definitions are four writeback messages. Each input message generates a corresponding writeback message of the same type (SIMD16, SIMD8, SIMD4x2, or SIMD32/64). 2.13.2.1 SIMD16 A SIMD16 writeback message consists of up to 8 destination registers. Which registers are returned is determined by the write channel mask received in the corresponding input message. Each asserted write channel mask results in both destination registers of the corresponding channel being skipped in the writeback message, and all channels with higher numbered registers being dropped down to fill in the space occupied by the masked channel. For example, if only red and alpha are enabled, red is sent to regid+0 and regid+1, and alpha to regid+2 and regid+3. The pixels written within each destination register is determined by the execution mask on the “send” instruction. DWord Bit Description W0.7 31:0 Subspan 1, Pixel 3 (lower right) Red: Specifies the value of the pixel’s red channel. Format = IEEE Float, S31 signed 2’s comp integer, or U32 unsigned integer. Format depends on the Data Return Format programmed for the surface being sampled. W0.6 31:0 Subspan 1, Pixel 2 (lower left) Red W0.5 31:0 Subspan 1, Pixel 1 (upper right) Red W0.4 31:0 Supspan 1, Pixel 0 (upper left) Red W0.3 31:0 Subspan 0, Pixel 3 (lower right) Red W0.2 31:0 Subspan 0, Pixel 2 (lower left) Red W0.1 31:0 Subspan 0, Pixel 1 (upper right) Red W0.0 31:0 Supspan 0, Pixel 0 (upper left) Red W1.7 31:0 Subspan 3, Pixel 3 (lower right) Red W1.6 31:0 Subspan 3, Pixel 2 (lower left) Red W1.5 31:0 Subspan 3, Pixel 1 (upper right) Red W1.4 31:0 Supspan 3, Pixel 0 (upper left) Red W1.3 31:0 Subspan 2, Pixel 3 (lower right) Red W1.2 31:0 Subspan 2, Pixel 2 (lower left) Red W1.1 31:0 Subspan 2, Pixel 1 (upper right) Red W1.0 31:0 Supspan 2, Pixel 0 (upper left) Red Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 142 DWord Bit Description W2 Subspans 1 and 0 of Green: See W0 definition for pixel locations W3 Subspans 3 and 2 of Green: See W1 definition for pixel locations W4 Subspans 1 and 0 of Blue: See W0 definition for pixel locations W5 Subspans 3 and 2 of Blue: See W1 definition for pixel locations W6 Subspans 1 and 0 of Alpha: See W0 definition for pixel locations W7 Subspans 3 and 2 of Alpha: See W1 definition for pixel locations W8.7:1 Reserved (not written): W8 is only delivered when Pixel Fault Mask Enable is enabled. W8.0 31:16 Reserved: always written as 0xffff 15:0 Pixel Fault Mask: This field has the bit for all pixels set to 1 except those pixels in which a page fault has occurred. 2.13.2.2 SIMD8/SIMD8D This writeback message consists of four registers, or five in the case of sample+killpix. As opposed to the SIMD16 writeback message, channels that are masked in the write channel mask are not skipped, all four channels are always returned. The masked channels, however, are not overwritten in the destination register. For the sample+killpix message types, an additional register (W4) is included after the last channel register. DWord Bits Description W0.7 31:0 Subspan 1, Pixel 3 (lower right) Red: Specifies the value of the pixel’s red channel. Format = IEEE Float, S31 signed 2’s comp integer, or U32 unsigned integer. Format depends on the Data Return Format programmed for the surface being sampled. W0.6 31:0 Subspan 1, Pixel 2 (lower left) Red W0.5 31:0 Subspan 1, Pixel 1 (upper right) Red W0.4 31:0 Supspan 1, Pixel 0 (upper left) Red W0.3 31:0 Subspan 0, Pixel 3 (lower right) Red W0.2 31:0 Subspan 0, Pixel 2 (lower left) Red W0.1 31:0 Subspan 0, Pixel 1 (upper right) Red W0.0 31:0 Supspan 0, Pixel 0 (upper left) Red W1 Subspans 1 and 0 of Green: See W0 definition for pixel locations W2 Subspans 1 and 0 of Blue: See W0 definition for pixel locations W3 Subspans 1 and 0 of Alpha: See W0 definition for pixel locations Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 143 DWord Bits Description W4.7:1 Reserved (not written) : This W4 is only delivered for the sample+killpix message type W4.0 31:16 Dispatch Pixel Mask: This field is always 0xffff to allow dword-based ANDing with the R0 header in the pixel shader thread. 15:0 Active Pixel Mask: This field has the bit for all pixels set to 1 except those pixels that have been killed as a result of chroma key with kill pixel mode. Since the SIMD8 message applies to only 8 pixels, only the low 8 bits within this field are used. The high 8 bits are always set to 1. Errata: Active Pixel Mask needs to be ORed with the inverse of the EMask before it is ANDed with the DMask. Also if the sample instruction is within a conditional then the active pixel mask will be overwritten with the partial mask on each different sample instruction so this will have to be done for each instance of the sample instruction not just as the end. W4.7:1 Reserved (not written): This W4 is only delivered when Pixel Fault Mask Enable is enabled. W4.0 31:8 Reserved: always written as 0xffffff 7:0 Pixel Fault Mask: This field has the bit for all pixels set to 1 except those pixels in which a page fault has occurred. 2.13.2.3 SIMD4x2 A SIMD4x2 writeback message always consists of a single message register containing all four channels of each of the two “pixels” (called “samples” here, as they are not really pixels) of data. The write channel mask bits as well as the execution mask on the “send” instruction are used to determine which of the channels in the destination register are overwritten. If any of the four execution mask bits for a sample is asserted, that sample is considered to be active. The active channels in the write channel mask will be written in the destination register for that sample. If the sample is inactive (all four execution mask bits deasserted), none of the channels for that sample will be written in the destination register. DWord Bit Description W0.7 31:0 Sample 1 Alpha: Specifies the value of the pixel’s alpha channel. Format = IEEE Float, S31 signed 2’s comp integer, or U32 unsigned integer. Format depends on the Data Return Format programmed for the surface being sampled. W0.6 31:0 Sample 1 Blue W0.5 31:0 Sample 1 Green W0.4 31:0 Sample 1 Red W0.3 31:0 Sample 0 Alpha W0.2 31:0 Sample 0 Blue W0.1 31:0 Sample 0 Green W0.0 31:0 Sample 0 Red W1.7:1 Reserved (not written) : W4 is only delivered when Pixel Fault Mask Enable is enabled. W1.0 31:2 Reserved: always written as 0x3fffffff 1:0 Pixel Fault Mask: This field has the bit for all samples set to 1 except those pixels in which a page fault has occurred. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 144 2.13.2.4 SIMD32/64 2.13.2.4.1 Sample_unorm* Pixels are numbered as follows: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Which registers are returned is determined by the write channel mask received in the corresponding input message. Each asserted write channel mask results in both destination registers of the corresponding channel being skipped in the writeback message, and all channels with higher numbered registers being dropped down to fill in the space occupied by the masked channel. For example, if only red and alpha are enabled, red is sent to regid+0 and regid+1, and alpha to regid+2 and regid+3 (using 16 bit Full mode as an example). “16 bit Full” Output Format Control Mode DWord Bit Description W0.7 31:16 Pixel 15 Red Format = 16-bit UNORM with an 8-bit range (the value FF00h maps to a real value of 1.0) Range = [0000h:FF00h] 15:0 Pixel 14 Red W0.6 Pixel 13 & 12 Red W0.5 Pixel 11 & 10 Red W0.4 Pixel 9 & 8 Red W0.3 Pixel 7 & 6 Red W0.2 Pixel 5 & 4 Red W0.1 Pixel 3 & 2 Red W0.0 Pixel 1 & 0 Red W1.7 Pixel 31 & 30 Red W1.6 Pixel 29 & 28 Red W1.5 Pixel 27 & 26 Red W1.4 Pixel 25 & 24 Red W1.3 Pixel 23 & 22 Red W1.2 Pixel 21 & 20 Red Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 145 DWord Bit Description W1.1 Pixel 19 & 18 Red W1.0 Pixel 17 & 16 Red W2 Pixels 15:0 Green W3 Pixels 31:16 Green W4 Pixels 15:0 Blue W5 Pixels 31:16 Blue W6 Pixels 15:0 Alpha W7 Pixels 31:16 Alpha “16 Bit Chrominance Downsampled” Output Format Control Mode In this mode the odd pixel red & blue channels are not included. DWord Bit Description W0.7 31:16 Pixel 30 Red Format = 16-bit UNORM with an 8-bit range (the value FF00h maps to a real value of 1.0) Range = [0000h:FF00h] 15:0 Pixel 28 Red W0.6 Pixel 26 & 24 Red W0.5 Pixel 22 & 20 Red W0.4 Pixel 18 & 16 Red W0.3 Pixel 14 & 12 Red W0.2 Pixel 10 & 8 Red W0.1 Pixel 6 & 4 Red W0.0 Pixel 2 & 0 Red W1.7 31:16 Pixel 15 Green 15:0 Pixel 14 Green W1.6 Pixel 13 & 12 Green W1.5 Pixel 11 & 10 Green W1.4 Pixel 9 & 8 Green Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 146 DWord Bit Description W1.3 Pixel 7 & 6 Green W1.2 Pixel 5 & 4 Green W1.1 Pixel 3 & 2 Green W1.0 Pixel 1 & 0 Green W2.7 Pixel 31 & 30 Green W2.6 Pixel 29 & 28 Green W2.5 Pixel 27 & 26 Green W2.4 Pixel 25 & 24 Green W2.3 Pixel 23 & 22 Green W2.2 Pixel 21 & 20 Green W2.1 Pixel 19 & 18 Green W2.0 Pixel 17 & 16 Green W3.7 31:16 Pixel 30 Blue 15:0 Pixel 28 Blue W3.6 Pixel 26 & 24 Blue W3.5 Pixel 22 & 20 Blue W3.4 Pixel 18 & 16 Blue W3.3 Pixel 14 & 12 Blue W3.2 Pixel 10 & 8 Blue W3.1 Pixel 6 & 4 Blue W3.0 Pixel 2 & 0 Blue W4.7 31:16 Pixel 15 Alpha 15:0 Pixel 14 Alpha W4.6 Pixel 13 & 12 Alpha W4.5 Pixel 11 & 10 Alpha W4.4 Pixel 9 & 8 Alpha Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 147 DWord Bit Description W4.3 Pixel 7 & 6 Alpha W4.2 Pixel 5 & 4 Alpha W4.1 Pixel 3 & 2 Alpha W4.0 Pixel 1 & 0 Alpha W5.7 Pixel 31 & 30 Alpha W5.6 Pixel 29 & 28 Alpha W5.5 Pixel 27 & 26 Alpha W5.4 Pixel 25 & 24 Alpha W5.3 Pixel 23 & 22 Alpha W5.2 Pixel 21 & 20 Alpha W5.1 Pixel 19 & 18 Alpha W5.0 Pixel 17 & 16 Alpha “8 Bit Full” Output Format Control Mode DWord Bit Description W0.7 31:24 Pixel 31 Red Format = 8-bit UNORM Range = [00h:FFh] 23:16 Pixel 30 Red 15:8 Pixel 29 Red 7:0 Pixel 28 Red W0.6 Pixel 27:24 Red W0.5 Pixel 23:20 Red W0.4 Pixel 19:16 Red W0.3 Pixel 15:12 Red W0.2 Pixel 11:8 Red W0.1 Pixel 7:4 Red W0.0 Pixel 3:0 Red Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 148 DWord Bit Description W1 Pixels 31:0 Green W2 Pixels 31:0 Blue W3 Pixels 31:0 Alpha “8 Bit Chrominance Downsampled” Output Format Control Mode If either red or blue channel (but not both) are masked, the W0 register is included in the payload but the masked channel is not written to the GRF. If both are masked, W0 is not included in the payload (reducing the response length by one). DWord Bit Description W0.7 31:24 Pixel 30 Red Format = 16-bit UNORM with an 8-bit range (the value FF00h maps to a real value of 1.0) Range = [0000h:FF00h] 23:16 Pixel 28 Red 15:8 Pixel 26 Red 7:0 Pixel 24 Red W0.6 Pixel 22, 20, 18, 16 Red W0.5 Pixel 14, 12, 10, 8 Red W0.4 Pixel 6, 4, 2, 0 Red W0.3 Pixel 30, 28, 26, 24 Blue W0.2 Pixel 22, 20, 18, 16 Blue W0.1 Pixel 14, 12, 10, 8 Blue W0.0 Pixel 6, 4, 2, 0 Blue W1.7 31:24 Pixel 31 Green 23:16 Pixel 30 Green 15:8 Pixel 29 Green 7:0 Pixel 28 Green W1.6 Pixel 27:24 Green W1.5 Pixel 23:20 Green W1.4 Pixel 19:16 Green Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 149 DWord Bit Description W1.3 Pixel 15:12 Green W1.2 Pixel 11:8 Green W1.1 Pixel 7:4 Green W1.0 Pixel 3:0 Green W2.7 Pixel 31:28 Alpha W2.6 Pixel 27:24 Alpha W2.5 Pixel 23:20 Alpha W2.4 Pixel 19:16 Alpha W2.3 Pixel 15:12 Alpha W2.2 Pixel 11:8 Alpha W2.1 Pixel 7:4 Alpha W2.0 Pixel 3:0 Alpha Additional Writeback Phase for sample_unorm+killpix For the sample_unorm+killpix messages, an additional writeback phase is returned. The value of “n” depends on which channels are enabled for return and the Output Format Control Mode, this register will immediately follow the first part of the writeback message. DWord Bit Description Wn.7:1 Reserved (not written) Wn.0 31:0 Active Pixel Mask: This field has the bit for all pixels set to 1 except those pixels that have been killed as a result of chroma key with kill pixel mode. The bits in this mask correspond to the pixels as follows and they are listed from upper left (MSB) lower right LSB: 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 2.13.2.5 Sample_8x8 Writeback Messages 2.13.2.5.1 Sample_8x8 Writeback Messages The writeback message for sample_8x8 consists of up to 16 destination registers. Which registers are returned is determined by the write channel mask received in the corresponding input message. Each asserted write channel mask results in all four destination registers of the corresponding channel being Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 150 skipped in the writeback message, and all channels with higher numbered registers being dropped down to fill in the space occupied by the masked channel. Pixels are numbered as follows: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 “16 bit Full” Output Format Control Mode DWord Bit Description W0.7 31:16 Pixel 15 Red Format = 16-bit UNORM with an 8-bit range (the value FF00h maps to a real value of 1.0) Range = [0000h:FF00h] 15:0 Pixel 14 Red W0.6 Pixel 13 & 12 Red W0.5 Pixel 11 & 10 Red W0.4 Pixel 9 & 8 Red W0.3 Pixel 7 & 6 Red W0.2 Pixel 5 & 4 Red W0.1 Pixel 3 & 2 Red W0.0 Pixel 1 & 0 Red W1 Pixel 31:16 Red W2 Pixels 47:32 Red W3 Pixels 63:33 Red W4 Pixels 15:0 Green W5 Pixels 31:16 Green W6 Pixels 47:32 Green W7 Pixels 63:33 Green W8 Pixels 15:0 Blue W9 Pixels 31:16 Blue Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 151 W10 Pixels 47:32 Blue W11 Pixels 63:33 Blue W12 Pixels 15:0 Alpha W13 Pixels 31:16 Alpha W14 Pixels 47:32 Alpha W15 Pixels 63:33 Alpha “16 Bit Chrominance Downsampled” Output Format Control Mode In this mode the odd pixel red & blue channels are not included. DWord Bit Description W0.7 31:16 Pixel 30 Red Format = 16-bit UNORM with an 8-bit range (the value FF00h maps to a real value of 1.0) Range = [0000h:FF00h] 15:0 Pixel 28 Red W0.6 Pixel 26 & 24 Red W0.5 Pixel 22 & 20 Red W0.4 Pixel 18 & 16 Red W0.3 Pixel 14 & 12 Red W0.2 Pixel 10 & 8 Red W0.1 Pixel 6 & 4 Red W0.0 Pixel 2 & 0 Red W1.7 Pixel 62 & 60 Red W1.6 Pixel 58 & 56 Red W1.5 Pixel 54 & 52 Red W1.4 Pixel 50 & 48 Red W1.3 Pixel 46 & 44 Red W1.2 Pixel 42 & 40 Red W1.1 Pixel 38 & 36 Red Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 152 W1.0 Pixel 34 & 32 Red W2.7 31:16 Pixel 15 Green 15:0 Pixel 14 Green W2.6 Pixel 13 & 12 Green W2.5 Pixel 11 & 10 Green W2.4 Pixel 9 & 8 Green W2.3 Pixel 7 & 6 Green W2.2 Pixel 5 & 4 Green W2.1 Pixel 3 & 2 Green W2.0 Pixel 1 & 0 Green W3 Pixel 31:16 Green W4 Pixel 47:32 Green W5 Pixel 63:48 Green W6.7 31:16 Pixel 30 Blue 15:0 Pixel 28 Blue W6.6 Pixel 26 & 24 Blue W6.5 Pixel 22 & 20 Blue W6.4 Pixel 18 & 16 Blue W6.3 Pixel 14 & 12 Blue W6.2 Pixel 10 & 8 Blue W6.1 Pixel 6 & 4 Blue W6.0 Pixel 2 & 0 Blue W7.7 Pixel 62 & 60 Blue W7.6 Pixel 58 & 56 Blue W7.5 Pixel 54 & 52 Blue W7.4 Pixel 50 & 48 Blue Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 153 W7.3 Pixel 46 & 44 Blue W7.2 Pixel 42 & 40 Blue W7.1 Pixel 38 & 36 Blue W7.0 Pixel 34 & 32 Blue W8.7 31:16 Pixel 15 Alpha 15:0 Pixel 14 Alpha W8.6 Pixel 13 & 12 Alpha W8.5 Pixel 11 & 10 Alpha W8.4 Pixel 9 & 8 Alpha W8.3 Pixel 7 & 6 Alpha W8.2 Pixel 5 & 4 Alpha W8.1 Pixel 3 & 2 Alpha W8.0 Pixel 1 & 0 Alpha W9 Pixel 31:16 Alpha W10 Pixel 47:32 Alpha W11 Pixel 63:48 Alpha “8 Bit Full” Output Format Control Mode DWord Bit Description W0.7 31:24 Pixel 31 Red Format = 8-bit UNORM Range = [00h:FFh] 23:16 Pixel 30 Red 15:8 Pixel 29 Red 7:0 Pixel 28 Red W0.6 Pixel 27:24 Red W0.5 Pixel 23:20 Red W0.4 Pixel 19:16 Red Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 154 W0.3 Pixel 15:12 Red W0.2 Pixel 11:8 Red W0.1 Pixel 7:4 Red W0.0 Pixel 3:0 Red W1.7 Pixel 63:60 Red W1.6 Pixel 59:56 Red W1.5 Pixel 55:52 Red W1.4 Pixel 51:48 Red W1.3 Pixel 47:44 Red W1.2 Pixel 43:40 Red W1.1 Pixel 39:36 Red W1.0 Pixel 35:52 Red W2 Pixels 31:0 Green W3 Pixels 63:32 Green W4 Pixels 31:0 Blue W5 Pixels 63:32 Blue W6 Pixels 31:0 Alpha W7 Pixels 63:32 Alpha “8 Bit Chrominance Downsampled” Output Format Control Mode DWord Bit Description W0.7 31:24 Pixel 62 Red Format = 8-bit UNORM Range = [00h:FFh] 23:16 Pixel 60 Red 15:8 Pixel 58 Red 7:0 Pixel 56 Red W0.6 Pixel 54, 52, 50, 48 Red Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 155 W0.5 Pixel 46, 44, 42, 40 Red W0.4 Pixel 38, 36, 34, 32 Red W0.3 Pixel 30, 28, 26, 24 Red W0.2 Pixel 22, 20, 18, 16 Red W0.1 Pixel 14, 12, 10, 8 Red W0.0 Pixel 6, 4, 2, 0 Red 31:24 W1.7 Pixel 31 Green 23:16 Pixel 30 Green 15:8 Pixel 29 Green 7:0 Pixel 28 Green W1.6 Pixel 27:24 Green W1.5 Pixel 23:20 Green W1.4 Pixel 19:16 Green W1.3 Pixel 15:12 Green W1.2 Pixel 11:8 Green W1.1 Pixel 7:4 Green W1.0 Pixel 3:0 Green W2 Pixel 63:32 Green W3.7 31:24 Pixel 62 Blue 23:16 Pixel 60 Blue 15:8 Pixel 58 Blue 7:0 Pixel 56 Blue W3.6 Pixel 54, 52, 50, 48 Blue W3.5 Pixel 46, 44, 42, 40 Blue W3.4 Pixel 38, 36, 34, 32 Blue W3.3 Pixel 30, 28, 26, 24 Blue Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 156 W3.2 Pixel 22, 20, 18, 16 Blue W3.1 Pixel 14, 12, 10, 8 Blue W3.0 Pixel 6, 4, 2, 0 Blue W4.7 31:24 Pixel 31 Alpha 23:16 Pixel 30 Alpha 15:8 Pixel 29 Alpha 7:0 Pixel 28 Alpha W4.6 Pixel 27:24 Alpha W4.5 Pixel 23:20 Alpha W4.4 Pixel 19:16 Alpha W4.3 Pixel 15:12 Alpha W4.2 Pixel 11:8 Alpha W4.1 Pixel 7:4 Alpha W4.0 Pixel 3:0 Alpha W5 Pixel 63:32 Alpha 2.13.2.6 Deinterlace The deinterlace message has three different writeback messages, depending on the DI Enable and DI Partial fields of SAMPLER_STATE. Pixels are indicated by an (X, Y) pair. The following tables indicate the format of common Luma, Chroma, STMM, and Block Noise Estimate/Denoise History blocks defined as portions of the specific writeback messages defined in the following sections. Each block defines one register. Luma block definition: DWord Bit Description Wn.7 31:24 Luma (15,1) Format = U8 23:16 Luma (14,1) 15:8 Luma (13,1) 7:0 Luma (12,1) Wn.6 31:0 Luma (11:8,1) Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 157 DWord Bit Description Wn.5 31:0 Luma (7:4,1) Wn.4 31:0 Luma (3:0,1) Wn.3 31:0 Luma (15:12,0) Wn.2 31:0 Luma (11:8,0) Wn.1 31:0 Luma (7:4,0) Wn.0 31:0 Luma (3:0,0) Chroma block definition: DWord Bit Description Wp.7 31:24 Cb (14,1) Format = U8 23:16 Cr (14,1) Format = U8 15:8 Cb (12,1) 7:0 Cr (12,1) Wp.6 31:0 Cr & Cb (10:8,1) Wp.5 31:0 Cr & Cb (6:4,1) Wp.4 31:0 Cr & Cb (2:0,1) Wp.3 31:0 Cr & Cb (14:12,0) Wp.2 31:0 Cr & Cb (10:8,0) Wp.1 31:0 Cr & Cb (6:4,0) Wp.0 31:0 Cr & Cb (2:0,0) STMM block definition: DWord Bit Description Wr.7 31:24 STMM (14,3) Format = U8 23:16 STMM (12,3) 15:8 STMM (10,3) 7:0 STMM (8,3) Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 158 DWord Bit Description Wr.6 31:0 STMM (6:0,3) Wr.5 31:0 STMM (14:8,2) Wr.4 31:0 STMM (6:0,2) Wr.3 31:0 STMM (14:8,1) Wr.2 31:0 STMM (6:0,1) Wr.1 31:0 STMM (14:8,0) Wr.0 31:0 STMM (6:0,0) Block Noise Estimate/Denoise History block definition: [prior to Gen6] DWord Bit Description Wq.7 31:0 Reserved : MBZ Wq.6 31:0 Reserved : MBZ Wq.5 31:0 Reserved : MBZ Wq.4 31:0 Reserved : MBZ Wq.3 31:0 Reserved : MBZ Wq.2 31:0 Reserved : MBZ Wq.1 31:8 Reserved : MBZ Wq.1 7:0 Block Noise Estimate Format = U8 Wq.0 31:24 Denoise History for 4x4 at Y = 15 to 12, X = 3 to 0 Format = U8 Wq.0 23:16 Denoise History for 4x4 at Y = 11 to 8, X = 3 to 0 Wq.0 15:8 Denoise History for 4x4 at Y = 7 to 4, X = 3 to 0 Wq.0 7:0 Denoise History for 4x4 at Y = 3 to 0, X = 3 to 0 Block Noise Estimate/Denoise History block definition: [ Gen6] Wq.7 31:16 Y[15:0] - For a 1080 screen & 4 high blocks we need 9-bits Wq.7 15:0 X[15:0] – for a 2048 screen & 16 wide block we need 7-bits 31:24 Wq.6 STAD0 – Sum in time of absolute differences for 16x8 (DN only) or 16x4 (DN/DI) Format = U8 23:16 Wq.6 STAD1 Wq.6 15:8 STAD2 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 159 Wq.6 7:0 STAD3 31:24 Wq.5 SHCM0 – Sum horizontaly of absolute differences 23:16 Wq.5 SHCM1 Wq.5 15:8 SHCM2 Wq.5 7:0 SHCM3 31:24 Wq.4 SVCM0 – Sum vertically of absolute differences. 23:16 Wq.4 SVCH1 15:8 Wq.4 SVCH2 7:0 Wq.4 SVCH3 Wq.3 31:16 FMD Variance[0] - Diff_cTpT – difference in top fields of current and previous frame Format = U16 Wq.3 15:0 FMD Variance[1] – Diff_cBpB – difference in bottom field of current and previous frame Wq.2 31:16 FMD Variance[2] – Diff_cTcB – difference between top and bottom field in current frame. Wq.2 15:0 FMD Variance[3] – Diff_cTpB – difference between current top and previous bottom Wq.1 31:16 FMD Variance[4] – Diff_cBpT – difference between current bottom and previous top. Wq.1 15:8 FMD Variance[7] – sum of pixels that are moving (different above a threshold) Format = U8 Wq.1 Wq.0 Wq.0 Wq.0 Wq.0 Block Noise Estimate/Denoise History block definition: [Gen6 DI enabled] DWord Bit Description Wq.7 31:16 Y[15:0] – Location of 16x4 Wq.7 15:0 X[15:0] - Location of 16x4 Wq.6 31:24 STAD0 - Sum in time of absolute differences for 4x4 Format = U8 [STAD values are 0 if DN is disabled] Wq.6 23:16 STAD1 Wq.6 15:8 STAD2 Wq.6 7:0 STAD3 (Ignore when both DN & DI are enabled) Wq.5 31:24 SHCM0 - Sum horizontally of absolute differences for 4x4 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 160 Format = U8 [SHCM values are 0 if DN is disabled] Wq.5 23:16 SHCM1 Wq.5 15:8 SHCM2 Wq.5 7:0 SHCM3 (Ignore when both DN & DI are enabled) Wq.4 31:24 SVCM0 Sum Vertically of absolute differences for 4x4 Format = U8 [SVCM values are 0 if DN is disabled] Wq.4 23:16 SVCM1 Wq.4 15:8 SVCM2 Wq.4 7:0 SVCM3 (Ignore when both DN & DI are enabled) Wq.3 31:16 Diff_cTpT - difference in top fields of current and previous frame Format = U16 Wq.3 15:0 Diff_cBpB - difference in bottom field of current and previous frame Wq.2 31:16 Diff_cTcB - difference between top and bottom field in current frame. Wq.2 15:0 Diff_cTpB - difference between current top and previous bottom Wq.1 31:16 Diff_cBpT - difference between current bottom and previous top. Wq.1 15:8 Motion_Count - number of pixels that are moving (different above a threshold) Format = U8 Wq.1 7:0 Block Noise Estimate for 16x4 (Valid only if DN is enabled) Wq.0 31:24 Denoise History for 4x4 at Y = 15 to 12, X = 3 to 0 Format = U8 Wq.0 23:16 Denoise History for 4x4 at Y = 11 to 8, X = 3 to 0 Wq.0 15:8 Denoise History for 4x4 at Y = 7 to 4, X = 3 to 0 Wq.0 7:0 Denoise History for 4x4 at Y = 3 to 0, X = 3 to 0 Block Noise Estimate/Denoise History block definition: [Gen6 DI disabled] DWord Bit Description Wq.7 31:16 Y[15:0] – Location of 16x4 Wq.7 15:0 X[15:0] - Location of 16x4 Wq.6 31:24 STAD0 - Sum in time of absolute differences for 4x8 Format = U8 Wq.6 23:16 STAD1 Wq.6 15:8 STAD2 Wq.6 7:0 STAD3 Wq.5 31:24 SHCM0 - Sum horizontally of absolute difference for 4x8 Wq.5 23:16 SHCM1 Wq.5 15:8 SHCM2 Wq.5 7:0 SHCM3 Wq.4 31:24 SVCM0 Sum Vertically of absolute difference for 4x8 Wq.4 23:16 SVCM1 Wq.4 15:8 SVCM2 Wq.4 7:0 SVCM3 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 161 Wq.3 31:16 Reserved Wq.3 15:0 Reserved Wq.2 Reserved 31:8 Wq.2 Block Noise Estimate for 16x8 7:0 Wq.1 31:24 Denoise History for 4x4 at X = 15 to 12, Y = 7 to 4 Format = U8 Wq.1 23:16 Denoise History for 4x4 at X = 11 to 8, Y = 7 to 4 Wq.1 15:8 Denoise History for 4x4 at X = 7 to 4, Y = 7 to 4 Wq.1 7:0 Denoise History for 4x4 at X = 15 to 12, Y = 3 to 0 Wq.0 31:24 Denoise History for 4x4 at Y = 15 to 12, X = 3 to 0 Format = U8 Wq.0 23:16 Denoise History for 4x4 at Y = 11 to 8, X = 3 to 0 Wq.0 15:8 Denoise History for 4x4 at Y = 7 to 4, X = 3 to 0 Wq.0 7:0 Denoise History for 4x4 at Y = 3 to 0, X = 3 to 0 Block Noise Estimate/Denoise History block definition: [Gen7 +] DI Enabled DWord Bit Description Wq.7 31:16 Y[15:0] Wq.7 15:0 X[15:0] Wq.6 31:16 STAD - Sum in time of absolute differences for 16x4 – value is 0 if DN disabled. Format = U16 Wq.6 15:0 SHCM - Sum horizontaly of absolute differences – value is 0 if DN is disabled. Format = U16 Wq.5 31:16 SVCM - Sum vertically of absolute differences – value is 0 if DN is disabled.. Format = U16 Wq.5 15:0 Diff_cTpT - sum of differences in top fields of current and previous frame Format = U16 Wq.4 31:16 Diff_cBpB - sum of differences in bottom field of current and previous frame Format = U16 Wq.4 15:0 Diff_cTcB -sum of differences between top and bottom field in current frame. Format = U16 Wq.3 31:16 Diff_cTpB - sum of differences between current top and previous bottom Format = U16 Wq.3 15:0 Diff_cBpT - sum of differences between current bottom and previous top. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 162 DWord Bit Description Format = U16 Wq.2 31:0 Reserved Wq.1 31:24 Tearing_Count - number of pixels that have (diff_cTcB > diff_cTcT + diff_cBcB) Format = U8 Wq.1 23:16 Fitting_Count - number of pixels that have (diff_cTcB<=diff_cTcT + diff_cBcB) Format = U8 Wq.1 15:8 Motion_Count - number of pixels that are moving (different above a threshold) Format = U8 Wq.1 7:0 Block Noise Estimate Format = U8 Wq.0 31:24 Denoise History for 4x4 at Y = 15 to 12, X = 3 to 0 Format = U8 Wq.0 23:16 Denoise History for 4x4 at Y = 11 to 8, X = 3 to 0 Wq.0 15:8 Denoise History for 4x4 at Y = 7 to 4, X = 3 to 0 Wq.0 7:0 Denoise History for 4x4 at Y = 3 to 0, X = 3 to 0 Block Noise Estimate/Denoise History block definition: [Gen7+] DI Disabled: DWord Bit Description Wq.7 31:16 Y[15:0] Wq.7 15:0 X[15:0] Wq.6 31:16 STAD - Sum in time of absolute differences for top 16x4 Format = U16 Wq.6 15:0 SHCM - Sum horizontaly of absolute differences for top 16x4 Format = U16 Wq.5 31:16 SVCM - Sum vertically of absolute differences for top 16x4 Format = U16 Wq.5 15:0 STAD - Sum in time of absolute differences for bottom 16x4 Format = U16 Wq.4 31:16 SHCM - Sum horizontaly of absolute differences for bottom 16x4 Format = U16 Wq.4 15:0 SVCM - Sum vertically of absolute differences for bottom 16x4 Format = U16 Wq.3 31:0 Reserved Wq.2 31:8 Reserved Wq.2 7:0 Block Noise Estimate Format = U8 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 163 DWord Bit Description Wq.1 31:24 Denoise History for 4x4 at X = 15 to 12, Y = 7 to 4 Format = U8 Wq.1 23:16 Denoise History for 4x4 at X = 11 to 8, Y = 7 to 4 Wq.1 15:8 Denoise History for 4x4 at X = 7 to 4, Y = 7 to 4 Wq.1 7:0 Denoise History for 4x4 at X = 3 to 0, Y = 7 to 4 Wq.0 31:24 Denoise History for 4x4 at X = 15 to 12, Y = 3 to 0 Format = U8 Wq.0 23:16 Denoise History for 4x4 at X = 11 to 8, Y = 3 to 0 Wq.0 15:8 Denoise History for 4x4 at X = 7 to 4, Y = 3 to 0 Wq.0 7:0 Denoise History for 4x4 at X = 3 to 0, Y = 3 to 0 DI Enabled (Only) This writeback message is returned when the DI Enable field in SAMPLER_STATE is enabled. The response length possibilities are:  DN Enabled & surface_format == 4:2:2 packed: 12  DN Enabled & surface_format != 4:2:2 packed: 11  DN Disabled: 10 DWord Bit Description W0 Previous 2nd Field Deinterlaced Luma for Y=0,1 Refer to Luma block above for definition. W1 Previous 2nd Field Deinterlaced Luma for Y=2,3 W2 Previous 2nd Field Deinterlaced Chroma for Y=0,1 Refer to Chroma block above for definition. W3 Previous 2nd Field Deinterlaced Chroma for Y=2,3 W4 Current 1st Field Deinterlaced Luma for Y=0,1 W5 Current 1st Field Deinterlaced Luma for Y=2,3 W6 Current 1st Field Deinterlaced Chroma for Y=0,1 W7 Current 1st Field Deinterlaced Chroma for Y=2,3 W8 STMM Refer to STMM block above for definition. W9 Block Noise Estimate/Denoise History Refer to Block Noise Estimate/Denoise History block above for definition. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 164 DWord Bit Description W10 nd Current 2 Field Luma for 16x2 This register is only included if DN Enable is enabled. W11 Current 2nd Field Chroma This register is only included if DN Enable is enabled. Only valid if input surface format is 4:2:2 The denoised luma for both the current 1st and 2nd field needs to be written out, but only the 2nd field has a dedicated location. This is because the denoised data for the 1st field is in the deinterlaced output for the 1st field – Y=0 and Y=2 are the denoised data, while Y=1 and Y=3 either the deinterlaced lines or copied from the previous or current frame if progressive. DI Disabled This writeback message is returned when the DI Enable field in SAMPLER_STATE is disabled. The DN with DI disabled responses with a 16x8 block rather than a 16x4 with a response length of 9 for a 4:2:2 input format, or 5 for other formats. Two denoised luma and chroma fields are combined into an interleaved top/bottom format. Description W0 Luma for Y=0 & 1 Refer to Luma block above for definition. W1 Luma for Y=2 & 3 Refer to Luma block above for definition, but add 2 to Y to get location W2 Luma for Y=4 & 5 W3 Luma for Y=6 & 7 W4.7 31:16 Y[15:0] Y co-ordinate of the current block within the frame W4.7 15:0 X[15:0] X co-ordinate of the current block within the frame W4.6 31:24 STAD0 – Sum in time of absolute differences for the 1st 4x8 Format = U8 W4.6 23:16 STAD1– Sum in time of absolute differences for the 2nd 4x8 W4.6 15:8 STAD2 – Sum in time of absolute differences for the 3rd 4x8 W4.6 7:0 STAD3 – Sum in time of aboslute differences for the 4th 4x8 W4.5 31:24 SHCM0 – Sum horizontaly of absolute differences W4.5 23:16 SHCM1 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 165 Description W4.5 15:8 SHCM2 W4.5 7:0 SHCM3 W4.4 31:24 SVCM0 – Sum vertically of absolute differences. W4.4 23:16 SVCH1 W4.4 15:8 SVCH2 W4.4 7:0 SVCH3 Reserved : MBZ W4.3 31:0 Reserved : MBZ W4.2 31:8 7:0 Block Noise Estimate Format = U8 W4.1 31:24 Denoise History for 4x4 at X = 15 to 12, Y = 7 to 4 23:16 Denoise History for 4x4 at X = 11 to 8, Y = 7 to 4 15:8 Denoise History for 4x4 at X = 7 to 4, Y = 7 to 4 7:0 Denoise History for 4x4 at X = 3 to 0, Y = 7 to 4 W4.0 31:24 Denoise History for 4x4 at X = 15 to 12, Y = 3 to 0 23:16 Denoise History for 4x4 at X = 11 to 8, Y = 3 to 0 15:8 Denoise History for 4x4 at X = 7 to 4, Y = 3 to 0 7:0 Denoise History for 4x4 at X = 3 to 0, Y = 3 to 0 W5 Chroma for Y=0 & 1 Refer to Chroma block above for definition. Only delivered if input surface format is 4:2:2 W6 Chroma for Y=2 & 3 Refer to Chroma block above for definition, but add 2 to Y to get location. Only delivered if input surface format is 4:2:2 W7 Chroma for Y=4 & 5 Only valid if input surface format is 4:2:2 W8 Chroma for Y=6 & 7 Only sent if input surface format is 4:2:2 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 166 3. Shared Functions – Data Port The Data Port provides all memory accesses for the subsystem other than those provided by the sampling engine. These include render target writes, constant buffer reads, scratch space reads/writes, and media surface accesses. The diagram below shows the three parts of the Data Port (Sampler Cache, Constant Cache, and Render Cache) and how they connect with the caches and memory subsystem. The execution units and sampling engine are shown for clarity. The kernel programs running in the execution units communicate with the data port via messages, the same as for the other shared function units. The three data ports are considered to be separate shared functions, each with its own shared function identifier. The diagram below shows the four parts of the Data Port (Sampler Cache, Constant Cache, Data Cache and Render Cache) and how they connect with the caches and memory subsystem. The execution units and sampling engine are shown for clarity. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 167 The kernel programs running in the execution units communicate with the data port via messages, the same as for the other shared function units. The four data ports are considered to be separate shared functions, each with its own shared function identifier. 3.1 Cache Agents The data port allows access to memory via various caches. The choice of which cache to use for a given application is dictated by its restrictions, coherency issues, and how heavily that cache is used for other purposes. The cache to use is selected by the shared function accessed. 3.1.1 Render Cache The render cache is intended to be used for the following surfaces:  3D render target surfaces  destination surfaces for media applications  intermediate working surfaces for media applications  scratch space buffers  streamed vertex buffers The render cache is a read/write cache that supports 3D render target surfaces, media read/write surfaces, and typed read/write surfaces. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 168 3.1.2 Data Cache The data cache is a read/write cache that is coherent across the physical instances of this cache. It is intended to be used for the following surfaces:  constant buffers  destination surfaces for media applications  intermediate working surfaces for media applications  scratch space buffers  general read/write access of surfaces  atomic operations  shared memory for GPGPU thread groups The data cache can be accessed via the Data Cache Data Port shared function, and via the load and store EU messages. Ordering from a single thread is maintained when accessing the data cache using only one of these mechanisms, but is not maintained when using both of these mechanisms from the same thread. In these instances, software must ensure ordering by utilizing write commits and/or waiting for read data to be returned. 3.1.3 Sampler Cache The sampler cache is a read-only cache that supports both linear and tiled memory. In addition to being used by the sampling engine (via the sampling engine messages), the sampler cache is intended to be used for source surfaces in media applications via the data port. The same application may use the sampler cache via the sampling engine and data port without flushing the pipeline between accesses. 3.2 Surfaces The data elements accessed by the data port are called “surfaces”. There are two models used by the data port to access these surfaces: surface state model and stateless model. 3.2.1 Surface State Model The data port uses the binding table to bind indices to surface state, using the same mechanism used by the sampling engine. The surface state model is used when a Binding Table Index (specified in the message descriptor) of less than 255 is specified. In this model, the Binding Table Index is used to index into the binding table, and the binding table entry contains a pointer to the SURFACE_STATE. SURFACE_STATE contains the parameters defining the surface to be accessed, including its location, format, and size. This model is intended to be used for constant buffers, render target surfaces, and media surfaces. 3.2.2 Stateless Model The stateless model is used when a Binding Table Index (specified in the message descriptor) of 255 is specified. In this model, the binding table is not accessed, and the parameters that define the surface state are overloaded as follows:  Surface Type = SURFTYPE_BUFFER  Surface Format = R32G32B32A32_FLOAT Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 169  Vertical Line Stride = 0  Surface Base Address = General State Base Address + Immediate Base Address  Buffer Size = checked only against General State Access Upper Bound  Surface Pitch = 16 bytes  Utilize Fence = false  Tiled = false This model is primarily intended to be used for scratch space buffers. 3.2.3 Shared Local Memory (SLM) The shared local memory (SLM) is a high bandwidth memory that is not backed up by system memory. It is enabled by configuring the L3 cache to use a portion of its space for the SLM. One SLM is present in each half slice, and its contents are shared between all of the active threads in that half slice. Its contents are uninitialized after creation, and its contents disappear when deallocated. The SLM is accessed when a Binding Table Index (specified in the message descriptor) of 254 is specified. The binding table is not accessed, and the parameters that define the surface state are overloaded as follows:  Surface Type = SURFTYPE_BUFFER  Surface Format = RAW  Surface Base Address = points to the start of the internal SLM (no memory address is applicable)  Surface Pitch = 1 byte Due to the predefined surface state attributes for the SLM, only a subset of the data port messages can be used. This includes the Byte Scattered Read/Write, Untyped Surface Read/Write, and Untyped Atomic Operation messages. In addition, only the data cache data port is supported, the other data ports treat Binding Table Index 254 as a normal surface state access. Programming Note: Accesses to SLM don’t have any bounds checking. Addresses beyond the size (64KB) of the SLM will wrap around. 3.3 Write Commit For write messages, an optional write commit writeback message can be requested via the Send Write Commit Message bit in the message descriptor. This bit causes a return message to the thread indicating when the write has been committed to the in-order cache pipeline and it is safe to issue another access to the same data with the assurance that it will happen after the first write. A read issued after the write commit ensures that the read will get the newly written data, and another write issued after the write commit will be the last to modify the data. "Committed" does not guarantee that the data has been actually written to the memory subsystem, but only that the write has been scheduled and cannot be passed by another read or write issued subsequently. If Send Write Commit Message is used on a Flush Render Cache message, the write commit is sent only when the render cache has completed its flush to memory. A read issued to another cache after the write commit is received will be guaranteed to retrieve the “new” data that was written before the Flush Render Cache message was issued. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 170 The write commit does not modify the destination register, but merely clears the dependency associated with the destination register. Thus, a simple “mov” instruction using the register as a source is sufficient to wait for the write commit to occur. The following code sequence indicates this: send r12 m1 DPWRITE; issue write to render cache mov m1 r3; assemble read message mov r12 r12; block on write commit send r13 m1 DPREAD; read same location as write Prior to End of Thread with a URB_WRITE, the kernel must ensure all writes are complete by sending the final write as a committed write for all non-pixel shaders. 3.4 Read/Write Ordering Reads and writes issued from the same thread are guaranteed to be processed in the same order as they are issued. Software mechanisms must still ensure ordering of accesses issued from different threads. 3.5 Accessing Buffers There are four data port messages used to access buffers. Three of these are used for both constant buffers and scratch space buffers, the fourth is used by the geometry shader kernel to write to streamed vertex buffers. All of these messages support only buffers, and can use the surface state model as well as the stateless model. The following table indicates the intended applications of each of the buffer messages. Message Applications OWord Block  constant buffer reads of a single constant or multiple contiguous constants Read/Write  scratch space reads/writes where the index for each pixel/vertex is the same  block constant reads, scratch memory reads/writes for media OWord Dual  SIMD4x2 constant buffer reads where the indices of each vertex/pixel are different Block Read/Write (if there are two indices and they are the same, hardware will optimize the cache accesses and do only one cache access)  SIMD4x2 scratch space reads/writes where the indices are different. DWord Scattered  SIMD8/16 constant buffer reads where the indices of each pixel are different (read Read/Write one channel per message)  SIMD8/16 scratch space reads/writes where the indices are different (read/write one channel per message)  general purpose DWord scatter/gathering, used by media Streamed Vertex  geometry shader streaming vertex data out Buffer Write These messages generally ignore the surface format field of the state and perform no format conversion. The exception is the Streamed Vertex Buffer Write, which uses the surface format field to determine only how many channels are to be written. The data contained in each channel is still not converted in any way. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 171 3.6 Accessing Media Surfaces The Media Block Read/Write message is intended to be used to access 2D media surfaces. The message specifies an X/Y coordinate into the 2D surface as input. Since this message only supports 2D surfaces, the stateless model cannot be used with this message. 3.6.1 Color Processing The image enhancement color processing pipe, known as IECP or shortly CP. The pipe contains a couple of functions:  Packer with 422 to 444 converter.  Skin Tone detection & Enhancement (STDE).  Color Gamut Compression (CGC) (added for  TCCE - Automatic Contrast Enhancement (ACE) & Total Color Control (TCC).  Procamp.  Color Space Converter (CSC).  repacker with 444 to 422 converter Since these functions are performed on per-pixel basis, IECP is integrated in Render Cache Pixel Backend (RCPB). The operation of each functionality could be on/off through the enable bit of each function. Surface Format Name R16G16B16A16_UNORM B8G8R8A8_UNORM R10G10B10A2_UNORM R10G10B10A2_UNORM_SRGB R8G8B8A8_UNORM R8G8B8A8_UNORM_SRGB B10G10R10A2_UNORM B10G10R10A2_UNORM_SRGB B8G8R8X8_UNORM R16_UNORM YCRCB_NORMAL YCRCB_SWAPUVY YCRCB_SWAPUV YCRCB_SWAPY 3.6.1.1 Overview of color processing pipeline The input message to IECP is 256 bits data from RCPB (contains 2 lines X 2 pixels per clock); along with 256 bits color enhancement state from ISC (State Arbitator for). This unpacker converts 256b into two pixels per clock, 36 bits each. In case of 422 inputs the UV are the same for the two pixels in the pair (422 to 444 conversion). The Re-packer (the CSC) delivers 2 pixels in parallel, 36 bits each. The 2x2 message pixels are packed again to 256b and sent with the outgoing message. The 256 bits are organized according to the data type (422/444, 8/16 bits). In case of 422 output, the UV is the average of two adjacent pixels. Also the pipe itself is 12bis/pixel component, in the output message it will be either 8 bit/pixel component (while taking only the 8 MSB) or 16 bits/pixel component (while adding 0000 at the LSB). Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 172 There is statistic information from ACE block (10 bit histogram, 1 bit aoi and 1bit skin pixel) to be sent to VSC (Video Statistic Counter). VSC will process on these data and output the maximum and minimum value of the luma values ( Ymax and Ymin) and the number of total skin pixels through MMIO. The Software development can access these data through MMIO and performs the SW part of the color processing algorithms. The color-processing enables the user to customize visual quality of video playback on the PC platform. The seven functions main goals can be summarized as:  422 to 444 converter and the 444 to 422 converter functions enable us some flexibility in the data format input and output.  Skin Tone Detection/Enhancement function detects skin like color and attempts to change the tone based on user specified parameters to make it more palatable to the user.  Automatic Contrast Enhancement increases details in dark and bright areas by changing the contrast function in relation to frames luma histogram.  Total color control allows the user to increase or decrease the color saturation of the six basic colors (Red, Green, Blue, Magenta, Cyan, Yellow).  Procamp enables the user to control the Brightness, Contrast, Saturation and the Hue.  Color Space Converter enables the user to convert color space from YUV format to RGB. The module of color gamut compression is added among STDE and TCC/ACE in the below diagram. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 173 The performance of IVB IECP pipe is improved to 4 pixels per clock for input video of 4:2:2 format and maintained at 2 pixels per clock for input video of 4:4:4 format. With this performance improvement for 4:2:2 input, there are a couple of addition/modification of IVB pipe to the existing IECP pipe of GT. The following changes are being done: Unpacker : The input format 4:2:2 and 4:4:4 are supported for unpacker. Input video of 4:2:2 format by default is operating at 4 pixels per clock. Input video of 4:4:4 format by default is dependent of an auto UV detection logic to determine if it is operating at 2 pixels per clock, or it could be operating at 4 pixels per clock if detection logic identifies the “true” 4:2:2 format is contained. A by default auto UV detection logic for the input video of 4:4:4 format tests the MSB 8-bits of the U, V channel value. With the pixel layout below: Pix_0 Pix_1 Pix_2 Pix_3 The 4:2:2 format is detected if the below conditions are observed U_pixel_0 = U_pixel_1 U_pixel_2 = U_pixel_3 V_pixel_0 = V_pixel_1 V_pixel_2 = V_pixel_3 When the 4:2:2 format is detected from the input video of 4:4:4 format, the performance improved mode at 4 pixels per clock is applicable. Thus, the average of the U, V values in horizontal direction is used as the U, V output to the remaining pipe. If UV detection logic cannot detect the input as 4:2:2 format, it will operate as 4:4:4 mode. There is a flag bit as the state parameters to force the operation in 4:2:2 mode () when the input video is of 4:4:4 format. In this case, the horizontal average of U, V pixel values is taken as the output values to the remaining pipe. A flag bit of state parameter,, is provided to ensure the 4:4:4 operation for the input of 4:4:4 format. There is also a flag bit of state parameter to force the operation in 4:4:4 mode () when the input video is of 4:2:2 format. In this case, U, V pixel values are horizontally replicated as the output values to the remaining pipe. It is 2 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 174 pixel/clk when oris enabled and is 4 pixel/clk when is enabled.. In 4:2:2 mode, all the four Y-channels and two U, V channels in the 422 format as is to STD. No sequencing. An example of the values Y_p0, Y_p1, Y_p2, Y_p3, U_p01, V_p01, U_p23, V_p23 are the pixel values being sent to the pipe. In 4:4:4 mode, 2 pixels (two Y, U, V, A channels) are forwarded per clock to STD. Sequencing is done across two clocks. To keep the pipe with minimum changes the corresponding channels are sent like below example: Y_p0, X, Y_p1, X, U_p0, V_p0, U_p1, V_p1 are the pixel values which are sent to the pipe. Where “X” is don’t care. Skin tone detection /enhancement For both 4:2:2/4:4:4 the detection in UV space is done for the two UV values independently. i.e. both the rectangle and diamond std factor are calculated in similar way for both 4:2:2/4:4:4 format. Satnew and HueNew are also calculated based on the two UV values based out of the PWL. For the Y-factor calculation is done for 4 pixels. In case of 4:2:2 all four pixels are valid, but for 4:4:4 only two pixels are valid. The factor calculated on UV space in step 1 is replicated for the horizontal pixels and we get the effective four STD factors out of this step. In VY-factor calculation, the V is replicated for the horizontal pixels i.e. pixel0 and pixel1 will use the same V pixel01 value and pixel2 and pixel3 will use the same V pixel23 value. We will get four STD factors out of this stage. For 4:2:2 mode, two resultant STD factors can be produced for skin tone enhancement or later stage based on the horizontal minimum, maximum, or average of the STD factors, which can specified via the state parameters  In skin tone enhancement module, based on Y-channel, MVdark and MVbright are calculated for 4 pixels. Then for 4:2:2 mode, the horizontal minimum, maximum, or average of MVdark values, which could be specified via the state parameters  can be used to effect the new Satnew and Huenew values. In 4:4:4, we use the corresponding MVdark/bright and discard the other i.e. no averaging. Delta U/V : For 4:2:2 mode, the two resultant STD factors froom step iii are used to derive Delta U/V. For 4:4:4 mode, the corresponding pixel STD factor is used. Out of this stage we always get two Delta U/V values. Finally only two updated U/V values using the above delta U/V values come out of the STDE pipe. Color Gamut Compression: For 4:2:2 mode, only two U/V values are received, and thus two Hue index are calculated and only two vertex point (Lv, Cv) lookups is checked. For both 4:2:2/4:4:4, there are 4pixel Y channels so 4 parallel out pixel detection occurs based on the vertex points(Lv, Cv), U, V values. Four SF (scaling factor) are produced. In 4:4:4 mode, only two of the above are valid and the rest two are discarded. Only the corresponding SF is used to calculate the new U/V values. In 4:2:2 mode, two SF values are produced based on the horizontal minimum, maximum, or average value of SF, which could be specified via the state parameters . 4 updated Y values and 2 U/V values are produced out of Gamut compression TCC works on 2 UV values received from gamut compression and is 2wide for 4:2:2 mode. ACE works on 4 Y pixel received from Gamut compression and is 4 wide Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 175 Procamp optimizes and has 4pixel Y and 2pixel UV values and output the same in 4:2:2 mode CSC optimized the UV portion and then uses the same result out for the 2 horizontal pixels and adds the result to the individual Ypixels. From CSC we will get 4pixel out for 4:2:2 mode. Repacker pack sends the data 4 pixels for 4:2:2 mode as is to RCPB, but in the case of 4:4:4 it will combine the 2pixels received from CSC across 2 clocks before outputting the 4pixels to RCPB. 3.6.1.2 Skin Tone Detection/Enhancement (STD/E) The STD/E unit, composed of the Skin Tone Detection (STD) and Skin Tone Enhancement (STE) units, is part of color processing pipe located at the Render Cache Pixel Backend (RCBP). The main goal of the STD/E is to reproduce the skin colors in a way that is more palatable to the observer, and by that to increase the sensed image quality. It may also pass indication of skin tones to the TCC and ACE. The STD unit detects the skin like colors and passes a grade of skin tone color to the STE. The STE modify the saturation and Hue of the pixel. Both the STD and STE are per-pixel basis. The input pixels are required to be on the YUV space. The skin tone detected factor will be recorded as a 5-bit number and it will be passed to the module of ACE and TCC to indicate the strength of skin tone likelihood. 3.6.1.2.1 STD The STD operates on digital images in the YUV color space. In these space the skin-tone region is represented by the ellipse in the (U,V) subspace (chroma components), by a trapeze membership function in the Y direction (luma component) and by a piece-wise linear classifier in the (V,Y) subspace. U,V data is transformed into Hue and Saturation space through shifting and rotation Step 1: shift rectangle U_center = U –  V_center = V -  Step 2: rotate rectangle Sat = -(U_center *  - V_center * ) Hue = -(U_center *  + V_center * ) Where: Sin =   and Cos =   Rectangle skin-tone measure determination Skin-tone detection is described by a continue score on the [0,1] range, where a level 0 means not a skin (SkinToneFactor = 0) , and a level 1 (SkinToneFactor = 1) means a full skin. In between, (0,1) region, we have partial skin-tone detection. This partial skin-tone detection is controlled by a margin parameter, which will be denoted by “”. The SkinToneFactor is expressed by 5 bits, and thus have values in the [0,31] range. if( abs(Sat) <= SatMax && abs(Hue) <= HueMax) { if(HS_margin >= 5) { Sat_Factor = (Sat_max-abs(Sat)) / 2(HS_margin - 5); Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 176 Hue_Factor = (Hue_max-abs(Hue)) / 2(HS_margin - 5); } else { Sat_Factor = (Sat_max-abs(Sat)) * 2(HS_margin - 5); Hue_Factor = (Hue_max-abs(Hue)) * 2(HS_margin - 5); } //end of if(HS_margin >= 5) } else { Sat_Factor = 0; Hue_Factor = 0; } //end of if( abs(Sat) <= SatMax && abs(Hue) <= HueMax) Sat_Factor = min(Sat_Factor,31); Hue_Factor = min(Hue_Factor,31); Rectagle_SkinToneFactor = min(Sat_Factor, Hue_Factor); Rhombus skin tone detection determination Similar to the rectangle skin-tone measure, a rhombus-margin () is introduced. This introduces a new rhombus region, inner to the original rhombus, in a similar happened with the rectangle. There are two regions such that: outside the original rhombus a SkinToneFactor = 0 (not a skin); inside the inner rhombus SkinToneFactor = 1 (full skin); in between 0 < SkinToneFactor < 1 indicating a partial skin-tone detection. As in the rectangle case, the SkinToneFactor is expressed by 5 bits, and thus have values in the [0,31] range. A Diamond SkinToneFactor calculations algorithm is: Dist = abs(Sat – Diamond_du) + Diamond_alpha(1/tan( )) * abs(Hue – Diamond_dv); //outside the diamond if(Dist >= Diamond_TH) { D_Factor = 0; //the point is out of the large rhombus } else if(Dist < (Diamond_TH - Diamond_margin)) { D_Factor = 31; //the point is inside the inner rhombus } else //the point is inbetween the outer and the inner rhombuses { if(Diamond_margin >= 5) { D_Factor = (Diamond_TH - Dist) / 2(Diamond_margin - 5); } else { D_Factor = (Diamond_TH - Dist) * 2(Diamond_margin - 5); } // end of if(Diamond_margin >= 5) Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 177 } // if(D < (Diamond_TH - Diamond_margin)) Diamond_SkinToneFactor = D_factor; Finally the level of the skin-tone detection in the (U,V) subspace is given by: UV_SkinToneFactor = min(Rectangle_SkinToneFactor, Diamond_SkinToneFactor); Detection in Y direction The detection based on the Y-values, is given by a piece-wise linear membership function, which is defined with 4 points ) (x=1, 2, 3, and 4). if(Y >= Y_Point_0 && in_Y < Point_1) Y_Factor = (Y – Y_Point_0) * Y_Slope_1; else if(Y >= Point_1 && Y < Point_2) Y_Factor = 31; else if(Y >= Point_2 && Y < Point_3) Y_Factor = (Point_3 - Y) * Y_Slope_2 else Y_Factor = 0; At the end of the process a double (min,max) clipping is applied: Y_Factor = min(31,max(Y_Factor,0)); The final Skin-Tone detection is is given by: SkinToneFactor = min(UV_SkinToneFactor, Y_factor); Detection in the VY plane (3D-like DTD) The operation of the detection in VY plane is particularly enabled by  bit It is known that the application of a three-dimensional (3D) classifier in the (Y,U,V) space, instead of a two dimensional (2D) skin-tone detector in the (U,V) plane, is resulted in a better detection. Implementation complexity of the full 3D classifier is too high, and forces us to approximate the classifier by more simple, but useful methods. Skin-tone data distribution implies (it is almost convex, and has a predominate directions) that the 3D classifier could be approximated by the intersection of the three 2D classifiers in (U,V), (U,Y), and (V,Y) subspaces. The (U,V) subspace is the most important one it is already approximated by the ellipse, as was described previously. Our study implies that the (V,Y) subspace is the next most important one. Although the (U,Y) space carries the STD information, it is heavily redundant and has the reduced importance. Thus the approximation of 3D classifier is an intersection of (U,V) and (V,Y) two-dimensional classifiers. The (V,Y) classifier is given by two piece-wise linear functions (PWLF), Each PWLF is composed of four straight segments. Each segment is described by the three parameters (Point, Slope and bias). Thus a single PWLF (lower or upper) is described by 12 parameters (4 points, 4 biases, 4 slopes). The parameters of lower part are: 4 point PxL (x=0, 1, 2, 3), 4 bias BxL (x=0, 1, 2, 3) and 4 slope SxL (x=0, 1, 2, 3). The parameters of upper part are: 4 point PxU (x=0, 1, 2, 3), 4 bias BxU (x=0, 1, 2, 3) and 4 slope SxU (x=0, 1, 2, 3). There is Programming Restrictions to specify the parameters The points must be in the non-decreasing order: P0 <= P1 <= P2 <= P3. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 178 The parts must be continues on they ends. Thus the user: (a). must set: P0L = P0U (continuity at the leftmost points). (b). must care for continuity at the rightmost points. Margin for the detection in the VY plane (3D-like DTD) Vertical margins of each part were introduced to provide a “soft” continuous detection over the classifier boundaries. There are two parameters defined  - the margin of the lower (blue) part.  - the margin of the upper (red) part. Consider a pixel with coordinates (Y,V) = (P2L,V1),. This pixel has a Y coordinate exactly as of the point P2, and a V coordinate equal V1. For this pixel the detection relative to the Lower Part will be: detL = Min (Max ((V1 – B2L) / MarginVYL, 0), 1) The identical calculations are made for the Upper Line as well: detU = Min (Max ((VU – V1) / MarginVYU, 0) , 1) Where: detL - is a detection relative to the Lower Part detU - is a detection relative to the Upper Part VU - is a V value of the Upper PWLF correspond to the Y=P2L BU - is a V value of the Lower PWLF correspond to the Y=P2L The inverse operation of (1/ MarginVYL), and (1/ MarginVYU) is specified by the parameters INV_ and . Both detections (detL, detU) are reduced to 5 bit representations, and the overal detection in the (V,Y)- plane is given by: det_VY = min(detL, detU) The final Skin-Tone Detection is given by the minimum of the previously calculated STD in the (U,V)- plane (9), and the current one: SkinToneFactor = min(SkinToneFactor, det_VY) This value is represented with 5 bits, and has a [0,31] range. 3.6.1.2.2 STE The enhancement step is performed on the pixels which were detected as the skin-tone pixels only by the previous (STD) step. This step is divided into two sub-steps: saturation correction enhancemen and hue correction enhancement STE – Saturation Correction Enhancement The enhancement is performed by the transformation SatNew = FSat(SatOld), which is realized by the piece- wise linear function (PWLF) with a 4 straight segments. The parameters of this PWLF are:  Points: SATP0 = -SatMax Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 179 (x=1,2,3) – defined by the user SATP4 = SatMax  Biases: SATB0 = -SatMax  (x=1,2,3) – defined by the user SATB4 = SatMax  Slopes:  (x=0,1,2,3) – defined by the user There is Programming Restrictions to specify the parameters The point Sat = -SatMax maps to itself: (-SatMax) (-SatMax). The point Sat = SatMax maps to itself: (SatMax) (SatMax). The correction function is continuous. The correction function is non-decreasing. SatOld SatNew (-SatMax ,-SatMax) (SatMax ,SatMax) Identity transformation Fig.. General form of the Saturation correction PWLF. Correction Function STE – Hue Correction Enhancement The enhancement is performed by the transformation HueNew = FSat(HueOld), which is realized by the piece- wise linear function (PWLF) with a 4 straight segments. The parameters of this PWLF are:  Points: HUEP0 = -HueMax (x=1,2,3) – defined by the user HUEP4 = HueMax  Biases: HUEB0 = -HueMax  (x=1,2,3) – defined by the user HUEB4 = HueMax  Slopes: Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 180  (x=0,1,2,3) – defined by the user There are Programming Restrictions to specify the parameters The point Hue = -HueUEMax maps to itself: (-HueMax) (-HueMax). The point Hue = HueMax maps to itself: (HueMax) (HueMax). The correction function is continuous. The correction function is non-decreasing. HueOld HueNew (-HueMax,-HueMax) (HueMax ,HueMax) Identity transformation Fig. General form of the Hue correction PWLF. Correction Function STE – Skin Type Correction Enhancement The operation of this mode is enabled by the control parameter . The Saturation and Hue enhancement processes are basic STE procedure. The advanced mode to adjust the enhacement based on the skin type define the second set of the Sat and the Hue enhancement parameters, which has an identical structure as the previous one (Points, Biases, Slopes) but having different values. We will refer one set of parameters to the Bright skin (Bs), and the other to the Dark skin (Ds). Each pixel is referred as belongs to the Bright, the Dark, or to the both skin types with a different membership values. The Dark/Bright skin classifier is defined by the two parameters: , and . It works on the luma (Y) values. The parameters related are Points: (x=1,2,3) – defined by the user (x=1,2,3) – defined by the user Biases:  (x=1,2,3) – defined by the user  (x=1,2,3) – defined by the user Slopes:  (x=0,1,2,3) – defined by the user  (x=0,1,2,3) – defined by the user For the luma value Y, we define YA = skinTypesThesh - skinTypesMargin YB = skinTypesThesh + skinTypesMargin MVDark = 1 , if Y < YA Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 181 = 0, if Y > YB = (YB – Y) / (2* skinTypesMargin), if YA <= Y <= YB MVBright = 1 - mVDark Where MVDark and MVBright are the membership value of the Dark and Bright skin (belongnes). (Note: the membership values represent the “belongness” of the skin pixel to the different skin types). Also, we mark that the inversee operation of 1/(2* Skin_types_margin) wil be specified by the parameter . In previous sections the procedure for the calculation of the Sat New and HueNew values was described. We calculate these values for the two skin types and thus get SatNew B, HueNew B, and SatNew D, HueNew D values , where and subscribes “B” and “D” stands for the Bright and the Dark skin types, respectively. (In this case, the parameters with “_DARK” extension are used to work out SatNew D and HueNew D, and the other set of the parameter could be reloaded with the parameters to work out SatNew D, HueNew D.)The final values of the enhanced pixel will be given by: SatNew = MVDark * SatNew D + MVBright * SatNew B HueNew = MVDark * HueNew D + MVBright * HueNew B STE – (Sat, Hue) to (U, V) transformation In prior session,, the (U,V) (Sat,Hue) transformation was proceeded by the two steps:  and . Thus the backward transformation should be done in the inverse order: a , and then a . // Rotate back: U_Center_New = (Sat_New * Cos) + (Hue_New * Sin) V_Center_New = -(Sat_New * Sin) + (Hue_New * Cos) // Shift: U_New = U_Center_New + U_mid V_New = V_Center_New + V_mid The (U_new, V_new) are the (SatNew, HueNew) values in transformed to the original (U,V) coordinates. Let denote the original (U,V) values of the pixel by (U_in,V_in). Thus the difference between the corrected and the original values are: DU = U_new – U_in DV = V_new – V_in The final correction must be depended by the SkinToneFactor value, and therefore DU, DV are corrected by: DU = DU * STD_ Likelihood_Factor DV = DV * STD_ Likelihood_Factor Where: STD_ Likelihood_Factor = (SkinToneFactor / 32) (Remember that the 0 <= SkinToneFactor <= 31). After the DU and DV were corrected by the STD likelihood factor, the final (U,V) will be calculated by: U = U_in + DU Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 182 V = V_in + DV 3.6.1.2.3 STD Score Output This mode outputs the STD score, which is controlled by the state bit “Output STD Decisions” instead of the pixel values. In this mode, the STD should be enabled and other functions in the IECP after STDE in the pipe should be disabled. Only ACE can be enabled to collect the histogram of the STD score values. The output when “Output STD Decision” is enabled should be as follows: Y = 0x7FF + + (STD_Score <<6) U = 0x7FF V = 0x7FF In this mode, a histogram of skin tone distribution can be obtained in ACE module, and a special ACE PWLF curve (step function) can be configurated to produce a bi-level picture to illustrate the pixels based on the level of skin tone detection. 3.6.1.3 Adaptive Contrast Enhancement (ACE) The Automatic Contrast Enhancement (ACE) is a part of the color processing pipe, which located at the render cache in the RCPB block. The main goals of the ACE is to improve the overall contrast of the image, and emphasizing details when relevant (such as in dark areas). The ACE algorithm analyzes the image, and consequently changes contrast of the image according to its characteristics. It works in YCbCr color space, where analysis and changes are performed over the Y component. The result of ACE is a 1d (1 dimension) look up table (1D LUT) operating on Y. The ACE follows the skin tone enhancement module in the pipe. The ACE is receiving skin information from the STD block. When the frame includes skin the affect of the ACE is reduced in the skin area. The ACE operation is divided into three stages:  Collecting information on Y and building the picture histogram. (Hardware)  Analysis on the collected data. (Software/Kernel)  Modification of the Y component. (Hardware) The major steps of ACE can be divided into the following steps and depict in the below diagram. 1. Histogram calculation of the Y values. 2. Limiting extremely large histogram’s bins. 3. Calculate the Image’s gray level mean value (Ymean). 4. Calculate the Image’s “Dark Factor” by the Ymean and external transfer function. 5. Find the PWLF anchor input and output points according to the “Portion Values” and the “Destination Points” of the Bright and the Dark images. 6. Find the PWLF anchor Input points by the blending of the Dark and Bright anchor input points, according to the Dark Factor calculated previously. 7. Find the PWLF anchor Output points by the blending of the Dark and Bright anchor output points, according to the Dark Factor calculated previously. 8. Limit Slopes between the anchor points. This stage’s output is the current’s image ACE PWLF. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 183 9. “Soften” the ACE PWLF by blending I with the Identity Transformation. 10. Blend the current PWLF with the PWLF of the previous image (History blend). 11. Apply the final PWLF, and get the Yout values. Note: Step 1 & step 11 are done in HW and steps 2-10 are done in software. The main ACE goals are overall contrast improvement, and details emphasizing. ACE algorithm generates a Piece-wise Linear Function (PWLF), and the final gray values, Yout, are calculated by Yout = PWLF(Yin). The HW compares the input pixels to the  to determine if the target pixel is a skin pixel or not. It operates on all of the input pixels if the  flag is defined. (to ignore the AOI flag). HW output the histogram of luma pixel value to VSC, and at VSC, the maximum and minimum value of luma pixels (Ymax, Ymin) ans the number of skin pixels is determined to be made available to the software development via MMIO register. An eleven-segment (12 points) was established to implement PWLF via the state parameters (Points: , Bias: , Slope: ). Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 184 3.6.1.4 Total Color Control (TCC) The TCC allows users to choose different grades of saturation for each of the six basic colors (Red, Green, Blue, Magenta, Yellow and Cyan) in order to custom the color scheme. The TCC algorithm operates on the UV-color components in the YUV color space. It operates in the pixel-wise mode, without considering any neighborhood information. Its input is:  U,V color components (10 bit)  Skin-tone detection value (5 bit)  External control parameters Its output is the new U, V values (10 bit). The motivation to implement this block in HW is to reduce the power of the system and therefore the battery life. The pixel TPT (throughput) is two pixels per clock. The pipeline works in YUV formats only – 10bit pixels. The TCC block is control by state only and does not require any memory access. The TCC block runs at the same frequency of the existing RCPBunit. There are two paths in parallel to support the requirement of two pixels per clock. Valid out is a signal which high when the pixels are valid. The TCC block includes three sub blocks. Angle_calculator This block receive pixel U and V and perform division of abs|v| by abs|u| using Divider ROM with pipeline. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 185 The division result is used to calculated arctan of the V/U. This result is used to calculate the angle called θ, by using approximation equation. This angle is defined as a 10bit. To simplify this calculation the “arctangent” function is approximated in the [0,45] o region by the second order polynomial: = arctan(x) = -0.2880x2 + 1.0797x - 0.005; (0 <= x <= 1) The resulted is given in radians with the maximal error of 0.005 rad. (0.286 deg.) This approximation is calculated by the minimizing the mean squared error (mse) between the actual “arctan” function, and its polynomial approximation, and thus represents the optimal mse-approximation in the [0, /4] region. The for the all regions is calculated by: 0.25 ; for region I, (0 <= x <= 1), /2 – 0.25 ; for region II, (1 < (V/U) < infinity) /2 + 0.25 ; for region III, (-infinity < (V/U) < -1) = - 0.25 ; for region IV, (-1 <= (V/U) < 0) + 0.25 ; for region V, (0 <= (V/U) <= 1) 3 - 0.25 ; for region VI, (1 < (V/U) < infinity) 3 + 0.25 ; for region VII, (-infinity < (V/U) < -1) 2 - 0.25 ; for region VIII, (-1 <= (V/U) < 0) Whereas x = (V/U), and the 0.25 is given by the above equation. Saturation_Factor_Calculator This block is using the angle θ, locate where it is in the color wheel, find the appropriate base colors and calculate the proportional distance from the adjacent base color. The result called . Alpha ( ) represent the distance from the two relevant base color. Calculate the saturation by using the appropriate user parameters. The result is the Saturation factor. This block considering also the threshold and the maximum UV values, and considering also correction for gray colors to minimize the possible noise. In addition the saturation skipping doing saturation when the color is skin and doing alpha blending according the skin factor called STDscore. This block requires several external parameters such:  – Six basic user defined colors.  – Six basic saturation change user defined factors.  – Six calculation result of 1/(BaseColorX – BaseColorY) ColorBias1,…, ColorBias6 – Six color bias. STDscore – Skin-tone Detection score (from STD/E). The result of SF is a number of 8bits. There are four major steps to derive the saturation factor. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 186 The Interpolated Basic SFs1 With the calculated angle , which lies in the [ , Ci Ci+1 ] interval, the Interpolated Basic SFs1 will be: SFs1 = (1-  i +  i+1 Whereas is calculated by: = Min{Max[(  i)* i – i, 0], 1} Over Saturation Limiter SFs2 Over Saturation Limiter block is used to avoid saturation boosting of the already high saturated pixels. The SFs2 is calculated by: SFs1 , for (SF1 <= 1) SFs2 = 1 + (SFs1 – 1)(MaxColor – UVmax)/MaxColor, for (1 < SF1 <= 2) AND (UVmax <= ) 1, for (UVmax > ) Where the UVmax = max(|U|,|V|), and  is an external parameter which in the case of YUV color space is equal to 448 in 10bit representation.  was used for the inverse calculation of 1/UVMaxColor. Note: The last condition (UVmax > UVMaxColor) is associated with the illegal colors, and usually hasn’t to appea (Can this be OK for wide gamut mapping?). GrayPixels Saturation LimiterSFs3 This block limits the saturation of the almost gray pixels. The reason for this limiter is to prevent the noise amplification by the Saturation increase process. The result of this block is: SFs3 = 1 + dSF * CLF Where: dSF = SFs2 – 1; Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 187 And the CLF is called Color Limiting Factor and ranges from 0 to 1. The calculation of the CLF is given by: = 1; for (SFs2 <= 1) AND ( any UVmax) CLF = 0; for (UVmax <= ) = (UVmax – UV_Threshold) / 2UV_Threshold_Bits ; for (UV_Threshold < UVmax < (UV_Threshold+2UV_Threshold_Bits) ) Skin-tone Saturation LimiterSFs4 The last block effects TCC strength operation of the Skin-tone pixels. Uncontrolled enhancement of the skin pixels could lead to appearing of artifacts and to undesired results. The final SFs4 is calculated by a linear blending: SFs4 = (128*STEfactor + (256 - STEfactor) SFs3 ) / 256 Where the STEfactor is called Skin Tone factor and is calculated by: diff = (STDscore – ) * 23 Note: the STDscore (from STD) and the STE_Threshold are presented with 5 bits. The multiplication by 23 is in order to raise the “diff” to 8 bits. STEfactor = Min {Max [(diff * 2 STE_SlopeBits ), 0], 255} The STDscore is a result of the Skin-tone Detection module. It is represented with 5 bits, where the values 0 and 31 mean no skin-tone, and full skin-tone detection, respectively. The STEfactor is given by 8 bits, where the value 256 represents the number 1. It is evident that for the high values of STEfactor the resulted SFs4 is close to 1, which means a weak TCC action of this pixel (SFs4 = 1 actually means TCC is off).  – The input pixels are multiple by the saturation factor. The results are the output pixels. SF final is the final saturation factor which actually resulted from the forth SFcalculation block: SFfinal = SFs4 The calculation of the Unew, and Vnew output values. They are calculated below: Unew = U * SFfinal Vnew = V * SFfinal Whereas (U,V) are the original input color components, Because these pixels are represented in the unbiased form, which is the result of substraction of the value 512 from the original [U,V] values, the final [Uout, Vout] values are given by: Uout = Unew + 512 Vout = Vnew + 512 This is the final TCC output represented with 10 bits. 3.6.1.5 ProcAmp The PROCAMP block modifies the brightness, contrast, hue and saturation of an image in YCbCr color space (or similar). Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 188 The algorithm itself uses 8-16 bits per color. Y Processing: 256 is subtracted from the Y values to position the black level at zero. This removes the DC offset so that adjusting the contrast does not vary the black level. Since Y values may be less than 256, negative Y values should be supported at this point. Contrast is adjusted by multiplying the YUV pixel values by a constant. If U and V are adjusted, a color shift will result whenever the contrast is changed. The brightness property value is added (or subtracted) from the contrast adjusted Y values; this is done to avoid introducing a DC offset due to adjusting the contrast. Finally the value 64 is added to reposition the black level at 256. The equation for processing of Y values is: Y’ = ((Y-256) x C) + B + 256, where C is the Contrast value and B is the Brightness value. UV Processing: 2048 is first subtracted from both U and V values to position the range around zero. The hue property is implemented by mixing the U and V values together: U’ = (U-2048) x Cos(H) + (V-2048) x Sin(H) V’ = (V-2048) x Cos(H) – (U-2048) x Sin(H) Where H represents the desired Hue angle; Saturation is adjusted by multiplying both U and V by a constant. Finally, the value 2048 is added to both U and V. The combined processing of Hue and Saturation on the UV data is: U’ = (((U-2048) x Cos(H) + (V-2048) x Sin(H)) x C x S) + 2048 V’ = (((V-2048) x Cos(H) - (U-2048) x Sin(H)) x C x S) + 2048 Where C is the contrast, H is Hue angle and S is the Saturation and the combination of Cos(H)*C*S and Sin(H)*C*S is specified by parameters Cos_c_s and Sin_c_s. 3.6.1.6 Color Space Conversion The CSC block enables linear conversion between color spaces using vector shift, matrix multiplication, and additional shift. The CSC algorithm is a linear coordinate transformation, comprising of the following stages: Shifting the input color coordinate. Multiply by 3*3 matrix Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 189 Shifting the output color coordinate Formula representation of last 3 steps: Where is aij are the matrix elements, i.e., the transform coefficients:  vin_i is the input pixel color components v0_i is the input offset vector, i.e., ,  u0_1_i is the output offset vector. i.e.,  Clipping the output to ensure each component is in allowed range. The parameters is used to set input to be RGB format and is uased to set output to be RGB format Notes about Repacker: There are two states to be used in the repacker:  and . The last module in the IECP pipeline. If Alpha from State Select is set, the Y, U ,V is packed with the information from color pipe alpha, and then the data is sent out to RCPB. Otherwise, “0” is inserted in the 4LSB (alpha) and the packed data is sent out to RCPB. 3.6.1.7 Color Gamut Compression 3.6.1.7.1 Background of Color Gamut Compression While most photography today complies with the sRGB standard color space, which covers around 72% of color perceived by human being, this 72% content looks incorrect/unnatural on wide gamut displays, which can extend more than 100%. Therefore, a gamut mapping (GM) algorithm is required to adjust when the input gamut range is different to the output gamut range such as the input sRGB color space to be displayed onto the WG display, or to adjust the wide gamut content to be displayed onto the traditional lower gamut display. The easiest compression method applied to displaying wider gamut content on lower gamut displays is to clip the out of range primary values to the valid range (i.e., 0-1). Although this simple clipping procedure leads to acceptable visual appearance in most cases, loss of color depth can be observed in the video containing out-of-range pixels. The reason behind this effect should be the uniform quantization process applied to out-of-range values (e.g., two distinct out-of-range red colors are mapped to the same boundary red color). Moreover, the simple clipping method treats each color channel independently. This may lead to unexpected perceptual loss since the composite ratios of three primaries have been changed. An approach which takes these two factors into account while scaling down the out of range values can possibly maintain the detail information of the image. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 190 3.6.1.7.2 Usage Models There are two usage models depending on the set up of bit: Basic mode: fixed-hue color gamut clipping mode Advanced mode: fixed-hue full range mapping mode The application of basic mode of the fixed-hue color gamut clipping is preferred when the content having the smaller percentage of out-of-range pixels in the scene. The advanced mode of fixed-hue full range mapping mode may also change the in-range pixels and is thus preferred when the percentage of out-of- range pixel is large. The outcome of the in/out range pixel percentage is derived from the out-of range color gamut detection module to provide an indicator to operate among basic mode and advanced mode. 3.6.1.7.3 Gamut compression module overview The main goal of color gamut compression module algorithm is to compress out-of-range pixel values while keeping their hue values same as it is before compression. A block diagram to color gamut compress the xv Color video into sRGB format is shown below. AT the pipeline level, the input into Gamut compression unit is from STDE unit and the output from the Gamut compression goes to TCCE unit. The Gamut compression comprises of the following stages: xvYCC decoding YUV2LCH color space conversion Out of range Gamut pixel detection Scaling factor calculation Find out the Euclidean distance for the out of range pixel for advance mode Fixed-hue Gamut compression Bring the out of range pixel to the boundary for basic mode Bring the out of range pixel depending on the distance and apply uniform quantization process in advance mode xvYCC encoding Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 191 3.6.1.7.4 xvYCC decoding The non-linear YCbCr values (i.e.,Y’Cb’Cr’, or Y’UV) is decoded from an example of 8-bit/channel below: . For 12-bit/channel the above equation can be re-written as follows: 3.6.1.7.5 YUV2LCH The parameters for scaling the out-of-range pixel values are determined in LCHuv space, which is the cylindrical version of LUV space. For every input pixel, (Y_in = Y” , U_in = Cb” , V_in = Cr” ) we find its chrominance value (i.e., C) and hue value (i.e., H) , , The approximation of hue angle calculation is described in the TCC session. 3.6.1.7.6 Out-of-range gamut pixel detection An input pixel is denoted as in the LCH color space. If , the pixel can be outputted without pixel value change. Every input pixel is associated with a hue value in LCH space. From the calculated hue value, we can read a corresponding vertex point from the pre-calculated table which contained the 512-entry vertex points of the below color triangle in LCH space with the designated hue value derived off-line. Note that with the symmetric property of the lightness vertex, only vertices in need to be stored in the pre- calculated LUT. Therefore, the 512x2 components in the LUT correspond to the information of 512 equally-distributed hue angles in the range of . Moreover, the vertex value of a certain hue angle is dependent of the color space (e.g., BT. 709 or BT. 601). Here, the vertex point V for a hue angle is denoted as .(3) Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 192 Left: The RGB boundary corresponding to hue value H. Right: the RGB boundary in left projected on the luminance-chrominance plane. Vertex point look up table: Utilizing the hue angle calculation module in TCC, the equally-spaced, discrete hue angle ranging from 0 to is represented with an integer (i.e., angle index) in [0~1023]. Since the LUT in color compression only stores vertices in [0~ ), a mapping procedure is required to remap angles in to before indexing the LUT: if((angle_index < 512) && (angle_index > =0)) angle_index = angle_index; else angle_index = angle_index – 512; With the properly remapped angle index for accessing the LUT, the information of the vertex point can be obtained as below. Sat_Vertex = m_SatVertex[angle_index]; // Sat Vertex form the LUT Luma1 = m_LumaVertex[angle_index]; // lightness vertex in [0~pi) Luma2 = denorm-Luma1; // symmetric lightness vertex; denorm = 4096 in 12 bit representation Note that the lightness vertex is symmetric in uv/ CbCr-plane (i.e., Luma1 + Luma2 = denom), and the lightness vertex stored in the LUT correspond to those in . Thus, one has to check the hue side (i.e., whether this pixel is originally in or in of the current pixel to acquire the correct lightness vertex for this pixel: if(srcV == 0)// 0 or 180 degree Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 193 { if (srcU > 0)// srcU == 0 Cp = 0 Luma_Vertex = Luma1; else Luma_Vertex = Luma2; } else { if(srcV > 0) Luma_Vertex = Luma1; else Luma_Vertex = Luma2; } An input pixel is detected as an out-of-range pixel if the below condition is true. (4) A statistics parameter, , is incremented if the above equation is true. The  will be collected at picture level through VSC unit to assess the property of a picture to determine the strategy of ways to do gamut compression. Note: If is an in-range pixel, the pixel will be outputted according to equation (13). 3.6.1.7.7 Scaling factor – Basic mode The slope of a compression line is defined from the vertex point table. , with  default to be 3.(5) in the above equation is the slope of the compression line while represents the slope of the line perpendicular to the RGB boundary line: , and(6) where .(7) The intersection between the compression line for pixel and the L-axis is denoted as Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 194 , then , and(8) The point nearest to the input pixel on the RGB boundary along the compression direction (i.e., intersection between the compression line and the RGB boundary) be , then , with , and (9) . Scaling factor is denoted as .(10) For the usage of Basic mode - fixed-hue color gamut clipping mode, all out-of-range pixels will be clipped to the boundary, which means (11) And the luma is mapped at along the compression line to hit the boundary line at (12) Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 195 3.6.1.7.8 Fixed-hue compression The output of fixed compression is based on the scaling factor and the property of pixel. , if or , else . (13) 3.6.1.7.9 Scaling factor – Advanced mode The out-of-range pixel values can be mapped inwards according to how far they are from the boundary from the following equation: .(14) . Where is coming from the reference point as the origin of the linear transformation for compressing pixel as Denote the reference point (15) Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 196 3.6.1.7.10 xvYCC encoding The output of Y, Cb and Cr values are scaled back through xvYCC encoding process, and the example for the 12bit format is provided below: 3.6.2 Boundary Behavior The table below summarizes the behavior of the Media Boundary Pixel Mode field (SURFACE_STATE) in combination with the Vertical Line Stride and Vertical Line Stride Offset fields (both of which are subject to being overridden by the Data Port message descriptor fields). The Behavior column illustrates behavior for a surface with four rows numbered 0 to 3. The bold indicators are off-surface behavior and the non-bold indicators are on-surface behavior. Input row addresses range from -3 to +7 going left to right. Media Boundary Pixel Mode Vertical Line Stride Vertical Line Stride Offset Usage Model Behavior 0 0 X normal frame 000001233333 0 1 0 normal field even 000002222222 0 1 1 normal field odd 111113333333 2 0 X frame / progressive 000001233333 2 1 0 field even / progressive 000002333333 2 1 1 field odd / progressive 000013333333 3 0 X frame / interlaced 010101232323 3 1 0 field even / interlaced 000002222222 3 1 1 field odd / interlaced 111113333333 3.7 Accessing Render Targets Render targets are the surfaces that the final results of pixel shaders are written to. The render targets support a large set of surface formats (refer to surface formats table in Sampling Engine for details) with Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 197 hardware conversion from the format delivered by the thread. The render target message also causes numerous side effects, including potentially alpha test, depth test, stencil test, alpha blend (which normally causes a read of the render target), and other functions. These functions are covered in the Windower chapter as some of them (depth/stencil test) are also partially done in the Windower. The render target write messages are specifically for the use of pixel shader threads that are spawned by the windower, and may not be used by any other threads. This is due to the pixel scoreboard side-effects that sending of this message entails. The pixel scoreboard ensures that incorrect ordering of reads and writes to the same pixel does not occur. 3.7.1 Single Source The “normal” render target messages are single source. There are two forms, SIMD16 and SIMD8, intended for the equivalent-sized pixel shader threads. A single color (4 channels) is delivered for each of the 16 or 8 pixels in the message payload. Optional depth, stencil, and antialias alpha information can also be delivered with these messages. The pixel scoreboard bits corresponding to the dispatched pixel mask (or half of the mask in the case of SIMD8 messages) are cleared only if the Last Render Target Select bit is set in the message descriptor. The single source message will not cause a write to the render target if Dual Source Blend Enable in 3DSTATE_WM is enabled. However, if Last Render Target Select is set, the message will still cause pixel scoreboard clear and depth/stencil buffer updates if enabled. 3.7.2 Dual Source The dual source render target messages only have SIMD8 forms due to maximum message length limitations. SIMD16 pixel shaders must send two of these messages to cover all of the pixels. Each message contains two colors (4 channels each) for each pixel in the message payload. In addition to the first source, the second source can be selected as a blend factor (BLENDFACTOR_*_SRC1_* options in the blend factor fields of COLOR_CALC_STATE or BLEND_STATE). Optional depth, stencil, and antialias alpha information can also be delivered with these messages. Each dual source message delivered will clear the corresponding pixel scoreboard bits if the Last Render Target Select bit in the message descriptor is set. The dual source message will revert to a single source message using source 0 if Dual Source Blend Enable in 3DSTATE_WM is disabled. 3.7.3 Replicate Data The replicate data render target message is used for “fast clear” functionality in cases where the color data for each pixel is identical. This message performs better than the other messages due to its smaller message length. This message does not support depth, stencil, or antialias alpha data being sent with it. This message must target only tiled memory. Access of linear memory using this message type is UNDEFINED. The depth buffer can be cleared through the “early depth” function in conjunction with a pixel shader using this message. Refer to the Windower chapter for more details on the early depth function. The pixel scoreboard bits corresponding to the dispatched pixel mask are cleared only if the Last Render Target Select bit is set in the message descriptor. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 198 3.7.4 Multiple Render Targets (MRT) Multiple render targets are supported with the single source and replicate data messages. Each render target is accessed with a separate Render Target Write message, each with a different surface indicated (different binding table index). The depth buffer is written only by the message(s) to the last render target, indicated by the Last Render Target Select bit set to clear the pixel scoreboard bits. MRT is not supported when one or more RTs have this surface formats: YCRCB_SWAPUVY, YCRCB_SWAPUV, YCRCB_SWAPY, YCRCB_NORMAL 3.8 State 3.8.1 BINDING_TABLE_STATE The data port uses the binding table to retrieve surface state. Refer to Statein the Sampling Engine section for the definition of this state. 3.8.2 SURFACE_STATE The data port uses the surface state for constant buffers, render targets, and media surfaces. Refer to SURFACE_STATE in the Sampling Engine section for the definition of this state. 3.8.3 COLOR_PROCESSING_STATE The following state structures contain different states used by the color processing function. COLOR_PROCESSING_STATE - STD/STE State Default 0x9A6E39F0, 0x400C0000, 0x00001180, 0xFE2F2E00, 0x000000FF, 0x00140000, 0xD82E0000, Value: 0x8285ECEC, 0x00008282, 0x00000000, 0x02117000, 0xA38FEC96, 0x00008CC8, 0x00000000, 0x01478000, 0x0007C300, 0x00000000, 0x00000000, 0x1C180000, 0x00000000, 0x00000000, 0x00000000, 0x0007CF80, 0x00000000, 0x00000000, 0x1C080000, 0x00000000, 0x00000000, 0x00000000 This state structure contains the STD/STE state used by the color processing function. DWord Bit Description 0 31:24 V_Mid Default Value: 154 Format: U8 Rectangle middle-point V coordinate 23:16 U_Mid Default Value: 110 Format: U8 Rectangle middle-point U coordinate 15:10 Hue Max Default Value: 14 Format: U6 Rectangle half width Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 199 COLOR_PROCESSING_STATE - STD/STE State 9:4 Sat Max Default Value: 31 Format: U6 Rectangle half length. 3 Reserved Format: MBZ 2 Output Control Value Name 0 Output Pixels [Default] 1 Output STD Decisions 1 STE Enable Format: Enable 0 STD Enable Format: Enable 1 31 Reserved Format: MBZ 30:28 Diamond Margin Default Value: 4 Format: U3 27:21 Diamond du Default Value: 0 Format: S7 2’s complement Rhombus center shift in the sat-direction, relative to the rectangle center. 20:18 HS Margin Default Value: 3 Format: U3 17:10 Cos(α) Format: S0.7 2's Compliment The default is 79/128 9:8 Reserved Format: MBZ 7:0 Sin(α) Format: S0.7 2's Compliment The default is 101/128 2 31:21 Reserved Format: MBZ Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 200 COLOR_PROCESSING_STATE - STD/STE State 20:13 Diamond Alpha Format: U2.6 1 / tan(β) The default is 100/64 12:7 Diamond Th Default Value: 35 Format: U6 Half length of the rhombus axis in the sat-direction. 6:0 Diamond dv Default Value: 0 Format: S6 2’s complement 3 31:24 Y_point_3 Default Value: 254 Format: U8 Third point of the Y piecewise linear membership function. 23:16 Y_point_2 Default Value: 47 Format: U8 Second point of the Y piecewise linear membership function. 15:8 Y_point_1 Default Value: 46 Format: U8 First point of the Y piecewise linear membership function. 7 VY_STD_Enable Format: Enable Enables STD in the VY subspace. 6:0 Reserved Format: MBZ 4 31:18 Reserved Format: MBZ 17:13 Y_Slope_2 Format: U2.3 Slope between points Y3 and Y4. The default is 31/8. 12:8 Y_Slope_1 Format: U2.3 Slope between points Y1 and Y2. The default is 31/8. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 201 COLOR_PROCESSING_STATE - STD/STE State 7:0 Y_point_4 Default Value: 255 Format: U8 Fourth point of the Y piecewise linear membership function 5 31:16 INV_skin_types_margin Format: U0.16 1/(2* Skin_types_margin) Value Name Description 20 [Default] Skin_Type_margin 15:0 Inverse Margin VYL Format: U0.16 1 / Margin_VYL The default is 3300/65536 6 31:24 P1L Default Value: 216 Format: U8 Y Point 1 of the lower part of the detection PWLF. 23:16 P0L Default Value: 46 Format: U8 Y Point 0 of the lower part of the detection PWLF. 15:0 Inverse Margin VYU Format: U0.16 1 / Margin_VYU The default is 1600/65536. 7 31:24 B1L Default Value: 130 Format: U8 V Bias 1 of the lower part of the detection PWLF. 23:16 B0L Default Value: 133 Format: U8 V Bias 0 of the lower part of the detection PWLF. 15:8 P3L Default Value: 236 Format: U8 Y Point 3 of the lower part of the detection PWLF. 7:0 P2L Default Value: 236 Format: U8 Y point 2 of the lower part of the detection PWLF. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 202 COLOR_PROCESSING_STATE - STD/STE State 8 31:27 Reserved Format: MBZ 26:16 S0L Format: S2.8 2's complement Slope 0 of the lower part of the detection PWLF. The default is -5/256. 15:8 B3L Default Value: 130 Format: U8 V Bias 3 of the lower part of the detection PWLF. 7:0 B2L Default Value: 130 Format: U8 V Bias 2 of the lower part of the detection PWLF. 9 31:22 Reserved Format: MBZ 21:11 S2L Format: S2.8 2's complement Slope 2 of the lower part of the detection PWLF. The default is 0/256. 10:0 S1L Format: S2.8 2's complement Slope 1 of the lower part of the detection PWLF. The default is 0/256. 10 31:27 Reserved Format: MBZ 26:19 P1U Default Value: 66 Format: U8 Y Point 1 of the upper part of the detection PWLF. 18:11 P0U Default Value: 46 Format: U8 Y Point 0 of the upper part of the detection PWLF. 10:0 S3L Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 203 COLOR_PROCESSING_STATE - STD/STE State Format: S2.8 2's complement Slope 3 of the lower part of the detection PWLF. The default is 0/256. 11 31:24 B1U Default Value: 163 Format: U8 V Bias 1 of the upper part of the detection PWLF. 23:16 B0U Default Value: 143 Format: U8 V Bias 0 of the upper part of the detection PWLF. 15:8 P3U Default Value: 236 Format: U8 Y Point 3 of the upper part of the detection PWLF. 7:0 P2U Default Value: 150 Format: U8 Y Point 2 of the upper part of the detection PWLF. 12 31:27 Reserved Format: MBZ 26:16 S0U Format: S2.8 2's complement Slope 0 of the upper part of the detection PWLF. The default is 256/256. 15:8 B3U Default Value: 140 Format: U8 V Bias 3 of the upper part of the detection PWLF. 7:0 B2U Default Value: 200 Format: U8 V Bias 2 of the upper part of the detection PWLF. 13 31:22 Reserved Format: MBZ 21:11 S2U Format: S2.8 2's complement Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 204 COLOR_PROCESSING_STATE - STD/STE State Slope 2 of the upper part of the detection PWLF. The default is -179/256. 10:0 S1U Format: S2.8 2's complement Slope 1 of the upper part of the detection PWLF. The default is -113/256. 14 31:28 Reserved Format: MBZ 27:20 Skin Types Margin Default Value: 20 Format: U8 Skin types Y margin. 19:12 Skin Types Thresh Default Value: 120 Format: U8 Skin types Y threshold. 11 Skin Type Enable Format: Enable Treat differently bright and dark skin types. Value Name Description 0 [Default] Disable 10:0 S3U Format: S2.8 2's complement Slope 3 of the upper part of the detection PWLF. The default is 0/256. 15 31 Reserved Format: MBZ 30:21 SATB1 Format: S7.2 2's complement First bias for the saturation PWLF (bright skin). The default is -8/4. 20:14 SATP3 Default Value: 31 Format: S6 2's complement Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 205 COLOR_PROCESSING_STATE - STD/STE State Third point for the saturation PWLF (bright skin). 13:7 SATP2 Default Value: 6 Format: S6 2's complement Second point for the saturation PWLF (bright skin). 6:0 SATP1 Format: S6 2's complement First point for the saturation PWLF (bright skin). The default is -6. 16 31 Reserved Format: MBZ 30:20 SATS0 Format: U3.8 Zeroth slope for the saturation PWLF (bright skin). The default is 297/256. 19:10 SATB3 Format: S7.2 2's complement Third bias for the saturation PWLF (bright skin). The default is 124/4. 9:0 SATB2 Format: S7.2 2's complement Second bias for the saturation PWLF (bright skin). The default is 8/4. 17 31:22 Reserved Format: MBZ 21:11 SATS2 Format: U3.8 Second slope for the saturation PWLF (bright skin). The default is 297/256. 10:0 SATS1 Format: U3.8 First slope for the saturation PWLF (bright skin). The default is 85/256. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 206 COLOR_PROCESSING_STATE - STD/STE State 18 31:25 HUEP3 Default Value: 14 Format: S6 2's complement Third point for the hue PWLF (bright skin) 24:18 HUEP2 Default Value: 6 Format: S6 2's complement Second point for the hue PWLF (bright skin) 17:11 HUEP1 Format: S6 2's complement First point for the hue PWLF (bright skin). The default is -6. 10:0 SATS3 Format: U3.8 Thrid slope for the saturation PWLF (bright skin). The default is 256/256. 19 31:30 Reserved Format: MBZ 29:20 HUEB3 Format: S7.2 2's complement Third bias for the hue PWLF (bright skin). The default is 56/4. 19:10 HUEB2 Format: S7.2 2's complement Second bias for the hue PWLF (bright skin). The default is 8/4. 9:0 HUEB1 Format: S7.2 2's complement First bias for the hue PWLF (bright skin). The default is -8/4. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 207 COLOR_PROCESSING_STATE - STD/STE State 20 31:22 Reserved Format: MBZ 21:11 HUES1 Format: U3.8 First slope for the hue PWLF (bright skin) The default is 85/256. 10:0 HUES0 Format: U3.8 Zeroth slope for the hue PWLF (bright skin) The default is 384/256. 21 31:22 Reserved Format: MBZ 21:11 HUES3 Format: U3.8 Third slope for the hue PWLF (bright skin) The default is 256/256. 10:0 HUES2 Format: U3.8 Second slope for the hue PWLF (bright skin) The default is 384/256. 22 31 Reserved 30:21 SATB1_DARK Format: S7.2 2's complement First bias for the saturation PWLF (dark skin) The default is 0/4. 20:14 SATP3_DARK Default Value: 31 Format: S6 2's complement Third point for the saturation PWLF (dark skin) 13:7 SATP2_DARK Default Value: 31 Format: S6 2's complement Second point for the saturation PWLF (dark skin) 6:0 SATP1_DARK Format: S6 2's complement Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 208 COLOR_PROCESSING_STATE - STD/STE State First point for the saturation PWLF (dark skin). The default is -11. 23 31 Reserved Format: MBZ 30:20 SATS0_DARK Format: U3.8 Zeroth slope for the saturation PWLF (dark skin). The default is 397/256. 19:10 SATB3_DARK Format: S7.2 2's complement Third bias for the saturation PWLF (dark skin). The default is 124/4. 9:0 SATB2_DARK Format: S7.2 2's complement Second bias for the saturation PWLF (dark skin). The default is 124/4. 24 31:22 Reserved Format: U3.8 21:11 SATS2_DARK Format: U3.8 Second slope for the saturation PWLF (dark skin). The default is 256/256. 10:0 SATS1_DARK Format: U3.8 First slope for the saturation PWLF (dark skin). The default is 189/256. 25 31:25 HUEP3_DARK Default Value: 14 Format: S6 2's complement Third point for the hue PWLF (dark skin). 24:18 HUEP2_DARK Default Value: 2 Format: S6 2's complement Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 209 COLOR_PROCESSING_STATE - STD/STE State Third point for the hue PWLF (dark skin). 17:11 HUEP1_DARK Default Value: 0 Format: S6 2's complement Third point for the hue PWLF (dark skin). 10:0 SATS3_DARK Format: U3.8 Third slope for the saturation PWLF (dark skin). The default is 256/256. 26 31:30 Reserved Format: MBZ 29:20 HUEB3_DARK Format: S7.2 2's complement Third bias for the hue PWLF (dark skin). The default is 56/4. 19:10 HUEB2_DARK Format: S7.2 2's complement Second bias for the hue PWLF (dark skin). The default is 0/4. 9:0 HUEB1_DARK Format: S7.2 2's complement First bias for the hue PWLF (dark skin). The default is 0/4. 27 31:22 Reserved Format: MBZ 21:11 HUES1_DARK Format: U3.8 First slope for the hue PWLF (dark skin). The default is 0/256. 10:0 HUES0_DARK Format: U3.8 Zeroth slope for the hue PWLF (dark skin). The default is 256/256. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 210 COLOR_PROCESSING_STATE - STD/STE State 28 31:22 Reserved Format: MBZ 21:11 HUES3_DARK Format: U3.8 Third slope for the hue PWLF (dark skin). The default is 256/256. 10:0 HUES2_DARK Format: U3.8 Second slope for the hue PWLF (dark skin). The default is 299/256. COLOR_PROCESSING_STATE - ACE State Default 0x00000068, 0x4C382410, 0x9C887460, 0xEBD8C4B0, 0x604C3824, 0xB09C8874, 0x0000D8C4, Value: 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 This state structure contains the ACE state used by the color processing function. DWord Bit Description 29 31:7 Reserved Format: MBZ 6:2 Skin Threshold Format: U5 Used for Y analysis (min/max) for pixels which are higher than skin threshold. Value Name 1-31 26 [Default] 1 Full Image Histogram Default Value: 0 Format: Enable Used to ignore the area of interest for full image histogram. 0 ACE Enable Format: Enable 30 31:24 Y3 Default Value: 76 Format: U8 The value of the y_pixel for point 3 in PWL. 23:16 Y2 Default Value: 56 Format: U8 The value of the y_pixel for point 2 in PWL. 15:8 Y1 Default Value: 36 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 211 COLOR_PROCESSING_STATE - ACE State Format: U8 The value of the y_pixel for point 1 in PWL. 7:0 Ymin Default Value: 16 Format: U8 The value of the y_pixel for point 0 in PWL. 31 31:24 Y7 Default Value: 156 Format: U8 The value of the y_pixel for point 7 in PWL. 23:16 Y6 Default Value: 136 Format: U8 The value of the y_pixel for point 6 in PWL. 15:8 Y5 Default Value: 116 Format: U8 The value of the y_pixel for point 5 in PWL. 7:0 Y4 Default Value: 96 Format: U8 The value of the y_pixel for point 4 in PWL. 32 31:24 Ymax Default Value: 235 Format: U8 The value of the y_pixel for point 11 in PWL. 23:16 Y10 Default Value: 216 Format: U8 The value of the y_pixel for point 10 in PWL. 15:8 Y9 Default Value: 196 Format: U8 The value of the y_pixel for point 9 in PWL. 7:0 Y8 Default Value: 176 Format: U8 The value of the y_pixel for point 8 in PWL. 33 31:24 B4 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 212 COLOR_PROCESSING_STATE - ACE State Default Value: 96 Format: U8 The value of the bias for point 4 in PWL. 23:16 B3 Default Value: 76 Format: U8 The value of the bias for point 3 in PWL. 15:8 B2 Default Value: 56 Format: U8 The value of the bias for point 2 in PWL. 7:0 B1 Default Value: 36 Format: U8 The value of the bias for point 1 in PWL. 34 31:24 B8 Default Value: 176 Format: U8 The value of the bias for point 8 in PWL. 23:16 B7 Default Value: 156 Format: U8 The value of the bias for point 7 in PWL. 15:8 B6 Default Value: 136 Format: U8 The value of the bias for point 6 in PWL. 7:0 B5 Default Value: 116 Format: U8 The value of the bias for point 5 in PWL. 35 31:16 Reserved Format: MBZ 15:8 B10 Default Value: 216 Format: U8 The value of the bias for point 10 in PWL. 7:0 B9 Default Value: 196 Format: U8 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 213 COLOR_PROCESSING_STATE - ACE State The value of the bias for point 9 in PWL. 36 31:27 Reserved Format: MBZ 26:16 S1 Format: U1.10 The value of the slope for point 1 in PWL. The default is 1024/1024. 15:11 Reserved Format: MBZ 10:0 S0 Format: U1.10 The value of the slope for point 0 in PWL. The default is 1024/1024. 37 31:27 Reserved Format: MBZ 26:16 S3 Format: U1.10 The value of the slope for point 3 in PWL. The default is 1024/1024. 15:11 Reserved Format: MBZ 10:0 S2 Format: U1.10 The value of the slope for point 2 in PWL. The default is 1024/1024. 38 31:27 Reserved Format: MBZ 26:16 S5 Format: U1.10 The value of the slope for point 5 in PWL. The default is 1024/1024. 15:11 Reserved Format: MBZ 10:0 S4 Format: U1.10 The value of the slope for point 4 in PWL. The default is 1024/1024. 39 31:27 Reserved Format: MBZ 26:16 S7 Format: U1.10 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 214 COLOR_PROCESSING_STATE - ACE State The value of the slope for point 7 in PWL. The default is 1024/1024. 15:11 Reserved Format: MBZ 10:0 S6 Format: U1.10 The value of the slope for point 6 in PWL. The default is 1024/1024. 40 31:27 Reserved Format: MBZ 26:16 S9 Format: U1.10 The value of the slope for point 9 in PWL. The default is 1024/1024. 15:11 Reserved Format: MBZ 10:0 S8 Format: U1.10 The value of the slope for point 8 in PWL. The default is 1024/1024. 41 31:11 Reserved Format: MBZ 10:0 S10 Format: U1.10 The value of the slope for point 10 in PWL. The default is 1024/1024. COLOR_PROCESSING_STATE - TCC State Default 0xDCDCDC00, 0xDCDCDC00, 0x1E34CC91, 0x3E3CCE91, 0x02E80195, 0x0197046B, 0x01790174, Value: 0x00096000, 0x00000000, 0x03030000, 0x009201C0 This state structure contains the TCC state used by the color processing function. DWord Bit Description 42 31:24 SatFactor3 Default Value: 220 Format: U1.7 The saturation factor for yellow. 23:16 SatFactor2 Default Value: 220 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 215 COLOR_PROCESSING_STATE - TCC State Format: U1.7 The saturation factor for red. 15:8 SatFactor1 Default Value: 220 Format: U1.7 The saturation factor for magenta. 7 TCC Enable Format: Enable 6:0 Reserved Format: MBZ 43 31:24 SatFactor6 Default Value: 220 Format: U1.7 The saturation factor for blue. 23:16 SatFactor5 Default Value: 220 Format: U1.7 The saturation factor for cyan. 15:8 SatFactor4 Default Value: 220 Format: U1.7 The saturation factor for green. 7:0 Reserved Format: MBZ 44 31:30 Reserved Format: MBZ 29:20 Base Color 3 Default Value: 483 Format: U10 19:10 Base Color 2 Default Value: 307 Format: U10 9:0 Base Color 1 Default Value: 145 Format: U10 45 31:30 Reserved Format: MBZ 29:20 Base Color 6 Default Value: 995 Format: U10 19:10 Base Color 5 Default Value: 819 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 216 COLOR_PROCESSING_STATE - TCC State Format: U10 9:0 Base Color 4 Default Value: 657 Format: U10 46 31:16 Color Transit Slope 23 Default Value: 744 Format: U0.16 The calculation result of 1 / (BC3 – BC2) [1/62] 15:0 Color Transit Slope 12 Default Value: 405 Format: U0.16 The calculation result of 1 / (BC2 – BC1) [1/57] 47 31:16 Color Transit Slope 45 Default Value: 407 Format: U0.16 The calculation result of 1 / (BC5 – BC4) [1/57] 15:0 Color Transit Slope 34 Default Value: 1131 Format: U0.16 The calculation result of 1 / (BC4 – BC3) [1/61] 48 31:16 Color Transit Slope 61 Default Value: 377 Format: U0.16 The calculation result of 1 / (BC1 – BC6) [1/62] 15:0 Color Transit Slope 56 Default Value: 372 Format: U0.16 The calculation result of 1 / (BC6 – BC5) [1/62] 49 31:22 Color Bias 3 Default Value: 0 Format: U2.8 Color bias for BaseColor3. 21:12 Color Bias 2 Default Value: 150 Format: U2.8 Color bias for BaseColor2. 11:2 Color Bias 1 Default Value: 0 Format: U2.8 Color bias for BaseColor1. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 217 COLOR_PROCESSING_STATE - TCC State 1:0 Reserved Format: MBZ 50 31:22 Color Bias 6 Default Value: 0 Format: U2.8 Color bias for BaseColor6. 21:12 Color Bias 5 Default Value: 0 Format: U2.8 Color bias for BaseColor5. 11:2 ColorBias4 Default Value: 0 Format: U2.8 Color bias for BaseColor4. 1:0 Reserved Format: MBZ 51 31 Reserved Format: MBZ 30:24 UV Threshold Default Value: 3 Format: U7 Low UV threshold. 23:19 Reserved Format: MBZ 18:16 UV Threshold Bits Default Value: 3 Format: U3 Low UV transition width bits. 15:13 Reserved Format: MBZ 12:8 STE Threshold Default Value: 0 Format: U5 Skin tone pixels enhancement threshold. 7:3 Reserved Format: MBZ 2:0 STE Slope Bits Default Value: 0 Format: U3 Skin tone pixels enhancement slope bits. 52 31:16 Inverse UVMax Color Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 218 COLOR_PROCESSING_STATE - TCC State Default Value: 146 Format: U0.16 1 / UVMaxColor. Used for the SFs2 calculation. 15:9 Reserved Format: MBZ 8:0 UVMax Color Default Value: 448 Format: U9 The maximum absolute value of the legal UV pixels. Used for the SFs2 calculation. COLOR_PROCESSING_STATE - PROCAMP State Default Value: 0x00020001, 0x01000000 This state structure contains the PROCAMP state used by the color processing function. DWord Bit Description 53 31:28 Reserved Format: MBZ 27:17 Contrast Default Value: 1 Format: U4.7 Contrast magnitude. 16:13 Reserved Format: MBZ 12:1 Brightness Default Value: 0 Format: S7.4 2's complement Brightness magnitude. 0 PROCAMP Enable Default Value: 1 Format: Enable 54 31:16 Cos_c_s Default Value: 256 Format: S7.8 2's complement UV multiplication cosine factor. 15:0 Sin_c_s Default Value: 0 Format: S7.8 2's complement Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 219 COLOR_PROCESSING_STATE - PROCAMP State UV multiplication sine factor. COLOR_PROCESSING_STATE - CSC State Default 0x00002000, 0x00000000, 0x00000400, 0x00000000, 0x000004B4, 0x00000000, 0x00000000, Value: 0x00000000, 0x00000000 This state structure contains the CSC state used by the color processing function. DWord Bit Description 55 31:29 Reserved Format: MBZ 28:16 C1 Default Value: 0 Format: S2.10 2's complement Transform coefficient 15:3 C0 Default Value: 1024 Format: S2.10 2's complement Transform coefficient 2 YUV_IN Default Value: 0 Format: YUV CSC input offset enable. 1 YUV_OUT Default Value: 0 Format: RGB CSC output offset enable. 0 Transform Enable Format: Enable 56 31:26 Reserved Format: MBZ 25:13 C3 Default Value: 0 Format: S2.10 2's complement Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 220 COLOR_PROCESSING_STATE - CSC State Transform coefficient. 12:0 C2 Default Value: 0 Format: S2.10 2's complement Transform coefficient. 57 31:26 Reserved Format: MBZ 25:13 C5 Default Value: 0 Format: S2.10 2's complement Transform coefficient. 12:0 C4 Default Value: 1024 Format: S2.10 2's complement Transform coefficient. 58 31:26 Reserved Format: MBZ 25:13 C7 Default Value: 0 Format: S2.10 2's complement Transform coefficient. 12:0 C6 Default Value: 0 Format: S2.10 2's complement Transform coefficient. 59 31:13 Reserved Format: MBZ 12:0 C8 Default Value: 1204 Format: S2.10 2's complement Transform coefficient. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 221 COLOR_PROCESSING_STATE - CSC State 60 31:20 Reserved Format: MBZ 19:10 Offset out 1 Default Value: 0 Format: S9 2's complement Offset Out for Y/R. 9:0 Offset In 1 Default Value: 0 Format: S9 2's complement Offset in for Y/R. 61 31:20 Reserved Format: MBZ 19:10 Offset out 2 Default Value: 0 Format: S9 2's complement Offset out for U/G. 9:0 Offset in 2 Default Value: 0 Format: S9 2's complement Offset in for U/G. 62 31:20 Reserved Format: MBZ 19:10 Offset out 3 Default Value: 0 Format: S9 2's complement Offset out for V/B. 9:0 Offset in 3 Default Value: 0 Format: S9 2's complement Offset in for V/B. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 222 COLOR_PROCESSING_STATE - CSC State 63 31:17 Reserved Format: MBZ 16 Alpha from State Select Format: U1 Enumerated Type Value Name Description 0 Alpha is taken from message 1 Alpha is taken from state 15:0 Color Pipe Alpha Format: U16 COLOR_PROCESSING_STATE - CGC State Default Value: 0x0CD2911F, 0x30000334, 0x8A800000 This state structure contains the CGC state used by the color processing function. DWord Bit Description 64 31 Color Gamut Compression Enable 30 Full Range Mapping Enable Value Name 0 Basic Mode [Default] 1 Advanced Mode 29:20 d(in,default) Default Value: 205 Format: U10 din.defaultInnerTriangleMappingLength 19:10 d(out,default) Default Value: 164 Format: U10 dout.defaultOuterTriangleMappingLength 9:0 d1(out) Default Value: 287 Format: U10 d1outOuterTriangleMappingLengthBelow 65 31 Reserved Format: MBZ 30:28 Compression Line Shift Value Name 0-4 3 [Default] Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 223 COLOR_PROCESSING_STATE - CGC State 27:10 Reserved Format: MBZ 9:0 d1(in) Default Value: 820 Format: U10 d1inInnerTriangleMappingLengthBelow 66 31 xvYcc Decode Encode Enable Value Name Description 1 [Default] Both xvYcc decode and xvYcc encode are enabled 0 Disable both xvYcc decode and xvYcc encode Programming Notes This bit is valid only when ColorGamutCompressionnEnable is on. 30 Forced 444 for 444 Default Value: 0 Force the 4:4:4 operation when input video of 4:4:4 format 29 Forced 422 for 444 Default Value: 0 Force the 4:2:2 operation when input video of 4:4:4 format 28 Forced 444 for 422 Default Value: 0 Force the 4:4:4 operation when input video of 4:2:2 format 27:26 STD Factor Mode Value Name Description 00b STDMin Select the minimum value of the STD factors 01b STDMax Select the maximum value of the STD factors 10b STDAve [Default] Select the average value of the STD factors 11b Reserved Programming Notes This field is only valid for input of 4:2:2 (Forced444_for 422 is disabled), or when (Forced422_for444 is enabled). 25:24 MV Dark Factor Mode Value Name Description 00b MVDarkMin Select the minimum value of the MVDark factors 01b MVDarkMax Select the maximum value of the MVDark factors 10b MVDarkAve [Default] Select the average value of the MVDark factors 11b Reserved Programming Notes This field is only valid for input of 4:2:2 (Forced444_for 422 is disabled), or when (Forced422_for444 is enabled). Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 224 COLOR_PROCESSING_STATE - CGC State 23:22 Scaling Factor Mode This mode is for color gamut compression module Value Name Description 00b SFMin Select the minimum value of the Scaling Factors 01b SFMax Select the maximum value of the Scaling Factors 10b SFAve [Default] Select the average value of the Scaling Factors 11b Reserved Programming Notes This field is only valid for input of 4:2:2 (Forced444_for 422 is disabled), or when (Forced422_for444 is enabled). 21:5 Reserved Format: Reserved 4 Override Saturation Equal Zero Format: MBZ Programming Notes This bit should always be 0. 3:0 Display Color Space Mode Value Name 0 BT709 1 BT601 2-15 Reserved 3.9 Messages 3.9.1 Global Definitions For data port messages, part of the message descriptor is used to determine the message type. This field is documented here. The remainder of the message descriptor is defined differently depending on the message type, and is documented in the section for the corresponding message. The Data Port is actually three separate targets, DataPort Sampler Cache, DataPort Constant Cache, and Data Port Render Cache, each with its own target unit ID. Each target has its own set of message type encodings as shown below. Restrictions: Data port messages may not have the End of Thread bit set in the message descriptor other than the following exeptions: The Render Target Write message may have End of Thread set for pixel shader threads dispatched by the windower in non-contiguous dispatch mode. The Render Target UNORM Write message may have End of Thread set for pixel shader threads dispatched by the windower in contiguous dispatch mode. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 225 The Media Block Write message may have End of Thread set for pixel shader threads dispatched by the windower in contiguous dispatch mode. 3.9.2 Data Port Messages Most of the messages have an existing definition that is not expected to change. There are several new messages that are documented here. Data Cache Data Port Message Summary Shared Local Memory Stateless Address Vector Message Type Header Required Support Support Modes Width OWord Block Read yes no yes global 1 OWord Block Write yes no yes global 1 Unaligned OWord Block yes no yes global 1 Read OWord Dual Block no yes global + offset 2 Read no for stated yes for stateless OWord Dual Block no yes global + offset 2 Write no for stated yes for stateless DWord Scattered Read no yes global + offset 8, 16 no for stated yes for stateless DWord Scattered Write no yes global + offset 8, 16 no for stated yes for stateless Byte Scattered Read yes global + offset 8, 16 no for stated yes for stateless Byte Scattered Write yes global + offset 8, 16 no for stated yes for stateless Untyped Surface Read yes 1D or 2D 2, 8, 16 no for stated yes for stateless Untyped Surface Write yes 1D or 2D 2, 8, 16 no for stated yes for stateless Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 226 Shared Local Memory Stateless Address Vector Message Type Header Required Support Support Modes Width Untyped Atomic yes 1D or 2D 8, 16 Operation no for stated yes for stateless Scratch Block Read yes no yes (only) Imm_Buf + offset Scratch Block Write yes no yes (only) Imm_Buf + offset Memory Fence yes N/A N/A N/A N/A “global” is the Global Offset in the message header (if header is not present, Global Offset is zero). “imm_buf” is the Immediate Buffer Base Address provided in message header register M0.5. “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. “1D” and “2D” are the address payload. Render Cache Data Port Message Summary Message Type Header Required Address Modes Vector Width Media Block Read yes 2D 1 Media Block Write yes 2D 1 Render Target Write 2D + RTAI 8, 16 No 1 Typed Surface Read yes 1D, 2D, 3D, 4D 8 Typed Surface Write yes 1D, 2D, 3D, 4D 8 Typed Atomic Operation yes 1D, 2D, 3D, 4D 8 Memory Fence yes N/A N/A “4D” address refers to U/V/R/LOD for mip-mapped surfaces “2D + RTAI” address refers to a basic 2D address with render target array index for the third dimension 3.9.2.1 Message Descriptor The following message descriptor applies to. DATA PORT SAMPLER DATA PORT CONSTANT DATA PORT RENDER CACHE CACHE CACHE Bit Description Bit Description Bit Description 19 Header Present. If set, indicates that the message includes the header. Refer to Render Target Write message section for more details on this field. Programming Notes: The header must be present unless the message type is Render Target Write Format = Enable 18 Ignored 17:16 Ignored 17:16 Ignored 17 Send Write Commit Message. Indicates that a write commit message will be sent back to the thread when the write has been committed. See section Write Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 227 DATA PORT SAMPLER DATA PORT CONSTANT DATA PORT RENDER CACHE CACHE CACHE Commit for more details. This field is ignored on read message types. Format = Enable 15:13 15:13 16:13 Message Message Message Type Type Type 0000: OWord Block Read 000: OWord 000: OWord 0001: Render Target UNORM Read Block Read Block Read 0010: OWord Dual Block Read 010: OWord 010: OWord Dual Block Dual Block 0100: Media Block Read Read Read 0101: Unaligned OWord Block Read 100: Media 110: DWord 0110: DWord Scattered Read Block Read Scattered Read 0111: DWord Atomic write message 101: Unaligned All other 1000: OWord Block Write OWord Block encodings 1001: OWord Dual Block Write Read are reserved. 1010: Media Block Write 110: DWord Scattered 1011: DWord Scattered Write Read 1100: Render Target Write All other 1101: Streamed Vertex Buffer Write encodings are reserved. 1110: Render Target UNORM Write All other encodings are reserved. 12:8 Message Specific Control. Refer to the specific message section for the definition of these bits. 7:0 Binding Table Index. Specifies the index into the binding table for the specified surface. A binding table index of 255 indicates that a stateless model is to be used. The stateless model is allowed only with the render cache data port. Refer to section 2.2.2 for details on the stateless model. Format = U8 Range = [0,255] Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 228 3.9.2.1.1 Message Descriptor The following message descriptor applies to. SAMPLER CACHE DATA PORT RENDER CACHE DATA PORT Bit Description Bit Description 19 Header Present. If set, indicates that the message includes the header. Programming Notes: For the Render Cache Data Port, the header must be present for the following message types: Typed Surface Read/Write Typed Surface Atomic Operation Memory Fence For the Sampler Cache Data Port, the header must be present for the following message types: Unaligned OWord Block Read Media Block Read. Format = Enable 18 Ignored 18 Ignored 17:14 17:14 Message Type Message Type 0001: Unaligned OWord Block Read 0100: Media Block Read 0100: Media Block Read 0101: Typed Surface Read All other encodings are reserved. 0110: Typed Atomic Operation 0111: Memory Fence 1010: Media Block Write 1100: Render Target Write 1101: Typed Surface Write All other encodings are reserved. 13:8 Message Specific Control. Refer to the specific message section for the definition of these bits. 7:0 Binding Table Index. Specifies the index into the binding table for the specified surface. Format = U8 Range = [0,255] CONSTANT CACHE DATA PORT DATA CACHE DATA PORT Bit Description Bit Description 19 Header Present. If set, indicates that the message includes the header. Programming Notes: Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 229 CONSTANT CACHE DATA PORT DATA CACHE DATA PORT Bit Description Bit Description For the Data Cache Data Port, the header must be present for the following message types: OWord Block Read/Write Unaligned OWord Block Read Memory Fence Scratch read/write For the Constant Cache Data Port, the header must be present for the following message types: OWord Block Read Unaligned OWord Block Read. Format = Enable 18 Ignored 18 Category 0: Legacy DAP-DC messages 1: Scratch Block Read/Write messages 17:14 17:14 Message Type Category=0 (legacy dataport) 0000: OWord Block Read Message Type 0001: Unaligned OWord Block Read 0000: OWord Block Read 0010: OWord Dual Block Read 0001: Unaligned OWord Block Read 0011: DWord Scattered Read 0010: OWord Dual Block Read All other encodings are reserved. 0011: DWord Scattered Read 0100: Byte Scattered Read 0101: Untyped Surface Read 0110: Untyped Atomic Operation 0111: Memory Fence 1000: OWord Block Write 1010: OWord Dual Block Write 1011: DWord Scattered Write 1100: Byte Scattered Write 1101: Untyped Surface Write All other encodings are reserved. Category=1 (scratch) [17]: 0=Read; 1=write [16]:Type; 0=Oword, 1= Dword Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 230 CONSTANT CACHE DATA PORT DATA CACHE DATA PORT Bit Description Bit Description [15]:Invalidate after read; [14]: [13:12]: Block Size 11: 4 registers 10: 01: 2 registers 00: 1 register [11:0]: Addr offset (Hword based) 13:8 Message Specific Control. Refer to the specific message section for the definition of these bits. 7:0 Binding Table Index. Specifies the index into the binding table for the specified surface. For the data cache data port, two binding table indexes are used to select special surfaces: 254: A binding table index of 254 indicates that the shared local memory (SLM) is to be used. The SLM is only supported with the Byte Scattered Read/Write, Untyped Surface Read/Write, and Untyped Atomic Operation messages. Refer to the “Shared Local Memory” section earlier in this chapter for further details on its behavior. 255: A binding table index of 255 indicates that a stateless model is to be used. Stateless model is only supported with the OWord Block Read/Write, Unaligned OWord Block Read, Dual OWord Block Read/Write and DWord Scattered Read/Write messages. Refer to section “Stateless Model” section for details on the stateless model. Format = U8 Range = [0,255] 3.9.2.2 Message Header This header applies to the following data port messages:  OWord Block Read/Write  Unaligned OWord Block Read  OWord Dual Block Read/Write  DWord Scattered Read/Write  Byte Scattered Read/Write  Scratch Block Read/Write The header definitions for the other data port messages is in the section for each message. DWord Bit Description M0.7 31:0 M0.6 31:0 M0.5 31:10 Immediate Buffer Base Address. Specifies the surface base address for messages in which the Binding Table Index is 255 (stateless model), otherwise this field is ignored. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 231 DWord Bit Description This pointer is relative to the General State Base Address. Format = GeneralStateOffset[31:10] 9:8 Ignored 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. M0.4 31:0 Ignored (reserved for hardware delivery of binding table pointer) M0.3 31:4 Ignored 3:0 Programming Notes: This amount is available to the kernel for information only. It will be passed verbatim (if not altered by the kernel) to the Data Port in any scratch space access messages. The data port will use this to bounds check scratch space messages. Writes out of bounds will be ignored. Reads out of bounds will return 0. Format = U4 Range = [0,11] indicating [1k bytes, 2M bytes] in powers of two M0.2 31:0 Global Offset. : Specifies the global element offset into the buffer. For the Unaligned OWord messages, this offset is in units of Bytes but must be DWord aligned (bits 1:0 MBZ) For the other OWord messages, this offset is in units of OWords For the DWord messages, this offset is in units of DWords For the Byte messages, this offset is in units of Bytes Format = U32 Range = [0,FFFFFFFCh] for Unaliged OWord messages Range = [0,0FFFFFFFh] for other OWord messages Range = [0,3FFFFFFFh] for DWord messages Range = [0,FFFFFFFFh] for Byte messages M0.1 31:0 Ignored M0.0 31:0 Ignored 3.9.2.3 Write Commit Writeback Message The writeback message is only sent on Data Port Write messages if the Send Write Commit Message bit in the message descriptor is set. The destination register is not modified. Write messages without the Send Write Commit Message bit set will not return anything to the thread (response length is 0 and destination register is null). DWord Bit Description W0.7:0 Reserved Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 232 3.9.3 OWord Block Read/Write This message takes one offset (Global Offset), and reads or writes 1, 2, 4, or 8 contiguous OWords starting at that offset. Restrictions: 1. the only surface type allowed is SURFTYPE_BUFFER. 2. the surface format is ignored, data is returned from the constant buffer to the GRF without format conversion. 3. the surface pitch is ignored, the surface is treated as a 1-dimensional surface. An element size (pitch) of 16 bytes is used to determine the size of the buffer for out-of-bounds checking if using the surface state model. 4. the surface cannot be tiled 5. the surface base address must be OWord aligned 6. the Render Cache Read Write Mode field in SURFACE_STATE must be set to read/write mode when using this message with the render cache in the surface state model 7. the Stateless Render Cache Read-Write Mode field in the SVG_WORK_CTL register must be set to read/write mode when using this message with the render cache in the stateless model Applications: Constant buffer reads of a single constant or multiple contiguous constants. Scratch space reads/writes where the index for each pixel/vertex is the same. Block constant reads, scratch memory reads/writes for media. Execution Mask. The low 8 bits of the execution mask are used to enable the 8 channels in the first and third GRF registers returned (W0, W2) for read, or the first and third write registers sent (M1, M3). The high 8 bits are used similarly for the second and fourth (W1, W3 or M2, M4). For reads, any mask bit asserted within a group of four will cause the entire OWord to be read and returned to the destination GRF register. For writes, each mask bit is considered for its corresponding DWord written to the destination surface. For the 1-OWord messages, only the low 8 bits of the execution mask are used. Either the low 4 bits or the high 4 bits, depending on the position of the OWord to be read or written, is used as the single group of four with behavior following that in the preceding paragraph. The above behavior enables a SIMD16 thread to use the 8-OWord form of this message to access two channels (red and green) of a single scratch register across 16 pixels. A second message would access the other two channels (blue and alpha). The execution mask is used to ensure that data associated with inactive pixels are not overwritten. Out-of-Bounds Accesses. Reads to areas outside of the surface return 0. Writes to areas outside of the surface are dropped and will not modify memory contents. 3.9.3.1 Message Descriptor Bit Description 13 Invalidate After Read Enable This field, if enabled, causes all lines in the L3 cache accessed by the message to be invalidated after the read occurs, regardless of whether the line contains modified data. It is intended as a performance hint indicating that the data will no longer be used to avoid writing Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 233 Bit Description back data to memory. This field is ignored for write messages. Enabling this field is intended for scratch and spill/fill, where the memory is used only by a single thread and thus does not need to be maintained after the thread completes. Format = Enable 12 Ignored 11 Ignored 10:8 Block Size. Specifies the number of contiguous OWords to be read or written 000: 1 OWord, read into or written from the low 128 bits of the destination register 001: 1 OWord, read into or written from the high 128 bits of the destination register 010: 2 OWords 011: 4 OWords 100: 8 OWords all other encodings are reserved. Programming Notes: The 6 OWord block size is valid only with Data Port Constant Cache. 3.9.3.2 Message Payload (Write) For the write operation, the message payload consists of one, two, or four registers (not including the header) depending on the Block Size specified in the message. For the one-constant case, data is taken from either the high or low half of the payload register depending on the half selected in Block Size. In this case, the other half of the payload register is ignored. The Offset referred to below is the Global Offset and is in units of OWords. The OWord array index is also in units of OWords. DWord Bit Description M1.7:4 127:0 OWord[Offset + 1]. If the block size is 1 OWord to be written from the high 128 bits of the destination, OWord[Offset] will appear in this location M1.3:0 127:0 OWord[Offset] M2.7:4 127:0 OWord[Offset+3] M2.3:0 127:0 OWord[Offset+2] M3.7:4 127:0 OWord[Offset+5] M3.3:0 127:0 OWord[Offset+4] M4.7:4 127:0 OWord[Offset+7] M4.3:0 127:0 OWord[Offset+6] 3.9.3.3 Writeback Message (Read) For the read operation, the writeback message consists of one, two, three, or four registers depending on the Block Size specified in the message. For the one-constant case, data is placed in either the high or Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 234 low half of the returned register depending on the half selected in Block Size. In this case, the other half of the register is not changed. The Offset referred to below is the Global Offset and is in units of OWords. The OWord array index is also in units of OWords. DWord Bit Description W0.7:4 127:0 OWord[Offset + 1]. If the block size is 1 OWord to be loaded into the high 128 bits of the destination, OWord[Offset] will appear in this location W0.3:0 127:0 OWord[Offset] W1.7:4 127:0 OWord[Offset+3] W1.3:0 127:0 OWord[Offset+2] W2.7:4 127:0 OWord[Offset+5] W2.3:0 127:0 OWord[Offset+4] W3.7:4 127:0 OWord[Offset+7] W3.3:0 127:0 OWord[Offset+6] 3.9.4 Unaligned OWord Block Read This message takes one DWord aligned offset (Global Offset), and reads 1, 2, 4, or 8 contiguous OWords starting at that offset. This message is identical to the OWord Block Read message except the offset alignment. For read/write cache, only the read path supports this unaligned OWord Block access. Restrictions: 1. the only surface type allowed is SURFTYPE_BUFFER. 2. the surface format is ignored, data is returned from the constant buffer to the GRF without format conversion. 3. the surface pitch is ignored, the surface is treated as a 1-dimensional surface. An element size (pitch) of 16 bytes is used to determine the size of the buffer for out-of-bounds checking if using the surface state model. 4. the surface cannot be tiled 5. the surface base address must be OWord aligned 6. the Render Cache Read Write Mode field in SURFACE_STATE must be set to read/write mode when using this message with the render cache in the surface state model 7. the Stateless Render Cache Read-Write Mode field in the SVG_WORK_CTL register must be set to read/write mode when using this message with the render cache in the stateless model Applications: Reads with offset that is not aligned with data size, such as row store usage in media Execution Mask. The execution mask is ignored by this message. Out-of-Bounds Accesses. Reads to areas outside of the surface return 0. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 235 3.9.4.1 Message Descriptor Bit Description 13 Ignored 12:11 Ignored 10:8 Block Size. Specifies the number of contiguous OWords to be read 000: 1 OWord, read into the low 128 bits of the destination register 001: 1 OWord, read into the high 128 bits of the destination register 010: 2 OWords 011: 4 OWords 100: 8 OWords all other encodings are reserved. 3.9.4.2 Writeback Message (Read) For the read operation, the writeback message consists of one, two, or four registers depending on the Block Size specified in the message. For the one-constant case, data is placed in either the high or low half of the returned register depending on the half selected in Block Size. In this case, the other half of the register is not changed. The Global Offset is in units of Bytes, aligned to DWord (two LSBs set to zero). The OWordX array in units of OWord starts at Global Offset. DWord Bit Description W0.7:4 127:0 OWord1 = *(&OWord0 + 1). If the block size is 1 OWord to be loaded into the high 128 bits of the destination, OWord0 will appear in this location W0.3:0 127:0 OWord0 = Buffer[Global Offset] W1.7:4 127:0 OWord3 = *(&OWord2 + 1) W1.3:0 127:0 OWord2 = *(&OWord1 + 1) W2.7:4 127:0 OWord5= *(&OWord4 + 1) W2.3:0 127:0 OWord4 = *(&OWord3 + 1) W3.7:4 127:0 OWord7 = *(&OWord6 + 1) W3.3:0 127:0 OWord6 = *(&OWord5 + 1) 3.9.5 OWord Dual Block Read/Write This message takes two offsets, and reads or writes 1 or 4 contiguous OWords starting at each offset. The Global Offset is added to each of the specific offsets. The message header is no longer required for the OWord Dual Block Read/Write messages if sent to the data cache data port. If header is not sent, the Global Offset field is assumed to be zero. The header is required, however, if the binding table index is 255 (stateless model), as the Immediate Buffer Base Address field is required. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 236 Programming Restrictions: Writes to overlapping addresses will have undefined write ordering. Restrictions: 1. The only surface type allowed is SURFTYPE_BUFFER. 2. The surface format is ignored, data is returned from the constant buffer to the GRF without format conversion. 3. The surface pitch is ignored, the surface is treated as a 1-dimensional surface. An element size (pitch) of 16 bytes is used to determine the size of the buffer for out-of-bounds checking if using the surface state model. 4. The surface cannot be tiled 5. The surface base address must be OWord aligned 6. The Render Cache Read Write Mode field in SURFACE_STATE must be set to read/write mode when using this message with the render cache in the surface state model 7. the Stateless Render Cache Read-Write Mode field in the SVG_WORK_CTL register must be set to read/write mode when using this message with the render cache in the stateless model Applications: SIMD4x2 constant buffer reads where the indices of each vertex/pixel are different (if there are two indices and they are the same, hardware will optimize the cache accesses and do only one cache access) SIMD4x2 scratch space reads/writes where the indices are different Execution Mask. The low 8 bits of the execution mask are used to enable the 8 channels in the GRF registers returned for read, or each of the write registers sent. For reads, any mask bit asserted within a group of four will cause the entire OWord to be read and returned to the destination GRF register. For writes, each mask bit is considered for its corresponding DWord written to the destination surface. Out-of-Bounds Accesses. Reads to areas outside of the surface return 0. Writes to areas outside of the surface are dropped and will not modify memory contents. 3.9.5.1 Message Descriptor Bit Description 13 Invalidate After Read Enable This field, if enabled, causes all lines in the L3 cache accessed by the message to be invalidated after the read occurs, regardless of whether the line contains modified data. It is intended as a performance hint indicating that the data will no longer be used to avoid writing back data to memory. This field is ignored for write messages. Enabling this field is intended for scratch and spill/fill, where the memory is used only by a single thread and thus does not need to be maintained after the thread completes. Format = Enable 12 Ignored 11:10 Ignored 9:8 Block Size: Specifies the number of OWords in each block to be read or written 00: 1 OWord Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 237 Bit Description 10: 4 OWords all other encodings are reserved. 3.9.5.2 Message Payload DWord Bit Description M1.7 31:0 Ignored M1.6 31:0 Ignored M1.5 31:0 Ignored M1.4 31:0 Block Offset 1. Specifies the OWord offset of OWord Block 1 into the surface. Format = U32 Range = [0,0FFFFFFFh] M1.3 31:0 Ignored M1.2 31:0 Ignored M1.1 31:0 Ignored M1.0 31:0 Block Offset 0 3.9.5.3 Additional Message Payload (Write) For the write operation, the message payload consists of one or four registers (not including the header or the first part of the payload) depending on the Block Size specified in the message. The Offset1/0 referred to below is the Global Offset added to the corresponding Block Offset 1/0 and is in units of OWords . The OWord array index is also in units of OWords. DWord Bit Description M2.7:4 127:0 OWord[Offset1] M2.3:0 127:0 OWord[Offset0] M3.7:4 127:0 OWord[Offset1+1] M3.3:0 127:0 OWord[Offset0+1] M4.7:4 127:0 OWord[Offset1+2] M4.3:0 127:0 OWord[Offset0+2] M4.7:4 127:0 OWord[Offset1+3] M4.3:0 127:0 OWord[Offset0+3] 3.9.5.4 Writeback Message (Read) For the read operation, the writeback message consists of one or four registers depending on the Block Size specified in the message. The Offset1/0 referred to below is the Global Offset added to the corresponding Block Offset 1/0 and is in units of Owords. The OWord array index is also in units of OWords. DWord Bit Description W0.7:4 127:0 OWord[Offset1] W0.3:0 127:0 OWord[Offset0] W1.7:4 127:0 OWord[Offset1+1] W1.3:0 127:0 OWord[Offset0+1] Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 238 DWord Bit Description W2.7:4 127:0 OWord[Offset1+2] W2.3:0 127:0 OWord[Offset0+2] W3.7:4 127:0 OWord[Offset1+3] W3.3:0 127:0 OWord[Offset0+3] 3.9.6 Media Block Read/Write The read form of this message enables a rectangular block of data samples to be read from the source surface and written into the GRF. The write form enables data from the GRF to be written to a rectangular block. Restrictions: 1. The only surface type allowed is non-arrayed, non-mipmapped SURFTYPE_2D. Because of this, the stateless surface model is not supported with this message. 2. The surface format is used to determine the pixel structure for boundary clamp, the raw data from the surface is returned to the thread without any format conversion nor filtering operation 3. The target cache cannot be the data cache 4. The surface base address must be 32-byte aligned 5. When a surface is XMajor tiled, (tilewalk field in the surface state is set to TILEWALK_XMAJOR), a memory area mapped through the Render Cache cannot be read and/or wrote in mixed frame and field modes. For example, if a memory location is first written with a zero Vertical Line Stride (frame mode), and later on (without render cache flush) read back using Vertical Line Stride of one (field mode), the read data stored in GRF are uncertain. 6. The block width and offset should be aligned to the size of pixels stored in the surface. For a surface with 8bpp pixels for example, the block width and offset can be byte aligned. For a surface with 16bpp pixels, it is word aligned. 7. For YUV422 formats, the block width and offset must be pixel pair aligned (i.e. dword aligned). 8. The write form of message has the additional restriction that both X Offset and Block Width must be DWord aligned. 9. Pitch must be a multiple of 64 bytes when the surface is linear. Applications: Block reads/writes for media Execution Mask. The execution mask on the send instruction for this type of message is ignored. The data that is read or written is determined completely by the block parameters. Out-of-Bounds Accesses. Reads outside of the surface results in the address being clamped to the nearest edge of the surface and the pixel in the position being returned. Writes outside of the surface are dropped and will not modify memory contents. Determining the boundary pixel value depends on the surface format. Surface format definitions can be found in the Surface Formats Section of the Sampling Engine Chapter. For a surface with 8bpp pixels, the boundary byte is replicated. For example, for a boundary dword B0B1B2B3, to replicate the left boundary byte pixel, the out of bound dwords have the format of B0B0B0B0, and that for right boundary is B3B3B3B3. This rule applies to all surface formats with BPE of 8. As the data port does not perform format conversion, the most likely used surface formats are R8_UINT and R8_SINT. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 239 For any other surfaces with 16bpp pixels, boundary pixel replication is on words. For example, for a boundary dword B0B1B2B3, to replicate the left boundary word pixel, the out of bound dwords have the format of B0B1B0B1, and that for right boundary is B2B3B2B3. This rule applies to all surface formats with BPE of 16. As the data port does not perform format conversion, only the formats with integer data types may be useful in practice. For special surfaces with 16bpp pixels YUV422 packed format, there are two basic cases depending on the Y location: YUYV (surface format YCRCB_NORMAL) and UYVY (surface format YCRCB_SWAPY). Boundary handling for YVYU (surface format YCRCB_SWAPUV) is the same as that for YUYV. Similarly, boundary handling for VYUY (surface format YCRCB_SWAPUVY) is the same as that for UYVY. Note that these four surface formats have 16bpp pixels, even though the BPE fields are set to zero according to the table in the Surface Formats Section. For a boundary dword Y0U0Y1V0, to replicate the left boundary, we get Y0U0Y0V0, and to replicate the right boundary, we get Y1U0Y1V0. For a boundary dword U0Y0V0Y1, to replicate the left boundary, we get U0Y0V0Y0, and to replicate the right boundary, we get U0Y1V0Y1. For a surface with 32bpp pixels, the boundary dword pixel is replicated. This rule applies to all surface formats with BPE of 32. As the data port does not perform format conversion, some of the formats may not be useful in practice. Hardware behavior for any other surface types is undefined. When Color Processing Enable is set to 1 and the IECP output surface to be written is NV12 format (R16_UNORM surface format 0x10A, should be used if the output surface is NV12 format). NV12 surface state : The width of the surface should be always multiples of 4pixels. For 16bpp input message (422 8-bit) the width will always need to be in multiples of 8bytes and for 32bpp input message (422 16-bit or 444 8-bit) the width should be in multiples of 16bytes. Height should be in multiples of 2pixel high. (presently the MFX restriction is that width should be in multiples of 2pixels). y-offset of the media block write from the EU should be always even x-offset of the media block write from the EU should be in multiples of 4 pixel. The media block dword write can have only the following combinations (for IECP when NV12 output format is used):  8pixel wide for 422 8-bit mode  4pixel wide for 422 8-bit mode  4pixel wide for 422 16-bit  4pixel wide for 444 8-bit.  444 16-bit input format cannot be supported when the output format is NV12 (s/w should not use this combination).  It has to be in multiples of 2pixel high for all above modes. If 444-format is used then we use only the pixel_0 UV values of the 2x2 pixel and the rest are dropped and in case of 422-format the top UV values are used and the bottom UV values is dropped if the output format is NV12 format. Assuming IECP messages will always have vertical stride = 0. (since this is only for pre-processing before the encoder). Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 240 3.9.6.1 Message Descriptor Bit Description 13 Reserved: MBZ 12 Reserved : MBZ 11 Reserved : MBZ 10 Vertical Line Stride Override Specifies whether the Vertical Line Stride and Vertical Line Stride Offset fields in the surface state should be replaced by bits 9 and 8 below. If this field is 1, Height in the surface state (see SURFACE_STATE section of Sampling Engine chapter) is modified according the following rules: Vertical Line Derived 1-based surface height Stride (As a function of the 0-based Height in surface state) (in surface state) Override Vertical Line Stride 0 0 Height + 1 (Normal) 0 1 (Height +1) / 2 Restriction: (Height + 1) must be an even number. 1 0 (Height + 1) * 2 1 1 Height + 1 (Normal) For example, for a 720x480 standard resolution video buffer, if Vertical Line Stride in surface state is 0, i.e. a frame, Height (of the frame) should be 479. When accessing the bottom field of this frame video buffer, both Override Vertical Line Stride and Override Vertical Line Stride Offset will be set to 1, then the derived surface height (of the field) will be 240 ((Height + 1) / 2). In contrary, if Vertical Line Stride in surface state is 1 and Vertical Line Stride Offset in surface state is 0, the surface state represents the top field of the video buffer. In this case, Height (of the top field) should be programmed as 239. Accessing the bottom video field will use the same surface height of 240. Accessing the video frame (with Override Vertical Line Stride and Override Vertical Line Stride Offset set to 0) will result in a derived surface height of 480 ((Height + 1) * 2). 0 -- Use parameters in the surface state and ignore bits 9:8 1 -- Use bits 9:8 to provide the Vertical Line Stride and Vertical Line Stride Offset 9 Override Vertical Line Stride Specifies number of lines (0 or 1) to skip between logically adjacent lines – provides support of interleaved (field) surfaces as textures. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 241 Bit Description Format = U1 in lines to skip between logically adjacent lines 8 Override Vertical Line Stride Offset Specifies the offset of the initial line from the beginning of the buffer. Ignored when Override VerticalLine Stride is 0. Format = U1 in lines of initial offset (when Vertical Line Stride == 1) 3.9.6.2 Message Header DWord Bit Description M0.7 31:0 M0.6 31:0 M0.5 31:8 Ignored 7:0 FFTID. 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 (reserved for hardware delivery of binding table pointer) M0.3 31:5 Color Processing State Pointer. Defines the pointer to COLOR_PROCESSING_STATE. Ignored on read messages and when Color Processing Enable is not set. This pointer is relative to the General State Base Address. Programming Notes: This pointer is not delivered via state variables like most other pointers are delivered. It must be delivered via another software-defined mechanism such as CURBE. Format = GeneralStateOffset[31:5] 4 Message Mode This field selects the mode of this message as follows: 0: NORMAL. The Block Height and Block Width fields are set in M0.2. The Pixel Mask is not explicitly set but behaves as if it is set to all ones. 1: PIXEL_MASK: The Pixel Mask field is set in M0.2. The Block Height and Block Width are not explicitly set but behave as if they are set to 4 rows and 32 bytes, respectively. 3:2 Message Format. Defines the format of the message if Color Processing Enable is set. 0: YUV 4:2:2, 8 bits per channel 1: YUV 4:4:4, 8 bits per channel 2: YUV 4:2:2, 16 bits per channel 3: YUV 4:4:4, 16 bits per channel 1 Area of Interest. This field controls whether the statistic for the luma pixels is collected at VSC for ACE histogram. This field is effective only when the state variable Full_image_histogram is disabled. 0 Color Processing Enable. This field controls whether color processing is enabled on a Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 242 DWord Bit Description media block write message. Format = Enable This bit must be set to zero on a Media Block Read to the Render Cache. The following M0.2 definition applies only if the Message Mode field is set to NORMAL: M0.2 31:29 Ignored 28:24 Programming Notes: Sub-Register Offset must be aligned to BasePitch (therefore will be a multiple of DWords as well). When Register Pitch Control = 0, Sub-Register Offset must align to BasePitch*Block Height and the output fits in a single GRF register. In general (and specifically when Sub-Register Offset is greater than 0), when the resulting data cross GRF register boundary, the data must be placed symmetrically between GRF registers. Sub-Register Offset and Register Pitch Control allow software to assembly multiple media block reads directly into a shared GRF register set. For example, if both are set to zero, the read data are written to GRF registers, aligning to the least significant bits of the first register, and the register pitch is equal to the next power-of-2 that is greater than or equal to the Block Width. If Register Pitch Control is non-zero, multiple media block read messages sharing the same Register Pitch Control but with different Sub- Register Offset can fill in the same set of GRF registers with media block data line interleaved. Format = U5 Range = [0, 28] (Only a multiple of BasePitch, including 0, is valid) Programming Note: This field must be zero for Render Cache Data Port. 21:16 Block Height. Height in rows of block being accessed. Programming Notes: The Block Height is restricted to the following maximum values depending on the Block Width: Block Width (bytes) Maximum Block Height (rows) 1-4 64 5-8 32 9-16 16 17-32 8 Format = U6 Range = [0,63] representing 1 to 64 rows 15:10 Ignored 9:8 Programming Notes: Register Pitch Control is only allowed to be non-zero, if Block Width is a multiple of Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 243 DWord Bit Description DWords. The effective register pitch must be less than or equal to 32 bytes (to fit in a single GRF register). Defining BasePitch as the next power-of-2 that is greater than or equal to the Block Width, Register Pitch Control set the register pitch in term of BasePitch as the following. Range = [0,3] representing 1 to 4 BasePitch Programming Note: This field must be zero for Render Cache Data Port. 7:5 Ignored 4:0 Block Width. Width in bytes of the block being accessed. Programming Notes: Must be DWord aligned for the write form of the message. The following M0.2 definition applies only if the Message Mode field is set to PIXEL_MASK: MO.2 31:0 Pixel Mask. One bit per pixel (each pixel being a DWord) indicating which pixels are to be written. This field is ignored by the read message, all pixels are always returned.. The bits in this mask correspond to the pixels (DWords) as follows: 0 1 4 5 16 17 20 21 2 3 6 7 18 19 22 23 8 9 12 13 24 25 28 29 10 11 14 15 26 27 30 31 M0.1 31:0 Y offset. The Y offset of the upper left corner of the block into the surface. Format = S31 Programming Notes: If Message Mode is set to PIXEL_MASK, this field must be a multiple of 4 M0.0 31:0 X offset. The X offset of the upper left corner of the block into the surface. Must be DWord aligned (Bits 1:0 MBZ) for the write form of the message. The X offset field defines the offset in the input message block. This may differ from the offset in the surface if Color Processing is enabled due to format conversion. Programming Notes: If Message Mode is set to PIXEL_MASK, this field must be a multiple of 32 Programming Note: The legal combinations of block width, pitch control, sub-register offset and block height are given below: Block Height for given block width, pitch control, subreg offsets sub-register offsets block width pitch control 0 1 2 3 4 5 6 7 1-4 00 1-64 1 1 1 1 1 1 1 01 1-64 1-64 illegal illegal 1-2 1-2 illegal illegal 10 illegal illegal illegal illegal illegal illegal illegal illegal 11 1-64 1-64 1-64 1-64 illegal illegal illegal illegal 5-8 00 1-32 illegal 1 illegal 1 illegal 1 illegal 01 1-32 illegal 1-32 illegal illegal illegal illegal illegal Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 244 10 illegal illegal illegal illegal illegal illegal illegal illegal 11 1-32 illegal 1-32 illegal 1-32 illegal 1-32 illegal 9-16 00 1-16 illegal illegal illegal 1 illegal illegal illegal 01 1-16 illegal illegal illegal 1-16 illegal illegal illegal 10 illegal illegal illegal illegal illegal illegal illegal illegal 11 1-16 illegal illegal illegal 1-16 illegal illegal illegal 7-32 00 1-8 illegal illegal illegal illegal illegal illegal illegal 01 1-8 illegal illegal illegal illegal illegal illegal illegal 10 illegal illegal illegal illegal illegal illegal illegal illegal 11 1-8 illegal illegal illegal illegal illegal illegal illegal 3.9.6.3 Message Payload (Write) DWord Bit Description M1:n Write Data. The format of the write data depends on the Block Height and Block Width. The data is aligned to the least significant bits of the first register, and the register pitch is equal to the next power-of-2 that is greater than or equal to the Block Width. If Color Processing Enable is enabled, the write data is divided into pixels according to the Message Format field. The fields within each pixel are defined below. For the 4:2:2 modes, each pixel position includes channels for two pixels. Message Format 31:24 23:16 15:8 7:0 YUV 4:2:2, 8 bits per channel Cr (V) right pixel lum (Y1) Cb (U) left pixel lum (Y0) YUV 4:4:4, 8 bits per channel alpha (A) luminance (Y) Cb (U) Cr (V) 63:48 47:32 31:16 15:0 YUV 4:2:2, 16 bits per channel Cr (V) right pixel lum (Y1) Cb (U) left pixel lum (Y0) YUV 4:4:4, 16 bits per channel alpha (A) Cr (V) luminance (Y) Cb (U) 3.9.6.4 Writeback Message (Read) DWord Bit Description W0:n Read Data. The format of the read data depends on the Block Height and Block Width. The data is aligned to the least significant bits of the first register, and the register pitch is equal to the next power-of-2 that is greater than or equal to the Block Width. . 3.9.7 DWord Scattered Read/Write This message takes a set of offsets, and reads or writes 8 or 16 scattered DWords starting at each offset. The Global Offset is added to each of the specific offsets. The message header is no longer required for the OWord DWord Scattered Read/Write messages if sent to the data cache data port. If header is not sent, the Global Offset field is assumed to be zero. The header is required, however, if the binding table index is 255 (stateless model), as the Immediate Buffer Base Address field is required. Programming Restrictions: Writes to overlapping addresses will have undefined write ordering. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 245 For read messages with X/Y offsets that are outside the bounds of the surface, the address is clamped to the nearest edge of the surface. For write messages with X/Y offsets that are outside the bounds of the surface, the behavior is undefined. Hardware does check for and optimize for cases where offsets are equal or contiguous, however for optimal performance in some these cases a different message may provide higher performance. 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. The surface pitch is ignored, the surface is treated as a 1-dimensional surface. An element size (pitch) of 16 bytes is used to determine the size of the buffer for out-of-bounds checking if using the surface state model. The surface cannot be tiled The surface base address must be DWord aligned The Render Cache Read Write Mode field in SURFACE_STATE must be set to read/write mode when using this message with the render cache in the surface state model The Stateless Render Cache Read-Write Mode field in the SVG_WORK_CTL register must be set to read/write mode when using this message with the render cache in the stateless model Applications: SIMD8/16 constant buffer reads where the indices of each pixel are different (read one channel per message) SIMD8/16 scratch space reads/writes where the indices are different (read/write one channel per message) general purpose DWord scatter/gathering, used by media Execution Mask. Depending on the block size, either the low 8 bits or all 16 bits of the execution mask are used to determine which DWords are read into the destination GRF register (for read), or which DWords are written to the surface (for write). Out-of-Bounds Accesses. Reads to areas outside of the surface return 0. Writes to areas outside of the surface are dropped and will not modify memory contents. 3.9.7.1 Message Descriptor Bit Description 13 Invalidate After Read Enable This field, if enabled, causes all lines in the L3 cache accessed by the message to be invalidated after the read occurs, regardless of whether the line contains modified data. It is intended as a performance hint indicating that the data will no longer be used to avoid writing back data to memory. This field is ignored for write messages. Enabling this field is intended for scratch and spill/fill, where the memory is used only by a single thread and thus does not need to be maintained after the thread completes. Format = Enable 12:10 Reserved Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 246 Bit Description 9:8 Block Size. Specifies the number of DWords to be read or written 10: 8 DWords 11: 16 DWords All other encodings are reserved. 3.9.7.2 Message Payload DWord Bit Description M1.7 31:0 Offset 7. Specifies the DWord offset of DWord 7 into the surface. Format = U32 Range = [0,3FFFFFFFh] M1.6 31:0 Offset 6 M1.5 31:0 Offset 5 M1.4 31:0 Offset 4 M1.3 31:0 Offset 3 M1.2 31:0 Offset 2 M1.1 31:0 Offset 1 M1.0 31:0 Offset 0 M2.7 31:0 Offset 15. This message register is included only if the block size is 16 DWords. M2.6 31:0 Offset 14 M2.5 31:0 Offset 13 M2.4 31:0 Offset 12 M2.3 31:0 Offset 11 M2.2 31:0 Offset 10 M2.1 31:0 Offset 9 M2.0 31:0 Offset 8 3.9.7.3 Additional Message Payload (Write) For the write operation, either one or two additional registers (depending on the block size) of payload contain the data to be written. The Offsetn referred to below is the Global Offset added to the corresponding Offset n and is in units of DWords . The DWord array index is also in units of DWords. DWord Bit Description M3.7 31:0 DWord[Offset7] M3.6 31:0 DWord[Offset6] M3.5 31:0 DWord[Offset5] M3.4 31:0 DWord[Offset4] M3.3 31:0 DWord[Offset3] M3.2 31:0 DWord[Offset2] M3.1 31:0 DWord[Offset1] M3.0 31:0 DWord[Offset0] Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 247 DWord Bit Description M4.7 31:0 DWord[Offset15]. This message register is included only if the block size is 16 DWords M4.6 31:0 DWord[Offset14] M4.5 31:0 DWord[Offset13] M4.4 31:0 DWord[Offset12] M4.3 31:0 DWord[Offset11] M4.2 31:0 DWord[Offset10] M4.1 31:0 DWord[Offset9] M4.0 31:0 DWord[Offset8] 3.9.7.4 Writeback Message (Read) For the read operation, the writeback message consists of either one or two registers depending on the block size. The DWord array index is also in units of DWords. DWord Bit Description W0.7 31:0 DWord[Offset7] W0.6 31:0 DWord[Offset6] W0.5 31:0 DWord[Offset5] W0.4 31:0 DWord[Offset4] W0.3 31:0 DWord[Offset3] W0.2 31:0 DWord[Offset2] W0.1 31:0 DWord[Offset1] W0.0 31:0 DWord[Offset0] W1.7 31:0 DWord[Offset15]. This writeback message register is included only if the block size is 16 DWords. W1.6 31:0 DWord[Offset14] W1.5 31:0 DWord[Offset13] W1.4 31:0 DWord[Offset12] W1.3 31:0 DWord[Offset11] W1.2 31:0 DWord[Offset10] W1.1 31:0 DWord[Offset9] W1.0 31:0 DWord[Offset8] 3.9.8 Byte Scattered Read/Write These messages are supported on only. These messages take a set of offsets, and read or write 8 or 16 scattered and possibly misaligned bytes, words, or dwords starting at each offset. The Global Offset from the message header is added to each of the specific offsets. Restrictions: The only surface type allowed is SURFTYPE_BUFFER. The surface format is ignored, data is returned from the buffer to the GRF without format conversion. The surface pitch is ignored, the surface is treated as a 1-dimensional surface. An element size (pitch) of 4 bytes is used to determine the size of the buffer for out-of-bounds checking if using the surface state model. The surface cannot be tiled Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 248 The surface base address must be DWord aligned The stateless model is not supported. Applications: Byte aligned buffer accesses in compute shaders Execution Mask. Depending on the block size, either the low 8 bits or all 16 bits of the execution mask are used to determine which slots are read into the destination GRF register (for read), or which slots are written to the surface (for write). Out-of-Bounds Accesses. Reads to areas outside of the surface return 0. Writes to areas outside of the surface are dropped and will not modify memory contents. Programming Restrictions: Writes to overlapping addresses will have undefined write ordering. 3.9.8.1 Message Descriptor Bit Description 13:12 Ignored 11:10 Data Size. Specifies the data size for each slot. 0: 1 byte 1: 2 bytes 2: 4 bytes 3: Reserved 9 Ignored 8 SIMD Mode. Specifies the SIMD mode of the message (number of slots processed). 0: SIMD8 1: SIMD16 3.9.8.2 Message Payload DWord Bit Description M1.7 31:0 Offset 7. Specifies the byte offset of DWord 7 into the surface. Format = U32 Range = [0,FFFFFFFFh] M1.6 31:0 Offset 6 M1.5 31:0 Offset 5 M1.4 31:0 Offset 4 M1.3 31:0 Offset 3 M1.2 31:0 Offset 2 M1.1 31:0 Offset 1 M1.0 31:0 Offset 0 M2.7 31:0 Offset 15. This message register is included only if the SIMD Mode is SIMD16. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 249 DWord Bit Description M2.6 31:0 Offset 14 M2.5 31:0 Offset 13 M2.4 31:0 Offset 12 M2.3 31:0 Offset 11 M2.2 31:0 Offset 10 M2.1 31:0 Offset 9 M2.0 31:0 Offset 8 3.9.8.3 Additional Message Payload (Write) For the write operation, either one or two additional registers (depending on the block size) of payload contain the data to be written. The Offsetn referred to below is the Global Offset added to the corresponding Offset n and is in units of bytes. The length of Data written depends on the Data Size and is right-justified within the 32-bit field. The upper bits are ignored for 1 byte and 2 byte Data Size. DWord Bit Description M3.7 31:0 Data[Offset7] M3.6 31:0 Data[Offset6] M3.5 31:0 Data[Offset5] M3.4 31:0 Data[Offset4] M3.3 31:0 Data[Offset3] M3.2 31:0 Data[Offset2] M3.1 31:0 Data[Offset1] M3.0 31:0 Data[Offset0] M4.7 31:0 Data[Offset15]. This message register is included only if the SIMD Mode is SIMD16. M4.6 31:0 Data[Offset14] M4.5 31:0 Data[Offset13] M4.4 31:0 Data[Offset12] M4.3 31:0 Data[Offset11] M4.2 31:0 Data[Offset10] M4.1 31:0 Data[Offset9] M4.0 31:0 Data[Offset8] 3.9.8.4 Writeback Message (Read) For the read operation, the writeback message consists of either one or two registers depending on the block size. The Offsetn referred to below is the Global Offset added to the corresponding Offset n and is in units of bytes. The length of Data written depends on the Data Size and is right-justified within the 32-bit field and only the requeted bytes are written to the GRF. DWord Bit Description W0.7 31:0 Data[Offset7] W0.6 31:0 Data[Offset6] W0.5 31:0 Data[Offset5] W0.4 31:0 Data[Offset4] W0.3 31:0 Data[Offset3] W0.2 31:0 Data[Offset2] W0.1 31:0 Data[Offset1] Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 250 DWord Bit Description W0.0 31:0 Data[Offset0] W1.7 31:0 Data[Offset15]. This message register is included only if the SIMD Mode is SIMD16. W1.6 31:0 Data[Offset14] W1.5 31:0 Data[Offset13] W1.4 31:0 Data[Offset12] W1.3 31:0 Data[Offset11] W1.2 31:0 Data[Offset10] W1.1 31:0 Data[Offset9] W1.0 31:0 Data[Offset8] 3.9.9 Typed/Untyped Surface Read/Write and Typed/Untyped Atomic Operation Six data port messages (Typed Surface Read, Typed Surface Write, Typed Atomic Operation, Untyped Surface Read, Untyped Surface Write, and Untyped Atomic Operation) allow direct read/write accesses to surfaces. These messages support three major categories of surfaces: Typed surfaces. These surfaces are of type SURFTYPE_1D, 2D, 3D, or BUFFER and have a supported surface format other than RAW. Supported via the render cache data port. Programming Restriction: Vertical stride & Vertical Offset fields of the surface state object is only supported for 2D non-array surfaces. Raw buffer (untyped). These surfaces are of type SURFTYPE_BUFFER and have a surface format of RAW and a surface pitch of 1 byte. Supported via the data cache data port. All SLM accesses are in this category. Structured buffer (untyped). These surfaces are of type SURFTYPE_STRBUF and have a surface format of RAW. Supported via the data cache data port. A typed surface uses U, V, R, and LOD address parameters (number of parameters utilized depends on surface type), and performs conversion of type to/from the selected surface format as follows: Surface formats with UINT require the message data in U32 format Surface formats with SINT require the message data in S32 format All other surface formats require the message data in FLOAT32 format The untyped surface categories, both of which use the RAW surface format, perform no type conversion. A raw buffer uses just the U address parameter, which specifies the byte offset into the surface, which must be a multiple of 4. A structured buffer uses the U address parameter as an array index and the V address parameter as a byte offset into the array element (which also must be a multiple of 4). For both raw and structured buffers, up to 4 dwords are accessed beginning at the byte address determined. These 4 dwords correspond to the red, green, blue, and alpha channels in that order with red mapping to the lowest order dword. The atomic operation messages will only access the first dword (corresponding to the red channel for typed messages). The atomic operation messages causes atomic read-modify-write operations on the “destination” location addressed. In the table below, the new value of the destination (new_dst) is computed as indicated based on the old value of the destination (old_dst) and up to two sources included in the message (src0 and src1). Optionally, a value can be returned by the message (ret). Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 251 The atomic operations guarantee that the read and the write are performed atomically, meaning that no read or write to the same memory location from this thread or any other thread can occur between the read and the write. The following atomic operations are available, along with the specific operation performed for each and the return value: Atomic Operation new_dst ret AOP_AND old_dst & src0 old_dst AOP_OR old_dst | src0 old_dst AOP_XOR old_dst ^ src0 old_dst AOP_MOV src0 old_dst AOP_INC old_dst + 1 old_dst AOP_DEC old_dst – 1 old_dst AOP_ADD old_dst + src0 old_dst AOP_SUB old_dst – src0 old_dst AOP_REVSUB src0 – old_dst old_dst AOP_IMAX imax(old_dst, src0) old_dst AOP_IMIN imin(old_dst, src0) old_dst AOP_UMAX umax(old_dst, src0) old_dst AOP_UMIN umin(old_dst, src0) old_dst AOP_CMPWR (src0 == old_dst) ? src1 : old_dst old_dst AOP_PREDEC old_dst – 1 new_dst AOP_CMPWR8B (src08B == old_dst8B) ? src18B : old_dst8B old_dst8B Programming Note: src08B is 8 bytes, src18B is 8 Bytes and old_dst8B is 8 bytes in length. Programming Note: AOP_CMPWR8B is not supported for SLM. Programming Note: AOP_CMPWR8B addresses must be QWORD aligned. Note: imax/imin assume operands are signed integers, umax/umin assume operands are unsigned integers. All other operations treat all values as 32-bit unsigned integers. Add and subtract operations will wrap without any special indication. These messages are supported on only. Restrictions: For untyped messages, the Surface Format must be RAW and the Surface Type must be SURFTYPE_BUFFER or SURFTYPE_STRBUF. For typed messages, the Surface Type must be SURFTYPE_1D, 2D, 3D, or BUFFER. Surface Format Name R32_SINT R32_UINT R32_FLOAT The Surface Format for typed surface writes must be Surface Format Name R32G32B32A32_FLOAT R32G32B32A32_SINT R32G32B32A32_UINT R16G16B16A16_UNORM R16G16B16A16_SNORM R16G16B16A16_SINT Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 252 Surface Format Name R16G16B16A16_UINT R16G16B16A16_FLOAT R32G32_FLOAT R32G32_SINT R32G32_UINT B8G8R8A8_UNORM R10G10B10A2_UNORM R10G10B10A2_UINT R8G8B8A8_UNORM R8G8B8A8_SNORM R8G8B8A8_SINT R8G8B8A8_UINT R16G16_UNORM R16G16_SNORM R16G16_SINT R16G16_UINT R16G16_FLOAT B10G10R10A2_UNORM R11G11B10_FLOAT R32_SINT R32_UINT R32_FLOAT B5G6R5_UNORM B5G5R5A1_UNORM B4G4R4A4_UNORM R8G8_UNORM R8G8_SNORM R8G8_SINT R8G8_UINT R16_UNORM R16_SNORM R16_SINT R16_UINT R16_FLOAT B5G5R5X1_UNORM R8_UNORM R8_SNORM R8_SINT R8_UINT A8_UNORM The Surface Format for typed atomic operations must be R32_UINT or R32_SINT. For untyped messages accessing SURFTYPE_STRBUF, the V address (byte offset) must be DWord aligned (low 2 bits must be zero). For untyped messages accessing SURFTYPE_BUFFER, the U address (byte offset) must be DWord aligned (low 2 bits must be zero). Typed messages only support SIMD8. The stateless model support is limited to untyped messages. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 253 Execution Mask: SIMD16: The 16 bits of the execution mask are ANDed with the 16 bits of the Pixel/Sample Mask from the message header and the resulting mask is used to determine which slots are read into the destination GRF register (for read), or which slots are written to the surface (for write). If the header is not present, only the execution mask is used. SIMD8: The low 8 bits of the execution mask are ANDed with 8 bits of the Pixel/Sample Mask from the message header. For the typed messages, the Slot Group in the message descriptor selects either the low or high 8 bits. For the untyped messages, the low 8 bits are always selected. The resulting mask is used to determine which slots are read into the destination GRF register (for read), or which slots are written to the surface (for write). If the header is not present, only the low 8 bits of the execution mask are used. SIMD4x2: Each group of 4 bits within the low 8 bits of the execution mask are ORed together to create two bits which are used to determine which slots are read into the destination GRF register. Out–of–Bounds Accesses: Reads to areas outside of the surface return 0, except for the Typed Surface Read message which returns 1 in the alpha channel and 0 in the other channels. Writes to areas outside of the surface are dropped and will not modify memory contents. Errata: The Typed Surface Read returns 0 in all channels for out-of-bounds accesses. Programming Restrictions: Writes to overlapping addresses will have undefined write ordering. The following table summarizes the SIMD Mode support for each message type: Untyped Typed Read Write Atomic Read Write Atomic SIMD16 x x x SIMD8 x x x x x x The following table indicates the hardware interpretation of each input parameter based on surface type. Parameters with blank entries are ignored by hardware if delivered. Surface Type“Surface Array” field in U Address V Address R Address LOD SURFACE_STATE SURFTYPE_1D disabled X pixel address LOD enabled X pixel address array LOD index SURFTYPE_2D disabled X pixel address Y pixel LOD address enabled X pixel address Y pixel array LOD address index SURFTYPE_3D disabled X pixel address Y pixel Z pixel LOD address address SURFTYPE_BU disabled buffer index FFER SURFTYPE_ST disabled buffer index byte offset RBUF Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 254 3.9.9.1 Typed Surface Read/Write Message Descriptor Bit Description 13 Slot Group This field controls which 8 bits of Pixel/Sample Mask in the message header are ANDed with the execution mask to determine which slots are accessed. This field is ignored if the header is not present. Format = U1 0: Use low 8 slots 1: Use high 8 slots 12 Ignored 11 Alpha Channel Mask For the read message, indicates that alpha will be included in the writeback message. For the write message, indicates that alpha is included in the message payload, and that alpha will be written to the surface. 0: Alpha channel included 1: Alpha channel not included Programming Notes: At least one of the channels must be unmasked (the 4-bit channel mask cannot be 1111b). 10 Blue Channel Mask 9 Green Channel Mask 8 Red Channel Mask 3.9.9.2 Untyped Surface Read/Write Message Descriptor Bit Description 13:12 SIMD Mode Format = U2 0: SIMD4x2 (valid for read message only) (valid for read message only) , 1: SIMD16 2: SIMD8 3: Reserved 11 Alpha Channel Mask For the read message, indicates that alpha will be included in the writeback message. For the write message, indicates that alpha is included in the message payload, and that alpha will be written to the surface. 0: Alpha channel included 1: Alpha channel not included Programming Notes: Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 255 Bit Description For the Untyped Surface Write message, each channel mask cannot be 0 unless all of the lower mask bits are also zero. This means that the only 4-bit channel mask values allowed are 0000b, 1000b, 1100b, and 1110b. Other messages allow any combination of channel masks. For the Untyped Surface Read message, at least one of the channels must be unmasked (the 4-bit channel mask cannot be 1111b). 10 Blue Channel Mask 9 Green Channel Mask 8 Red Channel Mask 3.9.9.3 Typed Atomic Operation Message Descriptor Bit Description 13 Return Data Control Specifies whether return data is sent back to the thread. Format = Enable 12 Slot Group This field controls which 8 bits of Pixel/Sample Mask in the message header are ANDed with the execution mask to determine which slots are accessed. Format = U1 0: Use low 8 slots 1: Use high 8 slots 11:8 Atomic Operation Type Specifies the atomic operation to be performed. 0000: Reserved 0001: AOP_AND 0010: AOP_OR 0011: AOP_XOR 0100: AOP_MOV 0101: AOP_INC 0110: AOP_DEC 0111: AOP_ADD 1000: AOP_SUB 1001: AOP_REVSUB 1010: AOP_IMAX 1011: AOP_IMIN 1100: AOP_UMAX Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 256 Bit Description 1101: AOP_UMIN 1110: AOP_CMPWR 1111: AOP_PREDEC 3.9.9.4 Typed Atomic Operation SIMD4x2 Message Descriptor Bit Description 13 Return Data Control Specifies whether return data is sent back to the thread. Format = Enable 12 Reserved 11:8 Atomic Operation Type Specifies the atomic operation to be performed. 0000: reserved 0001: AOP_AND 0010: AOP_OR 0011: AOP_XOR 0100: AOP_MOV 0101: AOP_INC 0110: AOP_DEC 0111: AOP_ADD 1000: AOP_SUB 1001: AOP_REVSUB 1010: AOP_IMAX 1011: AOP_IMIN 1100: AOP_UMAX 1101: AOP_UMIN 1110: AOP_CMPWR 1111: AOP_PREDEC 3.9.9.5 Untyped Atomic Operation Message Descriptor Bit Description 13 Return Data Control Specifies whether return data is sent back to the thread. Format = Enable Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 257 Bit Description 12 SIMD Mode Format = U1 0: SIMD16 1: SIMD8 11:8 Atomic Operation Type Specifies the atomic operation to be performed. 0000: 0000: AOP_CMPWR8B 0001: AOP_AND 0010: AOP_OR 0011: AOP_XOR 0100: AOP_MOV 0101: AOP_INC 0110: AOP_DEC 0111: AOP_ADD 1000: AOP_SUB 1001: AOP_REVSUB 1010: AOP_IMAX 1011: AOP_IMIN 1100: AOP_UMAX 1101: AOP_UMIN 1110: AOP_CMPWR 1111: AOP_PREDEC 3.9.9.6 Untyped Atomic Operation SIMD4x2 Message Descriptor Bit Description 13 Return Data Control Specifies whether return data is sent back to the thread. Format = Enable 12 Reserved 11:8 Atomic Operation Type Specifies the atomic operation to be performed. 0000: AOP_CMPWR8B 0001: AOP_AND Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 258 Bit Description 0010: AOP_OR 0011: AOP_XOR 0100: AOP_MOV 0101: AOP_INC 0110: AOP_DEC 0111: AOP_ADD 1000: AOP_SUB 1001: AOP_REVSUB 1010: AOP_IMAX 1011: AOP_IMIN 1100: AOP_UMAX 1101: AOP_UMIN 1110: AOP_CMPWR 1111: AOP_PREDEC 3.9.9.7 Atomic Counter Operation Message Descriptor Bit Description 13 Return Data Control Specifies whether return data is sent back to the thread. Format = Enable 12 SIMD Mode Format: U1 0: SIM16 1: SIM8 (low 8 slots) 11:8 Atomic Operation Type Specifies the atomic operation to be performed. 0000: Reserved 0001: AOP_AND 0010: AOP_OR 0011: AOP_XOR 0100: AOP_MOV 0101: AOP_INC 0110: AOP_DEC Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 259 Bit Description 0111: AOP_ADD 1000: AOP_SUB 1001: AOP_REVSUB 1010: AOP_IMAX 1011: AOP_IMIN 1100: AOP_UMAX 1101: AOP_UMIN 1110: AOP_CMPWR 1111: AOP_PREDEC For Append Counter Operations there is no address payload as the address is provided by the append counter field in the surface state. The write data payloads are the same as untyped atomic. The write back are the same as untyped atomic. When accessing a surface with the Append Counter Operation, if the Append Counter enable field of the surface state is not 1, it the access will be treated as out of bounds, w/ the writes being ignored and the reads returning 0. 3.9.9.8 Atomic Counter Operation SIMD4x2 Message Descriptor Bit Description 13 Return Data Control Specifies whether return data is sent back to the thread. Format = Enable 12 Reserved 11:8 Atomic Operation Type Specifies the atomic operation to be performed. 0000: Reserved 0001: AOP_AND 0010: AOP_OR 0011: AOP_XOR 0100: AOP_MOV 0101: AOP_INC 0110: AOP_DEC 0111: AOP_ADD 1000: AOP_SUB 1001: AOP_REVSUB 1010: AOP_IMAX Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 260 Bit Description 1011: AOP_IMIN 1100: AOP_UMAX 1101: AOP_UMIN 1110: AOP_CMPWR 1111: AOP_PREDEC For Append Counter Operations there is no address payload as the address is provided by the append counter field in the surface state. The write data payloads are the same as untyped atomic 4x2. The write back are the same as untyped atomic 4x2. When accessing a surface with the Append Counter Operation, if the Append Counter enable field of the surface state is not 1, it the access will be treated as out of bounds, w/ the writes being ignored and the reads returning 0. 3.9.9.9 Message Header The message header for the untyped messages only needs to be delivered for pixel shader threads, where the execution mask may indicate pixels/samples that are enabled only due to derivative (LOD) calculations, but the corresponding slot on the surface must not be accessed. Typed messages (which go to render cache data port) must include the header. DWord Bit Description M0.7 31:16 Ignored 15:0 Pixel/Sample Mask. This field contains the 16-bit pixel/sample mask to be used for SIMD16 and SIMD8 messages. All 16 bits are used for SIMD16 messages. For typed SIMD8 messages, Slot Group selects with 8 bits of this field are used. For untyped SIMD8 messages, the low 8 bits of this field are used. If the header is not delivered, this field defaults to all ones. The field is ignored for SIMD4x2 messages. M0.6 31:0 Ignored M0.5 31:0 Format = GeneralStateOffset[31:10] M0.4 31:0 Ignored (reserved for hardware delivery of binding table pointer) M0.3 31:0 Ignored M0.2 31:0 Ignored M0.1 31:0 Ignored M0.0 31:0 Ignored 3.9.9.10 Message Payload The message payload consists of the following:  For the read messages, only an address payload is delivered  For the write messages, an address payload is followed by the write data payload  For the atomic operation messages, an address payload is followed by the source payload  For SIMD16 and SIMD8 messages, the message length is used to determine how may address parameters are included in the message. The number of message registers in the write data payload is determined by the number of channel mask bits that are enabled, and the number of message Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 261 registers in the source payload is determined by the atomic operation operation. Thus, one or neither of these two values (depending on the message type), plus one for the header, can be subtracted from the message length to determine the number of message registers in the address payload, from which the number of address parameters can be determined. 3.9.9.10.1 SIMD16 Address Payload The payload of a SIMD16 message provides address parameters to process 16 slots. The possible address parameters are U and V (since SIMD16 is only supported with untyped messages). The number of parameters required depends on the surface type being accessed. Each parameter takes two message registers. Each parameter always takes a consistent position in the input payload. The length field can be used to send a shorter message, but intermediate parameters cannot be skipped as there is no way to signal this. DWord Bit Description M1.7 31:0 Slot 7 U Address Specifies the U Address for slot 7. Format = U32 M1.6 31:0 Slot 6 U Address M1.5 31:0 Slot 5 U Address M1.4 31:0 Slot 4 U Address M1.3 31:0 Slot 3 U Address M1.2 31:0 Slot 2 U Address M1.1 31:0 Slot 1 U Address M1.0 31:0 Slot 0 U Address M2.7 31:0 Slot 15 U Address M2.6 31:0 Slot 14 U Address M2.5 31:0 Slot 13 U Address M2.4 31:0 Slot 12 U Address M2.3 31:0 Slot 11 U Address M2.2 31:0 Slot 10 U Address M2.1 31:0 Slot 9 U Address M2.0 31:0 Slot 8 U Address M3 Slots 7:0 V Address M4 Slots 15:8 V Address 3.9.9.10.2 SIMD16 Source Payload (Atomic Operation message only) The source payload follows the address payload for atomic operation messages. Depending on the atomic operation, zero, one, or two sources are required. If the source is not required, it must not be included. Message registers given here could be a lower number if some of the address parameters are not included. The following atomic operations require no sources, thus the source payload is not delivered: AOP_INC, AOP_DEC, AOP_PREDEC The following atomic operations require both Source0 and Source1: AOP_CMPWR All of the remaining atomic operations require Source0 only. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 262 DWord Bit Description M5.7 31:0 Slot 7 Source0 Specifies Source0 for slot 7. Format = S31 for AOP_IMAX and AOP_IMIN, U32 for all other operations M5.6 31:0 Slot 6 Source0 M5.5 31:0 Slot 5 Source0 M5.4 31:0 Slot 4 Source0 M5.3 31:0 Slot 3 Source0 M5.2 31:0 Slot 2 Source0 M5.1 31:0 Slot 1 Source0 M5.0 31:0 Slot 0 Source0 M6.7 31:0 Slot 15 Source0 M6.6 31:0 Slot 14 Source0 M6.5 31:0 Slot 13 Source0 M6.4 31:0 Slot 12 Source0 M6.3 31:0 Slot 11 Source0 M6.2 31:0 Slot 10 Source0 M6.1 31:0 Slot 9 Source0 M6.0 31:0 Slot 8 Source0 M7 Slots 7:0 Source1 M8 Slots 15:8 Source1 3.9.9.10.3 SIMD16 Source Payload (AOP_CMPWR8B only) DWord Bit Description M5.7 31:0 Slot 7 Source0[31:0] Specifies Source0[31:0] for slot 7. Format = U32 M5.6 31:0 Slot 6 Source0[31:0] M5.5 31:0 Slot 5 Source0[31:0] M5.4 31:0 Slot 4 Source0[31:0] M5.3 31:0 Slot 3 Source0[31:0] M5.2 31:0 Slot 2 Source0[31:0] M5.1 31:0 Slot 1 Source0[31:0] M5.0 31:0 Slot 0 Source0[31:0] M6.7 31:0 Slot 15 Source0[31:0] M6.6 31:0 Slot 14 Source0[31:0] M6.5 31:0 Slot 13 Source0[31:0] M6.4 31:0 Slot 12 Source0[31:0] M6.3 31:0 Slot 11 Source0[31:0] M6.2 31:0 Slot 10 Source0[31:0] M6.1 31:0 Slot 9 Source0[31:0] M6.0 31:0 Slot 8 Source0[31:0] M7 Slots 7:0 Source0[63:32] M8 Slots 15:8 Source0[63:32] M9 Slots 7:0 Source1[31:0] M10 Slots 15:8 Source1[31:0] M11 Slots 7:0 Source1[63:32] Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 263 DWord Bit Description M12 Slots 15:8 Source1[63:32] 3.9.9.10.4 SIMD16 Write Data Payload (Write message only) The write data payload follows the address payload for write messages. Actual position within the message may vary if some of the parameters are not included or if some of the channel mask bits are asserted. Any parameter or write channel not included in the payload is skipped, with message phases below it being renumbered to take up the vacated space. DWord Bit Description M5.7 31:0 Slot 7 Red Specifies the value of the red channel to be written for slot 7. Format = 32 bits raw data. M5.6 31:0 Slot 6 Red M5.5 31:0 Slot 5 Red M5.4 31:0 Slot 4 Red M5.3 31:0 Slot 3 Red M5.2 31:0 Slot 2 Red M5.1 31:0 Slot 1 Red M5.0 31:0 Slot 0 Red M6.7 31:0 Slot 15 Red M6.6 31:0 Slot 14 Red M6.5 31:0 Slot 13 Red M6.4 31:0 Slot 12 Red M6.3 31:0 Slot 11 Red M6.2 31:0 Slot 10 Red M6.1 31:0 Slot 9 Red M6.0 31:0 Slot 8 Red M7 Slots 7:0 Green M8 Slots 15:8 Green M9 Slots 7:0 Blue M10 Slots 15:8 Blue M11 Slots 7:0 Alpha M12 Slots 15:8 Alpha 3.9.9.10.5 SIMD8 Address Payload The payload of a SIMD8 message provides address parameters to process 8 slots. The possible address parameters are U, V, R, and LOD. The number of parameters required depends on the surface type being accessed. Each parameter takes one message register. Each parameter always takes a consistent position in the input payload. The length field can be used to send a shorter message, but intermediate parameters cannot be skipped as there is no way to signal this. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 264 DWord Bit Description M1.7 31:0 Slot 7 U Address Specifies the U Address for slot 7. Format = U32 M1.6 31:0 Slot 6 U Address M1.5 31:0 Slot 5 U Address M1.4 31:0 Slot 4 U Address M1.3 31:0 Slot 3 U Address M1.2 31:0 Slot 2 U Address M1.1 31:0 Slot 1 U Address M1.0 31:0 Slot 0 U Address M2 Slots 7:0 V Address M3 Slots 7:0 R Address Programming Notes: This register can only be delivered for the Typed message types. M4 Slots 7:0 LOD Programming Notes: This register can only be delivered for the Typed message types. Errata: Overlapping addresses (identical U/V/R/LOD ) in the same simd8 message is not supported for typed (non- atomic) writes to tiled surfaces. 3.9.9.10.6 SIMD8 Source Payload (Atomic Operation message only) The source payload follows the address payload for atomic operation messages. Depending on the atomic operation, zero, one, or two sources are required. If the source is not required, it must not be included. Message registers given here could be a lower number if some of the address parameters are not included. The following atomic operations require no sources, thus the source payload is not delivered: AOP_INC, AOP_DEC, AOP_PREDEC The following atomic operations require both Source0 and Source1: AOP_CMPWR All of the remaining atomic operations require Source0 only. DWord Bit Description M5.7 31:0 Slot 7 Source0 Specifies Source0 for slot 7. Format = S31 for AOP_IMAX and AOP_IMIN, U32 for all other operations M5.6 31:0 Slot 6 Source0 M5.5 31:0 Slot 5 Source0 M5.4 31:0 Slot 4 Source0 M5.3 31:0 Slot 3 Source0 M5.2 31:0 Slot 2 Source0 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 265 DWord Bit Description M5.1 31:0 Slot 1 Source0 M5.0 31:0 Slot 0 Source0 M6 Slots 7:0 Source1 3.9.9.10.7 SIMD8 Write Data Payload (Write message only) The write data payload follows the address payload for write messages. Actual position within the message may vary if some of the parameters are not included or if some of the channel mask bits are asserted. Any parameter or write channel not included in the payload is skipped, with message phases below it being renumbered to take up the vacated space. DWord Bit Description M5.7 31:0 Slot 7 Red Specifies the value of the red channel to be written for slot 7. For Untyped messages: Format = 32 bits raw data. For Typed messages: Format = IEEE Float, S31, or U32 depending on the Surface Format of the surface being accessed. SINT formats use S31, UINT formats use U32, and all other formats use Float. M5.6 31:0 Slot 6 Red M5.5 31:0 Slot 5 Red M5.4 31:0 Slot 4 Red M5.3 31:0 Slot 3 Red M5.2 31:0 Slot 2 Red M5.1 31:0 Slot 1 Red M5.0 31:0 Slot 0 Red M6 Slots 7:0 Green M7 Slots 7:0 Blue M8 Slots 7:0 Alpha 3.9.9.10.8 SIMD8 Write Data Payload (Tile W Write message only) The write data payload follows the address payload for write messages. Actual position within the message may vary if some of the parameters are not included. DWord Bit Description M5.7 31:8 Ignored 7:0 Slot 7 Red Specifies the value of the red channel to be written for slot 7. For Typed messages: Format = U8 M5.6 31:8 Ignored 7:0 Slot 6 Red M5.5 31:8 Ignored 7:0 Slot 5 Red Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 266 DWord Bit Description M5.4 31:8 Ignored 7:0 Slot 4 Red M5.3 31:8 Ignored 7:0 Slot 3 Red M5.2 31:8 Ignored 7:0 Slot 2 Red M5.1 31:8 Ignored 7:0 Slot 1 Red M5.0 31:8 Ignored 7:0 Slot 0 Red 3.9.9.10.9 SIMD4x2 Address Payload The payload of a SIMD4x2 message provides address parameters to process 2 slots. DWord Bit Description M1.7 31:0 Programming Notes: This register can only be delivered for the Typed message types. M1.6 31:0 Programming Notes: This register can only be delivered for the Typed message types. M1.5 31:0 Slot 1 V Address Format = U32 M1.4 31:0 Slot 1 U Address Format = U32 M1.3 31:0 M1.2 31:0 M1.1 31:0 Slot 0 V Address M1.0 31:0 Slot 0 U Address 3.9.9.10.10 SIMD4x2 Source Payload (Atomic Operation message only) The source payload follows the address payload for atomic operation messages. Depending on the atomic operation, zero, one, or two sources are required. If the source is not required, it must not be included. Message registers given here could be a lower number if some of the address parameters are not included. The following atomic operations require no sources, thus the source payload is not delivered: AOP_INC, AOP_DEC, AOP_PREDEC The following atomic operations require both Source0 and Source1: AOP_CMPWR All of the remaining atomic operations require Source0 only. DWord Bit Description M2.7 31:0 Ignored M2.6 31:0 Ignored M2.5 31:0 Slot 1 Source1 Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 267 DWord Bit Description Specifies Source1 for slot 1. Format = S31 for AOP_IMAX and AOP_IMIN, U32 for all other operations M2.4 31:0 Slot 1 Source0 M2.3 31:0 Ignored M2.2 31:0 Ignored M2.1 31:0 Slot 0 Source1 M2.0 31:0 Slot 0 Source0 3.9.9.10.11 SIMD4x2 Source Payload ((AOP_CMPWR8B only) DWord Bit Description M2.7 31:0 Slot 1 Source1 [63:32] M2.6 31:0 Slot 1 Source1 [31:0] M2.5 31:0 Slot 1 Source0 [63:32] M2.4 31:0 Slot 1 Source0 [31:0] M2.3 31:0 Slot 0 Source1 [63:32] M2.2 31:0 Slot 0 Source1 [31:0] M2.1 31:0 Slot 0 Source0 [63:32] M2.0 31:0 Slot 0 Source0 [31:0] 3.9.9.10.12 SIMD4x2 Write Data Payload (Write message only) The write data payload follows the address payload for write messages. DWord Bit Description M2.7 31:0 Slot 1 Alpha Specifies the value of the red channel to be written for slot 7. For Untyped messages: Format = 32 bits raw data. For Typed messages: Format = IEEE Float, S31, or U32 depending on the Surface Format of the surface being accessed. SINT formats use S31, UINT formats use U32, and all other formats use Float. M2.6 31:0 Slot 1 Blue M2.5 31:0 Slot 1 Green M2.4 31:0 Slot 1 Red M2.3 31:0 Slot 0 Alpha M2.2 31:0 Slot 0 Blue M2.1 31:0 Slot 0 Green M2.0 31:0 Slot 0 Red 3.9.9.11 Writeback Message 3.9.9.11.1 SIMD16 Read A SIMD16 writeback message consists of up to 8 destination registers. Which registers are returned is determined by the channel mask in the message descriptor. Each asserted channel mask results in the Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 268 destination register of the corresponding channel being skipped in the writeback message, and all channels with higher numbered registers being dropped down to fill in the space occupied by the masked channel. For example, if only red and alpha are enabled, red is sent to regid+0 and regid+1, and alpha to regid+2 and regid+3. The slots written within each destination register is determined by the execution mask on the “send” instruction. DWord Bit Description W0.7 31:0 Slot 7 Red: Specifies the value of the red channel for slot 7. Format = 32 bits raw data. W0.6 31:0 Slot 6 Red W0.5 31:0 Slot 5 Red W0.4 31:0 Slot 4 Red W0.3 31:0 Slot 3 Red W0.2 31:0 Slot 2 Red W0.1 31:0 Slot 1 Red W0.0 31:0 Slot 0 Red W1.7 31:0 Slot 15 Red W1.6 31:0 Slot 14 Red W1.5 31:0 Slot 13 Red W1.4 31:0 Slot 12 Red W1.3 31:0 Slot 11 Red W1.2 31:0 Slot 10 Red W1.1 31:0 Slot 9 Red W1.0 31:0 Slot 8 Red W2 Slots 7:0 Green W3 Slots 15:8 Green W4 Slots 7:0 Blue W5 Slots 15:8 Blue W6 Slots 7:0 Alpha W7 Slots 15:8 Alpha 3.9.9.11.2 SIMD8 Read A SIMD8 writeback message consists of up to 4 destination registers. Which registers are returned is determined by the channel mask in the message descriptor. Each asserted channel mask results in the destination register of the corresponding channel being skipped in the writeback message, and all channels with higher numbered registers being dropped down to fill in the space occupied by the masked channel. For example, if only red and alpha are enabled, red is sent to regid+0, and alpha to regid+1. The slots written within each destination register is determined by the execution mask on the “send” instruction. DWord Bit Description W0.7 31:0 Slot 7 Red: Specifies the value of the red channel for slot 7. For Untyped messages: Format = 32 bits raw data. For Typed messages: Format = IEEE Float, S31, or U32 depending on the Surface Format of the surface being accessed. SINT formats use S31, UINT formats use U32, and all other formats use Float. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 269 DWord Bit Description W0.6 31:0 Slot 6 Red W0.5 31:0 Slot 5 Red W0.4 31:0 Slot 4 Red W0.3 31:0 Slot 3 Red W0.2 31:0 Slot 2 Red W0.1 31:0 Slot 1 Red W0.0 31:0 Slot 0 Red W1 Slots 7:0 Green W2 Slots 7:0 Blue W3 Slots 7:0 Alpha 3.9.9.11.3 SIMD8 Read (Tile W) The slots written within each destination register is determined by the execution mask on the “send” instruction. DWord Bit Description M5.7 31:8 Reserved (0) 7:0 Slot 7 Red Specifies the value of the red channel to be written for slot 7. For Typed messages: Format = U8 M5.6 31:8 Reserved (0) 7:0 Slot 6 Red M5.5 31:8 Reserved (0) 7:0 Slot 5 Red M5.4 31:8 Reserved (0) 7:0 Slot 4 Red M5.3 31:8 Reserved (0) 7:0 Slot 3 Red M5.2 31:8 Reserved (0) 7:0 Slot 2 Red M5.1 31:8 Reserved (0) 7:0 Slot 1 Red M5.0 31:8 Reserved (0) 7:0 Slot 0 Red Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 270 3.9.9.11.4 SIMD4x2 Read A SIMD4x2 writeback message always consists of a single message register containing all four color channels of each of the two slots. The channel mask bits as well as the execution mask on the “send” instruction are used to determine which of the channels in the destination register are overwritten. If any of the four execution mask bits for a slot is asserted, that slot is considered to be active. The active channels in the channel mask will be written in the destination register for that slot. If the slot is inactive (all four execution mask bits deasserted), none of the channels for that slot will be written in the destination register. DWord Bit Description W0.7 31:0 Slot 1 Alpha: Specifies the value of the pixel’s alpha channel. Format = 32 bits raw data. W0.6 31:0 Slot 1 Blue W0.5 31:0 Slot 1 Green W0.4 31:0 Slot 1 Red W0.3 31:0 Slot 0 Alpha W0.2 31:0 Slot 0 Blue W0.1 31:0 Slot 0 Green W0.0 31:0 Slot 0 Red 3.9.9.11.5 SIMD16 Atomic Operation A writeback message is only returned for an Atomic Operation message if the Send Return Data field in the message descriptor is enabled. The execution mask on the “send” instruction indicates which channels in the destination registers are overwritten. DWord Bit Description W0.7 31:0 Slot 7 Return Data: Specifies the value of the return data for slot 7. Format = U32 W0.6 31:0 Slot 6 Return Data W0.5 31:0 Slot 5 Return Data W0.4 31:0 Slot 4 Return Data W0.3 31:0 Slot 3 Return Data W0.2 31:0 Slot 2 Return Data W0.1 31:0 Slot 1 Return Data W0.0 31:0 Slot 0 Return Data W1.7 31:0 Slot 15 Return Data W1.6 31:0 Slot 14 Return Data W1.5 31:0 Slot 13 Return Data W1.4 31:0 Slot 12 Return Data W1.3 31:0 Slot 11 Return Data W1.2 31:0 Slot 10 Return Data W1.1 31:0 Slot 9 Return Data W1.0 31:0 Slot 8 Return Data Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 271 3.9.9.11.6 SIMD16 Atomic Operation (AOP_CMPWR8B only) A writeback message is only returned for an Atomic Operation AOP_CMPWR8B message if the Send Return Data field in the message descriptor is enabled. The execution mask on the “send” instruction indicates which channels in the destination registers are overwritten. DWord Bit Description W0.7 31:0 Slot 7 Return Data[31:0]: Specifies the value of the return data for slot 7. Format = U32 W0.6 31:0 Slot 6 Return Data[31:0] W0.5 31:0 Slot 5 Return Data[31:0] W0.4 31:0 Slot 4 Return Data[31:0] W0.3 31:0 Slot 3 Return Data[31:0] W0.2 31:0 Slot 2 Return Data[31:0] W0.1 31:0 Slot 1 Return Data[31:0] W0.0 31:0 Slot 0 Return Data[31:0] W1.7 31:0 Slot 15 Return Data[31:0] W1.6 31:0 Slot 14 Return Data[31:0] W1.5 31:0 Slot 13 Return Data[31:0] W1.4 31:0 Slot 12 Return Data[31:0] W1.3 31:0 Slot 11 Return Data[31:0] W1.2 31:0 Slot 10 Return Data[31:0] W1.1 31:0 Slot 9 Return Data[31:0] W1.0 31:0 Slot 8 Return Data[31:0] W2 Slot 7:0 Return Data[63:32] W3 Slot 15:8 Return Data[63:32] 3.9.9.11.7 SIMD8 Atomic Operation A writeback message is only returned for an Atomic Operation message if the Send Return Data field in the message descriptor is enabled. The execution mask on the “send” instruction indicates which channels in the destination registers are overwritten. DWord Bit Description W0.7 31:0 Slot 7 Return Data: Specifies the value of the return data for slot 7. Format = U32 W0.6 31:0 Slot 6 Return Data W0.5 31:0 Slot 5 Return Data W0.4 31:0 Slot 4 Return Data W0.3 31:0 Slot 3 Return Data W0.2 31:0 Slot 2 Return Data W0.1 31:0 Slot 1 Return Data W0.0 31:0 Slot 0 Return Data Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 272 3.9.9.11.8 SIMD8 Atomic Operation (AOP_CMPWR8B only) A writeback message is only returned for an Atomic Operation AOP_CMPWR8B message if the Send Return Data field in the message descriptor is enabled. The execution mask on the “send” instruction indicates which channels in the destination registers are overwritten. DWord Bit Description W0.7 31:0 Slot 7 Return Data[31:0]: Specifies the value of the return data for slot 7. Format = U32 W0.6 31:0 Slot 6 Return Data[31:0] W0.5 31:0 Slot 5 Return Data[31:0] W0.4 31:0 Slot 4 Return Data[31:0] W0.3 31:0 Slot 3 Return Data[31:0] W0.2 31:0 Slot 2 Return Data[31:0] W0.1 31:0 Slot 1 Return Data[31:0] W0.0 31:0 Slot 0 Return Data[31:0] W1.7 31:0 Slot 7 Return Data[63:32] W1.6 31:0 Slot 6 Return Data[63:32] W1.5 31:0 Slot 5 Return Data[63:32] W1.4 31:0 Slot 4 Return Data[63:32] W1.3 31:0 Slot 3 Return Data[63:32] W1.2 31:0 Slot 2 Return Data[63:32] W1.1 31:0 Slot 1 Return Data[63:32] W1.0 31:0 Slot 0 Return Data[63:32] 3.9.9.11.9 SIMD4x2 Atomic Operation A writeback message is only returned for an Atomic Operation message if the Send Return Data field in the message descriptor is enabled. The execution mask on the “send” instruction indicates which channels in the destination registers are overwritten. 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 Slot 1 Return Data: Specifies the value of the return data for slot 1. Format = U32 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 Slot 0 Return Data 3.9.9.11.10 SIMD4x2 Atomic Operation (AOP_CMPWR8B only) A writeback message is only returned for an Atomic Operation AOP_CMPWR8B message if the Send Return Data field in the message descriptor is enabled. The execution mask on the “send” instruction indicates which channels in the destination registers are overwritten. DWord Bit Description W0.7 31:0 reserved – not written to GRF W0.6 31:0 reserved – not written to GRF Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 273 DWord Bit Description W0.5 31:0 Slot 1 Return Data: [63:32] W0.4 31:0 Slot 1 Return Data: [31:0] W0.3 31:0 reserved – not written to GRF W0.2 31:0 reserved – not written to GRF W0.1 31:0 Slot 0 Return Data: [63:32] W0.0 31:0 Slot 0 Return Data[31:0] 3.9.10 Scratch Block Read/Write This message performs a read or write operation of between 1 and 4 simd-8 registers to a Hword aligned offset to scratch memory. The Hword offset into the scratch memory is provided in the message descriptor, allowing a single instruction read|write block operation in a single source instruction. 12b are provided for the Hword offset, allowing addressing of 4K Hword locations (128KB). Two modes of channel-enable interpretation are provided: Dword, which support a simd-8 or simd-16 dword channel-serial view of a register, and Oword, which supports a simd-4x2 view of a register. For operations under conditions of simd-32 processing, two messages should be used, with one of them indicating ‘H2’ to select the upper 16b of execution mask. This message type can only be used with stateless model memory access. Thus binding table entry 0xFF is hard-coded into the execution of this message. Applications: scratch space reads/writes for register spill/fill operations. Execution Mask. The low 8 bits of the execution mask are used to enable the 8 channels in the first and third GRF registers returned (W0, W2) for read, or the first and third write registers sent (M1, M3). The high 8 bits are used similarly for the second and fourth (W1, W3 or M2, M4). For Dword mode, the execution mask delivered with the message dictates dword-based control of read or write operations. For Oword mode, any one or more asserted bits within the Oword’s corresponding execution mask nibble causes read or write operations to occur across all four dwords of the Oword regardless of the setting of any particular dword’s bit. Out-of-Bounds Accesses. Reads to areas outside of the surface return 0. Writes to areas outside of the surface are dropped and will not modify memory contents. 3.9.10.1 Message Descriptor Bits Description 17 Operation Type: 0 = Read, 1 = write 16 Channel Mode: 0: Oword – Channel enables in effect at the time of ‘send’ are interpreted such if one or more are enabled, the read or write operation occurs on all four dwords. 1: Dword – Channel enables in effect at the time of the ‘send’ are used as dword enables, causing the read or write operation to occur only on the dwords whose corresponding channel enable is set.. 15 Invalidate after read – Indicates the cache line should invalidated after the read. 1: Invalidate cache line Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 274 Bits Description 0: no Invalidate 14 Reserved - MBZ 13:12 Block Size – indicates the number of simd-8 registers to be read|written. 11: 4 registers 10: 01: 2 registers 00: 1 register 11:0 Offset – A 12b Hword offset into the memory Immediate Memory buffer as specified by binding table 0xFF. 3.9.10.2 Message Header DWord Bit Description M0.7 31:16 Ignored 15:0 Ignored M0.6 31:0 Ignored M0.5 31:0 Immediate Buffer Base Address. Specifies the surface base address for messages in which the Binding Table Index is 255 (stateless model), otherwise this field is ignored. This pointer is relative to the General State Base Address. Format = GeneralStateOffset[31:10] 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 3.9.10.3 Message Payload (Write) The listing below illustrates the write payload for a message of block size = 4; DWord Bit Description M1.7:0 255:0 HWord[Offset] M2.7:0 255:0 HWord[Offset+1] M3.7:0 255:0 HWord[Offset+2] M3.7:0 255:0 HWord[Offset+3] 3.9.10.4 Message Payload (Read) Only required a message header. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 275 3.9.10.5 Writeback Message (Read) The table below illustrates an example where 4 Hwords are read through a scratch block read. DWord Bit Description W0.7:0 255:0 HWord[Offset] W1.7:0 255:0 HWord[Offset+1] W2.7:0 255:0 HWord[Offset+2] W3.7:0 255:0 HWord[Offset+3] 3.9.11 Render Target Write This message takes four subspans of pixels for write to a render target. Depending on parameters contained in the message and state, it may also perform a depth and stencil buffer write and/or a render target read for a color blend operation. Additional operations enabled in the Color Calculator state will also be initiated as a result of issuing this message (depth test, alpha test, logic ops, etc.). This message is intended only for use by pixel shader kernels for writing results to render targets. Restrictions: All surface types, except SURFTYPE_STRBUF, are allowed. For SURFTYPE_BUFFER and SURFTYPE_1D surfaces, only the X coordinate is used to index into the surface. The Y coordinate must be zero. For SURFTYPE_1D, 2D, 3D, and CUBE surfaces, a Render Target Array Index is included in the input message to provide an additional coordinate. The Render Target Array Index must be zero for SURFTYPE_BUFFER. The surface format is restricted to the set supported as render target. If source/dest color blend is enabled, the surface format is further restricted to the set supported as alpha blend render target. The last message sent to the render target by a thread must have the End Of Thread bit set in the message descriptor and the dispatch mask set correctly in the message header to enable correct clearing of the pixel scoreboard. The stateless model cannot be used with this message (Binding Table Index cannot be 255). This message can only be issued from a kernel specified in WM_STATE or 3DSTATE_WM (pixel shader kernel), dispatched in non-contiguous mode. Any other kernel issuing this message will cause undefined behavior. The dual source message cannot be used if the Render Target Rotation field in SURFACE_STATE is set to anything other than RTROTATE_0DEG. This message cannot be used on a surface in field mode (Vertical Line Stride = 1) If multiple SIMD8 Dual Source messages are delivered by the pixel shader thread, each SIMD8_DUALSRC_LO message must be issued before the SIMD8_DUALSRC_HI message with the same Slot Group Select setting. SIMD8 Image Write: Out of bounds write to SURFTYPE_BUFFER with more than 8K elements is undefined. Execution Mask. The execution mask for render target messages is ignored. Control of which pixels are active is controlled by the Pixel/Sample Enables fields in the message header. Out-of-Bounds Accesses. Accesses to pixels outside of the surface are dropped and will not modify memory contents. However, if the Render Target Array Index is out of bounds, it is set to zero and the surface write is not surpressed. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 276 The following table indicates the surface formats that are supported by this message. Surface Format Name R32G32B32A32_FLOAT R32G32B32A32_SINT R32G32B32A32_UINT R16G16B16A16_UNORM R16G16B16A16_SNORM R16G16B16A16_SINT R16G16B16A16_UINT R16G16B16A16_FLOAT R32G32_FLOAT R32G32_SINT R32G32_UINT B8G8R8A8_UNORM B8G8R8A8_UNORM_SRGB R10G10B10A2_UNORM R10G10B10A2_UINT R8G8B8A8_UNORM R8G8B8A8_UNORM_SRGB R8G8B8A8_SNORM R8G8B8A8_SINT R8G8B8A8_UINT R16G16_UNORM R16G16_SNORM R16G16_SINT R16G16_UINT R16G16_FLOAT B10G10R10A2_UNORM B10G10R10A2_UNORM_SRGB R11G11B10_FLOAT R32_SINT R32_UINT R32_FLOAT B5G6R5_UNORM B5G6R5_UNORM_SRGB B5G5R5A1_UNORM B5G5R5A1_UNORM_SRGB B4G4R4A4_UNORM B4G4R4A4_UNORM_SRGB R8G8_UNORM R8G8_SNORM R8G8_SINT R8G8_UINT R16_UNORM R16_SNORM R16_SINT R16_UINT R16_FLOAT B5G5R5X1_UNORM B5G5R5X1_UNORM_SRGB R8_UNORM R8_SNORM Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 277 Surface Format Name R8_SINT R8_UINT A8_UNORM YCRCB_NORMAL YCRCB_SWAPUVY YCRCB_SWAPUV YCRCB_SWAPY 3.9.11.1 Subspan/Pixel to Slot Mapping The following table indicates the mapping of subspans, pixels, and samples to slots in the pixel shader dispatch depending on the number of samples and message size. This table applies to all devices, however NumSamples = 4X is supported only on, and NumSamples = 8X is supported only on. Pixels are numbered as follows within a subspan: 0 = upper left 1 = upper right 2 = lower left 3 = lower right sspi = Starting Sample Pair Index (from the message header) Dispatch Size Num Samples Slot Mapping (SSPI = Starting Sample Pair Index) 1X SIMD32 Slot[3:0] = Subspan[0].Pixel[3:0].Sample[0] Slot[7:4] = Subspan[1].Pixel[3:0].Sample[0] Slot[11:8] = Subspan[2].Pixel[3:0].Sample[0] Slot[15:12] = Subspan[3].Pixel[3:0].Sample[0] Slot[19:16] = Subspan[4].Pixel[3:0].Sample[0] Slot[23:20] = Subspan[5].Pixel[3:0].Sample[0] Slot[27:24] = Subspan[6].Pixel[3:0].Sample[0] Slot[31:28] = Subspan[7].Pixel[3:0].Sample[0] 2X Slot[3:0] = Subspan[0].Pixel[3:0].Sample[0] Slot[7:4] = Subspan[0].Pixel[3:0].Sample[1] Slot[11:8] = Subspan[1].Pixel[3:0].Sample[0] Slot[15:12] = Subspan[1].Pixel[3:0].Sample[1] Slot[19:16] = Subspan[2].Pixel[3:0].Sample[0] Slot[23:20] = Subspan[2].Pixel[3:0].Sample[1] Slot[27:24] = Subspan[3].Pixel[3:0].Sample[0] Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 278 Dispatch Size Num Samples Slot Mapping (SSPI = Starting Sample Pair Index) Slot[31:28] = Subspan[3].Pixel[3:0].Sample[1] 4X Slot[3:0] = Subspan[0].Pixel[3:0].Sample[0] Slot[7:4] = Subspan[0].Pixel[3:0].Sample[1] Slot[11:8] = Subspan[0].Pixel[3:0].Sample[2] Slot[15:12] = Subspan[0].Pixel[3:0].Sample[3] Slot[19:16] = Subspan[1].Pixel[3:0].Sample[0] Slot[23:20] = Subspan[1].Pixel[3:0].Sample[1] Slot[27:24] = Subspan[1].Pixel[3:0].Sample[2] Slot[31:28] = Subspan[1].Pixel[3:0].Sample[3] SIMD16 8X Slot[3:0] = Subspan[0].Pixel[3:0].Sample[0] Slot[7:4] = Subspan[0].Pixel[3:0].Sample[1] Slot[11:8] = Subspan[0].Pixel[3:0].Sample[2] Slot[15:12] = Subspan[0].Pixel[3:0].Sample[3] Slot[19:16] = Subspan[0].Pixel[3:0].Sample[4] Slot[23:20] = Subspan[0].Pixel[3:0].Sample[5] Slot[27:24] = Subspan[0].Pixel[3:0].Sample[6] Slot[31:28] = Subspan[0].Pixel[3:0].Sample[7] 1X Slot[3:0] = Subspan[0].Pixel[3:0].Sample[0] Slot[7:4] = Subspan[1].Pixel[3:0].Sample[0] Slot[11:8] = Subspan[2].Pixel[3:0].Sample[0] Slot[15:12] = Subspan[3].Pixel[3:0].Sample[0] 2X Slot[3:0] = Subspan[0].Pixel[3:0].Sample[0] Slot[7:4] = Subspan[0].Pixel[3:0].Sample[1] Slot[11:8] = Subspan[1].Pixel[3:0].Sample[0] Slot[15:12] = Subspan[1].Pixel[3:0].Sample[1] Restriction: When SIMD32 or SIMD16 PS threads send render target writes with multiple SIMD8 and SIMD16 messages, the following must hold: All the slots (as described above) must have a corresponding render target write irrespective of the slot's validity. A slot is considered valid when at least one sample is enabled. For example, a SIMD16 PS thread must send two SIMD8 render target writes to cover all the slots. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 279 PS thread must send SIMD render target write messages with increasing slot numbers. For example, SIMD16 thread has Slot[15:0] and if two SIMD8 render target writes are used, the first SIMD8 render target write must send Slot[7:0] and the next one must send Slot[15:8]. 3.9.11.2 Message Descriptor Message Descriptor - Render Target Write Default Value: 0x00000000 DWord Bit Description 0 31 Reserved Format: MBZ 29:14 Reserved Format: MBZ 13 Reserved Format: MBZ 12 Last Render Target Select This bit must be set on the last render target write message sent for each group of pixels. For single render target pixel shaders, this bit is set on all render target write messages. For multiple render target pixel shaders, this bit is set only on messages sent to the last render target. This bit must be zero for SIMD8 Image Write message. Programming Notes In general, when threads are not launched by 3D FF, this bit must be zero. 11 Slot Group Select This field selects whether slots 15:0 or slots 31:16 are used for bypassed data. Bypassed data includes the antialias alpha, multisample coverage mask, and if the header is not present also includes the X/Y addresses and pixel enables. 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. Value Name Description 0 SLOTGRP_LO choose bypassed data for slots 15:0 1 SLOTGRP_HI choose bypassed data for slots 31:16 Programming Notes For SIMD8 Image Write message thsi field MBZ. 10:8 Message Type This field specifies the type of render target message. For the SIMD8_DUALSRC_xx messages, the low bit indicates which slots to use for the pixel enables, X/Y addresses, and oMask. Value Name Description 000b SIMD16 SIMD16 single source message 001b SIMD16_REPDATA SIMD16 single source message with replicated data 010b SIMD8_DUALSRC_LO SIMD8 dual source message, use slots 7:0 011b SIMD8_DUALSRC_HI SIMD8 dual source message, use slots 15:8 100b SIMD8_LO SIMD8 single source message, use slots 7:0 111b SIMD16_REPDATA It's only supported when accessing Tiled Memory. Using this Message Type to access linear (Untiled) memory is UNDEFINED. Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 280 Message Descriptor - Render Target Write Programming Notes Project the above slots indicated are within the 16 slots selected by Slot Group Select. If SLOTGRP_HI is selected, the SIMD8 message types above reference slots 23:16 or 31:24 instead of 7:0 or 15:8, respectively. SIMD16 messages are not supported for 8X MSAA when PS outputs depth. SIMD16_REPDATA message must not be used in SIMD8 pixel-shaders. 7:0 Reserved Format: MBZ 3.9.11.3 Message Header The render target write message has a two-register message header. If the header is not present, behavior is as if the message was sent with most fields set to the same value that was delivered in R0 and R1 on the pixel shader thread dispatch. The following fields, which are not delivered in the pixel shader dispatch, behave as if they are set to zero: Render Target Index Source0 Alpha Present to Render Target DWord Bits Description M0.7 31:0 M0.6 31:0 M0.5 31:10 Ignored 9:8 Color Code: This ID is assigned by the Windower unit and is used to track synchronizing events. Format: Reserved for HW Implementation Use. 7:0 FFTID. The Fixed Function Thread 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 (reserved for hardware delivery of binding table pointer) M0.3 31:0 Ignored M0.2 31:3 Ignored 2:0 Render Target Index. Specifies the render target index that will be used to select blend state from BLEND_STATE. Format = U3 M0.1 31:6 ColorCalculatorState Pointer. Specifies the 64-byte aligned pointer to the color calculator state. This pointer is relative to the General State Base Address. Format = GeneralStateOffset[31:6] 5:0 Ignored M0.0 31 Ignored Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 281 DWord Bits Description 30:27 Viewport Index. Specifies the index of the viewport currently being used. Format = U4 Range = [0,15] 26:16 Render Target Array Index. Specifies the array index to be used for the following surface types: SURFTYPE_1D: specifies the array index. Range = [0,511] SURFTYPE_2D: specifies the array index. Range = [0,511] SURFTYPE_3D: specifies the “z” or “r” coordinate. Range = [0,2047] SURFTYPE_CUBE: specifies the face identifier. Range = [0,5] SURFTYPE_BUFFER: must be zero. face Render Target Array Index +x 0 -x 1 +y 2 -y 3 +z 4 -z 5 Format = U11 The Render Target Array Index used by hardware for access to the Render Target is overridden with the Minimum Array Element defined in SURFACE_STATE if it is out of the range between Minimum Array Element and Depth. For cube surfaces, a depth value of 5 is used for this determination. 15 Front/Back Facing Polygon. Determines whether the polygon is front or back facing. Used by the render cache to determine which stencil test state to use. 0: Front Facing 1: Back Facing 14 Ignored 14 13 Source Depth Present to Render Target. Indicates that source depth is included in the message. 12 oMask to Render Target This bit indicates that oMask data is present in the message and is to be used to mask off samples. 11 Source0 Alpha Present to RenderTarget. This bit indicates that Source0 Alpha (aka o0.a) data is included in RTWrite message. If present, these alpha values are used as inputs to AlphaTest and AlphaToCoverage functions. This is required to meet the API Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 282 DWord Bits Description rules when writing to multiple render targets (MRTs). Programming Notes: This bit should not be set when writing to RT0, though sending and using redundant alpha will provide the correct results (at lower performance). This bit is not supported on Dual-Source Blend message types, as source0 alpha is already included in those messages. This bit is not supported on replicated data message types. 10:9 Ignored 8:6 Starting Sample Pair Index: indicates the index of the first sample pair of the dispatch Format = U3 Range = [0,3] 5:0 Ignored M1.7 31:16 Dispatched Pixel/Sample Enables. One bit per pixel (or sample within pixel) indicating which pixels/samples were originally enabled when the thread was dispatched. This field is only required for the end-of-thread message and on all dual-source messages. The Dispatched Pixel/Sample Enablesmust be unmodified from the ones sent when the pixel shader thread was initiated. If the Dispatched Pixel/Sample Enables are modified, behavior is undefined. Multisample Note: When operating in PERSAMPLE mode these bits correspond to samples, not pixels. Each subspan slot (4 bits) corresponds to a specific sample location for the subspan. Note that in NUMSAMPLES_1 mode, a pixel and sample are synonomous. When operating in PERPIXEL mode, this field is ignored, and instead the SampleEnableMask (obtained via bypass) are used to clear the Depth Scoreboard. 15:0 Pixel/Sample Enables. One bit per pixel/sample indicating which pixels/samples are still lit based on kill instruction activity in the pixel shader. This mask is used to control actual writes to the color buffer. Multisample Note: When operating in PERSAMPLE mode these bits correspond to samples, not pixels, as the PS is run per-sample. Each subspan slot (4 bits) corresponds to a specific sample location for the subspan. When operating in PERPIXEL mode, these bits still correspond to pixels, as the PS is run per-pixel. Each pixel’s mask bit is replicated according to Number of Multisamples and combined with other masks to control writes to the multisample locations. M1.6 31:0 Ignored M1.5 31:16 Y3. Y coordinate for upper-left pixel of subspan 3 (slot 12) Format = U16 15:0 X3. X coordinate for upper-left pixel of subspan 3 (slot 12) Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 283 DWord Bits Description Format = U16 M1.4 31:16 Y2 15:0 X2 M1.3 31:16 Y1 15:0 X1 M1.2 31:16 Y0 15:0 X0 M1.1 31:0 Ignored M1.0 31:0 Ignored 3.9.11.4 Source 0 Alpha Payload The source 0 alpha registers, if included, appear in M2 and M3, immediately following the header (if present). For the SIMD8 single source message, only slot 7:0 data is sent (M2). The source 0 alpha phases are not supported for dual source messages. DWord Bit Description M2.7 31:0 Source 0 Alpha for Slot 7 Format = IEEE_Float This and the next register is only included if Source 0 Alpha Present bit is set. M2.6 31:0 Source 0 Alpha for Slot 6 M2.5 31:0 Source 0 Alpha for Slot 5 M2.4 31:0 Source 0 Alpha for Slot 4 M2.3 31:0 Source 0 Alpha for Slot 3 M2.2 31:0 Source 0 Alpha for Slot 2 M2.1 31:0 Source 0 Alpha for Slot 1 M2.0 31:0 Source 0 Alpha for Slot 0 M3.7 31:0 Source 0 Alpha for Slot 15 M3.6 31:0 Source 0 Alpha for Slot 14 M3.5 31:0 Source 0 Alpha for Slot 13 M3.4 31:0 Source 0 Alpha for Slot 12 M3.3 31:0 Source 0 Alpha for Slot 11 M3.2 31:0 Source 0 Alpha for Slot 10 M3.1 31:0 Source 0 Alpha for Slot 9 M3.0 31:0 Source 0 Alpha for Slot 8 3.9.11.5 oMask Payload () The oMask payload, if present, follows source 0 alpha. The value of ‘p’ depends on whether the header and source 0 alpha are present. Sample “n” for that pixel will be killed (not written to the render target or depth buffer) if bit “n” of the oMask is zero. Bits numbers where “n” is larger than the number of multisamples are ignored. For the SIMD8 messages, only slots 7:0 data is used, or only slots 15:8 depending on the Message Type encoding. DWord Bit Description Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 284 DWord Bit Description Mp.7 31:16 oMask for Slot 15 Format = 16-bit mask This register is only included if oMask Present bit is set. 15:0 oMask for Slot 14 Mp.6 31:16 oMask for Slot 13 15:0 oMask for Slot 12 Mp.5 31:16 oMask for Slot 11 15:0 oMask for Slot 10 Mp.4 31:16 oMask for Slot 9 15:0 oMask for Slot 8 Mp.3 31:16 oMask for Slot 7 15:0 oMask for Slot 6 Mp.2 31:16 oMask for Slot 5 15:0 oMask for Slot 4 Mp.1 31:16 oMask for Slot 3 15:0 oMask for Slot 2 Mp.0 31:16 oMask for Slot 1 15:0 oMask for Slot 0 3.9.11.6 Color Payload: SIMD16 Single Source 3.9.11.6.1 Color Payload This payload is included if the Message Type is SIMD16 single source. The value of ‘m’ depends on whether the header, source 0 alpha, and oMask are present. DWord Bit Description Mm.7 31:0 Slot 7 Red. Specifies the value of the slot’s red component. Format = IEEE Float, S31, or U32 depending on the Surface Format of the surface being accessed. SINT formats use S31, UINT formats use U32, and all other formats use Float. Mm.6 31:0 Slot 6 Red Mm.5 31:0 Slot 5 Red Mm.4 31:0 Slot 4 Red Mm.3 31:0 Slot 3 Red Mm.2 31:0 Slot 2 Red Mm.1 31:0 Slot 1 Red Mm.0 31:0 Slot 0 Red M(m+1).7 31:0 Slot 15 Red M(m+1).6 31:0 Slot 14 Red M(m+1).5 31:0 Slot 13 Red M(m+1).4 31:0 Slot 12 Red M(m+1).3 31:0 Slot 11 Red M(m+1).2 31:0 Slot 10 Red M(m+1).1 31:0 Slot 9 Red M(m+1).0 31:0 Slot 8 Red M(m+2) Slot[7:0] Green. See Mm definition for slot locations Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 285 DWord Bit Description M(m+3) Slot[15:8] Green. See M(m+1) definition for slot locations M(m+4) Slot[7:0] Blue. See Mm definition for slot locations M(m+5) Slot[15:8] Blue. See M(m+1) definition for slot locations M(m+6) Slot[7:0] Alpha. See Mm definition for slot locations M(m+7) Slot[15:8] Alpha. See M(m+1) definition for slot locations 3.9.11.7 Color Payload: SIMD8 Single Source This payload is included if the Message Type is SIMD8 single source or SIMD8 Image Write. For , the value of ‘m’ depends on whether the header, source 0 alpha, and oMask are present. DWord Bit Description Mm.7 31:0 Slot 7 Red. Specifies the value of the slot’s red component. Format = IEEE Float, S31, or U32 depending on the Surface Format of the surface being accessed. SINT formats use S31, UINT formats use U32, and all other formats use Float. Mm.6 31:0 Slot 6 Red Mm.5 31:0 Slot 5 Red Mm.4 31:0 Slot 4 Red Mm.3 31:0 Slot 3 Red Mm.2 31:0 Slot 2 Red Mm.1 31:0 Slot 1 Red Mm.0 31:0 Slot 0 Red M(m+1) Slot[7:0] Green. See Mm definition for slot locations M(m+2) Slot[7:0] Blue. See Mm definition for slot locations M(m+3) Slot[7:0] Alpha. See Mm definition for slot locations 3.9.11.8 Color Payload: SIMD16 Replicated Data This payload is included if the Message Type specifies single source message with replicated data. One set of R/G/B/A data is included in the message, and this data is replicated to all 16 pixels. This message is legal with color data only (for , oMask is also legal with this message). The registers for depth, stencil, and antialias alpha data cannot be included with this message, and the corresponding bits in the message header must indicate that these registers are not present. Programming Notes: This message is allowed only on tiled surfaces DWord Bit Description Mm.7:4 31:0 Reserved Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 286 DWord Bit Description Mm.3 31:0 Alpha. Specifies the value of all slots’ alpha channel. Format = IEEE Float, S31, or U32 depending on the Surface Format of the surface being accessed. SINT formats use S31, UINT formats use U32, and all other formats use Float. Mm.2 31:0 Blue Mm.1 31:0 Green Mm.0 31:0 Red 3.9.11.9 Message Sequencing Summary This section summarizes the sequencing that occurs for each legal render target write message. All messages have the M0 and M1 header registers if the header is present. If the header is not present, all registers below are renumbered starting with M0 where M2 appears. All cases not shown in this table are illegal. Key: s0, s1 = source 0, source 1 1/0 = slots 15:8 3/2 = slots 7:0 sZ = source depth oM = oMask Messag oMask Source Source M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12 M13 M14 e Type Presen Depth 0 t Presen Alpha t Presen t 000 0 0 0 1/0R 3/2R 1/0G 3/2G 1/0B 3/2B 1/0A 3/2A 000 0 0 1 1/0s0 3/2s0 1/0R 3/2R 1/0G 3/2G 1/0B 3/2B 1/0A 3/2A A A 000 0 1 0 1/0R 3/2R 1/0G 3/2G 1/0B 3/2B 1/0A 3/2A 1/0sZ 3/2s Z 000 0 1 1 1/0s0 3/2s0 1/0R 3/2R 1/0G 3/2G 1/0B 3/2B 1/0A 3/2A 1/0s 3/2s A A Z Z 000 1 0 0 oM 1/0R 3/2R 1/0G 3/2G 1/0B 3/2B 1/0A 3/2A 000 1 0 1 1/0so 3/2s0 oM 1/0R 3/2R 1/0G 3/2G 1/0B 3/2B 1/0A 3/2A A A 000 1 1 0 oM 1/0R 3/2R 1/0G 3/2G 1/0B 3/2B 1/0A 3/2A 1/0s 3/2s Z Z 000 1 1 1 1/0s0 3/2s0 oM 1/0R 3/2R 1/0G 3/2G 1/0B 3/2B 1/0A 3/2A 1/0s 3/2s A A Z Z 001 0 0 0 RGBA 001 1 0 0 oM RGBA 010 0 0 0 1/0s0 1/0s0 1/0s0 1/0s0 1/0s1 1/0s1 1/0s1 1/0s1 R G B A R G B A 010 0 1 0 1/0s0 1/0s0 1/0s0 1/0s0 1/0s1 1/0s1 1/0s1 1/0s1 1/0sZ R G B A R G B A 010 1 0 0 oM 1/0s0 1/0s0 1/0s0 1/0s0 1/0s1 1/0s1 1/0s1 1/0s1 R G B A R G B A Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 287 Messag oMask Source Source M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12 M13 M14 e Type Presen Depth 0 t Presen Alpha t Presen t 010 1 1 0 oM 1/0s0 1/0s0 1/0s0 1/0s0 1/0s1 1/0s1 1/0s1 1/0s1 1/0s R G B A R G B A Z 011 0 0 0 3/2s0 3/2s0 3/2s0 3/2s0 3/2s1 3/2s1 3/2s1 3/2s1 R G B A R G B A 011 0 1 0 3/2s0 3/2s0 3/2s0 3/2s0 3/2s1 3/2s1 3/2s1 3/2s1 3/2sZ R G B A R G B A 011 1 0 0 oM 3/2s0 3/2s0 3/2s0 3/2s0 3/2s1 3/2s1 3/2s1 3/2s1 R G B A R G B A 011 1 1 0 oM 3/2s0 3/2s0 3/2s0 3/2s0 3/2s1 3/2s1 3/2s1 3/2s1 3/2s R G B A R G B A Z 100 0 0 0 R G B A 100 0 0 1 s0A R G B A 100 0 1 0 R G B A sZ 100 0 1 1 s0A R G B A sZ 100 1 0 0 oM R G B A 100 1 0 1 s0A oM R G B A 100 1 1 0 oM R G B A sZ 100 1 1 1 s0A oM R G B A sZ Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 288 Revision History Revision Number Description Revision Date 1.0 First 2012 OpenSource edition May 2012 §§ Doc Ref #: IHD-OS-V4 Pt 1 – 05 12 5/31/2012 289