Intel® OpenSource HD Graphics Programmer’s Reference Manual (PRM) Volume 2 Part 1: 3D/Media – 3D Pipeline (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-V2 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. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 5/29/2012 2 Contents 1. 3D Pipeline ............................................................................................................................................. 9 1.1 Introduction .......................................................................................................................................... 9 1.2 3D Pipeline Overview ........................................................................................................................... 9 1.2.1 3D Pipeline Stages ......................................................................................................................... 9 1.3 3D Primitives Overview ...................................................................................................................... 10 1.4 3D Pipeline State Overview ............................................................................................................... 16 1.4.1 3D State Model ............................................................................................................................. 16 1.4.2 3DSTATE_CC_STATE_POINTERS ............................................................................................ 18 1.4.3 3DSTATE_BLEND_STATE_POINTERS ..................................................................................... 19 1.4.4 3DSTATE_DEPTH_STENCIL_STATE_POINTERS .................................................................... 20 1.4.5 3DSTATE_BINDING_TABLE_POINTERS .................................................................................. 21 1.5 3DSTATE_SAMPLER_STATE_POINTERS...................................................................................... 26 1.5.1 1.5.1 3DSTATE_SAMPLER_STATE_POINTERS_VS ............................................................... 26 1.5.2 3DSTATE_SAMPLER_STATE_POINTERS_HS ......................................................................... 27 1.5.3 3DSTATE_SAMPLER_STATE_POINTERS_DS ......................................................................... 28 1.5.4 3DSTATE_SAMPLER_STATE_POINTERS_GS ......................................................................... 29 1.5.5 3DSTATE_SAMPLER_STATE_POINTERS_PS ......................................................................... 30 1.6 3DSTATE_VIEWPORT_STATE_POINTERS.................................................................................... 31 1.6.1 3DSTATE_VIEWPORT_STATE_POINTERS_CC ....................................................................... 31 1.6.2 3DSTATE_VIEWPORT_STATE_POINTERS_SF_CLIP ............................................................. 32 1.6.3 3DSTATE_SCISSOR_STATE_POINTERS ................................................................................. 33 1.7 3DSTATE_URB Commands .............................................................................................................. 34 1.7.1 3DSTATE_URB_VS ..................................................................................................................... 34 1.7.2 3DSTATE_URB_HS ..................................................................................................................... 36 1.7.3 3DSTATE_URB_DS ..................................................................................................................... 37 1.7.4 3DSTATE_URB_GS ..................................................................................................................... 39 1.7.5 Gather Constants ......................................................................................................................... 40 1.7.6 Dx9 Constant Buffer Generation .................................................................................................. 40 1.8 Vertex Data Overview ........................................................................................................................ 41 1.8.1 Vertex URB Entry (VUE) Formats ................................................................................................ 41 1.8.2 Vertex Positions ............................................................................................................................ 43 1.9 3D Pipeline Stage Overview .............................................................................................................. 45 1.9.1 Generic 3D FF Unit Block Diagram .............................................................................................. 46 1.9.2 1Common 3D FF Unit Functions .................................................................................................. 46 1.9.3 Thread Initiation Management ...................................................................................................... 48 1.9.4 Thread Request Generation ......................................................................................................... 48 1.9.5 Thread Output Handling ............................................................................................................... 54 1.9.6 VUE Readback ............................................................................................................................. 54 1.9.7 Statistics Gathering ...................................................................................................................... 54 1.10 Synchronization of the 3D Pipeline ................................................................................................... 56 1.10.1 Top-of-Pipe Synchronization ...................................................................................................... 56 1.10.2 End-of-Pipe Synchronization ...................................................................................................... 56 1.10.3 Synchronization Actions ............................................................................................................. 57 1.10.4 PIPE_CONTROL Command ...................................................................................................... 58 1.11 Push Constant URB Allocation ......................................................................................................... 67 2. 3D Pipeline – Vertex Fetch (VF) Stage .............................................................................................. 71 2.1 Vertex Fetch (VF) Stage Overview .................................................................................................... 71 2.1.1 Input Assembly ............................................................................................................................. 71 2.1.2 Vertex Cache ................................................................................................................................ 72 2.1.3 Input Data: Push Model vs. Pull Model ........................................................................................ 72 2.1.4 Generated IDs .............................................................................................................................. 72 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 5/29/2012 3 2.2 Index Buffer (IB) ................................................................................................................................. 73 2.2.1 3DSTATE_INDEX_BUFFER ........................................................................................................ 73 2.2.2 Index Buffer Access ...................................................................................................................... 76 2.3 Vertex Buffers (VBs) .......................................................................................................................... 76 2.3.1 3DSTATE_VERTEX_BUFFERS .................................................................................................. 77 2.3.2 VERTEX_BUFFER_STATE Structure ......................................................................................... 78 2.3.3 VERTEXDATA Buffers – SEQUENTIAL Access.......................................................................... 81 2.3.4 VERTEXDATA Buffers – RANDOM Access ................................................................................ 82 2.3.5 INSTANCEDATA Buffers ............................................................................................................. 83 2.4 Input Vertex Definition ........................................................................................................................ 83 2.4.1 3DSTATE_VERTEX_ELEMENTS ............................................................................................... 84 2.4.2 VERTEX_ELEMENT_STATE Structure ....................................................................................... 85 2.4.3 Vertex Element Data Path ............................................................................................................ 89 2.5 3D Primitive Processing ..................................................................................................................... 90 2.5.1 3D PRIMITIVE Command ............................................................................................................ 90 2.5.2 Functional Overview ..................................................................................................................... 94 2.5.3 CommandInit ................................................................................................................................ 94 2.5.4 InstanceLoop ................................................................................................................................ 94 2.5.5 VertexLoop ................................................................................................................................... 95 2.5.6 VertexIndexGeneration ................................................................................................................. 95 2.5.7 TerminatePrimitive ........................................................................................................................ 96 2.5.8 VertexCacheLookup ..................................................................................................................... 96 2.5.9 VertexElementLoop ...................................................................................................................... 96 2.5.10 SourceElementFetch .................................................................................................................. 97 2.5.11 Format Conversion ..................................................................................................................... 97 2.5.12 DestinationFormatSelection ....................................................................................................... 99 2.5.13 PrimitiveInfoGeneration ............................................................................................................ 100 2.5.14 URBWrite .................................................................................................................................. 101 2.5.15 OutputBufferedVertex ............................................................................................................... 101 2.6 Dangling Vertex Removal ................................................................................................................ 101 2.7 Other Vertex Fetch Functionality ..................................................................................................... 102 2.7.1 Statistics Gathering .................................................................................................................... 102 3. 3D Pipeline – Vertex Shader (VS) Stage .......................................................................................... 104 3.1 VS Stage Overview .......................................................................................................................... 104 3.1.1 Vertex Caching ........................................................................................................................... 104 3.2 VS Stage Input ................................................................................................................................. 106 3.2.1 State ........................................................................................................................................... 106 3.2.2 Input Vertices .............................................................................................................................. 116 3.3 SIMD4x2 VS Thread Request Generation ....................................................................................... 116 3.3.1 Thread Payload .......................................................................................................................... 117 3.4 SIMD4x2 VS Thread Execution ....................................................................................................... 119 3.4.1 Vertex Output.............................................................................................................................. 119 3.4.2 Thread Termination .................................................................................................................... 119 3.5 Primitive Output ................................................................................................................................ 119 3.6 Other VS Functions .......................................................................................................................... 119 3.6.1 Statistics Gathering .................................................................................................................... 119 4. 3D Pipeline – Hull Shader (HS) Stage .............................................................................................. 121 4.1 HS Stage Overview .......................................................................................................................... 121 4.2 HS Stage Input ................................................................................................................................. 121 4.2.1 State ........................................................................................................................................... 121 4.3 3DSTATE_CONSTANT_HS ............................................................................................................ 124 4.4 3DSTATE_HS .................................................................................................................................. 127 4.5 Patch Object Staging ....................................................................................................................... 133 4.6 HS Thread Payload .......................................................................................................................... 133 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 5/29/2012 4 4.6.1 SINGLE_PATCH Layout (SINGLE-PATCH Mode) .................................................................... 133 4.7 HS Thread Execution ....................................................................................................................... 136 4.7.1 Dispatch Mask ............................................................................................................................ 137 4.8 ICP Dereferencing............................................................................................................................ 137 4.9 Patch URB Entry (Patch Record) Output ......................................................................................... 137 4.9.1 Patch Header .............................................................................................................................. 137 4.9.2 DOMAIN_POINT Structure ......................................................................................................... 139 4.10 Statistics Gathering......................................................................................................................... 140 4.10.1 HS Invocations ......................................................................................................................... 140 5. 3D Pipeline – Tessellation Engine (TE) ........................................................................................... 141 5.1 3DSTATE_TE .................................................................................................................................. 141 5.2 Domain Types and Output Topologies ............................................................................................ 144 5.3 QUAD Domain Tessellation ............................................................................................................. 144 5.3.1 TRI Domain Tessellation ............................................................................................................ 146 5.4 ISOLINE Domain Tessellation ......................................................................................................... 147 5.5 Patch Culling .................................................................................................................................... 147 5.6 Tessellation Factor Limits ................................................................................................................ 147 5.7 Partitioning ....................................................................................................................................... 148 6. 3D Pipeline – Domain Shader (DS) Stage ....................................................................................... 149 6.1 3DSTATE_DS .................................................................................................................................. 149 6.1.1 3DSTATE_PUSH_CONSTANT_ALLOC_DS ............................................................................. 154 6.1.2 3DSTATE_CONSTANT_DS....................................................................................................... 156 6.2 Thread Payload ................................................................................................................................ 159 6.3 DS Thread Execution ....................................................................................................................... 163 6.4 Statistics Gathering .......................................................................................................................... 164 7. 3D Pipeline – Geometry Shader (GS) Stage ................................................................................... 165 7.1 GS Stage Overview.......................................................................................................................... 165 7.2 GS Stage Input ................................................................................................................................. 165 7.2.1 State ........................................................................................................................................... 165 7.3 Object Staging .................................................................................................................................. 178 7.4 GS Thread Request Generation ...................................................................................................... 178 7.4.1 Object Vertex Ordering ............................................................................................................... 178 7.4.2 GS Thread Payload High-Level Layout ...................................................................................... 182 7.4.3 GS Thread Payload SIMD 4x2 ................................................................................................... 183 7.5 GS Thread Execution ....................................................................................................................... 188 7.5.1 GS Thread Output ...................................................................................................................... 189 7.5.2 Stream Output ............................................................................................................................ 190 7.5.3 Thread Termination .................................................................................................................... 191 7.6 Primitive Output ................................................................................................................................ 191 7.7 Other Functionality ........................................................................................................................... 191 7.7.1 Statistics Gathering .................................................................................................................... 191 8. 3D Pipeline - Stream Output Logic (SOL) Stage ............................................................................ 193 8.1 Input Buffering .................................................................................................................................. 193 8.2 Stream Output Buffers ..................................................................................................................... 195 8.3 Stream Output Function ................................................................................................................... 196 8.4 3DSTATE_STREAMOUT ................................................................................................................ 196 8.5 3DSTATE_SO_DECL_LIST Command ........................................................................................... 201 8.5.1 SO_DECL Structure Definition ................................................................................................... 205 8.6 3DSTATE_SO_BUFFER ................................................................................................................. 207 8.7 Rendering Disable............................................................................................................................ 208 8.8 Statistics ........................................................................................................................................... 208 9. 3D Pipeline – Clip Stage ................................................................................................................... 209 9.1 3D Pipeline – CLIP Stage Overview ................................................................................................ 209 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 5/29/2012 5 9.1.1 Clip Stage – General-Purpose Processing ................................................................................. 209 9.1.2 Clip Stage – 3D Clipping ............................................................................................................ 209 9.1.3 Fixed Function Clipper ................................................................................................................ 210 9.2 Concepts .......................................................................................................................................... 210 9.2.1 The Clip Volume ......................................................................................................................... 210 9.2.2 User-Specified Clipping .............................................................................................................. 212 9.2.3 Guard Band ................................................................................................................................ 212 9.2.4 Vertex-Based Clip Testing & Considerations ............................................................................. 215 9.2.5 3D Clipping ................................................................................................................................. 217 9.3 CLIP Stage Input .............................................................................................................................. 217 9.3.1 State ........................................................................................................................................... 218 9.4 Object Staging .................................................................................................................................. 223 9.4.1 Partial Object Removal ............................................................................................................... 223 9.4.2 ClipDetermination Function ........................................................................................................ 223 9.4.3 ClipMode..................................................................................................................................... 226 9.5 Object Pass-Through ....................................................................................................................... 227 9.6 Primitive Output ................................................................................................................................ 228 9.7 Other Functionality ........................................................................................................................... 229 9.7.1 Statistics Gathering .................................................................................................................... 229 10. 3D Pipeline - Strips and Fans (SF) Stage ........................................................................................ 230 10.1 Overview ......................................................................................................................................... 230 10.1.1 Inputs from CLIP ....................................................................................................................... 230 10.1.2 Attribute Setup/Interpolation Process ....................................................................................... 231 10.1.3 Outputs to WM .......................................................................................................................... 231 10.2 Primitive Assembly ......................................................................................................................... 231 10.2.1 Point List Decomposition .......................................................................................................... 234 10.2.2 Line List Decomposition ........................................................................................................... 235 10.2.3 Line Strip Decomposition .......................................................................................................... 236 10.2.4 Triangle List Decomposition ..................................................................................................... 237 10.2.5 Triangle Strip Decomposition ................................................................................................... 238 10.2.6 Triangle Fan Decomposition..................................................................................................... 239 10.2.7 Polygon Decomposition ............................................................................................................ 240 10.2.8 Rectangle List Decomposition .................................................................................................. 240 10.3 Object Setup ................................................................................................................................... 241 10.3.1 Invalid Position Culling (Pre/Post-Transform) .......................................................................... 241 10.3.2 Viewport Transformation .......................................................................................................... 241 10.3.3 Destination Origin Bias ............................................................................................................. 241 10.3.4 Point Rasterization Rule Adjustment ........................................................................................ 242 10.3.5 Drawing Rectangle Offset Application ...................................................................................... 243 10.3.6 Point Width Application ............................................................................................................. 246 10.3.7 Rectangle Completion .............................................................................................................. 247 10.3.8 Vertex X,Y Clamping and Quantization .................................................................................... 247 10.3.9 Degenerate Object Culling ....................................................................................................... 248 10.3.10 Triangle Orientation (Face) Culling ........................................................................................ 248 10.3.11 Scissor Rectangle Clipping..................................................................................................... 249 10.3.12 Line Rasterization ................................................................................................................... 250 10.3.13 3DSTATE_SF ......................................................................................................................... 257 10.3.14 3DSTATE_SBE ...................................................................................................................... 263 10.3.15 SF_CLIP_VIEWPORT ............................................................................................................ 270 10.3.16 SCISSOR_RECT .................................................................................................................... 271 10.4 Attribute Interpolation Setup ........................................................................................................... 272 10.4.1 Attribute Swizzling .................................................................................................................... 272 10.4.2 1Interpolation Modes ................................................................................................................ 273 10.4.3 Point Sprites ............................................................................................................................. 273 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 5/29/2012 6 10.5 Depth Offset .................................................................................................................................... 274 10.6 Other SF Functions ......................................................................................................................... 274 10.6.1 Statistics Gathering .................................................................................................................. 274 11. 3D Pipeline – Windower (WM) Stage ............................................................................................... 275 11.1 Overview ......................................................................................................................................... 275 11.1.1 Inputs from SF to WM ............................................................................................................... 275 11.2 Windower Pipelined State............................................................................................................... 276 11.2.1 3DSTATE_WM ......................................................................................................................... 276 11.2.2 3DSTATE_PS ........................................................................................................................... 283 11.2.3 3DSTATE_CONSTANT_PS ..................................................................................................... 291 11.2.4 3DSTATE_PUSH_CONSTANT_ALLOC_PS ........................................................................... 292 11.2.5 3DSTATE_SAMPLE_MASK..................................................................................................... 293 11.3 Rasterization ................................................................................................................................... 294 11.3.1 Drawing Rectangle Clipping ..................................................................................................... 295 11.3.2 Line Rasterization ..................................................................................................................... 295 11.3.3 Polygon (Triangle and Rectangle) Rasterization ...................................................................... 300 11.4 Multisampling .................................................................................................................................. 303 11.4.1 Multisample Modes/State ......................................................................................................... 303 11.4.2 3DSTATE_MULTISAMPLE ...................................................................................................... 304 11.5 Early Depth/Stencil Processing ...................................................................................................... 309 11.5.1 Depth Offset.............................................................................................................................. 309 11.5.2 Early Depth Test/Stencil Test/Write.......................................................................................... 310 11.5.3 Hierarchical Depth Buffer ......................................................................................................... 311 11.5.4 Separate Stencil Buffer............................................................................................................. 314 11.5.5 Depth/Stencil Buffer State ........................................................................................................ 315 11.6 Barycentric Attribute Interpolation .................................................................................................. 325 11.7 MCS Buffer for Render Target(s) ................................................................................................... 325 11.8 Render Target Fast Clear ............................................................................................................... 328 11.9 Render Target Resolve................................................................................................................... 328 11.10 Pixel Shader Thread Generation .................................................................................................. 329 11.10.1 Pixel Grouping (Dispatch Size) Control .................................................................................. 329 11.10.2 Multisampling Effects on Pixel Shader Dispatch .................................................................... 332 11.10.3 PS Thread Payload for Normal Dispatch ............................................................................... 336 11.11 Other WM Functions ..................................................................................................................... 349 11.11.1 Statistics Gathering ................................................................................................................ 349 12. 3D Pipeline – Color Calculator (Output Merger)............................................................................. 351 12.1 Overview ......................................................................................................................................... 351 12.1.1 Alpha Coverage ........................................................................................................................ 352 12.1.2 Alpha Test................................................................................................................................. 352 12.1.3 Depth Coordinate Offset ........................................................................................................... 353 12.1.4 Stencil Test ............................................................................................................................... 353 12.1.5 Depth Test ................................................................................................................................ 354 12.1.6 Pre-Blend Color Clamping ........................................................................................................ 354 12.1.7 Color Buffer Blending ............................................................................................................... 355 12.1.8 Post-Blend Color Clamping ...................................................................................................... 357 12.1.9 Dithering ................................................................................................................................... 358 12.1.10 Logic Ops................................................................................................................................ 358 12.1.11 Buffer Update ......................................................................................................................... 359 12.2 Pixel Pipeline State Summary ........................................................................................................ 361 12.2.1 COLOR_CALC_STATE............................................................................................................ 361 12.2.2 DEPTH_STENCIL_STATE....................................................................................................... 362 12.2.3 BLEND_STATE ........................................................................................................................ 366 12.2.4 CC_VIEWPORT ....................................................................................................................... 373 12.3 Other Pixel Pipeline Functions ....................................................................................................... 374 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 5/29/2012 7 12.3.1 Statistics Gathering .................................................................................................................. 374 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 5/29/2012 8 1. 3D Pipeline 1.1 Introduction This section covers the programming details for the 3D fixed functions. 1.2 3D Pipeline Overview 1.2.1 3D Pipeline Stages The following table lists the various stages of the 3D pipeline and describes their major functions. Pipeline Stage Functions Performed Command Stream (CS) The Command Stream stage is responsible for managing the 3D pipeline and passing commands down the pipeline. In addition, the CS unit reads “constant data” from memory buffers and places it in the URB. Note that the CS stage is shared between the 3D and Media pipelines. Vertex Fetch (VF) The Vertex Fetch stage, in response to 3D Primitive Processing commands, is responsible for reading vertex data from memory, reformatting it, and writing the results into Vertex URB Entries. It then outputs primitives by passing references to the VUEs down the pipeline. Vertex Shader (VS) The Vertex Shader stage is responsible for processing (shading) incoming vertices by passing them to VS threads. Hull Shader (HS) The Hull Shader is responsible for processing (shading) incoming patch primitives as part of the tessellation process. Tesselation Engine (TE) The Tessellation Engine is responsible for using tessellation factors (computed in the HS stage) to tessellate U,V parametric domains into domain point topologies. Domain Shader (DS) The Domain Shader stage is responsible for processing (shading) the domain points (generated by the TE stage) into corresponding vertices. Geometry Shader (GS) The Geometry Shader stage is responsible for processing incoming objects by passing each object’s vertices to a GS thread. Stream Output Logic (SOL) The Stream Output Logic is responsible for outputting incoming object vertices into Stream Out Buffers in memory. Clipper (CLIP) The Clipper stage performs Clip Tests on incoming objects and clips objects if required. Objects are clipped using fixed-function hardware. Strip/Fan (SF) The Strip/Fan stage performs object setup. Object setup uses fixed-function hardware. Windower/Masker (WM) The Windower/Masker performs object rasterization and spawns WM thread (aka PS thread) to process (shade) the object pixels. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 9 1.3 3D Primitives Overview The 3DPRIMITIVE command (defined in the VF Stage chapter) is used to submit 3D primitives to be processed by the 3D pipeline. Typically the processing results in the rendering of pixel data into the render targets, but this is not required. Terminology Note: There is considerable confusion surrounding the term ‘primitive’, e.g., is a triangle strip a ‘primitive’, or is a triangle within a triangle strip a ‘primitive’? In this spec, we will try to avoid ambiguity by using the term ‘object’ to represent the basic shapes (point, line, triangle), and ‘topology’ to represent input geometry (strips, lists, etc.). Unfortunately, terms like ‘3DPRIMITIVE’ must remain for legacy reasons. The following table describes the basic primitive topology types supported in the 3D pipeline. Notes:  There are several variants of the basic topologies. These have been introduced to allow slight variations in behavior without requiring a state change.  Number of vertices: o Dangling Vertices: Topologies have an “expected” number of vertices in order to form complete objects within the topologies (e.g., LINELIST is expected to have an even number of vertices). The actual number of vertices specified in the 3DPRIMITIVE command, and as output from the GS unit, is allowed to deviate from this expected number --- in which case any “dangling” vertices are discarded. The removal of dangling vertices is initially performed in the VF unit. In order to filter out dangling vertices emitted by GS threads, the CLIP unit also performs dangling-vertex removal at its input. 3D Primitive Topology Types 3D Primitive Topology Type (ordered alphabetically) Description LINELIST A list of independent line objects (2 vertices per line). Programming Restrictions: Normal usage expects a multiple of 2 vertices, though incomplete objects are silently ignored. LINELIST_ADJ A list of independent line objects with adjacency information (4 vertices per line). Programming Restrictions: Normal usage expects a multiple of 4 vertices, though incomplete objects are silently ignored. Not valid as output from GS thread. LINELOOP Similar to a 3DPRIM_LINESTRIP, though the last vertex is connected back to the initial vertex via a line object. The LINELOOP topology is converted to LINESTRIP topology at the beginning of the 3D pipeline. Programming Restrictions: Normal usage expects at least 2 vertices, though incomplete objects are silently ignored. (The 2-vertex case is required by OGL). Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 10 3D Primitive Topology Type (ordered alphabetically) Description Not valid after the GS stage (i.e., must be converted by a GS thread to some other primitive type). LINESTRIP A list of vertices connected such that, after the first vertex, each additional vertex is associated with the previous vertex to define a connected line object. Programming Restrictions: Normal usage expects at least 2 vertices, though incomplete objects are silently ignored. LINESTRIP_ADJ A list of vertices connected such that, after the first vertex, each additional vertex is associated with the previous vertex to define connected line object. The first and last segments are adjacent–only vertices. Programming Restrictions: Normal usage expects at least 4 vertices, though incomplete objects are silently ignored. Not valid as output from GS thread. LINESTRIP_BF Similar to LINESTRIP, except treated as “backfacing’ during rasterization (stencil test). This can be used to support “line” polygon fill mode when two-sided stencil is enabled. LINESTRIP_CONT Similar to LINESTRIP, except LineStipple (if enabled) is continued (vs. reset) at the start of the primitive topology. This can be used to support line stipple when the API-provided primitive is split across multiple tolopologies. LINESTRIP_CONT_BF Combination of LINESTRIP_BF and LINESTRIP_CONT variations. POINTLIST A list of point objects (1 vertex per point). POINTLIST_BF Similar to POINTLIST, except treated as “backfacing’ during rasterization (stencil test). This can be used to support “point” polygon fill mode when two- sided stencil is enabled. POLYGON Similar to TRIFAN, though the first vertex always provides the “flat- shaded” values (vs. this being programmable through state). Programming Restrictions: Normal usage expects at least 3 vertices, though incomplete objects are silently ignored. QUADLIST A list of independent quad objects (4 vertices per quad). The QUADLIST topology is converted to POLYGON topology at the beginning of the 3D pipeline. Programming Restrictions: Normal usage expects a multiple of 4 vertices, though incomplete Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 11 3D Primitive Topology Type (ordered alphabetically) Description objects are silently ignored. QUADSTRIP A list of vertices connected such that, after the first two vertices, each additional pair of vertices are associated with the previous two vertices to define a connected quad object. Programming Restrictions: Normal usage expects an even number (4 or greater) of vertices, though incomplete objects are silently ignored. : To work around IVB bug #3665983 the driver must detect the use of a QUADSTRIP input topology along with the use of primitive ID in the pixel shader, and correspondingly shift right by 1the primitive ID in the pixel shader. RECTLIST A list of independent rectangles, where only 3 vertices are provided per rectangle object, with the fourth vertex implied by the definition of a rectangle. V0=LowerRight, V1=LowerLeft, V2=UpperLeft. Implied V3 = V0-V1+V2. Programming Restrictions: Normal usage expects a multiple of 3 vertices, though incomplete objects are silently ignored. The RECTLIST primitive is supported specifically for 2D operations (e.g., BLTs and “stretch” BLTs) and not as a general 3D primitive. Due to this, a number of restrictions apply to the use of RECTLIST: Must utilize “screen space” coordinates (VPOS_SCREENSPACE) when the primitive reaches the CLIP stage. The W component of position must be 1.0 for all vertices. The 3 vertices of each object should specify a screen-aligned rectangle (after the implied vertex is computed). Clipping: Must not require clipping or rely on the CLIP unit’s ClipTest logic to determine if clipping is required. Either the CLIP unit should be DISABLED, or the CLIP unit’s Clip Mode should be set to a value other than CLIPMODE_NORMAL. Viewport Mapping must be DISABLED (as is typical with the use of screen-space coordinates). TRIFAN Triangle objects arranged in a fan (or polygon). The initial vertex is maintained as a common vertex. After the second vertex, each additional vertex is associated with the previous vertex and the common vertex to define a connected triangle object . Programming Restrictions: Normal usage expects at least 3 vertices, though incomplete objects are silently ignored. TRIFAN_NOSTIPPLE Similar to TRIFAN, but poylgon stipple is not applied (even if enabled). This can be used to support “point” polygon fill mode, under the combination of the following conditions: (a) when the frontfacing and backfacing polygon fill modes are Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 12 3D Primitive Topology Type (ordered alphabetically) Description different (so the final fill mode is not known to the driver), (b) one of the fill modes is “point” and the other is “solid”, (c) point mode is being emulated by converting the point into a trifan, (d) polygon stipple is enabled. In this case, polygon stipple should not be applied to the points-emulated-as-trifans. TRILIST A list of independent triangle objects (3 vertices per triangle). Programming Restrictions: Normal usage expects a multiple of 3 vertices, though incomplete objects are silently ignored. TRILIST_ADJ A list of independent triangle objects with adjacency information (6 vertices per triangle). Programming Restrictions: Normal usage expects a multiple of 6 vertices, though incomplete objects are silently ignored. Not valid as output from GS thread. TRISTRIP A list of vertices connected such that, after the first two vertices, each additional vertex is associated with the last two vertices to define a connected triangle object. Programming Restrictions: Normal usage expects at least 3 vertices, though incomplete objects are silently ignored. TRISTRIP_ADJ A list of vertices where the even-numbered (including 0th) vertices are connected such that, after the first two vertex pairs, each additional even-numbered vertex is associated with the last two even-numbered vertices to define a connected triangle object. The odd-numbered vertices are adjacent-only vertices. Programming Restrictions: Normal usage expects at least 6 vertices, though incomplete objects are silently ignored. Not valid as output from GS thread. TRISTRIP_REVERSE Similar to TRISTRIP, though the sense of orientation (winding order) is reversed – this allows SW to break long tristrips into smaller pieces and still maintain correct face orientations. PATCHLIST_n List of n-vertex “patch” objects. These topologies cannot be rendered directly – the tessellation units must be utilized to convert them into points, lines or triangles in order to produce rasterization results. (VS, GS and StreamOutput operations can also be performed). The following diagrams illustrate the basic 3D primitive topologies. (Variants are not shown if they have the same definition with respect to the information provided in the diagrams). Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 13 A note on the arrows you see below: These arrows are intended to show the vertex ordering of triangles that are to be considered having “clockwise” winding order in screen space. Effectively, the arrows show the order in which vertices are used in the cross-product (area, determinant) computation. Note that for TRISTRIP, this requires that either the order of odd-numbered triangles be reversed in the cross-product or the sign of the result of the normally-ordered cross-product be flipped (these are identical operations). Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 14 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 15 1.4 3D Pipeline State Overview 1.4.1 3D State Model The locations of the sampler state and viewport state pointers have been moved from the state descriptors to the ring buffer as compared to In addition, the state for the fixed function pipeline has been moved from indirect state descriptors to inline commands. The color calculator state has been repartitioned. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 16 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 17 1.4.2 3DSTATE_CC_STATE_POINTERS 3DSTATE_CC_STATE_POINTERS Length Bias: 2 The 3DSTATE_CC_STATE_POINTERS command is used to set up the pointers to the color calculator state. 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 0Eh 3DSTATE_CC_STATE_POINTERS Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 0h DWORD_COUNT_n Project: All Format: =n 1 31:6 Pointer to COLOR_CALC_STATE Project: All Format: DynamicStateOffset[31:6]COLOR_CALC_STATE Specifies the 64-byte aligned offset of the COLOR_CALC_STATE. This offset is relative to the Dynamic State Base Address. 5:1 Reserved Project: All Format: MBZ 0 Reserved Format: MB0 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 18 1.4.3 3DSTATE_BLEND_STATE_POINTERS 3DSTATE_BLEND_STATE_POINTERS Length Bias: 2 The 3DSTATE_BLEND_STATE_POINTERS command is used to set up the pointers to the color calculator state. 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 24h 3DSTATE_BLEND_STATE_POINTERS Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 0h DWORD_COUNT_n Project: All Format: =n 1 31:6 Pointer to BLEND_STATE Project: All Format: DynamicStateOffset[31:6]BLEND_STATE*8 Specifies the 64-byte aligned offset of the BLEND_STATE. This offset is relative to the Dynamic State Base Address. 5:1 Reserved Project: All Format: MBZ 0 Reserved Format: MB0 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 19 1.4.4 3DSTATE_DEPTH_STENCIL_STATE_POINTERS 3DSTATE_DEPTH_STENCIL_STATE_POINTERS Length Bias: 2 Set up the pointer to the Depth Stencil state. 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 25h 3DSTATE_DEPTH_STENCIL_STATE_POINTERS Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 0h DWORD_COUNT_n Project: All Format: =n 1 31:6 Pointer to DEPTH_STENCIL_STATE Project: All Format: DynamicStateOffset[31:6]DEPTH_STENCIL_STATE Specifies the 64-byte aligned offset of the DEPTH_STENCIL_STATE. This offset is relative to the Dynamic State Base Address. 5:1 Reserved Project: All Format: MBZ 0 Reserved Format: MB0 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 20 1.4.5 3DSTATE_BINDING_TABLE_POINTERS 1.4.5.1 3DSTATE_BINDING_TABLE_POINTERS_VS 3DSTATE_BINDING_TABLE_POINTERS_VS Length Bias: 2 The 3DSTATE_BINDING_TABLE_POINTERS_VS command is used to define the location of fixed functions’ BINDING_TABLE_STATE. Only some of the fixed functions utilize binding tables. 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 26h 3DSTATE_BINDING_TABLE_POINTERS_VS Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 0h DWORD_COUNT_n Project: All Format: =n 1 31:16 Reserved Project: All Format: MBZ 15:5 Pointer to VS Binding Table Format: SurfaceStateOffset[15:5]BINDING_TABLE_STATE*256 Specifies the 32-byte aligned address offset of the VS function’s BINDING_TABLE_STATE. This offset is relative to the Surface State Base Address. 4:0 Reserved Project: All Format: MBZ Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 21 1.4.5.2 3DSTATE_BINDING_TABLE_POINTERS_HS 3DSTATE_BINDING_TABLE_POINTERS_HS Length Bias: 2 The 3DSTATE_BINDING_TABLE_POINTERS_HS command is used to define the location of fixed functions’ BINDING_TABLE_STATE. Only some of the fixed functions utilize binding tables. 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 27h 3DSTATE_BINDING_TABLE_POINTERS_HS Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 0h DWORD_COUNT_n Project: All Format: =n 1 31:16 Reserved Project: All Format: MBZ 15:5 Pointer to HS Binding Table Format: SurfaceStateOffset[15:5]BINDING_TABLE_STATE*256 Specifies the 32-byte aligned address offset of the HS function’s BINDING_TABLE_STATE. This offset is relative to the Surface State Base Address. 4:0 Reserved Project: All Format: MBZ Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 22 1.4.5.3 3DSTATE_BINDING_TABLE_POINTERS_DS 3DSTATE_BINDING_TABLE_POINTERS_DS Length Bias: 2 The 3DSTATE_BINDING_TABLE_POINTERS_DS command is used to define the location of fixed functions’ BINDING_TABLE_STATE. Only some of the fixed functions utilize binding tables. 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 28h 3DSTATE_BINDING_TABLE_POINTERS_DS Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 0h DWORD_COUNT_n Project: All Format: =n 1 31:16 Reserved Project: All Format: MBZ 15:5 Pointer to DS Binding Table Format: SurfaceStateOffset[15:5]BINDING_TABLE_STATE*256 Specifies the 32-byte aligned address offset of the DS function’s BINDING_TABLE_STATE. This offset is relative to the Surface State Base Address. 4:0 Reserved Project: All Format: MBZ Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 23 1.4.5.4 3DSTATE_BINDING_TABLE_POINTERS_GS 3DSTATE_BINDING_TABLE_POINTERS_GS Length Bias: 2 The 3DSTATE_BINDING_TABLE_POINTERS_GS command is used to define the location of fixed functions’ BINDING_TABLE_STATE. Only some of the fixed functions utilize binding tables. 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 29h 3DSTATE_BINDING_TABLE_POINTERS_GS Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 0h DWORD_COUNT_n Project: All Format: =n 1 31:16 Reserved Project: All Format: MBZ 15:5 Pointer to GS Binding Table Format: SurfaceStateOffset[15:5]BINDING_TABLE_STATE*256 Specifies the 32-byte aligned address offset of the GS function’s BINDING_TABLE_STATE. This offset is relative to the Surface State Base Address. 4:0 Reserved Project: All Format: MBZ Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 24 1.4.5.5 3DSTATE_BINDING_TABLE_POINTERS_PS 3DSTATE_BINDING_TABLE_POINTERS_PS Length Bias: 2 The 3DSTATE_BINDING_TABLE_POINTERS_PS command is used to define the location of fixed functions’ BINDING_TABLE_STATE. Only some of the fixed functions utilize binding tables. 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 2Ah 3DSTATE_BINDING_TABLE_POINTERS_PS Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 0h DWORD_COUNT_n Project: All Format: =n 1 31:16 Reserved Project: All Format: MBZ 15:5 Pointer to PS Binding Table Format: SurfaceStateOffset[15:5]BINDING_TABLE_STATE*256 Specifies the 32-byte aligned address offset of the PS function’s BINDING_TABLE_STATE. This offset is relative to the Surface State Base Address. 4:0 Reserved Project: All Format: MBZ Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 25 1.5 3DSTATE_SAMPLER_STATE_POINTERS 1.5.1 1.5.1 3DSTATE_SAMPLER_STATE_POINTERS_VS 3DSTATE_SAMPLER_STATE_POINTERS_VS Length Bias: 2 The 3DSTATE_SAMPLER_STATE_POINTERS_VS command is used to define the location of VS SAMPLER_STATE table. Only some of the fixed functions utilize sampler state tables. 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 2Bh 3DSTATE_SAMPLER_STATE_POINTERS_VS Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 0h DWORD_COUNT_n Format: =n 1 31:5 Pointer to VS Sampler State Project: All Format: DynamicStateOffset[31:5]SAMPLER_STATE*16 Specifies the 32-byte aligned address offset of the VS function’s SAMPLER_STATE table. This offset is relative to the Dynamic State Base Address. 4:0 Reserved Project: All Format: MBZ Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 26 1.5.2 3DSTATE_SAMPLER_STATE_POINTERS_HS 3DSTATE_SAMPLER_STATE_POINTERS_HS Length Bias: 2 The 3DSTATE_SAMPLER_STATE_POINTERS_HS command is used to define the location of HS SAMPLER_STATE table. Only some of the fixed functions utilize sampler state tables. 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 2Ch 3DSTATE_SAMPLER_STATE_POINTERS_HS Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 0h DWORD_COUNT_n Format: =n 1 31:5 Pointer to HS Sampler State Project: All Format: DynamicStateOffset[31:5]SAMPLER_STATE*16 Specifies the 32-byte aligned address offset of the HS function’s SAMPLER_STATE table. This offset is relative to the Dynamic State Base Address. 4:0 Reserved Project: All Format: MBZ Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 27 1.5.3 3DSTATE_SAMPLER_STATE_POINTERS_DS 3DSTATE_SAMPLER_STATE_POINTERS_DS Length Bias: 2 The 3DSTATE_SAMPLER_STATE_POINTERS_DS command is used to define the location of DS SAMPLER_STATE table. Only some of the fixed functions utilize sampler state tables. 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 2Dh 3DSTATE_SAMPLER_STATE_POINTERS_DS Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 0h DWORD_COUNT_n Format: =n 1 31:5 Pointer to DS Sampler State Project: All Format: DynamicStateOffset[31:5]SAMPLER_STATE*16 Specifies the 32-byte aligned address offset of the DS function’s SAMPLER_STATE table. This offset is relative to the Dynamic State Base Address. 4:0 Reserved Project: All Format: MBZ Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 28 1.5.4 3DSTATE_SAMPLER_STATE_POINTERS_GS 3DSTATE_SAMPLER_STATE_POINTERS_GS Length Bias: 2 The 3DSTATE_SAMPLER_STATE_POINTERS_GS command is used to define the location of GS SAMPLER_STATE table. Only some of the fixed functions utilize sampler state tables. 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 2Eh 3DSTATE_SAMPLER_STATE_POINTERS_GS Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 0h DWORD_COUNT_n Format: =n 1 31:5 Pointer to GS Sampler State Project: All Format: DynamicStateOffset[31:5]SAMPLER_STATE*16 Specifies the 32-byte aligned address offset of the GS function’s SAMPLER_STATE table. This offset is relative to the Dynamic State Base Address. 4:0 Reserved Project: All Format: MBZ Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 29 1.5.5 3DSTATE_SAMPLER_STATE_POINTERS_PS 3DSTATE_SAMPLER_STATE_POINTERS_PS Length Bias: 2 The 3DSTATE_SAMPLER_STATE_POINTERS_PS command is used to define the location of PS SAMPLER_STATE table. Only some of the fixed functions utilize sampler state tables. 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 2Fh 3DSTATE_SAMPLER_STATE_POINTERS_PS Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 0h DWORD_COUNT_n Format: =n 1 31:5 Pointer to PS Sampler State Project: All Format: DynamicStateOffset[31:5]SAMPLER_STATE*16 Specifies the 32-byte aligned address offset of the PS function’s SAMPLER_STATE table. This offset is relative to the Dynamic State Base Address. 4:0 Reserved Project: All Format: MBZ Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 30 1.6 3DSTATE_VIEWPORT_STATE_POINTERS 1.6.1 3DSTATE_VIEWPORT_STATE_POINTERS_CC 3DSTATE_VIEWPORT_STATE_POINTERS_CC Length Bias: 2 The 3DSTATE_VIEWPORT_STATE_POINTERS_CC command is used to define the location of fixed functions’ viewport state table. 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 23h 3DSTATE_VIEWPORT_STATE_POINTERS Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 0h DWORD_COUNT_n Format: =n 1 31:5 Pointer to CC_VIEWPORT Project: All Format: DynamicStateOffset[31:5]CC_VIEWPORT*16 Specifies the 32-byte aligned address offset of the CC_VIEWPORT state. This offset is relative to the Dynamic State Base Address. 4:0 Reserved Project: All Format: MBZ Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 31 1.6.2 3DSTATE_VIEWPORT_STATE_POINTERS_SF_CLIP 3DSTATE_VIEWPORT_STATE_POINTERS_SF_CLIP Length Bias: 2 The 3DSTATE_VIEWPORT_STATE_POINTERS_CLIP command is used to define the location of fixed functions’ viewport state table. 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 21h 3DSTATE_VIEWPORT_STATE_POINTERS_SF_CLIP Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 0h DWORD_COUNT_n Format: =n 1 31:6 Pointer to SF_CLIP_VIEWPORT Project: All Format: DynamicStateOffset[31:6]SF_CLIP_VIEWPORT*16 Specifies the 64-byte aligned address offset of the SF_CLIP_VIEWPORT state. This offset is relative to the Dynamic State Base Address. 5:0 Reserved Project: All Format: MBZ Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 32 1.6.3 3DSTATE_SCISSOR_STATE_POINTERS 3DSTATE_SCISSOR_STATE_POINTERS Length Bias: 2 The 3DSTATE_SCISSOR_STATE_POINTERS command is used to define the location of the indirect SCISSOR_RECT state. 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 0Fh 3DSTATE_SCISSOR_STATE_POINTERS Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 0h DWORD_COUNT_n Format: =n 1 31:5 Pointer to SCISSOR_RECT Project: All Format: DynamicStateOffset[31:5]SCISSOR_RECT*16 Specifies the 32-byte aligned address offset of the SCISSOR_RECT state. This offset is relative to the Dynamic State Base Address. 4:0 Reserved Project: All Format: MBZ Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 33 1.7 3DSTATE_URB Commands 1.7.1 3DSTATE_URB_VS 3DSTATE_URB_VS Length Bias: 2 Description Project VS URB Entry Allocation Size equal to 4(5 512-bit URB rows) may cause performance to decrease due to banking in the URB. Element sizes of 16 to 20 should be programmed with six 512-bit URB rows. This command may not overlap with the push constants in the URB defined by the 3DSTATE_PUSH_CONSTANT_ALLOC_VS, 3DSTATE_PUSH_CONSTANT_ALLOC_DS, 3DSTATE_PUSH_CONSTANT_ALLOC_HS, and 3DSTATE_PUSH_CONSTANT_ALLOC_GS commands. Programming Notes 3DSTATE_URB_HS, 3DSTATE_URB_DS, and 3DSTATE_URB_GS must also be programmed in order for the programming of this state to be valid. 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: 0h Format: OpCode 23:16 3D Command Sub Opcode Default Value: 30h 3DSTATE_URB_VS Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 0h DWORD_COUNT_n Project: All Format: =n 1 31 Reserved Format: MBZ 30 Reserved Format: MBZ 29:25 VS URB Starting Address Format: U5 Offset from the start of the URB memory where VS starts its allocation, specified in multiples of 8 KB. Value Name Project Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 34 3DSTATE_URB_VS [0,31] [0,15] 24:16 VS URB Entry Allocation Size Project: All Format: U9-1 count of 512-bit units Specifies the length of each URB entry owned by VS. This field is always used (even if VS Function Enable is DISABLED). Programming Notes Programming Restriction: As the VS URB entry serves as both the per-vertex input and output of the VS shader, the VS URB Allocation Size must be sized to the maximum of the vertex input and output structures. 15:0 VS Number of URB Entries Project: All Format: U16 Specifies the number of URB entries that are used by VS. This field is always used (even if VS Function Enable is DISABLED). Value Name Project [32,704] [32,512] Programming Notes Programming Restriction: VS Number of URB Entries must be divisible by 8 if the VS URB Entry Allocation Size is less than 9 512-bit URB entries.“2:0” = reserved “000b” Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 35 1.7.2 3DSTATE_URB_HS 3DSTATE_URB_HS Length Bias: 2 This command may not overlap with the push constants in the URB defined by the 3DSTATE_PUSH_CONSTANT_ALLOC_VS, 3DSTATE_PUSH_CONSTANT_ALLOC_DS, 3DSTATE_PUSH_CONSTANT_ALLOC_HS, and 3DSTATE_PUSH_CONSTANT_ALLOC_GS commands. Programming Notes 3DSTATE_URB_VS, 3DSTATE_URB_DS, and 3DSTATE_URB_GS must also be programmed in order for the programming of this state to be valid. 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 31h 3DSTATE_URB_HS Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 0h DWORD_COUNT_n Project: All Format: =n 1 31 Reserved Format: MBZ 30 Reserved Format: MBZ 29:25 HS URB Starting Address Format: U5 Offset from the start of the URB memory where HS starts its allocation, specified in multiples of 8 KB. Value Name Project [0,31] [0,15] 24:16 HS URB Entry Allocation Size Project: All Format: U9-1 Count of 512-bit units Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 36 3DSTATE_URB_HS Specifies the length of each URB entry owned by HS. This field is always used (even if HS Function Enable is DISABLED). 15:0 HS Number of URB Entries Project: All Specifies the number of URB entries that are used by HS. This field is always used (even if HS Function Enable is DISABLED). Programming Restriction:HS Number of URB Entries must be divisible by 8 if the HS URB Entry Allocation Size is less than 9 512-bit URB entries.“2:0” = reserved “000” Value Name Project [0,64] [0,32] 1.7.3 3DSTATE_URB_DS 3DSTATE_URB_DS Length Bias: 2 This command may not overlap with the push constants in the URB defined by the 3DSTATE_PUSH_CONSTANT_ALLOC_VS, 3DSTATE_PUSH_CONSTANT_ALLOC_DS, 3DSTATE_PUSH_CONSTANT_ALLOC_HS, and 3DSTATE_PUSH_CONSTANT_ALLOC_GS commands. Programming Notes 3DSTATE_URB_VS, 3DSTATE_URB_HS, and 3DSTATE_URB_GS must also be programmed in order for the programming of this state to be valid. 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 32h 3DSTATE_URB_DS Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 0h DWORD_COUNT_n Project: All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 37 3DSTATE_URB_DS Format: =n 1 31 Reserved Format: MBZ 30 Reserved Format: MBZ 29:25 DS URB Starting Address Format: U5 Offset from the start of the URB memory where DS starts its allocation, specified in multiples of 8 KB. Value Name Project [0,31] [0,15] 24:16 DS URB Entry Allocation Size Project: All Format: U9-1 Count of 512-bit units Specifies the length of each URB entry owned by DS. This field is always used (even if DS Function Enable is DISABLED). Value Name [0,9] 15:0 DS Number of URB Entries Project: All Description Project Specifies the number of URB entries that are used by DS. This field is always used (even if DS Function Enable is DISABLED). If Domain Shader Thread Dispatch is Enabled then the minimum number handles that must be allocated is 138 URB entries. "2:0" = reserved "000" Value Name Project [0,448] [0,288] Programming Notes DS Number of URB Entries must be divisible by 8 if the DS URB Entry Allocation Size is less than 9 512-bit URB entries.If Domain Shader Thread Dispatch is Enabled then the minimum number of handles that must be allocated is 10 URB entries. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 38 1.7.4 3DSTATE_URB_GS 3DSTATE_URB_GS Length Bias: 2 This command may not overlap with the push constants in the URB defined by the 3DSTATE_PUSH_CONSTANT_ALLOC_VS, 3DSTATE_PUSH_CONSTANT_ALLOC_DS, 3DSTATE_PUSH_CONSTANT_ALLOC_HS, and 3DSTATE_PUSH_CONSTANT_ALLOC_GS commands. Programming Notes 3DSTATE_URB_VS, 3DSTATE_URB_HS, and 3DSTATE_URB_DS must also be programmed in order for the programming of this state to be valid. 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 33h 3DSTATE_URB_GS Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 0h DWORD_COUNT_n Project: All Format: =n 1 31 Reserved Format: MBZ 30 Reserved Format: MBZ 29:25 GS URB Starting Address Format: U5 Offset from the start of the URB memory where GS starts its allocation, specified in multiples of 8 KB. Value Name Project [0,31] [0,15] 24:16 GS URB Entry Allocation Size Project: All Format: U9-1 512-bit units Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 39 3DSTATE_URB_GS Specifies the length of each URB entry owned by GS. This field is always used (even if GS Function Enable is DISABLED). 15:0 GS Number of URB Entries Project: All Specifies the number of URB entries that are used by GS. This field is always used (even if GS Function Enable is DISABLED). Programming Restriction: GS Number of URB Entries must be divisible by 8 if the GS URB Entry Allocation Size is less than 9 512-bit URB entries. “2:0” = reserved “000” Value Name Project [0,320] [0,192] 1.7.5 Gather Constants In Dx10 the app can provide up to 16 constant buffers. The compiler does some optimizations of constant usage and determines which elements of which constants should be packed in which push constant register for optimum shader performance. While this gathering and packing of constant elements into push constant registers optimizes the shader, it cause the driver additional work at draw call time, since the driver must do the gather and packing at draw time. A new cmd 3D_STATE_GATHER_CONSTANT_* is added to offload the gather and packing functions from the driver. There are 5 FF which support push constants (VS, GS, DS, HS, PS) and they all have corresponding gather cmds. The compiler generates a gather table which instructs what elements of what buffers should be pack into the gather buffer. The gather table indexes the BT to get the surface state which points to the constant buffer. The resource streamer fills gather buffer when it executes a 3D_STATE_GATHER_CONSTANT_* cmd. Once the gather buffer has been filled, the Cmd streamer will execute the 3D_STATE_CONSTANT_* to load the push constant into the URB. Note: The gather push constants can only be used if the HW generated binding tables are also used. 1.7.6 Dx9 Constant Buffer Generation The Dx9 constant model is a set of register that the App can incrementally update. The HW requires a constant buffer which lives until the last shader using that buffer retires. To offload the driver the 3DSTATE_DX9_CONSTANT*_* cmds are added. These commands allow the on-die constant register to be maintained. When all the edits to the constant register have been completed, the 3DSTATE_DX9_GENERATE_ACTIVE_* cmd is used to write out a constant buffer to the Dx9 Constant buffer pool. The Dx9 constant buffers are fixed 8KB in size, w/ a large portion of the 2 nd 4KB unused. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 40 1.8 Vertex Data Overview The 3D pipeline FF stages (past VF) receive input 3D primitives as a stream of vertex information packets. (These packets are not directly visible to software). Much of the data associated with a vertex is passed indirectly via a VUE handle. The information provided in vertex packets includes:  The URB Handle of the VUE: This is used by the FF unit to refer to the VUE and perform any required operations on it (e.g., cause it to be read into the thread payload, dereference it, etc.).  Primitive Topology Information: This information is used to identify/delineate primitive topologies in the 3D pipeline. Initially, the VF unit supplies this information, which then passes through the VS stage unchanged. GS and CLIP threads must supply this information with each vertex they produce (via the URB_WRITE message). If a FF unit directly outputs vertices (that were not generated by a thread they spawned), that FF unit is responsible for providing this information. o PrimType: The type of topology, as defined by the corresponding field of the 3DPRIMITIVE command. o StartPrim: TRUE only for the first vertex of a topology. o EndPrim: TRUE only for the last vertex of a topology. o The FF unit which owns the VUE o Sequence numbers which uniquely identify (with some limits) the VUE output by the owning FF unit. (This data can be used to trap on a specific vertex)  (Possibly, depending on FF unit) Data read back from the Vertex Header of the VUE. 1.8.1 Vertex URB Entry (VUE) Formats In general, vertex data is stored in Vertex URB Entries (VUEs) in the URB, processed by CLIP threads, and only referenced by the pipeline stages indirectly via VUE handles. Therefore (for the most part) the contents/format of the vertex data is not exposed to 3D pipeline hardware – the FF units are typically only aware of the handles and sizes of VUEs. VUEs are written in two ways:  At the top of the 3D Geometry pipeline, the VF’s InputAssembly function creates VUEs and initializes them from data extracted from Vertex Buffers as well as internally-generated data.  VS, GS, and CLIP threads can compute, format and write new VUEs as thread output. There are only two points in the 3D FF pipeline where the FF units are exposed to the VUE data. Otherwise the VUE remains opaque to the 3D pipeline hardware.  Just prior to the CLIP stage, all VUEs are read-back: o : Optional readback of ClipDistance values (up to 8 floats in an aligned 256-bit URB row)  Just after the CLIP stage, on clip-generated VUEs are read-back: o Readback of the Vertex Header (first 256 bits of the VUE) Software must ensure that any VUEs subject to readback by the 3D pipeline start with a valid Vertex Header. This extends to all VUEs with the following exceptions listed below: Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 41  If the VS function is enabled, the VF-written VUEs are not required to have Vertex Headers, as the VS-incoming vertices are guaranteed to be consumed by the VS (i.e., the VS thread is responsible for overwriting the input vertex data).  If the GS FF is enabled, neither VF-written VUEs nor VS thread-generated VUEs are required to have Vertex Headers, as the GS will consume all incoming vertices.  (There is a pathological case where the CLIP state can be programmed to guarantee that all CLIP- incoming vertices are consumed – regardless of the data read back prior to the CLIP stage – and therefore only the CLIP thread-generated vertices would require Vertex Headers). The following table defines the Vertex Header. The Position fields are described in further detail below. VUE Vertex Header () DWord Bit Description D0 31:0 Reserved: MBZ D1 31:0 Render Target Array Index (RTAIndex). This value is (eventually) used to index into a specific element of an “array” Render Target. It is read back by the GS unit (for all exiting vertices) and the Clip unit (for all clip-generated vertices), subsequently routed into the PS thread payload, and eventually included in the RTWrite DataPort message header for use by the DataPort shared function. Software is responsible for ensuring this field is zero whenever a programmable index value is not required. When a programmable index value is required (e.g. ) software must ensure that the correct 11-bit value is written to this field. Specifically, the kernels must perform a reange check of computed index values against [0,2047], and output zero if that range is exceeded. Note that the unmodified “renderTargetArrayIndex” must be maintained in the VUE outside of the Vertex Header. Software can force an RTAIndex of 0 to be used (effectively ignoring the setting of this DWord) by use of the ForceZeroRTAIndex bit (3DSTATE_CLIP). Otherwise the read-back value will be used to select an RTArray element, after being clamped to the RTArray surface’s [MinimumArrayElement, Depth] range (SURFACE_STATE). Format: 0-based U32 index value D2 31:0 Viewport Index. This value is used to select one of a possible 16 sets of viewport (VP) state parameters in the Clip unit’s VertexClipTest function and in the SF unit’s ViewportMapping and Scissor functions. The GS unit (even if disabled) will read back this value for all vertices exiting the GS stage and entering the Clip stage. When enabled, the GS unit will range-check the value against [0,Maximum VPIndex] (see GS_STATE, CLIP_STATE). After this range-check the values are sent down the pipeline and used in the Clip unit’s VertexClipTest function. For vertices passing through the Clip stage, these values will also be sent to the SF unit for use in ViewportMapping and Scissor functions. The Clip unit (if enabled) will read back this value only for vertices generated by CLIP threads. The Clip unit will perform a range clamp similar to the GS unit. Software can force a value of 0 to be used by programming Maximum VPIndex to 0. Format: 0-based U32 index value D3 31:0 Point Width. This field specifies the width of POINT objects in screen-space pixels. It is used only for vertices within POINTLIST and POINTLIST_BF primitive topologies, and is ignored for vertices associated with other primitive topologies. This field is read back by both the GS and Clip units. Format: FLOAT32 D4 31:0 Vertex Position X Coordinate. This field contains the X component of the vertex’s 4D space position. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 42 DWord Bit Description Format: FLOAT32 D5 31:0 Vertex Position Y Coordinate. This field contains the Y component of the vertex’s 4D space position Format: FLOAT32 D6 31:0 Vertex Position Z Coordinate. This field contains the Z component of the vertex’s NDC space position Format: FLOAT32 D7 31:0 Vertex Position W Coordinate. This field contains the Z component of the vertex’s 4D space position Format: FLOAT32 D8 31:0 ClipDistance 0 Value (optional). If the UserClipDistance Clip Test Enable Bitmask bit (3DSTATE_CLIP) is set, this value will be read from the URB in the Clip stage. If the value is found to be less than 0 or a NaN, the vertex’s UCF<0> bit will set in the Clip unit’s VertexClipTest function. If the UserClipDistance Clip Test Enable Bitmask bit is clear, this value will not be read back, and the vertex’s UCF<0> bit will be zero by definition. Format: FLOAT32 D9 31:0 ClipDistance 1 Value (optional). See above D10 31:0 ClipDistance 2 Value (optional). See above D11 31:0 ClipDistance 3 Value (optional). See above D12 31:0 ClipDistance 4 Value (optional). See above D13 31:0 ClipDistance 5 Value (optional). See above D14 31:0 ClipDistance 6 Value (optional). See above D15 31:0 ClipDistance 7 Value (optional). See above 31:0 (Remainder of Vertex Elements). The absolute maximum size limit on this data is specified via a maximum limit on the amount of data that can be read from a VUE (including the Vertex Header) (Vertex Entry URB Read Length has a maximum value of 63 256-bit units). Therefore the Remainder of Vertex Elements has an absolute maximum size of 62 256-bit units. Of course the actual allocated size of the VUE can and will limit the amount of data in a VUE. 1.8.2 Vertex Positions (For the sake of brevity, the following discussion will use the term map as a shorthand for “compute screen space coordinate via perspective divide followed by viewport transform”.) The “Position” fields of the Vertex Header are the only vertex position coordinates exposed to the 3D Pipeline. The CLIP and SF units are the only FF units which perform operations using these positions. The VUE will likely contain other position attributes for the vertex outside of the Vertex Header, though this information is not directly exposed to the FF units. For example, the Clip Space position will likely be Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 43 required in the VUE (outside of the Vertex Header) in order to perform correct and robust 3D Clipping in the CLIP thread. In the CLIP unit, the read-back Position fields are interpreted as being in one of two coordinate systems, depending on the CLIP_STATE.VertexPositionSpace bit. The CLIP unit will modify its VertexClipTest function depending on the coordinate space of the incoming vertices.  VPOS_CLIPSPACE (Homogeneous 4D Clip-space coordinates, pre-perspective division): The Clip Space position is defined in a homogeneous 4D coordinate space (pre-perspective divide), where the visible “view volume” is defined by the APIs. The API’s VS or GS shader program will include geometric transforms in the computation of this clip space position such that the resulting coordinate is positioned properly in relation to the view volume (i.e., it will include a “view transform” in this computation path). When this coordinate system is selected, the 3D FF pipeline will perform a perspective projection (division of x,y,z by w), perform clip-test on the resulting NDC (Normalized Device Coordinates), and eventually perform viewport mapping (in the SF unit) to yield screen-space (pixel) coordinates.  VPOS_SCREENSPACE (Screen Space position): Under certain circumstances, the position in the Vertex Header will contain the screen-space (pixel) coordinates (post viewport mapping). The SF unit does not have a state bit defining the coordinate space of the incoming vertex positions. Software must use the Viewport Mapping function of the SF unit in order to ensure that screen-space coordinates are available after that function. If screen space coordinates are passed into SF, then software will likely turn off the Viewport Mapping function. The following subsections briefly describe the three relevant coordinate spaces. 1.8.2.1 Clip Space Position The clip-space position of a vertex is defined in a homogeneous 4D coordinate space where, after perspective projection (division by W), the visible “view volume” is some canonical (3D) cuboid. Typically the X/Y extents of this cuboid are [-1,+1], while the Z extents are either [-1,+1] or [0,+1]. The API’s VS or GS shader program will include geometric transforms in the computation of this clip space position such that the resulting coordinate is positioned properly in relation to the view volume (i.e., it will include a “view transform” in this computation path). Note that, under typical perspective projections, the clip-space W coordinate is equal to the view-space Z coordinate. A vertex’s clip-space coordinates must be maintained in the VUE up to 3D clipping, as this clipping is performed in clip space.  In , vertex clip-space positions must be included in the Vertex Header, so that they can be read-back (prior to Clipping) and then subjected to perspective projection (in hardware) and subsequent use by the FF pipeline. 1.8.2.2 NDC Space Position A perspective divide operation performed on a clip-space position yields a [X,Y,Z,RHW] NDC (Normalized Device Coordinates) space position. Here “normalized” means that visible geometry is located within the [-1,+1] or [0,+1] extent view volume cuboid (see clip-space above).  The NDC X,Y,Z coordinates are the clip-space X,Y,Z coordinates (respectively) divided by the clip- space W coordinate (or, more correctly, the clip-space X,Y,Z coordinates are multiplied by the reciprocal of the clip space W coordinate). o Note that the X,Y,Z coordinates may contain INFINITY or NaN values (see below). Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 44  The NDC RHW coordinate is the reciprocal of the clip-space W coordinate and therefore, under normal perspective projections, it is the reciprocal of the view-space Z coordinate. Note that NDC space is really a 3D coordinate space, where this RHW coordinate is retained in order to perform perspective-correct interpolation, etal. Note that, under typical perspective projections. o Note that the RHW coordinate make contain an INFINITY or NaN value (see below). 1.8.2.3 Screen-Space Position Screen-space coordinates are defined as:  X,Y coordinates are in absolute screen space (pixel coordinates, upper left origin). See Vertex X,Y Clamping and Quantization in the SF section for a discussion of the limitations/restrictions placed on screenspace X,Y coordinates.  Z coordinate has been mapped into the range used for DepthTest.  RHW coordinate is actually the reciprocal of clip-space W coordinate (typically the reciprocal of the view-space Z coordinate). 1.9 3D Pipeline Stage Overview The fixed-function (FF) stages of the 3D pipeline share some common functionality, specifically related to the creation and management of threads. This chapter is intended to describe the behavior and programming model of these common functions, in an effort to not replicate this information for each pipeline stage. Stage-specific exceptions to the information provided here will be included in the stage- specific chapters to follow. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 45 1.9.1 Generic 3D FF Unit Block Diagram The following block diagram, in general, applies to the VS, GS and CLIP stages. 1.9.2 1Common 3D FF Unit Functions A major role of the FF stages is in managing the threads that perform the majority of the processing on the vertex/pixel data. (In general, the amount of non-thread processing performed by the 3DPIPE stages increases towards the end of the pipeline.) In a generic sense, the key functions included are:  Bypass Mode  URB Entry Management  Thread Initiation Management  Thread Request Data Generation o Thread Control Information Generation o Thread Payload Header Generation o Thread Payload Data Generation  Thread Output Handling  URB Entry Readback  Statistics Gathering Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 46 The following table lists the various state variables used to control the common FF functions: State Variable Programmed Via Generic Functions Affected Bypass Mode Enable Thread Request Data Gen. Kernel Start Pointer Thread Request Data Gen. GRF Register Block Count Thread Request Data Gen. Single Program Flow Thread Request Data Gen. Thread Priority Thread Request Data Gen. Floating Point Mode Thread Request Data Gen. Exceptions Enable Thread Request Data Gen. Scratch Space Base Pointer Thread Request Data Gen. Per Thread Scratch Space Payload Data Gen. Constant URB Entry Read Length Payload Data Gen. Constant URB Entry Read Offset Payload Data Gen. Vertex URB Entry Read Length Payload Data Gen. Vertex URB Entry Read Offset Payload Data Gen. Dispatch GRF Start Register for URB Data Maximum Number of Thread Resource Alloc. Threads Scratch Space Mgt. URB_FENCE_POINTER URB Entry Mgt. Fence URB Entry Mgt. URB Entry Allocation Size URB Entry Mgt. Number of URB Entries Payload Header Gen. Sampler State Pointer : 3DSTATE_SAMPLER_STATE_POINTERS 3DSTATE_BINDING_TABLE_POINTERS This gets routed directly to shared Binding Table functions (transparent to software). Pointer Thread Request Data Gen. Sampler Count Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 47 State Variable Programmed Via Generic Functions Affected Thread Request Data Gen. Binding Table Entry Count Statistics Gathering Statistics Enable 1.9.3 Thread Initiation Management Those FF stages that can spawn threads must have buffered the input (URB entries) available to supply a thread, and then ensure that there are sufficient resources (within the domain of the 3D pipeline) to make the thread request. Once a FF stage determines a thread request can be submitted, (a) all input data required to initiate the thread is generated, (b) this information is submitted to the common thread dispatcher, (c) the thread dispatcher will spawn the thread as soon as an EU with sufficient GRF resources becomes available, and finally (d) the thread will start execution. With respect to concurrent threads, steps (c) and (d) can proceed out of order (i.e., a threads are not necessarily dispatched in the order that the thread requests are submitted to the thread dispatcher). 1.9.3.1 Thread Input Buffering Each FF stage varies with regard to thread input requirements, and so this will not be discussed in this chapter other than the overview information provided in the following table: FF Stage Thread Input Requirements N/A (does not spawn threads) CS N/A (does not spawn threads) VF Normally, two vertices are buffered before a VS thread is spawned to shade the pair in parallel. VS Under some circumstances (e.g., a flush, state change, etc.) a single vertex will be shaded. All the vertices associated with an object must be buffered before a GS thread can be initiated to GS process the object. Threads spawned as required by the rasterization algorithm. WM 1.9.3.2 Thread Resource Allocation In general, the considerations listed in the preceding section are relevant, with the following exceptions:  CLIP, SF: Threads are not spawned. 1.9.4 Thread Request Generation Once a FF unit determines that a thread can be requested, it must gather all the information required to submit the thread request to the Thread Dispatcher. This information is divided into several categories, as listed below and subsequently described in detail.  Thread Payload Header: This is the first portion of the thread payload passed in the GRF, starting at GRF R0. This is information passed directly from the FF unit. It precedes the Thread Payload Input URB Data. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 48  Thread Payload Input URB Data: This is the second portion of the thread payload. It is read from the URB using entry handles supplied by the FF unit. 1.9.4.1 Thread Control Information The following table describes the various state variables that a FF unit uses to provide information to the Thread Dispatcher and which affect the thread execution environment. Note that this information is not directly passed to the thread in the thread payload (though some fields may be subsequently accessed by the thread via architectural registers). State Variables Included in Thread Control Information State Variable Usage FFs All FFs Kernel Start This field, together with the General State Pointer, specifies the starting location spawning Pointer (1st core instruction) of the kernel program run by threads spawned by this FF unit. threads It is specified as a 64-byte-granular offset from the General State Pointer. Specifies, in 16-register blocks, how many GRF registers are required to run the All FFs GRF Register kernel. The Thread Dispatcher will only seek candidate EUs that have a sufficient spawning Block Count number of GRF register blocks available. Upon selecting a target EU, the Thread threads DIspatcher will generate a logical-to-physical GRF mapping and provide this to the target EU. All FFs Single Specifies whether the kernel program has a single program flow (SIMDnxm with m spawning Program Flow = 1) or multiple program flows (SIMDnxm with m > 1). See CR0 description in ISA (SPF) threads Execution Environment. The Thread Dispatcher will give priority to those thread requests with Thread All FFs Thread Priority of HIGH_PRIORITY over those marked as LOW_PRIORITY. Within these spawning Priority two classes of thread requests, the Thread Dispatcher applies a priority order (e.g., threads round-robin --- though this algorithm is considered a device implementation- dependent detail). All FFs Floating Point This determines the initial value of the Floating Point Mode bit of the EU’s CR0 spawning Mode architectural register that controls floating point behavior in the EU core. (See ISA.) threads This bitmask controls the exception handing logic in the EU. (See ISA.) All FFs Exceptions spawning Enable threads All stages Sampler This is a hint which specifies how many indirect SAMPLER_STATE structures supporting Count should be prefetched concurrent with thread initiation. It is recommended that sampling (VS, software program this field to equal the number of samplers, though there may be some minor performance impact if this number gets large. GS, WM) This value should not exceed the number of samplers accessed by the thread as there would be no performance advantage. Note that the data prefetch is treated as any other memory fetch (with respect to page faults, etc.). All FFs Binding Table This is a hint which specifies how many indirect BINDING_TABLE_STATE spawning Entry Count structures should be prefetched concurrent with thread initiation. (The notes threads included in Sampler Count (above) also apply to this field). 1.9.4.2 Thread Payload Generation FF units are responsible for generating a thread payload – the data pre-loaded into the target EU’s GRF registers (starting at R0) that serves as the primary direct input to a thread’s kernel. The general format of Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 49 these payloads follow a similar structure, though the exact payload size/content/layout is unique to each stage. This subsection describes the common aspects – refer to the specific stage’s chapters for details on any differences. The payload data is divided into two main sections: the payload header followed by the payload URB data. The payload header contains information passed directly from the FF unit, while the payload URB data is obtained from URB locations specified by the FF unit. NOTE: The first 256 bits of the thread payload (the initial contents of R0, aka “the R0 header”) is specially formatted to closely match (and in some cases exactly match) the first 256 bits of thread-generated messages (i.e., the message header) accepted by shared functions. In fact, the send instruction supports having a copy of a GR’s contents (such as R0) used as the message header. Software must take this intention into account (i.e., “don’t muck with R0 unless you know what you’re doing”). This is especially important given the fact that several fields in the R0 header are considered opaque to SW, where use or modification of their contents might lead to UNDEFINED results. The payload header is further (loosely) divided into a leading fixed payload header section and a trailing, variable-sized extended payload header section. In general the size, content and layout of both payload header sections are FF-specific, though many of the fixed payload header fields are common amongst the FF stages. The extended header is used by the FF unit to pass additional information specific to that FF unit. The extended header is defined to start after the fixed payload header and end at the offset defined by Dispatch GRF Start Register for URB Data. Software can cause use the Dispatch GRF Start Register for URB Data field to insert padding into the extended header in order to maintain a fixed offset for the start of the URB data. 1.9.4.2.1 Fixed Payload Header The payload header is used to pass FF pipeline information required as thread input data. This information is a mixture of SW-provided state information (state table pointers, etc.), primitive information received by the FF unit from the FF pipeline, and parameters generated/computed by the FF unit. most of the fields of the fixed header are common between the FF stages. These non-FF-specific fields are described in Fixed Payload Header. Note that a particular stage’s header may not contain all these fields, so they are not “common” in the strictest sense. Fixed Payload Header Fields (non-FF-specific) Fixed Payload Header Field (non-FF-specific) Description FFs Function ID of the FF unit. This value identifies the FF unit within All FFs FF Unit ID the subsystem. The FF unit will use this field (when transmitted spawning in a Message Header to the URB Function) to detect messages threads emanating from its spawned threads. All FFs Snapshot Flag spawning threads All FFs Thread ID spawning threads All FFs Scratch Space Pointer This is the starting location of the thread’s allocated scratch spawning space, specified as an offset from the General State Base Address. Note that scratch space is allocated by the FF unit on threads a per-thread basis, based on the Scratch Space Base Pointer and Per-Thread Scratch Space Size state variables. FF units will assign a thread an arbitrarily-positioned region within this Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 50 Fixed Payload Header Field (non-FF-specific) Description FFs space. The scratch space for multiple (API-visible) entities (vertices, pixels) will be interleaved within the thread’s scratch space. All FFs Dispatch ID This field identifies this thread within the outstanding threads spawning spawned by the FF unit. This field does not uniquely identify the threads thread over any significant period of time. Implementation Note: This field is effectively an “active thread index”. It is used on a thread’s URB allocation request to identify which thread’s handle pool is to source the allocation. It is used upon thread termination to free up the thread’s scratch space allocation. All FFs Binding Table Pointer This field, together with the Surface State Base Pointer, spawning specifies the starting location of the Binding Table used by threads threads spawned by the FF unit. It is specified as a 64-byte- granular offset from the Surface State Base Pointer. See Shared Functions for a description of a Binding Table. All FFs Sampler State Pointer This field, together with the General State Base Pointer, spawning specifies the starting location of the Sampler State Table used threads which by threads spawned by the FF unit. It is specified as a 64-byte- granular offset from the General State Base Pointer. sample (VS, GS, WM) See Shared Functions for a description of a Sampler State Table. All FFs Per Thread Scratch Space This field specifies the amount of scratch space allocated to spawning each thread spawned by the FF unit. threads The driver must allocate enough contiguous scratch space, starting at the Scratch Space Base Pointer, to ensure that the Maximum Number of Threads can each get Per-Thread Scratch Space size without exceeding the driver-allocated scratch space. VS,GS,CLIP,SF Handle ID This ID is assigned by the FF unit and links the thread to a specific entry within the FF unit. The FF unit will use this information upon detecting a URB_WRITE message issued by the thread. Threads spawned by the GS, CLIP, and SF units are provided with a single Handle ID / URB Return Handle pair. Threads spawned by the VS are provided with one or two pairs (depending on how many vertices are to be processed). Threads spawned by the WM do not write to URB entries, and therefore this info is not supplied. VS,GS,CLIP,SF URB Return Handle This is an initial destination URB handle passed to the thread. If the thread does output URB entries, this identifies the destination URB entry. Threads spawned by the GS, CLIP, and SF units are provided with a single Handle ID / URB Return Handle pair. Threads Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 51 Fixed Payload Header Field (non-FF-specific) Description FFs spawned by the VS are provided with one or two pairs (depending on how many vertices are to be processed). Threads spawned by the WM do not write to URB entries, and therefore this info is not supplied. GS, CLIP, SF, Primitive Topology Type As part of processing an incoming primitive, a FF unit is often WM required to spawn a number of threads (e.g., for each individual triangle in a TRIANGLE_STRIP). This field identifies the type of primitive which is being processed by the FF unit, and which has lead to the spawning of the thread. Kernels written to process different types of objects can use this value to direct that processing. E.g., when a CLIP kernel is to provide clipping for all the various primitive types, the kernel would need to examine the Primitive Topology Type to distinguish between point, lines, and triangle clipping requests. NOTE: In general, this field is identical to the Primitive Topology Type assoociated with the primitive vertices as received by the FF unit. Refer to the individual FF unit chapters for cases where the FF unit modifies the value before passing it to the thread. (E.g., certain units perform toggling of TRIANGLESTRIP and TRIANGLESTRIP_REV). 1.9.4.2.2 Extended Payload Header The extended header is of variable-size, where inclusion of a field is determined by FF unit state programming. In order to permit the use of common kernels (thus reducing the number of kernels required), the Dispatch GRF Start Register for URB Data state variable is supported in all FF stages. This SV is used to place the payload URB data at a specific starting GRF register, irrespective of the size of the extended header. A kernel can therefore reference the payload URB data at fixed GRF locations, while conditionally referencing extended payload header information. 1.9.4.2.3 Payload URB Data In each thread payload, following the payload header, is some amount of URB-sourced data required as input to the thread. This data is divided into an optional Constant URB Entry (CURBE), following either by a Primitive URB Entry (WM) or a number of Vertex URB Entries (VS, GS, CLIP, SF). A FF unit only knows the location of this data in the URB, and is never exposed to the contents. For each URB entry, the FF unit will supply a sequence of handles, read offsets and read lengths to the subsystem. The subsystem will read the appropriate 256-bit locations of the URB, optionally perform swizzling (VS only), and write the results into sequential GRF registers (starting at Dispatch GRF Start Register for URB Data). Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 52 State Variables Controlling Payload URB Data State Variable Usage FFs FFs Dispatch GRF This SV identifies the starting GRF register receiving payload URB data. spawning Start Register for Software is responsible for ensuring that URB data does not overwrite the Fixed or threads URB Data Extended Header portions of the payload. Vertex URB This SV specifies the starting offset within VUEs from which vertex data is to be VS, GS, Entry Read read and supplied in this stage’s payloads. It is specified as a 256-bit offset into any t Offset and all VUEs passed in the payload. This SV can be used to skip over leading data in VUEs that is not required by the stage’s threads (e.g., skipping over the Vertex Header data at the SF stage, as that information is not required for setup calculations). Skipping over irrelevant data can only help to improve performance. Specifying a vertex data source extending beyond the end of a vertex entry is UNDEFINED. Vertex URB This SV determines the amount of vertex data (starting at Vertex URB Entry Read Entry Read Offset) to be read from each VUEs and passed into the payload URB data. It is Length specified in 256-bit units. A zero value is INVALID (at very least one 256-bit unit must be read). Specifying a vertex data source extending beyond the end of a VUE is UNDEFINED. Programming Restrictions: (others may already been mentioned)  The maximum size payload for any thread is limited by the number of GRF registers available to the thread, as determined by min( 128, 16 * GRF Register Block Count). Software is responsible for ensuring this maximum size is not exceeded, taking into account: o The size of the Fixed and Extended Payload Header associated with the FF unit. o The Dispatch GRF Start Register for URB Data SV. o The amount of CURBE data included (via Constant URB Entry Read Length) o The number of VUEs included (as a function of FF unit, it’s state programming, and incoming primitive types) o The amount of VUE data included for each vertex (via Vertex URB Entry Read Length) o (For WM-spawned PS threads) The amount of Primitive URB Entry data.  For any type of URB Entry reads: o Specifying a source region (via Read Offset, Read Length) that goes past the end of the URB Entry allocation is illegal.  The allocated size of Vertex/Primitive URB Entries is determined by the URB Entry Allocation Size value provided in the pipeline state descriptor of the FF unit owning the VUE/PUE.  The allocated size of CURBE entries is determined by the URB Entry Allocation Size value provided in the CS_URB_STATE command. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 53 1.9.5 Thread Output Handling Those FF units spawning threads are responsible for monitoring and responding to certain events generated by their spawned threads. Such events are indirectly detected by these FF units monitoring messages sent from threads to the URB Shared Function. By snooping the Message Bus Sideband and Header information, a FF can detect when a particular spawned thread sends a message to the URB function. A subset of this information is then captured and acted upon. Refer to the URB chapter for more details (including a table of valid/invalid combinations of the Complete, Used, Allocate, and EOT bits) The following subsections describe functions that FF units perform as part of Thread Output Handling. 1.9.5.1 VUE Allocation (GS) The following description is applicable only to the GS stage. The threads are not passed an initial handle. Instead, they request a first handle (if any) via the URB shared function’s FF_SYNC message (see Shared Functions). If additional handles are required, the URB_WRITE allocate mechanism (mentioned above) is used. 1.9.5.2 Thread Termination All threads must explicitly terminate by executing a SEND instruction with the EOT bit set. (See EU chapters). When a thread spawned by a 3D FF unit terminates, the spawning FF unit detects this termination as a part of Thread Management. This allows the FF units to manage the number of concurrent threads it has spawned and also manage the resources (e.g., scratch space) allocated to those threads. 1.9.6 VUE Readback Starting with the CLIP stage, the 3D pipeline requires vertex information in addition to the VUE handle. For example, the CLIP unit’s VertexClipTest function needs the vertex position, as does the SF unit’s functions. This information is obtained by the 3D pipeline reading a portion of each vertex’s VUE data directly from the URB. This readback (effectively) occurs immediately before the CLIP VertexClipTest function, and immediately after a CLIP thread completes the output of a destination VUE. The Vertex Header (first 256 bits) of the VUE data is read back. (See the previous VUE Formats subsection (above) for details on the content and format of the Vertex Header.) : Additional Clip/Cull data (located immediately past the Vertex Header) may be read prior to clipping. This readback occurs automatically and is not under software control. The only software implication is that the Vertex Header must be valid at the readback points, and therefore must have been previously loaded or written by a thread. 1.9.7 Statistics Gathering The table below describes how supports the required API statistics counters. DX Statistic HW Support IAVertices = # of vertices IA generated. May or may not VF maintains IA_VERTICES_COUNT. include (a) vertices in partial primitives, (b) unused adjacent- Will include unused adjacent-only vertices. Will not only vertices. Not affected by vertex caching. include vertices in partial primitives. IAPrimitives = # of primitives (objects) IA generated. May or VF maintains IA_PRIMITIVES_COUNT. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 54 DX Statistic HW Support may not include partial primitives. Will not include partial primitives. Will not count patch topologies that do not match what the HS or GS expects as input , if enabled (i.e., mismatching patch topologies are discarded by VF). VSInvocations = # of times VS is executed. May be affected VS maintains VS_INVOCATION_COUNT. by vertex caching. May or may not include (a) shared vertices Impacted by vertex caching. Will not include vertices in non-indexed strips, (b) vertices in partial primitives, (c) in partial primitives. Will include unused adjacent- unused adjacent-only vertices. only vertices. Will not include shared vertices in non- indexed strips, unless pre-empted. Increments even if VS Function Enable is DISABLED. HSInvocations = # of patches executed by HS. HS maintains HS_INVOCATION_COUNT. This gets incremented by 1 for each patch whenever HS is enabled. DSInvocations = # of times DS is executed to shade a DS maintains DS_INVOCATION_COUNT. This is domain point. Allows HW to shade identical domain points incremented for each domain point passed to a DS multiple times, with the exception of point outputs where only thread. unique domain points can be generated. GSInvocations = # of times GS is executed. Obviously does GS maintains GS_INVOCATION_COUNT, not include partial primitives. May be incremented when incrementing it by GSInvocations Increment Value StreamOut enabled, even if NULL_GS. for each dispatched instance. Will not be incremented if NULL_GS. GSPrimitives = # of primitives GS generated. Does not GS maintains GS_PRIMITIVE_COUNT. GS unit will include primitives passing through a disabled GS stage. May increment this as it parses the GS thread output. or may not include partial primitives output by GS. Will not include partial primitives output by GS threads. NumPrimitivesWritten[] = # of complete SOL maintains SO_NUM_PRIMS_WRITTEN[0-3]. primitives written to the stream’s SO buffer, subject to buffer overflow. PrimitiveStorageNeeded[] = # of complete SOL maintains SO_PRIM_STORAGE_NEEDED[0- primitives which would have been written to the stream’s SO 3]. buffer ignoring any overflow. CInvocations = # of primitives entering rasterization (which CL OSB maintains CL_INVOCATION_COUNT. starts with the clipper) and isn’t affected by any actual clipping. Will not include partial primitives. Note that the SOL Does not increment when rasterization is disabled (e.g., when (regardless of SO enabled) will discard primitives if StreamOut is the last enabled stage). May or may not include rendering is disabled, so these primitives will not partial primitives. reach the CL unit. CPrimitives = # of primitives output from clipper. I.e., doesn’t SF OSB maintains CL_PRIMITIVES_COUNT. increment if TrivReject or dropped due to NaNs, increments by Will not include partial primitives. 1 if TrivAccept, or increments by number of primitives generated if MustClip. Does not increment when rasterization is disabled. May or may not include partial primitives. Accomodates infinite or no guardband. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 55 DX Statistic HW Support PSInvocations = # of times PS is executed, including unlit WIZ maintains PS_INVOCATION_COUNT. “helper pixels” within a subspan that need to go through the PS shader to provide 2x2 gradients. Accomodates early depth/stencil. Does not increment if NULL PS. Multisampling: counts pixels shaded If PERPIXEL or samples shaded if PERSAMPLE. Occlusion = # of “visible” multisamples which passed both WIZ & PBE maintain PS_DEPTH_COUNT. depth and stencil testing. Doesn’t include PS-discarded pixels or oMask/AlphaToCoverage-killed samples. Both (a) a disabled test (depth or stencil) and (b) no bound RT or Depth/Stencil buffer conditions count as always passing. 1.10 Synchronization of the 3D Pipeline Two types of synchronizations are supported for the 3D pipe: top of the pipe and end of the pipe. Top of the pipe synchronization really enforces the read-only cache invalidation. This synchronization guarantees that primitives rendered after such synchronization event fetches the latest read-only data from memory. End of the pipe synchronization enforces that the read and/or read-write buffers do not have outstanding hardware accesses. These are used to implement read and write fences as well as to write out certain statistics deterministically with respect to progress of primitives through the pipeline (and without requiring the pipeline to be flushed.) The PIPE_CONTROL command (see details below) is used to perform all of above synchronizations. 1.10.1 Top-of-Pipe Synchronization Top-of-pipe synchronization refers to SW actions to prepare HW for new state-binding at the beginning of the rendering sequence in a given context. HW may have residual states cached in the state-caches and read-only surfaces in various caches. With new rendering sequence, read-only surfaces may go through change in the binding. Hence read-only invalidation is required before such new rendering sequence. Read-only cache invalidation is top-of-pipe synchronization. Upon parsing this specific pipe-control command, HW invalidates all caches in GT domain that have read-only surfaces but does not guarantee invalidation beyond GT caches (i.e. LLC). Further, HW does not guarantee that all prior accesses to those read-only surfaces have completed. Therefore SW must guarantee that there are no pending accesses to those read-only surfaces before initializing the top-of-pipe synchronization. PIPE-CONTROL command described below allows for invalidating individual read-only stream type. It is recommended that driver invalidates only the required caches on the need basis so that cache warm-up overhead can be reduced. 1.10.2 End-of-Pipe Synchronization The driver can use end-of-pipe synchronization to know that rendering is complete (although not necessarily in memory) so that it can de-allocate in-memory rendering state, read-only surfaces, instructions, and constant buffers. An end-of-pipe synchronization point is also sufficient to guarantee that all pending depth tests have completed so that the visible pixel count is complete prior to storing it to memory. End-of-pipe completion is sufficient (although not necessary) to guarantee that read events are complete (a “read fence” completion). Read events are still pending if work in the pipeline requires any type of read except a render target read (blend) to complete. Write synchronization is a special case of end-of-pipe synchronization that requires that the render cache and/or depth related caches are flushed to memory, where the data will become globally visible. This type Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 56 of synchronization is required prior to SW (CPU) actually reading the result data from memory, or initiating an operation that will use as a read surface (such as a texture surface) a previous render target and/or depth/stencil buffer. 1.10.3 Synchronization Actions In order for the driver to act based on a synchronization point (usually the whole point), the reaching of the synchronization point must be communicated to the driver. This section describes the actions that may be taken upon completion of a synchronization point which can achieve this communication. 1.10.3.1 Writing a Value to Memory The most common action to perform upon reaching a synchronization point is to write a value out to memory. An immediate value (included with the synchronization command) may be written. In lieu of an immediate value, the 64-bit value of the PS_DEPTH_COUNT (visible pixel count) or TIMESTAMP register may be written out to memory. The captured value will be the value at the moment all primitives parsed prior to the synchronization commands have been completely rendered, and optionally after all said primitives have been pushed to memory. It is not required that a value be written to memory by the synchronization command. Visible pixel or TIMESTAMP information is only useful as a delta between 2 values, because these counters are free-running and are not to be reset except at initialization. To obtain the delta, two PIPE_CONTROL commands should be initiated with the command sequence to be measured between them. The resulting pair of values in memory can then be subtracted to obtain a meaningful statistic about the command sequence. 1.10.3.2 PS_DEPTH_COUNT If the selected operation is to write the visible pixel count (PS_DEPTH_COUNT register), the synchronization command should include the Depth Stall Enable parameter. There is more than one point at which the global visible pixel count can be affected by the pipeline; once the synchronization command reaches the first point at which the count can be affected, any primitives following it are stalled at that point in the pipeline. This prevents the subsequent primitives from affecting the visible pixel count until all primitives preceding the synchronization point reach the end of the pipeline, the visible pixel count is accurate and the synchronization is completed. This stall has a minor effect on performance and should only be used in order to obtain accurate “visible pixel” counts for a sequence of primitives. The PS_DEPTH_COUNT count can be used to implement an (API/DDI) “Occlusion Query” function. 1.10.3.3 Generating an Interrupt The synchronization command may indicate that a “Sync Completion” interrupt is to be generated (if enabled by the MI Interrupt Control Registers – see Memory Interface Registers) once the rendering of all prior primitives is complete. Again, the completion of rendering can be considered to be when the internal render cache has been updated, or when the cache contents are visible in memory, as selected by the command options. 1.10.3.4 Invalidating of Caches If software wishes to use the notification that a synchronization point has been reached in order to reuse referenced structures (surfaces, state, or instructions), it is not sufficient just to make sure rendering is complete. If additional primitives are initiated after new data is laid over the top of old in memory following a synchronization point, it is possible that stale cached data will be referenced for the subsequent Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 57 rendering operation. In order to avoid this, the PIPE_CONTROL command must be used. (See PIPE_CONTROL Commanddescription below). 1.10.4 PIPE_CONTROL Command The PIPE_CONTROL command is used to effect the synchronization described above. Parsing of a PIPE_CONTROL command stalls 3D pipe only if the stall enable bit is set. Commands after PIPE_CONTROL will continue to be parsed and processed in the 3D pipeline. This may include additional PIPE_CONTROL commands. The implementation does enforce a practical upper limit (8) on the number of PIPE_CONTROL commands that may be outstanding at once. Parsing of a PIPE_CONTROL command that causes this limit to be reached will stall the parsing of new commands until the first of the outstanding PIPE_CONTROL commands reaches the end of the pipe and retires. Note that although PIPE_CONTROL is intended for use with the 3D pipe, it is legal to issue PIPE_CONTROL when the Media pipe is selected. In this case PIPE_CONTROL will stall at the top of the pipe until the Media FFs finish processing commands parsed before PIPE_CONTROL. Post- synchronization operations, flushing of caches and interrupts will then occur if enabled via PIPE_CONTROL parameters. Due to this stalling behavior, only one PIPE_CONTROL command can be outstanding at a time on the Media pipe. For the invalidate operation of the pipe control, the following pointers are affected. The invalidate operation affects the restore of these packets. If the pipe control invalidate operation is completed before the context save, the indirect pointers will not be restored from memory. 1. Pipeline State Pointer 2. Media State Pointer 3. Constant Buffer Packet It is up to software to program the appropriate read-only cache invalidation such as the sampler and constant read caches or the instruction and state caches. Once notification is observed, new data may then be loaded (potentially “on top of” the old data) without fear of stale cache data being referenced for subsequent rendering. If software wishes to access the rendered data in memory (for analysis by the application or to copy it to a new location to use as a texture, for examples), it must also ensure that the write cache (render cache) is flushed after the synchronization point is reached so that memory will be updated. This can be accomplished by setting the Write Cache Flush Enable bit. Note that the Depth Stall Enable bit must be clear in order for the flush of the render cache to occur. Depth Stall Enable is intended only for accurate reporting of the PS_DEPTH counter; the render cache cannot be flushed nor can the read caches be invalidated (except for the instruction/state cache) in conjunction with this operation. 1.10.4.1 PIPE_CONTROL Hardware can support up to 8 pending PIPE_CONTROL flushes 2 Store Data Commands (such as MI_STORE_DATA_IMM or MI_STORE_DATA_INDEX) PIPE_CONTROL w/ stall (20) and TLB inv bit (18) set Ring/Batch Contents - ILLEGAL 3DPRIMITIVE np-state pipelined (bit 20 = ‘0’) PIPE_CONTROL Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 58 Ring/Batch Contents - ILLEGAL np-state 3DPRIMITIVE Ring/Batch Contents - LEGAL 3DPRIMITIVE np-state 3DPRIMITIVE pipelined (bit 20 = ‘0’) PIPE_CONTROL np-state 3DPRIMITIVE  Pipe_control with CS-stall bit set must be issued before a pipe-control command that has the State Cache Invalidate bit set. Caches Invalidated/Flushed by PIPE_CONTROL Bit Settings The table below explains all the different flush/invalidation scenerios. Write non-VF RO pipeline Top of pipe cache Notification Cache VF RO Cache Marker marker Completion invalidate pulse flush Enabled Invalidate Invalidate Sent enable Requested from CS 0 0 0 0 N/A N/A N/A N/A 0 0 0 1 Yes No N/A No 0 0 1 0 No N/A N/A Yes 0 0 1 1 Yes No No Yes X 1 0 X Yes Yes Yes No X 1 1 X Yes Yes Yes Yes 1 X 0 X Yes Yes Yes No 1 X 1 X Yes Yes Yes Yes PIPE_CONTROL Length Bias: 2 The PIPE_CONTROL command is used to effect the synchronization described above. 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: 2h PIPE_CONTROL Format: OpCode 23:16 3D Command Sub Opcode Default Value: 0h PIPE_CONTROL Format: OpCode Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 59 PIPE_CONTROL 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 3h DWORD_COUNT_n Format: =n 1 31:28 Reserved Project: All Format: MBZ 27 Reserved Format: MBZ 26 Reserved Project: All Format: MBZ 25 Reserved Format: MBZ 24 Destination Address Type Defines address space of Destination Address Value Name Description Project 0h PPGTT Use PPGTT address space for DW write All 1h GGTT Use GGTT address space for DW write All Programming Notes Ignored if “”No Write” is selected in Operation. 23 LRI Post-Sync Operation Value Name Description Project 0h No LRI Operation No LRI operation occurs as a result of this instruction. The Post-Sync All Operation field is valid and may be used to specify an operation. 1h MMIO Write Write the DWord contained in Immediate Data Low (DW3) to the All Immediate Data MMIO offset specifed in the Address field. Programming Notes This bit caues a post sync operation with an LRI (Load Register Immediate) operation. If this bit is set then the Post-Sync Operation field must be cleared. 21 Store Data Index Project: All Format: U1 Ring Buffer Mode Scheduling: This field is valid only if the post-sync operation is not 0. If this bit is set, the store data address is actually an index into the global hardware status page. This bit only applies to the Global HW status page. If this field is 1, the Destination Address Type in this command must be set Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 60 PIPE_CONTROL to 1 (GGTT). Execlist Mode Scheduling: This field is valid only if the post-sync operation is not 0. If this bit is set, the store data address is index into the global hardware status page when destination address type in the command is set to 1 (GGTT). The store data address is index into the per-process hardware status page when destination address type in the command is set to 0 (PPGTT). 20 CS Stall Project: All Format: U1 If ENABLED, the sync operation will not occur until all previous flush operations pending a completion of those previous flushes will complete, including the flush produced from this command. This enables the command to act similar to the legacy MI_FLUSH command. Programming Notes Project One of the following must also be set:  Render Target Cache Flush Enable ([12] of DW1)  Depth Cache Flush Enable ([0] of DW1)  Stall at Pixel Scoreboard ([1] of DW1)  Depth Stall ([13] of DW1)  Post-Sync Operation ([13] of DW1) 19 Global Snapshot Count Reset Project: All Format: U1 Value Name Description Project 0h Don’t Do not reset the snapshot counts or Statistics Counters. All Reset 1h Reset Reset the snapshot count for all the units and reset the Statistics Counters All except as noted above. Programming Notes Project TIMESTAMP is not reset by PIPE_CONTROL with this bit set. When Post Sync Operation is set to “Write PS Depth Count” along with Global Snapshot Count Reset, PS Depth Count is Reported first before resetting the value. 18 TLB Invalidate Project: All Format: U1 If ENABLED, all TLBs will be invalidated once the flush operation is complete. Note that if the flush TLB invalidation mode is clear, a TLB invalidate will occur irrespective of this bit setting Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 61 PIPE_CONTROL If ENABLED, PIPE_CONTROL command will flush the in flight data written out by render engine to Global Observation point on flush done. Also Requires stall bit ([20] of DW1) set. Programming Notes Project If ENABLED, all TLBs will be invalidated once the flush operation is complete. Note that if the flush TLB invalidation mode is clear, a TLB invalidate will occur irrespective of this bit setting. 17 Reserved Format: MBZ 16 Generic Media State Clear Format: Disable If set, all generic media state context information will not be included with the next context save, assuming no new state is initiated after the flush. If clear, the generic media state context save state will not be affected. An MI_FLUSH with this bit set should be issued once all the Media Objects that will be processed by a given persistent root thread have been issued or when an MI_SET_CONTEXT switching from a generic media context to a 3D context completes. When using MI_SET_CONTEXT, once state is programmed, it will be saved and restarted as part of any context each time that context is saved/restored until an MI_FLUSH with this bit set is issued in that context. 15:14 Post-Sync Operation Project: All Description Project This field specifies an optional action to be taken upon completion of the synchronization operation. This field must be cleared if the LRI Post-Sync Operation bit is set. Value Name Description Project 0h No Write No write occurs as a result of this instruction. This can be used to All implement a “trap” operation, etc. 1h Write Immediate Write the QWord containing Immediate Data Low, High DWs to the All Data Destination Address 2h Write PS Depth Write the 64-bit PS_DEPTH_COUNT register to the Destination All Count Address 3h Write Timestamp Write the 64-bit TIMESTAMP register to the Destination Address All Programming Notes If executed in non-secure batch buffer, the address given will be in a PPGTT address space. If in a secure ring or batch, address given will be in GGTT space 13 Depth Stall Enable Project: All Format: Enable This bit should be set when obtaining a “visible pixel” count to preclude the possible inclusion in the PS_DEPTH_COUNT value written to memory of some fraction of pixels from objects initiated after the PIPE_CONTROL command. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 62 PIPE_CONTROL Value Name Description Project 0h Disable 3D pipeline will not stall subsequent primitives at the Depth Test stage. All 1h Enable 3D pipeline will stall any subsequent primitives at the Depth Test stage until the All Sync and Post-Sync operations complete. Programming Notes This bit should be DISABLED for operations other than writing PS_DEPTH_COUNT. This bit will have no effect (besides preventing write cache flush) if set in a PIPE_CONTROL command issued to the Media pipe. 12 Render Target Cache Flush Enable Project: All Format: Enable Setting this bit will force Render Cache to be flushed to memory prior to this synchronization point completing. This bit should be set for all write fence sync operations to assure that results from operations initiated prior to this command are visible in memory once software observes this synchronization. Value Name Description Project 0h Disable Flush Render Target Cache is NOT flushed. All 1h Enable Flush Render Target Cache is flushed. All Programming Notes This bit should be DISABLED for End-of-pipe (Read) fences, PS_DEPTH_COUNT or TIMESTAMP queries. This bit must not be set when Depth Stall Enable bit is set in this packet. 11 Instruction Cache Invalidate Enable Project: All Format: Enable Setting this bit is independent of any other bit in this packet. This bit controls the invalidation of the L1 and L2 at the top of the pipe i.e. at the parsing time. 10 Texture Cache Invalidation Enable Project: All Format: Enable Setting this bit is independent of any other bit in this packet. This bit controls the invalidation of the texture caches at the top of the pipe i.e. at the parsing time. 9 Indirect State Pointers Disable Project: All Format: Enable Description Project At the completion of the post-sync operation associated with this pipe control packet, the indirect state pointers in the hardware are considered invalid; the indirect pointers are not saved in the context. If any new indirect state commands are executed in the command stream while the pipe control is pending, the new indirect state commands are preserved. Using Invalidate State Pointer (ISP) only inhibits context restoring of Push Constant Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 63 PIPE_CONTROL (3DSTATE_CONSTANT_*) commands. Push Constant commands are only considered as Indirect State Pointers. Once ISP is issued in a context, SW must initialize by programming push constant commands for all the shaders (at least to zero length) before attempting any rendering operation for the same context. 8 Notify Enable Project: All Format: Enable If ENABLED, a Sync Completion Interrupt will be generated (if enabled by the MI Interrupt Control registers) once the sync operation is complete. See Interrupt Control Registers in Memory Interface Registers for details. 7 PIPE_CONTROL Flush Enable Format: Enable If ENABLED, the PIPE_CONTROL command will wait until all previous writes of immediate data from post sync circles are complete before executing the next command. 5 DC Flush Enable Format: Enable Setting this bit enables flushing of the L3$ portions that caches DC writes. 4 VF(address based) Cache Invalidation Enable Project: All Format: Enable Setting this bit is independent of any other bit in this packet. This bit controls the invalidation of VF address based cache at the top of the pipe i.e. at the parsing time. 3 Constant Cache Invalidation Enable Project: All Format: Enable Setting this bit is independent of any other bit in this packet. This bit controls the invalidation of the constant cache at the top of the pipe i.e. at the parsing time. 2 State Cache Invalidation Enable Project: All Format: Enable Setting this bit is independent of any other bit in this packet. This bit controls the invalidation of the L1 and L2 state caches at the top of the pipe i.e. at the parsing time. 1 Stall At Pixel Scoreboard Project: All Format: Enable Defines the behavior of PIPE_CONTROL command at the pixel scoreboard. Value Name Description Project 0h Disable Stall at the pixel scoreboard is disabled. All 1h Enable Stall at the pixel scoreboard is enabled. All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 64 PIPE_CONTROL Programming Notes This bit should be DISABLED for End-of-pipe (Read) fences, PS_DEPTH_COUNT or TIMESTAMP queries. This bit is ignored if Depth Stall Enable is set. Further the render cache is not flushed even if Write Cache Flush Enable bit is set. 0 Depth Cache Flush Enable Project: All Format: Enable Setting this bit enables flushing (i.e. writing back the dirty lines to memory and invalidating the tags) of depth related caches. This bit applies to HiZ cache, Stencil cache and depth cache. Value Name Description Project 0h Flush Disabled Depth relates caches (HiZ, Stencil and Depth) are NOT flushed. All 1h Flush Enabled Depth relates caches (HiZ, Stencil and Depth) are flushed. All Programming Notes Ideally depth caches need to be flushed only when depth is required to be coherent in memory for later use as a texture, source or honoring CPU lock. This bit should be DISABLED for End-of-pipe (Read) fences, PS_DEPTH_COUNT or TIMESTAMP queries. This bit must not be set when Depth Stall Enable bit is set in this packet. 2 31:2 Address Format: GraphicsAddress[31:2]U32 If Post Sync Operation is set to 1h (LRI Post-Sync Operation must be clear): Bits 31:3 secify the QW address of where the Immediate Data following this DW in the packet to be stored. Bit 2 MBZ Ignored if "No Write" is the selected in Post-Sync Operation If LRI Post-Sync Operation is set: Bits 31:2 specify the MMIO offset destination for the data in the Immediate Data Low (DW3) field. Only DW writes are valid. 1:0 Reserved Project: All Format: MBZ 3 31:0 Immediate Data Project: All Format: U32 This field specifies the Lower DWord value to be written to the targeted location. Only valid when Post- Sync Operation is 1h (Write Immediate Data) or LRI Post-Sync Operation is set. Ignored if Post-Sync Operation is “No write”, “Write PS_DEPTH_COUNT” or “Write TIMESTAMP”. 4 31:0 Immediate Data Project: All Format: U32 This field specifies the Upper DWord value to be written to the targeted location. Only valid when Post- Sync Operation is 1h (Write Immediate Data) Ignored if Post-Sync Operation is “No write”, “Write PS_DEPTH_COUNT”, “Write TIMESTAMP” or “LRI Post Sync Opeation”. 1.10.4.2 Programming Restrictions for PIPE_CONTROL PIPE_CONTROL arguments can be split up into three categories:  Post-sync operations Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 65  Flush Types  Stall Post-sync operation is only indirectly affected by the flush type category via the stall bit. The stall category depends on the both flush type and post-sync operation arguments. A PIPE_CONTROL with no arguments set is Invalid. 1.10.4.2.1 Post-Sync Operation These arguments relate to events that occur after the marker initiated by the PIPE_CONTROL command is completed. The table below shows the restrictions: Arguments Bits Restrictions LRI Post Sync Operation 23 Post Sync Operation ([15:14] of DW1) must be set to 0x0. Global Snapshot Count 19 Requires stall bit ([20] of DW1) set. Reset Generic Media State 16 Requires stall bit ([20] of DW1) set. Clear Indirect State Pointers 9 Requires stall bit ([20] of DW1) set. Disable Store Data Index 21 Post-Sync Operation ([15:14] of DW1) must be set to something other than ‘0’. Sync GFDT 17 Post-Sync Operation ([15:14] of DW1) must be set to something other than ‘0’ or 0x2520[13] must be set. TLB inv 18 Also Requires stall bit ([20] of DW1) set. Post Sync Op 15:14 No Restriction. LRI Post Sync Operation ([23] of DW1) must be set to ‘0’. Notify En 8 No Restriction. 1.10.4.2.2 Flush Types These are arguments related to the type of read only invalidation or write cache flushing is being requested. Note that there is only intra-dependency. That is, it is not affected by the post-sync operation or the stall bit. The table below shows the restrictions. Arguments Bit Restrictions Depth Stall 13 The following bits must be clear  Render Target Cache Flush Enable ([12] of DW1)  Depth Cache Flush Enable ([0] of DW1) 12 Render Target Cache Flush Depth Stall must be clear ([13] of DW1) Depth Cache Flush 0 Depth Stall must be clear ([13] of DW1) Stall Pixel Scoreboard 1 No Restriction Inst invalidate. 11 No Restriction Tex invalidate. 10 No Restriction VF invalidate 4 No Restriction Constant invalidate 3 No Restriction State Invalidate 2 No Restriction Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 66 1.10.4.2.3 \ Stall If the stall bit is set, the command streamer waits until the pipe is completely flushed. Arguments Bit Restrictions 20 Stall Bit [All Stepping][All SKUs]: One of the following must also be set  Render Target Cache Flush Enable ([12] of DW1)  Depth Cache Flush Enable ([0] of DW1)  Stall at Pixel Scoreboard ([1] of DW1)  Depth Stall ([13] of DW1)  Post-Sync Operation ([13] of DW1)  Notify Enable ([8] of DW1) 1.11 Push Constant URB Allocation The push constants are stored into the URB which is part of the L3$. Software is required to program the hardware to allocate space in the URB for each shader push constant. The software is limited to the bottom address of the URB and must ensure that none of the shaders have overlapping handles. Below is a diagram that represents a possible programming of the URB with Push Constants: The sizes of the regions in the diagram will change to 16KB and 80KB, respectively URB Allocation Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 67 In the above scheme we are allocating 16KB of push constants and 240KB of URB space. The handle allocation is shown in the order of the FF pipeline but with the current hardware and state, the software can program these to be any order and may size them to zero. Software may also use some if not all of the 16KB above as handle allocations as long as none of the push constants or handle allocations overlap. The only limitations are the sizes based off the table below and the restrictions in granularity which are specified in the command descriptions of the URB state and the push constant allocation state for each fixed function. Below is a table that specifies the maximum size of each buffer: Max Constant Buffer URB size 16KB 256KB 16KB 128KB Below is a diagram that represents how the hardware may move and store one CONSTANT_BUFFER command for a fixed function shader: Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 68 The bubbles in the URB are caused by the constant buffer in memory starting on a half cacheline and being an even number in length. If the constant buffer starts on an odd cacheline and has an odd number length then there will only be a bubble at the beginning of the buffer in the URB. If the constant buffer in Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 69 memory starts on a cache line boundary and has an odd number length then the bubble will only be at the end of the constant buffer in the URB. Once the constant buffer is written to the GRF space then all the bubbles will be removed. Software must guarantee that there is enough space in the push constant buffer in the URB to hold one constant buffer from memory. This includes any buffering to write the 512b aligned requests from memory into the URB. Because the L3$ only supports writes from memory in 512b chunks, the URB may have some bubbles between each constant buffer fetch. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 70 2. 3D Pipeline – Vertex Fetch (VF) Stage 2.1 Vertex Fetch (VF) Stage Overview The VF stage performs one major function: executing 3DPRIMITIVE commands. This is handled by the VF’s InputAssembly function. The InputAssembly process is closely matched to the Input Assembly function. Minor enhancements have been included to better support OpenGL. The following subsections describe some high-level concepts associated with the VF stage. 2.1.1 Input Assembly The VF’s InputAssembly function includes (for each vertex generated):  Generation of VertexIndex and InstanceIndex for each vertex, possibly via use of an Index Buffer.  Lookup of the VertexIndex in the Vertex Cache (if enabled)  If a cache miss is detected: o Use of computed indices to fetch data from memory-resident vertex buffers o Format conversion of the fetched vertex data o Assembly of the format conversion results (and possibly some internally generated data) to form the complete “input” (raw) vertex o Storing the input vertex data in a Vertex URB Entry (VUE) in the URB o Output of the VUE handle of the input vertex to the VS stage  If a cache hit is detected, the VUE handle from the Vertex Cache is passed to the VS stage (marked as a cache hit to prevent any VS processing). 2.1.1.1 Vertex Assembly The VF utilizes a number of VERTEX_ELEMENT state structures to define the contents and format of the vertex data to be stored in Vertex URB Entries (VUEs) in the URB. See below for a detailed description of the command used to define these structures (3DSTATE_VERTEX_ELEMENTS). Each active VERTEX_ELEMENT structure defines up to 4 contiguous DWords of VUE data, where each DWord is considered a “component” of the vertex element. The starting destination DWord offset of the vertex element in the VUE is specified, and the VERTEX_ELEMENT structures must be defined with monotonically increasing VUE offsets. For each component, the source of the component is specified. The source may be a constant (0, 0x1, or 1.0f), a generated ID (VertexID, InstanceID or PrimitiveID), or a component of a structure in memory (e.g,. the Y component of an XYZW position in memory). In the case of a memory source, the Vertex Buffer sourcing the data, and the location and format of the source data with that VB are specified. The VF’s Vertex Assembly process can be envisioned as the VF unit stepping through the VERTEX_ELEMENT structures in order, fetching and format-converting the source information (if memory resident), and storing the results in the destination VUE. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 71 2.1.2 Vertex Cache The VF stage communicates with the VS stage in order to implement a Vertex Cache function in the 3D pipeline. The Vertex Cache is strictly a performance-enhancing feature and has no impact on 3D pipeline results (other than a few statistics counters). The Vertex Cache contains the VUE handles of VS-output (shaded) vertices if the VS function is enabled, and the VUE handles of VF-output (raw) vertices if the VS function is disabled. (Note that the actual vertex data is held in the URB, and only the handles of the vertices are stored in the cache). In either case, the contents of the cache (VUE handles) are tagged with the VertexIndex value used to fetch the input vertex data. The rationale for using the VertexIndex as the tag is that (assuming no other state or parameters change) a vertex with the same VertexIndex as a previous vertex will have the same input data, and therefore the same result from the VF+VS function. Note that any change to the state controlling the InputAssembly function (e.g., vertex buffer definition), or any change to the state controlling the VS function (if enabled) (e.g., VS kernel), will result in the Vertex Cache being invalidated. In addition, any non-trivial use of instancing (i.e., more than one instance per 3DPRIMITIVE command and the inclusion of instance data in the input vertex) will effectively invalidate the cache between instances, as the InstanceIndex is not included in the cache tag. See Vertex Caching in Vertex Shader for more information on the Vertex Cache (e.g., when it is implicitly disabled, etc.) 2.1.3 Input Data: Push Model vs. Pull Model Given the programmability of the pipeline, and the ability of shaders to input (load/sample) data from memory buffers in an arbitrary fashion, the decision arises in whether to push instance/vertex data into the front of the pipeline or defer the data access (pull) to the shaders that require it. There are tradeoffs involved in deciding between these models. For vertex data, it is probably always better to push the data into the pipeline, as the VF hardware attempts to cover the latency of the data fetch. The decision is less clear for instance data, as pushing instance data leads to larger Vertex URB entries which will be holding redundant data (as the instance data for vertices of an object are by definition the same). Regardless, the GEN 3D pipeline supports both models. 2.1.4 Generated IDs [Note that the generated IDs are considered separate from any offset computations performed by the VF unit, and are therefore described separately here.] The VF generates InstanceID, VertexID, and PrimitiveID values as part of the InputAssembly process. VertexID and InstanceID are only allowed to be inserted into the input vertex data as it is gathered and written into the URB as a VUE. The definition/use of PrimitiveID is more complicated than the other auto-generated IDs. PrimitiveID is associated with an “object” , not a particular vertex. It is only available to the GS (: and HS) as a special non-vertex input, and the PS as a constant-interpolated attribute. It is not seen by the VS (or DS) at all. The PrimitiveID therefore is kept separate from the vertex data. Take for example a TRILIST primitive topology: It should be possible to share vertices between triangles in the list (i.e., reuse the VS output of a vertex), even though each triangle has a different PrimitiveID associated with it. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 72 2.1.4.1 Generated IDs The InstanceID, VertexID, and PrimitiveID values associated with each vertex can be stored in the vertex's VUE, via use of the Component n Control fields in the VERTEX_ELEMENT structure. This makes the values available to the VS thread. While the PrimitiveID can still be stored in the VUE (see above), there should be no API-specific reason to do so. The 32-bit PrimitiveIDs associated with objects are passed down the FF pipeline and made available to GS and Setup threads as payload header data. A side effect of this feature is that the vertex cache can operate even when PrimitiveIDs are being used. 2.2 Index Buffer (IB) The 3DSTATE_INDEX_BUFFER command is used to define an Index Buffer (IB) used in subsequent 3DPRIMITIVE commands. The RANDOM access mode of the 3DPRIMITIVE command involves the use of a memory-resident IB. The IB, defined via the 3DSTATE_INDEX_BUFFER command described below, contains a 1D array of 8, 16 or 32-bit index values. These index values will be fetched by the InputAssembly function, and subsequently used to compute locations in VERTEXDATA buffers from which the actual vertex data is to be fetched. (This is opposed to the SEQUENTIAL access mode were the vertex data is simply fetched sequentially from the buffers). Software is responsible for ensuring that accesses outside the IB do not occur. This is possible as software can compute the range of IB values referenced by a 3DPRIMITIVE command (knowing the StartVertexLocation, InstanceCount, and VerticesPerInstance values) and can then compare this range to the IB extent. 2.2.1 3DSTATE_INDEX_BUFFER 3DSTATE_INDEX_BUFFER Source: RenderCS Length Bias: 2 This command is used to specify the current IB state used by the VF function. At most one IB is defined and active at any given time. NOTES: The IB must be specified before any RANDOM 3D_PRIMITIVE commands are issued It is possible to have vertex elements source completely from generated ID values and therefore not require any Index Buffer accesses. In this case, VF function will simply ignore the Index Buffer state. 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: 0h 3DSTATE_PIPELINED Format: OpCode Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 73 3DSTATE_INDEX_BUFFER 23:16 3D Command Sub Opcode Default Value: 0Ah 3DSTATE_INDEX_BUFFER Format: OpCode 15:12 Index Buffer Object Control State Format: MEMORY_OBJECT_CONTROL_STATE Specifies the memory object control state for this index buffer. 11 Reserved Project: All Format: MBZ 10 Cut Index Enable Format: Enable If ENABLED, the largest index value (0xFF,0xFFFF,0xFFFFFFFF, depending on Index Format) is interpreted as the “cut” index. (See description of this elsewhere in this section). (Expected OpenGL driver usage)This field can only be enabled for certain primitive topology types. Refer to the table later in this section for details. 9:8 Index Format Project: All Format: U2 enumerated type This field specifies the data format of the index buffer. All index values are UNSIGNED. Value Name Project 0h INDEX_BYTE All 1h INDEX_WORD All 2h INDEX_DWORD All 7:0 DWord Length Default Value: 1h Excludes DWord (0,1) Project: All Format: =n Total Length – 2 1 31:0 Buffer Starting Address Project: All Format: GraphicsAddress[31:0]Index_Buffer_Entry This field contains the size-aligned (as specified by Index Format) Graphics Address of the first element of interest within the index buffer.Software must program this value with the combination (sum) of the base address of the memory resource and the byte offset from the base address to the starting structure within the buffer. Programming Notes Index Buffers can only be allocated in linear (not tiled) graphics memory 2 31:0 Buffer Ending Address Project: All Format: GraphicsAddress[31:0] If non-zero, this field contains the address of the last valid byte in the index buffer. Any index buffer reads past this address returns an index value of 0 (as if the index buffer was zero-extended). Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 74 3DSTATE_INDEX_BUFFER Software must guarantee that the buffer ends on an index boundary (e.g., for an INDEX_DWORD buffer, Bits [1:0] == 11b). Errata Description Project Software needs to disable the index buffer by setting Index Buffer Start address AFTER Index Buffer End address for draws where the starting index location is greater than the index buffer size. The following table lists which primitive topology types support the presence of Cut Indices. When 3DSTATE_INDEX_BUFFER has Cut Index Enable set,it is UNDEFINED to issue a 3DPRIMITIVE with a primitive topology type not supporting a Cut Index (even if no cut indices are actually present in the index buffer. Definition Cut Index? 3DPRIM_POINTLIST Y 3DPRIM_LINELIST Y 3DPRIM_LINESTRIP Y 3DPRIM_TRILIST Y 3DPRIM_TRISTRIP Y 3DPRIM_TRIFAN N 3DPRIM_QUADLIST N 3DPRIM_QUADSTRIP N 3DPRIM_LINELIST_ADJ Y 3DPRIM_LINESTRIP_ADJ Y 3DPRIM_TRILIST_ADJ Y 3DPRIM_TRISTRIP_ADJ Y 3DPRIM_TRISTRIP_REVERSE Y 3DPRIM_POLYGON N 3DPRIM_RECTLIST N 3DPRIM_LINELOOP N 3DPRIM_POINTLIST_BF Y 3DPRIM_LINESTRIP_CONT Y 3DPRIM_LINESTRIP_BF Y 3DPRIM_LINESTRIP_CONT_BF Y 3DPRIM_TRIFAN_NOSTIPPLE N 3DPRIM_PATCHLIST_n Y Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 75 2.2.2 Index Buffer Access The following figure illustrates how the Index Buffer is accessed. 2.3 Vertex Buffers (VBs) The 3DSTATE_VERTEX_BUFFERs and 3DSTATE_INSTANCE_STEP_RATE commands are used to define Vertex Buffers (VBs) used in subsequent 3DPRIMITIVE commands. Most input vertex data is sourced from memory-resident VBs. A VB is a 1D array of structures, where the size of the structure as defined by the VB’s BufferPitch. VBs are accessed either as VERTEXDATA buffers or INSTANCEDATA buffers, as defined by the VB’s BufferAccessType. The VB’s access type will determine whether the VF-computed VertexIndex or InstanceIndex is used to access data in the VB. Given that the RANDOM access mode of the 3DPRIMITIVE command utilizes an IB (possibly provided by an application) to compute VB index values, VB definitions contain a MaxIndex value used to detect accesses beyond the end of the VBs. Any access outside the extent of a VB returns 0. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 76 2.3.1 3DSTATE_VERTEX_BUFFERS 3DSTATE_VERTEX_BUFFERS Source: RenderCS Length Bias: 2 This command is used to specify VB state used by the VF function. This command can specify from 1 to 33 VBs. The VertexBufferID field within a VERTEX_BUFFER_STATE structure indicates the specific VB. If a VB definition is not included in this command, its associated state is left unchanged and is available for use if previously defined. Programming Notes It is possible to have individual vertex elements sourced completely from generated ID values and therefore not require any vertex buffer accesses for that vertex element. In this case, VF function will simply ignore the VB state associated with that vertex element. If all enabled vertex elements have this characteristic, no VBs are required to process 3DPRIMITIVE commands. For example, this might arise when the user wants to perform all data lookups in the first shader, so only generated index values need to be passed down to it. In this extreme case, SW would not need to program any VB state, and therefore not need to issue any 3DSTATE_VERTEX_BUFFERS commands. For any 3DSTATE_VERTEX_BUFFERS command, at least one VERTEX_BUFFER_STATE structure must be included. VERTEX_BUFFER_STATE structures are 4 DWords for both VERTEXDATA buffers and INSTANCEDATA buffers. Inclusion of partial VERTEX_BUFFER_STATE structures is UNDEFINED. The order in which VBs are defined within this command can be arbitrary, though a vertex buffer must be defined only once in any given command (otherwise operation is UNDEFINED). DWord Bit Description 0 31:29 Instruction Type Default Value: 03h GFXPIPE Format: Opcode 28:27 Instruction Sub-Type Default Value: 3h 3D Format: Opcode 26:24 Instruction Opcode Default Value: 0h 3DSTATE_VERTEX_BUFFERS Format: Opcode 23:16 Instruction Sub-Opcode Default Value: 08h 3DSTATE_VERTEX_BUFFERS Format: Opcode 15:8 Reserved 7:0 DWord Count Default Value: 3 DWORD_COUNT_n Format: =n n = 4b-1 (where b = # of buffer states included) 1..n 127:0 Vertex Buffer State [n] Format: VERTEX_BUFFER_STATE Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 77 2.3.2 VERTEX_BUFFER_STATE Structure VERTEX_BUFFER_STATE Source: RenderCS Default Value: 0x00000000, 0x00000000, 0x00000000, 0x00000000 This structure is used in 3DSTATE_VERTEX_BUFFERS to set the state associated with a VB. The VF function will use this state to determine how/where to extract vertex element data for all vertex elements associated with the VB. The VERTEX_BUFFER_STATE structure is 4 DWords for both INSTANCEDATA and VERTEXDATA buffers.A VB is defined as a 1D array of vertex data structures, accessed via a computed index value. The VF function therefore needs to know the starting address of the first structure (index 0) and size of the vertex data structure. Programming Notes Project Vertex element accesses which straddle or go past the VB’s End Address will return 0’s for all elements. DWord Bit Description 0 31:26 Vertex Buffer Index Format: U6 Index This field contains an index value which selects the VB state being defined. Value Name [0,32] 25:21 Reserved Project: All Format: MBZ 20 Buffer Access Type This field determines how vertex element data is extracted from this VB. This control applies to all vertex elements associated with this VB. Value Name Description Project 00b VERTEXDATA For SEQUENTIAL vertex access, each vertex of an instance is All sourced from sequential structures within the VB. For RANDOM vertex access, each vertex of an instance is looked up (separately) via a computed index value 01b INSTANCEDATA Each vertex of an instance is sourced with the same (instance) All data. Subsequent instances may be sourced with the same or different data, depending on Instance Data Step Rate. 19:16 Vertex Buffer Memory Object Control State Project: All Format: MEMORY_OBJECT_CONTROL_STATE Specifies the memory object control state for this vertex buffer. 15 Reserved Project: All Format: MBZ 14 Address Modify Enable If set, the Buffer Starting Address and End Address fields are used to update the state of this buffer. If Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 78 VERTEX_BUFFER_STATE clear, those fields are ignored and the previously-programmed values are maintained. 13 Null Vertex Buffer Format: Enable This field enabled causes any fetch for vertex data to return 0. 12 Vertex Fetch Invalidate Default Value: 0h Invalidate the Vertex overfetch cache when this bit is set. For multiple vertex buffer state structures in one packet, this bit may be set only once in the entire packet. 11:0 Buffer Pitch Format: U12 Count of bytes This field specifies the pitch in bytes of the structures accessed within the VB. This information is required in order to access elements in the VB via a structure index. Value Name Description Project [0,2048] Bytes Programming Notes  Different VERTEX_BUFFER_STATE structures can refer to the same memory region using different Buffer Pitch values.  See note on 64-bit float alignment in Buffer Starting Address. 31:0 Buffer Starting Address 1 Format: GraphicsAddress[31:0] Description Project This field contains the byte-aligned Graphics Address of the first element of interest within the VB. Software must program this value with the combination (sum) of the base address of the memory resource and the byte offset from the base address to the starting structure within the buffer. If the Address ModifyEnable bit is clear, this field is ignored and the previous value of Buffer Starting Address for this buffer is maintained. Programming Notes 64-bit floating point values must be 64-bit aligned in memory, or UNPREDICTABLE data will be fetched. When accessing an element containing 64-bit floating point values, the Buffer Starting Address and Source Element Offset values must add to a 64-bit aligned address, and BufferPitch must be a multiple of 64-bits. VBs can only be allocated in linear (not tiled) graphics memory. As computed index values are, by definition, interpreted as unsigned values, there is no issue with Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 79 VERTEX_BUFFER_STATE accesses to locations before (lower address value) the start of the buffer. However, these wrapped indices are subject to Max Index checking (see below). 2 31:0 End Address Format: GraphicsAddress[31:0]U32 Description Project This field defines the address of the last valid byte in this particular VB. Access of a vertex element which either straddles or is beyond this address will return 0’s for any data read. If the Address ModifyEnable bit is clear, this field is ignored and the previous value of End Address for this buffer is maintained. Value Name [0,FFFFFFFFh] 0h [Default] 3 31:0 Instance Data Step Rate Format: U32 This field only applies to INSTANCEDATA buffers – it is ignored (but still present) for VERTEXDATA buffers). This field determines the rate at which instance data for this particular INSTANCEDATA vertex buffer is changed in sequential instances. Only after the number of instances specified by this field is generated is new (sequential) instance data provided. This process continues for each group of instances defined in the draw command. For example, a value of 1 in this field causes new instance data to be supplied with each sequential (instance) group of vertices. A value of 2 causes every other instance group of vertices to be provided with new instance data. The special value of 0 causes all vertices of all instances generated by the draw command to be provided with the same instance data. (The same effect can be achieved by setting this field to its maximum value.) Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 80 2.3.3 VERTEXDATA Buffers – SEQUENTIAL Access Instead of “VBState.StartingBufferAddress + VBState.MaxIndex x VBState.BufferPitch”, the address of the byte immediately beyond the last valid byte of the buffer is determined by “VBState.EndAddress+1”. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 81 2.3.4 VERTEXDATA Buffers – RANDOM Access Instead of “VBState.StartingBufferAddress + VBState.MaxIndex x VBState.BufferPitch”, the address of the byte immediately beyond the last valid byte of the buffer is determined by “VBState.EndAddress+1”. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 82 2.3.5 INSTANCEDATA Buffers Instead of “VBState.StartingBufferAddress + VBState.MaxIndex x VBState.BufferPitch”, the address of the byte immediately beyond the last valid byte of the buffer is determined by “VBState.EndAddress+1”. 2.4 Input Vertex Definition The 3DSTATE_VERTEX_ELEMENTS command is used to define the source and format of input vertex data and the format of how it is stored in the destination VUE as part of 3DPRIMITIVE processing in the VF unit. Refer to 3DPRIMITIVE Processing below for the general flow of how input vertices are input and stored during processing of the 3DPRIMITIVE command. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 83 2.4.1 3DSTATE_VERTEX_ELEMENTS 3DSTATE_VERTEX_ELEMENTS Source: RenderCS Length Bias: 2 This is a variable-length command used to specify the active vertex elements (up to 34) Each VERTEX_ELEMENT_STATE structure contains a Valid bit which determines which elements are used. Programming Notes Project At least one VERTEX_ELEMENT_STATE structure must be included. Inclusion of partial VERTEX_ELEMENT_STATE structures is UNDEFINED. SW must ensure that at least one vertex element is defined prior to issuing a 3DPRIMTIVE command, or operation is UNDEFINED. There are no ‘holes’ allowed in the destination vertex: NOSTORE components must be overwritten by subsequent components unless they are the trailing DWords of the vertex. Software must explicitly chose some value (probably 0) to be written into DWords that would otherwise be ‘holes’. Within a VERTEX_ELEMENT_STATE structure, if a Component Control field is set to something other than VFCOMP_STORE_SRC, no higher-numbered Component Control fields may be set to VFCOMP_STORE_SRC. In other words, only trailing components can be set to something other than VFCOMP_STORE_SRC. (See additional restrictions listed in the command fields and VERTEX_ELEMENT_STATE description). Element[0] must be valid. All elements must be valid from Element[0] to the last valid element. (i.e. if Element[2] is valid then Element[1] and Element[0] must also be valid) The pitch between elements packed in the URB will always be 128 bits. DWord Bit Description 0 31:29 Instruction Type Default Value: 03h GFXPIPE Format: Opcode 28:27 Instruction Sub-Type Default Value: 3h 3D Format: Opcode 26:24 Instruction Opcode Default Value: 0h 3DSTATE_VERTEX_ELEMENTS Format: Opcode 23:16 Instruction Sub-Opcode Default Value: 09h 3DSTATE_VERTEX_ELEMENTS Format: Opcode 15:8 Reserved 7:0 DWord Count Format: =n Vertex Element Count = (DWord Count + 1) / 2 Value Name Description Project 1 DWORD_COUNT_n [Default] excludes DWords 0,1 [0,66] Range 1-34 Elements 1..n 63:0 Element [n] Format: VERTEX_ELEMENT_STATE Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 84 2.4.2 VERTEX_ELEMENT_STATE Structure VERTEX_ELEMENT_STATE Project: All Source: RenderCS Default Value: 0x00000000, 0x00000000 This structure is used in 3DSTATE_VERTEX_ELEMENTS to set the state associated with a vertex element. A vertex element is defined as an entity supplying from 1 to 4 DWord vertex components to be stored in the vertex URB entry. The number of supported vertex elements is: 34 The VF function will use this state, and possibly the state of the associated vertex buffer, to fetch/generate the source vertex element data, perform any required format conversions, padding with zeros, and store the resulting destination vertex element data into the vertex URB entry. DWord Bit Description 0 31:26 Vertex Buffer Index Format: U6 This field specifies which vertex buffer the element is sourced from. Value Name [0,32] Up to 33 VBs are supported Programming Notes It is possible for a vertex element to include only internally-generated data (VertexID, etc.), in which case the associated vertex buffer state is ignored. 25 Valid Format: Boolean Value Name Description Project 1h TRUE this vertex element is used in vertex assembly All 0h FALSE this vertex element is not used. All 24:16 Source Element Format Project: All Format: SURFACE_FORMAT Range: Valid encodings are those marked as “Y” in the “Vertex Buffer” column of the table of Surface Format encodings in the Sampler chapter. Format: The encoding of this field is identical the Surface Format field of the SURFACE_STATE structure, as described in the Sampler chapter. This field specifies the format in which the memory-resident source data for this particular vertex element is stored in the memory buffer. This only applies to elements stored with VFCOMP_STORE_SRC component control. (All other component types have an explicit format). 15 Edge Flag Enable Format: Enable Description Project When ENABLED, the source element is interpreted as an EdgeFlag for the vertex. If the source element is zero, the EdgeFlag will be set to FALSE. If the source element is non-zero, Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 85 VERTEX_ELEMENT_STATE the EdgeFlag will be set to TRUE. The EdgeFlag bit will travel down the fixed function pipeline along with the vertex handle, etc. and not be stored in the vertex data like the other vertex elements. Refer to the fixed function descriptions for how this EdgeFlag affects rendering. Edge flags are supported for the following primitive topology types only, otherwise EdgeFlagEnable must not be ENABLED.  3DPRIM_TRILIST*  3DPRIM_TRISTRIP*  3DPRIM_TRIFAN*  3DPRIM_POLYGON If this bit is DISABLED for all valid VERTEX_ELEMENTs, the vertex will be assigned a default EdgeFlag of TRUE. EdgeFlagEnable must not be ENABLED for 3DPRIM_TRISTRIP* and 3DPRIM_TRIFAN* Edge flags are supported for all primitive topology types. Programming Notes Project  This bit must only be ENABLED on the last valid VERTEX_ELEMENT structure.  When set, Component 0 Control must be set to VFCOMP_STORE_SRC, and Component 1-3 Control must be set to VFCOMP_NOSTORE. Edge Flags are not supported for QUADLIST primitives. Software may elect to convert QUADLIST primitives to some set of corresponding edge-flag-supported primitive types (e.g., POLYGONs) prior to submission to the 3D pipeline. 14:11 Reserved Project: All Format: MBZ 10:0 Source Element Offset (in bytes) Project: All Format: U11 byte offset Byte offset of the source vertex element data in the structures comprising the vertex buffer. Value Name [0,2047] Programming Notes See note on 64-bit float alignment in Buffer Starting Address. 1 31 Reserved Project: All Format: MBZ 30:28 Component 0 Control Project: All Format: 3D_VertexComponentControl Refer to the 3D_VertexComponentControl table below 27 Reserved Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 86 VERTEX_ELEMENT_STATE Project: All Format: MBZ 26:24 Component 1 Control Format: 3D_VertexComponentControl Refer to the 3D_VertexComponentControl table below 23 Reserved Project: All Format: MBZ 22:20 Component 2 Control Format: 3D_VertexComponentControl Refer to the 3D_VertexComponentControl table below 19 Reserved Project: All Format: MBZ 18:16 Component 3 Control Format: 3D_VertexComponentControl Refer to the 3D_VertexComponentControl table below 15:8 Reserved Project: All Format: MBZ 7:0 Reserved Format: MBZ 3D_VertexComponentControl Project: All Source: RenderCS Size (in bits): 3 Value Name Description Project 0 VFCOMP_NOSTORE Don’t store this component. (Not valid for Component 0, but can be All used for Component 1-3). Once this setting is used for a component, all higher-numbered components (if any) MUST also use this setting. (I.e., no holes within any particular vertex element). Also, there are no ‘holes’ allowed in the destination vertex: NOSTORE components must be overwritten by subsequent components unless they are the trailing DWords of the vertex. Software must explicitly chose some value (probably 0) to be written into DWords that would otherwise be ‘holes’. 1 VFCOMP_STORE_SRC Store corresponding component from format-converted source All element. Storing a component that is not included in the Source Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 87 3D_VertexComponentControl Element Format results in an UNPREDICTABLE value being stored. Software should used the STORE_0 or STORE_1 encoding to supply default components.Within a VERTEX_ELEMENT_STATE structure, if a Component Control field is set to something other than VFCOMP_STORE_SRC, no higher-numbered Component Control fields may be set to VFCOMP_STORE_SRC. In other words, only trailing components can be set to something other than VFCOMP_STORE_SRC. 2 VFCOMP_STORE_0 Store 0 (interpreted as 0.0f if accessed as a float value) All 3 VFCOMP_STORE_1_FP Store 1.0f All 4 VFCOMP_STORE_1_INT Store 0x1 All 5 VFCOMP_STORE_VID Store Vertex ID (as U32) 6 VFCOMP_STORE_IID Store Instance ID (as U32) 7 VFCOMP_STORE_PID Store Primitive ID (as U32)Software should no longer need to use All this encoding as PrimitiveID is passed down the FF pipeline – see explanation above. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 88 2.4.3 Vertex Element Data Path The following diagram shows the path by which a vertex element within the destination VUE is generated and how the fields of the VERTEX_ELEMENT_STATE structure is used to control the generation. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 89 2.5 3D Primitive Processing 2.5.1 3D PRIMITIVE Command 3DPRIMITIVE Source: RenderCS Length Bias: 2 The 3DPRIMITIVE command is used to submit 3D primitives to be processed by the 3D pipeline. Typically the processing results in rendering pixel data into the render targets, but this is not required. The parameters passed in this command are forwarded to the Vertex Fetch function. The Vertex Fetch function will use this information to generate vertex data structures and store them in the URB. These vertices are then passed down the 3D pipeline. Programming Notes Project If the threads spawned by this command are required to observe memory writes performed by threads spawned from a previous command, software must precede this command with a command that performs a (preferably pipelined) memory flush (e.g., 3D_PIPECONTROL). Workloads enabling topology filter using MI_TOPOLOGY_FILTER must always program PIPECONTROL command with only Post-Sync Operation (Write Immediate data) prior to every 3DPRIMTIVE command programmed. 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: 3h 3DPRIMITIVE Format: OpCode 23:16 3D Command Sub Opcode Default Value: 0h 3DPRIMITIVE Format: OpCode 15:11 Reserved Project: All Format: MBZ 10 Indirect Parameter Enable Project: All Format: U1 If set, the values in DW 2-5 are ignored and replaced by the current values of the corresponding 3DPRIM_xxx MMIO registers:  3DPRIM_VERTEX_COUNT (instead of DW2: VertexCountPerInstance)  3DPRIM_START_VERTEX (instead of DW3: StartVertexLocation)  3DPRIM_INSTANCE_COUNT (instead of DW4: InstanceCount)  3DPRIM_START_INSTANCE (instead of DW5: StartInstanceLocation) Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 90 3DPRIMITIVE  3DPRIM_BASE_VERTEX (instead of DW6: BaseVertexLocation) Indirect Parameter Enable and End Offset Enable must not be ENABLED at the same time, or behavior is UNDEFINED. 9 Reserved Format: MBZ 8 Predicate Enable Project: All Format: Enable If set, this command is executed (or not) depending on the current value of the MI Predicate internal state bit. This command is ignored only if PredicateEnable is set and the Predicate state bit is 0. 7:0 DWord Length Default Value: 5h Excludes DWord (0,1) Project: All Format: =n Total Length - 2 1 31:10 Reserved Project: All Format: MBZ 9 End Offset Enable Project: All Format: Enable If set, the Vertex Count Per Instance field is IGNORED, and the VB0ENDOFFSET register is used to indirectly specify the vertex count by defining the amount of valid data in VB0. The following restrictions apply:  VB0 must be enabled for use  VertexAccessType = SEQUENTIAL  Instance Count = 1  Start Vertex Location = 0  Start Instance Location = 0  Base Vertex Location = 0 Vertices are output until EndOffset is reached or exceeded in VB0. If EndOffset is reached or exceeded within the data associated with a vertex, that vertex is considered incomplete and will not be output. Partial objects will be discarded (as is normally done). If clear, End Offset is ignored. Indirect Parameter Enable and End Offset Enable must not be ENABLED at the same time, or behavior is UNDEFINED. 8 Vertex Access Type Project: All Format: VertexAccessType Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 91 3DPRIMITIVE This field specifies how data held in vertex buffers marked as VERTEXDATA is accessed by Vertex Fetch. Value Name Description Project 0h SEQUENTIAL VERTEXDATA buffers are accessed sequentiallyRequiref if End All Offset Enable is ENABLED. 1h RANDOM VERTEXDATA buffers are accessed randomly via an index All obtained from the Index Buffer. 7:6 Reserved Project: All Format: MBZ 5:0 Primitive Topology Type Project: All Format: 3D_PrimTopoType See table below for encoding, see 3D Overview for diagrams and general comments This field specifies the topology type of 3D primitive generated by this command. Note that a single primitive topology (list/strip/fan/etc.) can contain a number of basic objects (lines, triangles, etc.). 2 31:0 Vertex Count Per Instance Project: All Format: U32 Count of vertices Format: GraphicsAddress[31:0]U32*1 This field specifies how many vertices are to be generated for each instance of the primitive topology. If End Offset Enable is clear: Format = U32 count of vertices Range = [0, 2^32-1] (upper limit probably constrained by VB size) Ignored if End Offset Enable or Indirect Parameter Enable is ENABLED. Programming Notes  This per-instance value should specify a valid number of vertices for the primitive topology type. E.g., for 3DPRIM_TRILIST_ADJ, this field should specify a multiple of 6 vertices. However, in cases where too few or too many vertices are provided, the unused vertices will be silently discarded by the pipeline.  A 0 value is this field effectively makes the command a ‘no-operation’. 3 31:0 Start Vertex Location Project: All Format: U32 structure index This field specifies the “starting vertex” for each instance. This allows skipping over part of the vertices in a buffer if, for example, a previous 3DPRIMITIVE command had already drawn the primitives associated with the earlier entries. For SEQUENTIAL access, this field specifies, for each instance, a starting structure index into the vertex buffers For RANDOM access, this field specifies, for each instance, a starting index into the Index Buffer. Programming Notes  Access of any data outside of the valid extent of a vertex or index buffer will return the value 0 (i.e., appears as if the data stored at the invalid location was 0). Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 92 3DPRIMITIVE  Must be set to 0 if End Offset Enable is ENABLED.  Ignored if Indirect Parameter Enable is ENABLED 4 31:0 Instance Count Project: All Format: U32 Count of instances Description Project This field specifies the number of instances by which the primitive topology is to be regenerated. A value of 0 indicates “no instances” (no-op operation). A value of 1 effectively specifies “non-instanced” operation, though vertex buffers will still be used to provide instance data, if so programmed. Ignored if Indirect Parameter Enable is ENABLED. Must be set to 1 if End Offset Enable is ENABLED. Value Name [0,FFFFFFFFh] 5 31:0 Start Instance Location Project: All Format: U32 structure index Description Project This field specifies the “starting instance” for the command as an initial structure index into INSTANCEDATA buffers. Subsequent instances will access sequential instance data structures, as controlled by the Instance Data Step Rate. Programming Notes  Access of any data outside of the valid extent of a vertex or index buffer will return the value 0 (i.e., appears as if the data stored at the invalid location was 0).  Must be set to 0 if End Offset Enable is ENABLED.  Ignored if Indirect Parameter Enable is ENABLED. 6 31:0 Base Vertex Location Project: All Format: S31 index structure bias This field specifies a signed bias to be added to values read from the index buffer. This allows the same index buffer values to access different vertex data for different commands.This field applies only to RANDOM access mode. This field is ignored for SEQUENTIAL access mode, where there Start Vertex Location can be used to specify different regions in the vertex buffers. Programming Notes Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 93 3DPRIMITIVE  Access of any data outside of the valid extent of a vertex or index buffer will return the value 0 (i.e., appears as if the data stored at the invalid location was 0).  Must be set to 0 if End Offset Enable is ENABLED.  Ignored if Indirect Parameter Enable is ENABLED. 2.5.2 Functional Overview The following pseudocode summarizes the general flow of 3D Primitive Processing. CommandInit InstanceLoop{ VertexLoop{ VertexIndexGeneration if (CutFlag) TerminatePrimitive else OutputBufferedVertex VertexCacheLookup if (miss) { VertexElementLoop { SourceElementFetch FormatConversion DestinationComponentSelection PrimitiveInfoGeneration URBWrite } } } TerminatePrimitive } 2.5.3 CommandInit The InstanceID value is initialized to 0. 2.5.4 InstanceLoop The InstanceLoop is the outmost loop, iterating through each instance of primitives. There is no special “non-instanced” mode – at a minimum there is one instance of primitives. For SEQUENTIAL accessing, the VertexID value is initialized to 0 at the start of each instance. (For RANDOM accessing, there is no initial value for VertexID, as it is derived from the fetched IB value). The PrimitiveID is also initialized to 0 at the start of each instance. StartPrim is initialized to TRUE. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 94 The VertexLoop (see below) is then executed to iterate through the instance vertices and output vertices to the pipeline as required. The end of each iteration of InstanceLoop includes an implied “cut” operation. The InstanceID value is incremented at the end of each InstanceLoop. Note that each instance will produce the same vertex outputs with the exception of any data dependent on InstanceID (i.e., “instance data”). 2.5.5 VertexLoop The VertexLoop iterates VertexNumber through the VertexCountPerInstance vertices for the instance. For each iteration, a number of processing steps are performed (see below) to generate the information that comprises a vertex. Note that, due to CutProcessing, each iteration does not necessarily output a vertex to the pipeline. When a vertex is to be output, the following information is generated for that vertex:  PrimitiveType associated with the vertex. This is simply a copy of the PrimitiveTopologyType field of the 3DPRIMITIVE  VUE handle at which the vertex data is stored o For a Vertex Cache hit, the VUE handle is marked with a VCHit boolean, so that the VS unit will not attempt to process (shade) that vertex. o Otherwise, the VertexLoop will generate and store the input vertex data into the VUE referenced by this handle.  The PrimitiveID associated with the vertex. See PrimitiveInfoGeneration.  PrimStart and PrimEnd booleans associated with the vertex. See PrimitiveInfoGeneration. (Note that a single vertex of buffering is required in order to associate PrimEnd with a vertex, as this information may not be known until the next iteration through the VertexLoop (see OutputPrimitiveDelimiter). VertexNumber value is incremented by 1 at the end of the loop. 2.5.6 VertexIndexGeneration A VertexIndex value needs to be derived for each vertex. With the exception of the “cut” index, this index value is used as the vertex cache tag and will be used as a structure index into all VERTEXDATA VBs. For SEQUENTIAL accessing, the VertexID and VertexIndex value is derived as shown below: VertexIndex = StartVertexLocation + VertexNumber VertexID = VertexNumber For RANDOM access, the VertexID and VertexIndex is derived from an IBValue read from the IB, as shown below: IBIndex = StartVertexLocation + VertexNumber VertexID = IB[IBIndex] if (CutIndexEnable && VertexID == CutIndex) CutFlag = 1 else VertexIndex = VertexID + BaseVertexLocation Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 95 CutFlag = 0 endif 2.5.7 TerminatePrimitive For RANDOM accessing, and when enabled via Cut Index Enable, a fetched IBValue of ‘all ones’ (0xFF, 0xFFFF, or 0xFFFFFFFF depending on Index Format) is interpreted as a ‘cut value’ and signals the termination of the current primitive and the possible start of the next primitive. This allows the application to specify an instance as a sequence of variable-sized strip primitives (though the cut value applies to any primitive type). Also, there is an implied primitive termination at the end of each InstanceLoop (and so strip primitives cannot span multiple instances). In either case, the currently-buffered vertex (if any) is marked with EndPrim and then flushed out to the pipeline. The next-output vertex (if any) will be marked with StartPrim. Whenever a primitive delimiter is encountered, the PIDCounterS and PIDCounterR counters are reset to 0. These counters control the incrementing (in PrimitiveInfoGeneration, below) of PrimitiveID within each primitive topology of an instance. if (PIDCounterS != 0) // There is a buffered vertex if (primType == TRISTRIP_ADJ) if (PIDCounterS==6 || PIDCounterR==1) PrimitiveID++ endif endif PrimEnd = TRUE OutputBufferedVertex endif PrimEnd = FALSE PrimStart = TRUE 2.5.8 VertexCacheLookup The VertexIndex value is used as the tag value for the VertexCache (see Vertex Cacheabove). If the Vertex Cache is enabled and the VertexIndex value hits in the cache, the VUE handle is read from the cache and inserted into the vertex stream. It is marked with a VCHit boolean to surpress processing (shading) in the VS unit. Otherwise, for Vertex Cache misses, a VUE handle is obtained to provide storage for the generated vertex data. VertexLoop processing then proceeds to iterate through the VEs to generate the destination VUE data. 2.5.9 VertexElementLoop The VertexElementLoop generates and stores vertex data in the destination VUE one VE at a time. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 96 2.5.10 SourceElementFetch The following assumes the VE requires data from a VB, which is the typical case. In the case that the VE is completely comprised of constant and/or auto-generated IDs, the SourceElementFetch and FormatConversion steps are skipped. The structure index within the VE’s selected VB is computed as follows: if (VB is a VERTEXDATA VB) VBIndex = VertexIndex else // INSTANCEDATA VB VBIndex = StartInstanceLocation if (VB.InstanceDataStepRate > 0) VBIndex += InstanceID/VB.InstanceDataStepRate endif If VBIndex is invalid (i.e., negative or past Max Index), the data returned from the VB fetch is defined to be zero. Otherwise, the address of the source data required for the VE is then computed and the data is read from the VB. The amount of data read from the VB is determined by the Source Element Format. if ( (VBIndex<0) || (VBIndex>VB.MaxIndex) ) srcData = 0 else pSrcData = VB.BufferStartingAddress + (VBIndex * VB.BufferPitch) + VE.SourceElementOffset srcData = MemoryRead( pSrcData, VE.SourceElementFormat ) endif 2.5.11 Format Conversion Once the VE source data has been fetched, it is subjected to format conversion. The output of format conversion is up to 4 32-bit components, each either integer or floating-point (as specified by the Source Element Format). See Sampler for conversion algorithms. The following table lists the valid Source Element Format selections, along with the format and availability of the converted components (if a component is listed as “-“, it cannot be used as source of a VUE component). Note: This table is a subset of the list of supported surface formats defined in the Sampler chapter. Please refer to that table as the “master list”. This table is here only to identify the components available (per format) and their format. Source Element Formats supported in VF Unit Source Element Converted Component Surface Format Name Format 0 1 2 3 R32G32B32A32_FLOAT FLOAT R G B A R32G32B32A32_SINT SINT R G B A R32G32B32A32_UINT UINT R G B A Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 97 Source Element Converted Component Surface Format Name Format 0 1 2 3 R32G32B32A32_UNORM FLOAT R G B A R32G32B32A32_SNORM FLOAT R G B A R64G64_FLOAT FLOAT R G - - R32G32B32A32_SSCALED FLOAT R G B A R32G32B32A32_USCALED FLOAT R G B A R32G32B32_FLOAT FLOAT R G B - R32G32B32_SINT SINT R G B - R32G32B32_UINT UINT R G B - R32G32B32_UNORM FLOAT R G B - R32G32B32_SNORM FLOAT R G B - R32G32B32_SSCALED FLOAT R G B - R32G32B32_USCALED FLOAT R G B - R16G16B16A16_UNORM FLOAT R G B A R16G16B16A16_SNORM FLOAT R G B A R16G16B16A16_SINT SINT R G B A R16G16B16A16_UINT UINT R G B A R16G16B16A16_FLOAT FLOAT R G B A R32G32_FLOAT FLOAT R G - - R32G32_SINT SINT R G - - R32G32_UINT UINT R G - - R32G32_UNORM FLOAT R G - - R32G32_SNORM FLOAT R G - - R64_FLOAT FLOAT R - - - R16G16B16A16_SSCALED FLOAT R G B A R16G16B16A16_USCALED FLOAT R G B A R32G32_SSCALED FLOAT R G - - R32G32_USCALED FLOAT R G - - B8G8R8A8_UNORM FLOAT B G R A R10G10B10A2_UNORM FLOAT R G B A R10G10B10A2_UINT UINT R G B A R10G10B10_SNORM_A2_UNORM FLOAT R G B A R8G8B8A8_UNORM FLOAT R G B A R8G8B8A8_SNORM FLOAT R G B A R8G8B8A8_SINT SINT R G B A R8G8B8A8_UINT UINT R G B A R16G16_UNORM FLOAT R G - - R16G16_SNORM FLOAT R G - - R16G16_SINT SINT R G - - R16G16_UINT UINT R G - - R16G16_FLOAT FLOAT R G - - R11G11B10_FLOAT FLOAT R G B - R32_SINT SINT R - - - R32_UINT UINT R - - - R32_FLOAT FLOAT R - - - R32_UNORM FLOAT R - - - R32_SNORM FLOAT R - - - R10G10B10X2_USCALED FLOAT R G B - R8G8B8A8_SSCALED FLOAT R G B A R8G8B8A8_USCALED FLOAT R G B A Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 98 Source Element Converted Component Surface Format Name Format 0 1 2 3 R16G16_SSCALED FLOAT R G - - R16G16_USCALED FLOAT R G - - R32_SSCALED FLOAT R - - - R32_USCALED FLOAT R - - - R8G8_UNORM FLOAT R G - - R8G8_SNORM FLOAT R G - - R8G8_SINT SINT R G - - R8G8_UINT UINT R G - - R16_UNORM FLOAT R - - - R16_SNORM FLOAT R - - - R16_SINT SINT R - - - R16_UINT UINT R - - - R16_FLOAT FLOAT R - - - R8G8_SSCALED FLOAT R G - - R8G8_USCALED FLOAT R G - - R16_SSCALED FLOAT R - - - R16_USCALED FLOAT R - - - R8_UNORM FLOAT R - - - R8_SNORM FLOAT R - - - R8_SINT SINT R - - - R8_UINT UINT R - - - R8_SSCALED FLOAT R - - - R8_USCALED FLOAT R - - - R8G8B8_UNORM FLOAT R G B - R8G8B8_SNORM FLOAT R G B - R8G8B8_SSCALED FLOAT R G B - R8G8B8_USCALED FLOAT R G B - R64G64B64A64_FLOAT FLOAT R G B A R64G64B64_FLOAT FLOAT R G B A R16G16B16_FLOAT FLOAT R G B - R16G16B16_UNORM FLOAT R G B - R16G16B16_SNORM FLOAT R G B - R16G16B16_SSCALED FLOAT R G B - R16G16B16_USCALED FLOAT R G B - 2.5.12 DestinationFormatSelection The Component Select 0..3 bits are then used to select, on a per-component basis, which destination components will be written and with which value. The supported selections are the converted source component, VertexID, InstanceID, PrimitiveID, the constants 0 or 1.0f, or nothing (VFCOMP_NO_STORE). If a converted component is listed as ‘-‘ (not available) in FormatConversion, it must not be selected (via VFCOMP_STORE_SRC), or an UNPREDICTABLE value will be stored in the destination component. The selection process sequences from component 0 to 3. Once a Component Select of VFCOMP_NO_STORE is encountered, all higher-numbered Component Select settings must also be programmed as VFCOMP_NO_STORE. It is therefore not permitted to have ‘holes’ in the destination VE. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 99 2.5.13 PrimitiveInfoGeneration A PrimitiveID value and PrimStart boolean need to be associated with the vertex. If the vertex is either the first vertex of an instance or the first vertex following a ‘cut index’, the vertex is marked with PrimStart. PrimitiveID gets incremented such that subsequent per-object processing (i.e., in the GS or SF/WM) will see an incrementing value associated with each sequential object within an instance. The PrimitiveID associated with the provoking, non-adjacent vertex of an object is applied to the object. The following pseudocode describe the logic used in the VertexLoop to compute the PrimitiveID value associated with the vertex. Recall that PrimitiveID is reset to 0 at the start of each InstanceLoop. if (PIDCounterS < S[primType]) PIDCounterS++ else if (PIDCounterR < R[primType]) PIDCounterR++ else PrimitiveID++ PIDCounterR = 0 endif endif Two counters are employed to control the incrementing of PrimitiveID. The counters are compared against two corresponding parameters associated with the primitive topology type. The PIDCounterS is used to ‘skip over’ some number (possibly zero) initial vertices of the primitive topology. This counter gets reset to 0 after each primitive is terminated. Then the PIDCounterR is used to periodically increment the PrimitiveID, where the incrementing interval (vertex count) is topology-specific. The following table lists the S[] and R[] values associated with each primitive topology type. PrimTopologyType S, R PrimitiveID Outputs 1, 0 0,1,2,3, .. POINTLIST POINTLIST_BF LINELIST 1, 1 0,0,1,1,2,2,3,3, .. LINELIST_ADJ 1, 3 0,0,0,0,1,1,1,1,2,2,2,2,3,3,3,3 .. 2, 0 0,0,1,2,3, .. LINESTRIP LINESTRIP_BF LINESTRIP_CONT LINESTRIP_ADJ 3, 0 0,0,1,2,3,.. Note: this breaks the usage model (as the initial vertex is the provoking vertex for the closing line, but it has an invalid PrimitiveID of 0), but is effectively a don’t care as PrimitiveID is only required for LINELOOP is an OpenGL-only primitive.) The LINELOOP topology is converted to LINESTRIP topology Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 100 PrimTopologyType S, R PrimitiveID Outputs at the beginning of the 3D pipeline. 1, 2 0,0,0,1,1,1,2,2,2,3,3,3,.. TRILIST RECTLIST TRILIST_ADJ 1, 5 0,0,0,0,0,0,1,1,1,1,1,1,2,2,2,2,2,2,.. TRISTRIP TRISTRIP_REV 3, 0 0,0,0,1,2,3, .. TRISTRIP_ADJ 5, 1 0,0,0,0,0,0,1,1,2,2,3,3, .. 3, 0 0,0,0,1,2,3, .. TRIFAN TRIFAN_NOSTIPPLE POLYGON QUADLIST 1, 3 0,0,0,0,1,1,1,1,2,2,2,2,3,3,3,3, .. Note: The QUADLIST topology is converted to POLYGON topology at the beginning of the 3D pipeline. QUADSTRIP 3, 1 0,0,0,0,1,1,2,2,3,3, .. Note: The QUADSTRIP topology is converted to POLYGON topology at the beginning of the 3D pipeline. PATCHLIST_n 1,n-1 PATCHLIST_1: 0,1,2,3, .. PATCHLIST_2: 0,0,1,1,2,2,3,3 .. and so on. 2.5.14 URBWrite The selected destination components are written into the destination VUE starting at Destination Offset Select. See the description of 3DPRIMITIVE for restrictions on this field. 2.5.15 OutputBufferedVertex In order to accommodate ‘cut’ processing, the VF unit buffers one output vertex. The generation of a new vertex or the termination of a primitive causes the buffered vertex to be output to the pipeline. 2.6 Dangling Vertex Removal The last functional stage of processing of the 3DPRIMITIVE command is the removal of “dangling” vertices. This includes the discarding of primitive topologies without enough vertices for a single object (e.g., a TRISTRIP with only two vertices), as well as the discarding of trailing vertices that do not form a complete primitive (e.g., the last two vertices of a 5-vertex TRILIST). This function is best described as a filter operating on the vertex stream emitted from the processing of the 3DPRIMITIVE. The filter inputs the PrimType, PrimStart and PrimEnd values associated with the generated vertices. The filter only outputs primitive topologies without dangling vertices. This requires the filter to (a) be able to buffer some number of vertices, and (b) be able to remove dangling vertices from the pipeline and dereference the associated VUE handles. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 101 2.7 Other Vertex Fetch Functionality 2.7.1 Statistics Gathering 3DSTATE_VF_STATISTICS Source: RenderCS Length Bias: 1 The VF stage tracks two pipeline statistics, the number of vertices fetched and the number of objects generated. VF will increment the appropriate counter for each when statistics gathering is enabled by issuing the 3DSTATE_VF_STATISTICS command with the [Statistics Enable] bit set. DWord Bit Description 0 31:29 Instruction Type Default Value: 03h GFXPIPE Format: Opcode 28:27 Instruction Sub-Type Format: Opcode Value Name Project 1h Pipelined, Single DWord [Default] 26:24 Instruction Opcode Default Value: 0h 3DSTATE_VF_STATISTICS Format: Opcode GFXPIPE[28:27 = 1h, 26:24 = 0h, 23:16 = 0Bh] (Pipelined, Single DWord) 23:16 Instruction Sub-Opcode Default Value: 0Bh 3DSTATE_VF_STATISTICS Format: Opcode GFXPIPE[28:27 = 1h, 26:24 = 0h, 23:16 = 0Bh] (Pipelined, Single DWord) 15:1 Reserved Format: MBZ 0 Statistics Enable Format: Enable If ENABLED, VF will increment the pipeline statistics counters IA_VERTICES_COUNT and IA_PRIMITIVES_COUNT for each vertex fetched and each object output, respectively, for 3DPRIMITIVE commands issued subsequently. If DISABLED, these counters will not be incremented for subsequent 3DPRIMITIVE commands. 2.7.1.1 Vertices Generated VF will increment the IA_VERTICES_COUNT Register (see Memory Interface Registers in Volume Ia, GPU) for each vertex it fetches, even if that vertex comes from a cache rather than directly from a vertex buffer in memory. Any “dangling” vertices (fetched vertices that are part of an incomplete object) will not be included. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 102 2.7.1.2 Objects Generated VF will increment the IA_PRIMITIVES_COUNT Register (see Memory Interface Registers in vol1a System Overview) for each object (point, line, triangle, or quadrilateral) that it forwards down the pipeline. Note: For LINELOOP, the last (closing) line object is not counted. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 103 3. 3D Pipeline – Vertex Shader (VS) Stage 3.1 VS Stage Overview The VS stage of the 3D Pipeline is used to perform processing (“shading”) of vertices after being assembled and written to the URB by the VF function. The primary function of the VS stage is to pass vertices that miss in the Vertex Cache to VS threads, and then pass the VS thread-generated vertices down the pipeline. Vertices that hit in the Vertex Cache are passed down the pipeline unmodified. When the VS stage is disabled, vertices flow through the unit unmodified (i.e., as written by the VF unit). Refer to the Common 3D FF Unit Functions subsection in the 3D Overview chapter for a general description of a 3D pipeline stage, as much of the VS stage operation and control falls under these “common” functions; i.e., most stage state variables and VS thread payload parameters are described in 3D Overview, and although they are listed here for completeness, that chapter provides the detailed description of the associated functions. Refer to this chapter for an overall description of the VS stage, and any exceptions the VS stage exhibits with respect to common FF unit functions. 3.1.1 Vertex Caching The 3D Pipeline employs a Vertex Cache that is shared between the VF and VS units. (See Vertex Fetch chapter for additional information). The Vertex Cache may be explicitly DISABLED via the Vertex Cache Disable bit in VS_STATE. Even when explicitly ENABLED, the VS unit can (by default) implicitly disable and invalidate the Vertex Cache when it detects one of the following conditions: 1. Either VertexID or PrimitiveID is selected as part of the vertex data stored in the URB. 2. Sequential indices are used in the 3DPRIMITIVE command (though this is effectively a don’t care as there wouldn’t be any hits anyway). The implicit disable will persist as long as one of these conditions persist. The Vertex Cache is implicitly invalidated between 3DPRIMITIVE commands and between instances within a 3DPRIMITIVE command – therefore use of InstanceID in a Vertex Element is not a condition underwhich the cache is implicitly disabled. The following table summarizes the modes of operation of the Vertex Cache: Vertex Cache VS Function Enable Mode of Operation DISABLED (implicitly or explicitly) DISABLED Vertex Cache is not used. VF unit will assemble all vertices and write them into the URB entry supplied by the VS unit. VS unit will pass references to these VUEs down the pipeline unmodified. Usage Model: This is an exceptional condition, only required when the VF- generated vertices contain InstanceID or Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 104 Vertex Cache VS Function Enable Mode of Operation PrimitiveID and more than one instance is produced. Otherwise the Vertex Cache should be enabled. DISABLED ENABLED Vertex Cache is not used. VF unit will assemble all vertices and write them into (implicitly or explicitly) the URB entry supplied by the VS unit. VS unit will spawn VS threads to process all vertices, overwriting the input data with the results. The VS unit pass references to these VUEs down the pipeline. Usage Model: This mode is only used when the VS function is required, but either (a) the input vertex contains InstanceID or PrimitiveID and more than one instance is generated or (b) the VS kernel produces a side effect (e.g., writes to a memory buffer) which requires every vertex to be processed by a VS thread. ENABLED DISABLED Vertex Cache is used to provide reuse of VF-generated vertices. The VF unit will check the cache and only process (assemble/write) vertices that miss in the cache. In either case, the VS unit will pass references to vertices (that hit or miss) down the pipeline without spawning any VS threads. Usage Model: Normal operation when the VS function is not required. Note that there may be situations which require the VS function to be used even when not explicitly required by the API. E.g., perspective divide may be required for clip testing. ENABLED ENABLED Vertex Cache is used to provide reuse of VS-processed vertices. The VF unit will check the cache and only process (assemble/write) vertices that miss in the cache. The VS unit will only process (shade) the vertices that missed in the cache. The VS unit sends references to hit or missed vertices down the pipeline in the correct order. Usage Model: Normal operation when the VS function is required and use of the Vertex Cache is permissible. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 105 3.2 VS Stage Input As a stage of the 3D pipeline, the VS stage receives inputs from the previous (VF) stage. Refer to 3D Overview for an overview of the various types of input to a 3D Pipeline stage. The remainder of this subsection describes the inputs specific to the VS stage. 3.2.1 State A PIPE_CONTROL with Post-Sync Operation set to 1h and a depth stall needs to be sent just prior to any 3DSTATE_VS, 3DSTATE_URB_VS, 3DSTATE_CONSTANT_VS, 3DSTATE_BINDING_TABLE_POINTER_VS, 3DSTATE_SAMPLER_STATE_POINTER_VS command. Only one PIPE_CONTROL needs to be sent before any combination of VS associated 3DSTATE. 3.2.1.1 URB_FENCE Refer to 3D Overview for a description of how the VS stage processes this command. 3.2.1.2 3DSTATE_VS 3DSTATE_VS Source: RenderCS Length Bias: 2 Description Project The state used by VS is defined with this inline state packet. 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 10h 3DSTATE_VS Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 4h Excludes DWord (0,1) Project: All Format: =n Total Length - 2 1 31:6 Kernel Start Pointer Project: All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 106 3DSTATE_VS Format: InstructionBaseOffset[31:6]Kernel This field specifies the starting location (1st core instruction) of the kernel program run by threads spawned by this FF unit. It is specified as a 64-byte-granular offset from the Instruction Base Address. This field is ignored if VS Function Enable is DISABLED. 5:0 Reserved Project: All Format: MBZ 2 31 Single Vertex Dispatch Project: All Format: U1 Enumerated type This field can be used to force single vertex SIMD4x2 VS threads. Value Name Description Project 0h Multiple Dual vertex SIMD4x2 thread dispatches are allowed. All 1h Single Single vertex SIMD4x2 thread dispatches are forced. All 30 Vector Mask Enable (VME) Project: All When SPF=0, VME specifies which mask to use to initialize the initial channel enables. When SPF=1, VME specifies which mask to use to generate execution channel enables. Value Name Description Project 0h Dmask Channels are enabled based on the dispatch mask All 1h Vmask Channels are enabled based on the vector mask All 29:27 Sampler Count Project: All Specifies how many samplers (in multiples of 4) the vertex shader 0 kernel uses. Used only for prefetching the associated sampler state entries. This field is ignored if VS Function Enable is DISABLED. Value Name Description Project 0h No Samplers no samplers used All 1h 1-4 Samplers between 1 and 4 samplers used All 2h 5-8 Samplers between 5 and 8 samplers used All 3h 9-12 Samplers between 9 and 12 samplers used All 4h 13-16 Samplers between 13 and 16 samplers used All 26 Reserved Project: All Format: MBZ 25:18 Binding Table Entry Count Project: All Format: U8 Specifies how many binding table entries the kernel uses. Used only for prefetching of the binding table entries and associated surface state. Note: For kernels using a large number of binding table entries, it may be wise to set this field to zero to avoid prefetching too many entries and thrashing the state cache. This field is ignored if VS Function Enable is DISABLED. Value Name [0,255] Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 107 3DSTATE_VS 17 Reserved Project: Format: MBZ 16 Floating Point Mode Project: All Format: U1 enumerated type Specifies the initial floating point mode used by the dispatched thread.This field is ignored if VS Function Enable is DISABLED. Value Name Description Project 0h IEEE-754 Use IEEE-754 Rules All 1h Alternate Use alternate rules All 15:14 Reserved Project: All Format: MBZ 13 Illegal Opcode Exception Enable Project: All Format: Enable This bit gets loaded into EU CR0.1[12] (note the bit # difference). See Exceptions and ISA Execution Environment.This field is ignored if VS Function Enable is DISABLED. 12 Reserved Format: MBZ 11:8 Reserved Format: MBZ 7 Software Exception Enable Format: Enable This bit gets loaded into EU CR0.1[13] (note the bit # difference). See Exceptions and ISA Execution Environment.This field is ignored if VS Function Enable is DISABLED. 6:0 Reserved Format: MBZ 3 31:10 Scratch Space Base Offset Project: All Format: GeneralStateOffset[31:10]ScratchSpace Specifies the starting location of the scratch space area allocated to this FF unit as a 1K-byte aligned offset from the General State Base Address. If required, each thread spawned by this FF unit will be allocated some portion of this space, as specified by Per-Thread Scratch Space. The computed offset of the thread-specific portion will be passed in the thread payload as Scratch Space Offset. The thread is expected to utilize “stateless” DataPort read/write requests to access scratch space, where the DataPort will cause the General State Base Address to be added to the offset passed in the request header. This field is ignored if VS Function Enable is DISABLED. 9:4 Reserved Project: All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 108 3DSTATE_VS Format: MBZ 3:0 Per-Thread Scratch Space Project: All Format: U4 power of 2 Bytes over 1K Bytes Specifies the amount of scratch space to be allocated to each thread spawned by this FF unit. The driver must allocate enough contiguous scratch space, starting at the Scratch Space Base Pointer, to ensure that the Maximum Number of Threads can each get Per-Thread Scratch Space size without exceeding the driver-allocated scratch space. This field is ignored if VS Function Enable is DISABLED. Value Name Description [0,11] indicating [1K Bytes, 2M Bytes] 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, but the Data Port will ignore it. 4 31:25 Reserved Project: All Format: MBZ 24:20 Dispatch GRF Start Register for URB Data Format: U5 Specifies the starting GRF register number for the URB portion (Constant + Vertices) of the thread payload. This field is ignored if VS Function Enable is DISABLED. Value Name Description [0,31] indicating GRF [R0,R31] 19:17 Reserved Project: All Format: MBZ 16:11 Vertex URB Entry Read Length Project: All Format: U6 Specifies the number of pairs of 128-bit vertex elements to be passed into the payload for each vertex. This field is ignored if VS Function Enable is DISABLED. For SIMD4x2 dispatch, each vertex element requires one GRF of payload data, therefore the number of GRFs with vertex data will be double the value programmed in this field. Value Name [1,63] Programming Notes It is UNDEFINED to set this field to 0 indicating no Vertex URB data to be read and passed to the thread. 10 Reserved Project: All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 109 3DSTATE_VS Format: MBZ 9:4 Vertex URB Entry Read Offset Project: All Format: U6 Specifies the offset (in 256-bit units) at which Vertex URB data is to be read from the URB before being included in the thread payload. This offset applies to all Vertex URB entries passed to the thread. This field is ignored if VS Function Enable is DISABLED. Value Name [0,63] 3:0 Reserved Project: All Format: MBZ 5 31:25 Maximum Number of Threads Format: U7-1 representing thread count Specifies the maximum number of simultaneous threads allowed to be active. Used to avoid using up the scratch space. Programming the value of the max threads over the number of threads based off number of threads supported in the execution units may improve performance since the architecture allows threads to be buffered between the check for max threads and the actual dispatch into the EU. Programming the max values to a number less than the number of threads supported in the execution units may reduce performance. This field is ignored if VS Function Enable is DISABLED. Value Name Project [0,127] indicating thread count of [1,128] [0,35] indicating thread count of [1,36] 24:23 Reserved Format: MBZ 22:11 Reserved Project: All Format: MBZ 10 Statistics Enable Project: All Format: Enable Description Project If ENABLED, this FF unit will engage in statistics gathering. See the Statistics Gathering section later in this chapter. If DISABLED, statistics information associated with this FF stage will be left unchanged. This field is used even if VS Function Enable is DISABLED. 9:3 Reserved Project: All Format: MBZ 2 Reserved Format: MBZ 1 Vertex Cache Disable Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 110 3DSTATE_VS Project: All Format: Disable This bit controls the operation of the Vertex Cache. This field is always used.If the Vertex Cache is DISABLED and the VS Function is ENABLED, the Vertex Cache is not used and all incoming vertices will be passed to VS threads. If the Vertex Cache is ENABLED and the VS Function is ENABLED, incoming vertices that do not hit in the Vertex Cache will be passed to VS threads. If the Vertex Cache is ENABLED and the VS Function is DISABLED, input vertices that miss in the Vertex Cache will be assembled and written to the URB, though pass thru the VS stage unmodified (not shaded). The Vertex Cache is invalidated whenever the Vertex Cache becomes DISABLED , whenever the VS Function Enable toggles, between 3DPRIMITIVE commands and between instances within a 3DPRIMITIVE command. 0 VS Function Enable Project: All Format: Enable Description Project If ENABLED, VS threads may be spawned to process VF-generated vertices before the resulting vertices are passed down the pipeline. If DISABLED, VF-generated vertices will pass thru the VS function and sent down the pipeline unmodified. The Vertex Cache is still available in this mode, if enabled. If Statistics Enable is ENABLED, VS_INVOCATION_COUNT will increment by 1 for every vertex that passes through the VS stage, even if VS Function Enable is DISABLED. This field is always used. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 111 3.2.1.3 3DSTATE_CONSTANT_VS 3DSTATE_CONSTANT_VS Source: RenderCS Length Bias: 2 This command sets pointers to the push constants for VS unit. The constant data pointed to by this command is loaded into the VS unit’s push constant buffer (PCB). Programming Notes Project It is invalid to execute this command more than once between 3D_PRIMITIVE commands. Constant buffers must be enabled in order from Constant Buffer 0 to Constant Buffer 3 within this command. For example, it is not allowed to enable Constant Buffer 1 by programming a non-zero value in the VS Constant Buffer 1 Read Length without a non-zero value in VS Constant Buffer 0 Read Length. 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 15h 3DSTATE_CONSTANT_VS Format: OpCode 15:8 Reserved Format: MBZ 7:0 DWord Length Project: All Format: =n Total Length - 2 Value Name Project 5h Excludes DWord (0,1) [Default] 1..6 191:0 Constant Body Project: Format: 3DSTATE_CONSTANT(Body) Following table is the shared portion of the 3DSTATE_CONSTANT command for VS, HS, DS, and GS Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 112 3DSTATE_CONSTANT(Body) Project: All Source: RenderCS Default Value: 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 DWord Bit Description 0 31:16 Constant Buffer 1 Read Length Project: All Format: U16 read length This field specifies the length of the constant data to be loaded from memory in 256-bit units. Programming Notes  The sum of all four read length fields must be less than or equal to the size of 64  Setting the value of the register to zero will disable buffer 1.  If disabled, the Pointer to Constant Buffer 1 must be programmed to zero. 15:0 Constant Buffer 0 Read Length Project: All Format: U16 read length This field specifies the length of the constant data to be loaded from memory in 256-bit units. Programming Notes  The sum of all four read length fields must be less than or equal to the size of 64  Setting the value of the register to zero will disable buffer 0.  If disabled, the Pointer to Constant Buffer 0 must be programmed to zero. 1 31:16 Constant Buffer 3 Read Length Project: All Format: U16 read length This field specifies the length of the constant data to be loaded from memory in 256-bit units. Programming Notes  The sum of all four read length fields must be less than or equal to the size of 64  Setting the value of the register to zero will disable buffer 3.  If disabled, the Pointer to Constant Buffer 3 must be programmed to zero. 15:0 Constant Buffer 2 Read Length Project: All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 113 3DSTATE_CONSTANT(Body) Format: U16 read length This field specifies the length of the constant data to be loaded from memory in 256-bit units. Programming Notes  The sum of all four read length fields must be less than or equal to the size of 64  Setting the value of the register to zero will disable buffer 2.  If disabled, the Pointer to Constant Buffer 2 must be programmed to zero. 2 31:5 Pointer to Constant Buffer 0 Project: All Format: GraphicsAddress[31:5]ConstantBuffer This field points to the location of Constant Buffer 0. The state of INSTPM determines whether the Dynamic State Base Address is added to this pointer. Programming Notes Constant buffers must be allocated in linear (not tiled) graphics memory. 4:0 Constant Buffer Object Control State Format: MEMORY_OBJECT_CONTROL_STATE Specifies the memory object control state for all constant buffers defined in this command. 3 31:5 Pointer to Constant Buffer 1 Format: GraphicsAddress[31:5]ConstantBuffer This field points to the location of Constant Buffer 1. Programming Notes Constant buffers must be allocated in linear (not tiled) graphics memory. 4:0 Reserved Project: All Format: MBZ 4 31:5 Pointer to Constant Buffer 2 Format: GraphicsAddress[31:5]ConstantBuffer This field points to the location of Constant Buffer 2. Programming Notes Constant buffers must be allocated in linear (not tiled) graphics memory. 4:0 Reserved Project: All Format: MBZ 5 31:5 Pointer to Constant Buffer 3 Format: GraphicsAddress[31:5]ConstantBuffer This field points to the location of Constant Buffer 3. Programming Notes Constant buffers must be allocated in linear (not tiled) graphics memory. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 114 3DSTATE_CONSTANT(Body) 4:0 Reserved Format: MBZ 3.2.1.4 3DSTATE_PUSH_CONSTANT_ALLOC_VS 3DSTATE_PUSH_CONSTANT_ALLOC_VS Source: RenderCS Length Bias: 2 This command sets up the URB configuration for VS Push Constant Buffer. Programming Notes Programming Restriction:  The sum of the Constant Buffer Offset and the Constant Buffer Size may not exceed the maximum value of the Constant Buffer Size.  The sum of the constant length programmed in 3DSTATE_CONSTANT_VS must be equal or smaller then the size of the allocated space in the URB including the buffering for half cachelines. See Push Constant URB Allocation section for more details.  The 3DSTATE_CONSTANT_VS must be reprogrammed prior to the next 3DPRIMITIVE command after programming the 3DSTATE_PUSH_CONSTANT_ALLOC_VS. 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 GFXPIPE_NONPIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 12h 3DSTATE_PUSH_CONSTANT_ALLOC_VS 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 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 115 3DSTATE_PUSH_CONSTANT_ALLOC_VS 1 31:20 Reserved Format: MBZ 19:16 Constant Buffer Offset Format: U4 Specifies the offset of the VS constant buffer into the URB. Value Name [0,15] (0KB - 15KB) 0h 0KB [Default] 15:5 Reserved Format: MBZ 4:0 Constant Buffer Size Format: U5 Specifies the size of the VS constant buffer. This value will determine the amount of data the command stream can pre-fetch before the buffer is full. Value of zero is only valid when constants are not enabled for VS. Value Name [0,15] (0KB – 15KB) Increments of 1KB 0h 0KB [Default] 3.2.2 Input Vertices Refer to 3D Overview for a description of the vertex information input to the VS stage. 3.3 SIMD4x2 VS Thread Request Generation This section describes SIMD4x2 thread request generation, which is the only mode available. The following discussion assumes the VS Function is ENABLED. When the Vertex Cache is disabled, the VS unit will pass each pair of incoming vertices to a VS thread. Under certain circumstances (e.g., prior to a state change or pipeline flush) the VS unit will spawn a VS thread to process a single vertex. Note that, in this case, the “unused” vertex slot will be “disabled” via the Execution Mask provided by the VS unit to the subsystem as part of the thread dispatch (See ISA doc). The VS thread will in itself be unaware of the single-vertex case, and therefore a single VS kernel can be used to process one or two vertices. (The performance of single-vertex processing will roughly equal the two-vertex case). When the Vertex Cache is enabled, the VF unit will detect vertices that hit in the cache and mark these vertices so that they will bypass VS thread processing and be output via a reference to the cached VUE. The VS unit will keep track of these cache-hit vertices as it proceeds to process cache-miss vertices. The VS unit guarantees that vertices will exit the unit in the order they are received. This may require the VS unit to issue single-vertex VS threads to process a cache-miss vertex that has yet to be paired up with another cache-miss vertex (if this condition is preventing the VS unit from producing any output). Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 116 3.3.1 Thread Payload The following table describes the payload delivered to VS threads. VS Thread Payload (SIMD4x2) DWord Bit Description R0.7 31 30:0 Reserved R0.6 31:24 Reserved 23:0 Thread ID: This field uniquely identifies this thread within the threads spawned by this FF unit, over some period of time. Format: Reserved for HW Implementation Use. R0.5 31:10 Scratch Space Offset: Specifies the of the scratch space allocated to the thread, specified as a 1KB-granular offset from the General State Base Address. See Scratch Space Base Offset description in VS_STATE. (See 3D Pipeline for further description on scratch space allocation). Format = GeneralStateOffset[31:10] 9.0 Reserved 8:0 FFTID: This ID is assigned by the FF unit and used to identify the thread within the set of outstanding threads spawned by the FF unit. Format: Reserved for HW Implementation Use. Format: U7 Range: 0-127 R0.4 31:5 Binding Table Pointer. Specifies the 32-byte aligned pointer to the Binding Table. It is specified as an offset from the Surface State Base Address. Format = SurfaceStateOffset[31:5] 4:0 Reserved R0.3 31:5 Sampler State Pointer. Specifies the location of the Sampler State Table to be used by this thread, specified as a 32-byte granular offset from the General State Base Address or Dynamic State Base Address. Format = DynamicStateOffset[31:5] 4 Reserved 3:0 Per Thread Scratch Space: Specifies the amount of scratch space allowed to be Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 117 DWord Bit Description used by this thread. The value specifies the power that two will be raised to (over determine the amount of scratch space). (See 3D Pipeline for further description). Format = U4 power of two (in excess of 10) Range = [0,11] indicating [1K Bytes, 2M Bytes] R0.2 31:0 Reserved : delivered as zeros (reserved for message header fields) R0.1 31:16 Reserved 15:0 URB Return Handle 1: This is the 64B-aligned URB offset where the EU’s upper channels (DWords 7:4) results are to be stored. If only one vertex is to be processed (shaded) by the thread, this field will effectively be ignored (no results are stored for these channels, as controlled by the thread’s Channel Mask). (See Generic FF Unit for further description). Format: U12 64B-aligned offset R0.0 31:16 Reserved 15:0 URB Return Handle 0: This is the 64B-aligned URB offset where the EU’s lower channels (DWords 3:0) results are to be stored. (See Generic FF Unit for further description). Format: U12 64B-aligned offset [Varies] 255:0 optional Constant Data (optional) : Some amount of constant data (possible none) can be extracted from the push constant buffer (PCB) and passed to the thread following the R0 Header. The amount of data provided is defined by the sum of the read lengths in the last 3DSTATE_CONSTANT_VS command (taking the buffer enables into account). The Constant Data arrives in a non-interleaved format. Varies 255:0 Vertex Data : Data from (possibly) one or (more typically) two Vertex URB Entries is passed to the thread in the thread payload. The Vertex URB Entry Read Offset and Vertex URB Entry Read Length state variables define the regions of the URB entries that are read from the URB and passed in the thread payload. These SVs can be used to provide a subset of the URB data as required by SW. The vertex data is laid out in the thread header in an interleaved format. The lower DWords (0-3) of these GRF registers always contain data from a Vertex URB Entry. The upper DWords (4-7) may contain data from another Vertex URB Entry. This allows two vertices to be processed (shaded) in parallel SIMD8 fashion. The VS kernel is not aware of the validity of the upper vertex. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 118 3.4 SIMD4x2 VS Thread Execution This section describes SIMD4x2 thread execution. A VS kernel (with one exception mentioned below) assumes it is to operate on two vertices in parallel. Input data is either passed directly in the thread payload (including the input vertex data) or indirectly via pointers passed in the payload. Refer to ISA chapters for specifics on writing kernels that operate in SIMD4x2 fashion. Refer to 3D Pipeline Stage Overview (3D Overview) for information on FF-unit/Thread interactions. In the (unlikely) event that the VS kernel needs to determine whether it is processing one or two vertices, the kernel can compare the URB Return Handle 0 and URB Return Handle 1 fields of the thread payload. These fields will be different if two vertices are being processed, and identical if one vertex is being processed. An example of when this test may be required is if the kernel outputs some vertex- dependent results into a memory buffer – without the test the single vertex case might incorrectly output two sets of results. Note that this is not the case for writing the URB destinations, as the Execution Mask will prevent the write of an undefined output. Note: Prior to sending an End Of Thread, the kernel must dispatch a write commit cycle, if there were any previous writes to memory that had caused no dependency checks. 3.4.1 Vertex Output VS threads must always write the destination URB handles passed in the payload. VS threads are not permitted to request additional destination handles. Refer to 3D Pipeline Stage Overview (3D Overview) for details on how destination vertices are written and any required contents/formats. 3.4.2 Thread Termination VS threads must signal thread termination, in all likelihood on the last message output to the URB shared function. Refer to the ISA doc for details on End-Of-Thread indication. 3.5 Primitive Output The VS unit will produce an output vertex reference for every input vertex reference received from the VF unit, in the order received. The VS unit simply copies the PrimitiveType, StartPrim, and EndPrim information associated with input vertices to the output vertices, and does not use this information in any way. Neither does the VS unit perform any readback of URB data. 3.6 Other VS Functions 3.6.1 Statistics Gathering The VS stage tracks a single pipeline statistic, the number of times a vertex shader is executed. A vertex shader is executed for each vertex that is fetched on behalf of a 3DPRIMITIVE command, unless the shaded results for that vertex are already available in the vertex cache. If the Statistics Enable bit in VS_STATE is set, the VS_INVOCATION_COUNT Register (see Memory Interface Registers in Volume Ia, GPU) will be incremented for each vertex that is dispatched to a VS thread. This counter will often Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 119 need to be incremented by 2 for each thread invoked since 2 vertices are dispatched to one VS thread in the general case. When VS Function Enable is DISABLED and Statistics Enable is ENABLED, VS_INVOCATION_COUNT will increment by one for every vertex that passes through the VS stage, even though no VS threads are spawned. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 120 4. 3D Pipeline – Hull Shader (HS) Stage 4.1 HS Stage Overview The Hull Shader (HS) stage of the pipeline is used to process patchlist (PATCHLIST_n) topologies in support of higher-order surface (HOS) tessellaton. If the HS stage is enabled, each incoming patch object is processed by a possible series of HS threads. The combined output of these threads is a Patch URB Entry (“patch record”) written to the URB. This patch record is used by subsequent stages (TE, DS) to complete the HOS tessellation operations. For SW Tessellation mode, the HS thread can also write tessellated domain point topologies to memory. The domain point count and starting memory address of the domain points is passed via the Patch Header in the patch record. The vertices associated with patchlist primitives are also referred to as “Input Control Points” (ICPs) to contrast them with any “Output Control Points” the HS threads may write to the patch record. (The definition and use of OCPs are outside the scope of this document). The HS stage also performs statistics counting. Incomplete topologies will not reach the HS stage. The HS, TE and DS stages must be enabled and disabled together. When these stages are disabled, all topologies (including patchlist topologies) will be simply pass through to the GS stage. When these stages are enabled, only patchlist topologies should be issued to the pipeline, otherwise behavior is UNDEFINED. 4.2 HS Stage Input 4.2.1 State 4.2.1.1 3DSTATE_CONSTANT_HS 3DSTATE_CONSTANT_HS Source: RenderCS Length Bias: 2 This command sets pointers to the push constants for the HS unit. The constant data pointed to by this command is loaded into the HS unit’s push constant buffer (PCB). Programming Notes Project It is invalid to execute this command more than once between 3D_PRIMITIVE commands. Constant buffers must be enabled in order from Constant Buffer 0 to Constant Buffer 3 within this command. For example, It is not allowed to enable Constant Buffer 1 by programming a non-zero value in the HS Constant Buffer 1 Read Length without a non-zero value in HS Constant Buffer 0 Read Length. DWord Bit Description 0 31:29 Command Type Default Value: 3h GFXPIPE Format: OpCode 28:27 Command SubType Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 121 3DSTATE_CONSTANT_HS Default Value: 3h Format: OpCode 26:24 3D Command Opcode Default Value: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 19h 3DSTATE_CONSTANT_HS Format: OpCode 15:8 Reserved Format: MBZ 7:0 DWord Length Project: All Format: =n Total Length - 2 Value Name Project 5h Excludes DWord (0,1) [Default] 1..6 191:0 Constant Body Format: 3DSTATE_CONSTANT(Body) Following table is the shared portion of the 3DSTATE_CONSTANT command for VS, HS, DS, and GS Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 122 4.2.1.2 3DSTATE_PUSH_CONSTANT_ALLOC_HS 3DSTATE_PUSH_CONSTANT_ALLOC_HS Project: All Source: RenderCS Length Bias: 2 This command sets up the URB configuration for HS Push Constant Buffer. Programming Notes Programming Restriction:  The sum of the Constant Buffer Offset and the Constant Buffer Size may not exceed the maximum value of the Constant Buffer Size.  The sum of the constant length programmed in 3DSTATE_CONSTANT_HS must be equal or smaller then the size of the allocated space in the URB including the buffering for half cachelines. See Push Constant URB Allocation section for more details.  The 3DSTATE_CONSTANT_HS must be reprogrammed prior to the next 3DPRIMITIVE command after programming the 3DSTATE_PUSH_CONSTANT_ALLOC_HS. 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 GFXPIPE_NONPIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 13h 3DSTATE_PUSH_CONSTANT_ALLOC_HS 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:20 Reserved Format: MBZ 19:16 Constant Buffer Offset Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 123 3DSTATE_PUSH_CONSTANT_ALLOC_HS Format: U5 Specifies the offset of the HS constant buffer into the URB. Value Name [0,15] (0KB - 15KB) 0h 0KB [Default] 15:5 Reserved Format: MBZ 4:0 Constant Buffer Size Format: U5 Specifies the size of the HS constant buffer. This value will determine the amount of data the command stream can pre-fetch before the buffer is full. Value of zero is only valid when constants are not enabled for HS. Value Name [0,15] (0KB – 15KB) Increments of 1KB 0h 0KB [Default] 4.3 3DSTATE_CONSTANT_HS 3DSTATE_CONSTANT_HS Source: RenderCS Length Bias: 2 This command sets pointers to the push constants for the HS unit. The constant data pointed to by this command is loaded into the HS unit’s push constant buffer (PCB). Programming Notes Project It is invalid to execute this command more than once between 3D_PRIMITIVE commands. Constant buffers must be enabled in order from Constant Buffer 0 to Constant Buffer 3 within this command. For example, It is not allowed to enable Constant Buffer 1 by programming a non-zero value in the HS Constant Buffer 1 Read Length without a non-zero value in HS Constant Buffer 0 Read Length. DWord Bit Description 0 31:29 Command Type Default Value: 3h GFXPIPE Format: OpCode 28:27 Command SubType Default Value: 3h Format: OpCode 26:24 3D Command Opcode Default Value: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 19h 3DSTATE_CONSTANT_HS Format: OpCode Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 124 3DSTATE_CONSTANT_HS 15:8 Reserved Format: MBZ 7:0 DWord Length Project: All Format: =n Total Length - 2 Value Name Project 5h Excludes DWord (0,1) [Default] 1..6 191:0 Constant Body Format: 3DSTATE_CONSTANT(Body) Following table is the shared portion of the 3DSTATE_CONSTANT command for VS, HS, DS, and GS 3DSTATE_CONSTANT(Body) Project: All Source: RenderCS Default Value: 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 DWord Bit Description 0 31:16 Constant Buffer 1 Read Length Project: All Format: U16 read length This field specifies the length of the constant data to be loaded from memory in 256-bit units. Programming Notes  The sum of all four read length fields must be less than or equal to the size of 64  Setting the value of the register to zero will disable buffer 1.  If disabled, the Pointer to Constant Buffer 1 must be programmed to zero. 15:0 Constant Buffer 0 Read Length Project: All Format: U16 read length This field specifies the length of the constant data to be loaded from memory in 256-bit units. Programming Notes Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 125 3DSTATE_CONSTANT(Body)  The sum of all four read length fields must be less than or equal to the size of 64  Setting the value of the register to zero will disable buffer 0.  If disabled, the Pointer to Constant Buffer 0 must be programmed to zero. 1 31:16 Constant Buffer 3 Read Length Project: All Format: U16 read length This field specifies the length of the constant data to be loaded from memory in 256-bit units. Programming Notes  The sum of all four read length fields must be less than or equal to the size of 64  Setting the value of the register to zero will disable buffer 3.  If disabled, the Pointer to Constant Buffer 3 must be programmed to zero. 15:0 Constant Buffer 2 Read Length Project: All Format: U16 read length This field specifies the length of the constant data to be loaded from memory in 256-bit units. Programming Notes  The sum of all four read length fields must be less than or equal to the size of 64  Setting the value of the register to zero will disable buffer 2.  If disabled, the Pointer to Constant Buffer 2 must be programmed to zero. 2 31:5 Pointer to Constant Buffer 0 Project: All Format: GraphicsAddress[31:5]ConstantBuffer This field points to the location of Constant Buffer 0. The state of INSTPM determines whether the Dynamic State Base Address is added to this pointer. Programming Notes Constant buffers must be allocated in linear (not tiled) graphics memory. 4:0 Constant Buffer Object Control State Format: MEMORY_OBJECT_CONTROL_STATE Specifies the memory object control state for all constant buffers defined in this command. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 126 3DSTATE_CONSTANT(Body) 3 31:5 Pointer to Constant Buffer 1 Format: GraphicsAddress[31:5]ConstantBuffer This field points to the location of Constant Buffer 1. Programming Notes Constant buffers must be allocated in linear (not tiled) graphics memory. 4:0 Reserved Project: All Format: MBZ 4 31:5 Pointer to Constant Buffer 2 Format: GraphicsAddress[31:5]ConstantBuffer This field points to the location of Constant Buffer 2. Programming Notes Constant buffers must be allocated in linear (not tiled) graphics memory. 4:0 Reserved Project: All Format: MBZ 5 31:5 Pointer to Constant Buffer 3 Format: GraphicsAddress[31:5]ConstantBuffer This field points to the location of Constant Buffer 3. Programming Notes Constant buffers must be allocated in linear (not tiled) graphics memory. 4:0 Reserved Format: MBZ 4.4 3DSTATE_HS The state used by HS is defined with the following 3DSTATE_HS inline state packet. 3DSTATE_HS Source: RenderCS Length Bias: 2 Controls the HS stage hardware. 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: 0h 3DSTATE_PIPELINED Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 127 3DSTATE_HS Format: OpCode 23:16 3D Command Sub Opcode Default Value: 1Bh 3DSTATE_HS Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Format: =n Value Name Project 5 Excludes DWord (0,1) [Default] 1 31:30 Reserved Project: All Format: MBZ 29:27 Sampler Count Project: All Format: U3 Specifies how many samplers (in multiples of 4) the HS kernels use. Used only for prefetching the associated sampler state entries. Value Name Description Project 0h No Samplers no samplers used All 1h 1-4 Samplers between 1 and 4 samplers used All 2h 5-8 Samplers between 5 and 8 samplers used All 3h 9-12 Samplers between 9 and 12 samplers used All 4h 13-16 Samplers between 13 and 16 samplers used All 5h-7h Reserved Reserved All 26 Reserved Project: All Format: MBZ 25:18 Binding Table Entry Count Project: All Format: U8 When HW Generated Binding Table is disabled: Specifies how many binding table entries the kernel uses. Used only for prefetching of the binding table entries and associated surface state. Note: For kernels using a large number of binding table entries, it may be wise to set this field to zero to avoid prefetching too many entries and thrashing the state cache. 17 Reserved Format: MBZ 16 Floating Point Mode Project: All Specifies the initial floating point mode used by the dispatched thread. Value Name Description Project Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 128 3DSTATE_HS 0h IEEE-754 Use IEEE-754 Rules All 1h alternate Use alternate rules All 15:14 Reserved Project: All Format: MBZ 13 Illegal Opcode Exception Enable Project: All Format: Enable This bit gets loaded into EU CR0.1[12] (note the bit # difference). See Exceptions and ISA Execution Environment. 12 Reserved Format: MBZ 11:8 Reserved Project: All Format: MBZ 7 Software Exception Enable Format: Enable This bit gets loaded into EU CR0.1[13] (note the bit # difference). See Exceptions and ISA Execution Environment. 6:0 Maximum Number of Threads Format: U7-1 thread count Specifies the maximum number of simultaneous threads allowed to be active. Used to avoid using up the scratch space. Programming the value of the max threads over the number of threads based off number of threads supported in the execution units may improve performance since the architecture allows threads to be buffered between the check for max threads and the actual dispatch into the EU. Programming the max values to a number less than the number of threads supported in the execution units may reduce performance. Limit is based on max number of HS URB handles. Value Name Project [0,127] indicating a thread count of [1,128] [0,35] indicating a thread count of [1,36] Programming Notes A URB_FENCE command must be issued subsequent to any change to the value in this field and before any subsequent pipeline processing (e.g., via 3DPRIMITIVE or CONSTANT_BUFFER). See Graphics Processing Engine (Command Ordering Rules) 2 31 HS Enable Project: All Format: Enable Specifies whether the HS function is enabled or disabled (pass-through). If ENABLED MI_TOPOLOGY_FILTER must be used to silently discard any topologies that the HS kernel is not expecting. E.g., if the HS kernel is expecting PATCHLIST_32 topologies, MI_TOPOLOGY_FILTER Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 129 3DSTATE_HS must be set to PATCHLIST_32 so only those topologies can reach the enabled HS. Programming Notes The tessellation stages (HS, TE and DS) must be enabled/disabled as a group. I.e., draw commands can only be issued if all three stages are enabled or all three stages are disabled, otherwise the behavior is UNDEFINED. 30 Reserved Project: All Format: MBZ 29 HS Statistics Enable Project: All Format: Enable This bit controls whether HS-unit-specific statistics register(s) will increment (for each patch). Value Name Description Project 0h Disable HS_INVOCATIONS_COUNT will not increment 1h Enable HS_INVOCATIONS_COUNT will increment 28:18 Reserved Project: All Format: MBZ 16:8 Reserved Format: MBZ 7:4 Reserved Project: All Format: MBZ 3:0 Instance Count Project: All Format: U4-1 This field determines the number of threads (minus one) spawned per input patch. If the HS kernel uses a barrier function, software must restrict the Instance Count to the number of threads that can be simultaneously active within a half-slice. Factors which must be considered includes scratch memory availability. Value Name Description [0,15] representing [1,16] instances 3 31:6 Kernel Start Pointer Project: All Format: InstructionBaseOffset[31:6]Kernel This field specifies the starting location (1st GEN core instruction) of the kernel program run by threads spawned by this FF unit. It is specified as a 64-byte-granular offset from the Instruction Base Address. 5:0 Reserved Project: All Format: MBZ 4 31:10 Scratch Space Base Pointer Format: GeneralStateOffset[31:10] Format: GraphicsAddress[31:0] Specifies the location of the scratch space area allocated to this FF unit, specified as a 1KB-granular offset from the General State Base Address. If required, each thread spawned by this FF unit will be Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 130 3DSTATE_HS allocated some portion of this space, as specified by Per-Thread Scratch Space. 9:4 Reserved Format: MBZ 3:0 Per-Thread Scratch Space Format: U4 power of 2 Bytes over 1K Bytes Specifies the amount of scratch space to be allocated to each thread spawned by this FF unit.The driver must allocate enough contiguous scratch space, starting at the Scratch Space Base Pointer, to ensure that the Maximum Number of Threads can each get Per-Thread Scratch Space size without exceeding the driver-allocated scratch space. Value Name [0,11] indicating [1K Bytes, 2M Bytes] 5 31:28 Reserved Format: MBZ 27 Single Program Flow (SPF) Specifies the initial condition of the kernel program as either a single program flow (SIMDnxm with m = 1) or as multiple program flows (SIMDnxm with m > 1). See CR0 description in ISA Execution Environment. Value Name Description Project 0h Reserved All 1h Enable Single Program Flow enabled All 26 Vector Mask Enable Format: U1 FormatDesc: Enumerated Type When SPF=0, VME specifies which mask to use to initialize the initial channel enables. When SPF=1, VME specifies which mask to use to generate execution channel enables. Value Name Description Project 0h Dmask Channels are enabled based on the dispatch mask All 1h Vmask Channels are enabled based on the vector mask All 25 Reserved Format: MBZ 24 Include Vertex Handles Format: Boolean If set, all the input Vertex URB handles are included in payloads. This field is ignored if HS Function Enable is DISABLED.Programming Restriction:This field must be set if value if Vertex URB Entry Read Length is cleared to zero. 23:19 Dispatch GRF Start Register for URB Data Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 131 3DSTATE_HS Format: U5 Specifies the starting GRF register number for the URB portion (Constant + Vertices) of the thread payload. This field is ignored if HS Function Enable is DISABLED. Value Name [0,31] indicating GRF [R0,R31] 18:17 Reserved Format: MBZ 16:11 Vertex URB Entry Read Length Format: U6 Specifies the amount of URB data read and passed in the thread payload for each Vertex URB entry, in 256-bit register increments.This field is ignored if HS Function Enable is DISABLED.Programming Restriction:This field must be a non-zero value if Include Vertex Handles is cleared to zero. Value Name [0,63] 10 Reserved Format: MBZ 9:4 Vertex URB Entry Read Offset Format: U6 Specifies the offset (in 256-bit units) at which Vertex URB data is to be read from the URB before being included in the thread payload. This offset applies to all Vertex URB entries passed to the thread.This field is ignored if HS Function Enable is DISABLED. Value Name [0,63] 3:0 Reserved Format: MBZ 6 31:13 Reserved Project: All Format: MBZ 12 Reserved Format: MBZ 11:0 Semaphore Handle Format: URBOffset[17:6] This is the URB offset pointing to the first of the GS semaphore DWords in the URB. The size of the region is 32 DWs(16 – 512b URB entries). Software is responsible for allocating combined GS and/or HS semaphore Dwords in a single contiguous region of the URB. Software must also make sure the 3D pipeline is IDLE prior to allocating or deallocating the region. The semaphores can be located in an unused area within a FF unit’s URB fenced region or an unused area within the Push Constant region. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 132 4.5 Patch Object Staging The HS unit accepts patchlist topologies as a stream of incoming vertices. Depending on the number of vertices per patch object (as specified by the PATCHLIST_n topology), the HS thread will assemble each complete patch object and pass it (its vertices, PrimitiveID, etc.) to HS thread(s) as described below. 4.6 HS Thread Payload 4.6.1 SINGLE_PATCH Layout (SINGLE-PATCH Mode) The following tables show the layout of the payload delivered to HS threads. Refer to 3D Pipeline Stage Overview (3D Pipeline) for details on those fields that are common amongst the various pipeline stages. Patch object vertex (ICP) data can be passed by value (data pushed in the payload) and/or by reference (URB handle pushed in the payload). SINGLE_PATCH HS Thread Payload GRF DWord Bit Description R0:7 31:0 Reserved 31 R0.6 Dereference Thread This bit is defined to send back the Handle ID back to HS to dereference the input handles for this thread. 30:24 Reserved 23:0 Thread ID. This field uniquely identifies this thread within the threads spawned by this FF unit, over some period of time. Format: Reserved for HW Implementation Use. 31:10 R0.5 Scratch Space Pointer. Specifies the location of the scratch space allocated to this thread, specified as a 1KB-aligned offset from the General State Base Address. Format = GeneralStateOffset[31:10] 9.0 Reserved 8:0 FFTID. This ID is assigned by the fixed function unit and is relative identifier for the thread. It is used to free up resources used by the thread upon thread completion. Format: Reserved for Implementation Use Format: U7 Range: 0-127 31:5 R0.4 Binding Table Pointer: Specifies the 32-byte aligned pointer to the Binding Table. It is specified as an offset from the Surface State Base Address. Format = SurfaceStateOffset[31:5] Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 133 GRF DWord Bit Description 4:0 Reserved 31:5 R0.3 Sampler State Pointer. Specifies the location of the Sampler State Table to be used by this thread, specified as a 32-byte granular offset from the General State Base Address or Dynamic State Base Address. Format = DynamicStateOffset[31:5] 4 Reserved 3:0 Per Thread Scratch Space. Specifies the amount of scratch space allowed to be used by this thread. The value specifies the power that two will be raised to (over determine the amount of scratch space). 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, but the Data Port will ignore it. Format = U4 power of two (in excess of 10) Range = [0,11] indicating [1K Bytes, 2M Bytes] 31:24 R0.2 Semaphore Index. This is a Dword index to be used in URB_ATOMIC commands if the thread is using data pulled from input handles. This information is only required for pull-model vertex inputs and InstanceCount>1. Format = U8 23 Reserved 22:16 Instance Number. A patch-relative instance number between 0 and InstanceCount-1. Format = U7 15:12 Barrier Index. This index is to be used in any BarrierMsgs sent by this thread to the Gateway. Format = U4 11:0 Semaphore Handle: This is the URB handle pointing to the first HS semaphore DWord in the URB. Software is responsible for statically allocating the semaphore Dwords in the URB. Refer to Semaphore Handle field in 3DSTATE_HS for size of semaphore allocation. Format: U12 64B-aligned URB Offset R0.1 31:0 Primitive ID. This field contains the Primitive ID associated with the patch. Format: U32 31:16 Reserved R0.0 15:0 Patch Data Record URB Return Handle. Format: U12 64B-aligned URB Offset R1 is only included for dispatches that have Include Vertex Handles enabled. 31:16 ICP 7 Handle ID R1.7 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 134 GRF DWord Bit Description 15:0 ICP 7 Handle Format: 31:16 ICP 6 Handle ID R1.6 15:0 ICP 6 Handle 31:16 ICP 5 Handle ID R1.5 15:0 ICP 5 Handle R1.4 31:16 ICP 4 Handle ID 15:0 ICP 4 Handle R1.3 31:16 ICP 3 Handle ID 15:0 ICP 3 Handle R1.2 31:16 ICP 2 Handle ID 15:0 ICP 2 Handle R1.1 31:16 ICP 1 Handle ID 15:0 ICP 1 Handle R1.0 31:16 ICP 0 Handle ID 15:0 ICP 0 Handle R2 is only included for dispatches that have Include Vertex Handles enabled and when ICP Count >7 R2.7 31:16 ICP 15 Handle ID 15:0 ICP 15 Handle R2.6 31:16 ICP 14 Handle ID 15:0 ICP 14 Handle R2.5 31:16 ICP 13 Handle ID 15:0 ICP 13 Handle R2.4 31:16 ICP 12 Handle ID 15:0 ICP 12 Handle R2.3 31:16 ICP 11 Handle ID 15:0 ICP 11 Handle R2.2 31:16 ICP 10 Handle ID 15:0 ICP 10 Handle R2.1 31:16 ICP 9 Handle ID 15:0 ICP 9 Handle R2.0 31:16 ICP 8 Handle ID 15:0 ICP 8 Handle R3 is only included for dispatches that have Include Vertex Handles enabled and when ICP Count >15 R3.7 31:16 ICP 23 Handle ID 15:0 ICP 23 Handle R3.6 31:16 ICP 22 Handle ID 15:0 ICP 22 Handle R3.5 31:16 ICP 21 Handle ID 15:0 ICP 21 Handle R3.4 31:16 ICP 20 Handle ID 15:0 ICP 20 Handle R3.3 31:16 ICP 19 Handle ID 15:0 ICP 19 Handle R3.2 31:16 ICP 18 Handle ID 15:0 ICP 18 Handle R3.1 31:16 ICP 17 Handle ID 15:0 ICP 17 Handle Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 135 GRF DWord Bit Description R3.0 31:16 ICP 16 Handle ID 15:0 ICP 16 Handle R4 is only included for dispatches that have Include Vertex Handles enabled and when ICP Count >23 R4.7 31:16 ICP 31 Handle ID 15:0 ICP 31 Handle R4.6 31:16 ICP 30 Handle ID 15:0 ICP 30 Handle R4.5 31:16 ICP 29 Handle ID 15:0 ICP 29 Handle R4.4 31:16 ICP 28 Handle ID 15:0 ICP 28 Handle R4.3 31:16 ICP 27 Handle ID 15:0 ICP 27 Handle R4.2 31:16 ICP 26 Handle ID 15:0 ICP 26 Handle R4.1 31:16 ICP 25 Handle ID 15:0 ICP 25 Handle R4.0 31:16 ICP 24 Handle ID 15:0 ICP 24 Handle [Varies] 255:0 Constant Data (optional): optional Some amount of constant data (possible none) can be extracted from the push constant buffer (PCB) and passed to the thread following the R0 Header. The amount of data provided is defined by the sum of the read lengths in the last 3DSTATE_CONSTANT_HS command (taking the buffer enables into account). [Varies] 255:0 ICP Vertex Data (optional): There can be up to 32 vertices supplied, each with a size defined optional by the Vertex URB Entry Read Length state. Vertex 0 DWord 0 is located at Rn.0, Vertex 0 DWord 1 is located at Rn.1, etc. Vertex 1 DWord 0 immediately follows the last DWord of Vertex 0, and so on. 4.7 HS Thread Execution Input to HS threads is comprised of:  Input Control Points (incoming patch vertices), pushed into the payload and/or passed indirectly via URB handles.  Push Constants (common to all threads)  Patch Data handle  Resources available via binding table entries (accessed through shared functions)  Miscellaneous payload fields (Instance Number, etc.) Typically the only output of the HS threads is the Patch URB Entry (patch record). All thread instances for an input patch are passed the same patch record handle. As the (possibly concurrent) threads can both read and write the patch record, it is up to the kernels to ensure deterministic results. One approach would be to use the thread’s Instance Number as an index for URB write destinations. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 136 4.7.1 Dispatch Mask HS threads will be dispatched with the dispatch mask set to 0xFFFF. It is the responsibility of the kernel to modify the execution mask as required (e.g., if operating in SIMD4x2 mode but only the lower half is active, as would happen in one thread is the threads were computing an odd number of OCPs via SIMD4x2 operation). 4.8 ICP Dereferencing If ICPs are only pushed in HS payloads (i.e., the Include Vertex Handles state bit is clear), the ICP handles will automatically be released after the last instance for the patch is dispatched. If Include Vertex Handles is set (the HS thread(s) will be reading ICP data in from the URB, it is the responsibility of the HS thread instances to explicitly dereference all the ICP handles via use of the Complete bit in URB_READ_xxx commands.  If only one instance is used, that instance can dereference the ICP handles as soon as they are no longer needed, by setting Complete in the last URB_READ from that handle. Otherwise all (or the remaining) ICP handles need to be explicitly dereferenced via (possibly null-response-length) URB_READ commands prior to thread EOT.  If more than one instance is spawned, the last-terminating instance is responsible for dereferencing all the ICP handles before it terminates. Instances can detect that they are the last-terminating thread via use of the semaphore allocated to the patch (via the Semaphore Handle and Semaphore Index payload fields). A URB_ATOMIC_INC operation (URB_ATOMIC command) can be performed on this semaphore by each instance prior to terminating. Only the last-terminating thread will observe the value (InstanceCount – 1) as a return value. After dereferencing all the ICPs, the last-terminating thread must also reset the semaphore to 0 via the URB_ATOMIC_MOV operation. 4.9 Patch URB Entry (Patch Record) Output For each patch, the HS thread(s) generate a single patch record, starting with a fixed 32B Patch Header . When the final thread instance terminates, the patch record handle is passed down the pipeline to the Tessellation Engine (TE). 4.9.1 Patch Header The first 8 DWords of the patch record is defined as a “Patch Header”. The Patch Header is written by an HS thread and read by the TE stage. It normally contains up to six Tessellation Factors (TFs) that determine how finely the TE stage needs to tessellate a domain (if at all). In SW Tessellation mode, the header contains Domain Point Count and Domain Point Buffer Starting Address fields which identify the domain points generated by an HS thread. The following diagram shows the fixed layouts of the Patch Header, depending on DomainType and SW Tessellation Mode. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 137 Patch Header (QUAD Domain) DW ord Bits Description 7 31:0 UEQ0 Tessellation Factor Format: FLOAT32 6 31:0 VEQ0 Tessellation Factor Format: FLOAT32 5 31:0 UEQ1 Tessellation Factor Format: FLOAT32 4 31:0 VEQ1 Tessellation Factor Format: FLOAT32 3 31:0 Inside U Tessellation Factor Format: FLOAT32 2 31:0 Inside V Tessellation Factor Format: FLOAT32 1-0 31:0 Reserved : MBZ Patch Header (TRI Domain) DW Bit ord s Description 7 31:0 UEQ0 Tessellation Factor Format: FLOAT32 6 31:0 VEQ0 Tessellation Factor Format: FLOAT32 5 31:0 WEQ0 Tessellation Factor Format: FLOAT32 4 31:0 Inside Tessellation Factor Format: FLOAT32 3-0 31:0 Reserved : MBZ Patch Header (ISOLINE Domain) DW Bit ord s Description Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 138 DW Bit ord s Description 7 31:0 Line Detail Tessellation Factor Format: FLOAT32 6 31:0 Line Density Tessellation Factor Format: FLOAT32 5-0 31:0 Reserved : MBZ Patch Header (SW Tessellation Mode) DW Bit ord s Description 7 31:0 Domain Point Count Specifies the number of DOMAIN_POINT structures in the domain point list in memory. If 0, there are no domain points defined, the patch will considered “culled”, and the TE stage will discard the patch. Otherwise the TS stage will send this number of domain points down the pipeline. Format: U32 6 31:6 Domain Point Buffer Starting Address (DPBSA) This field specifies the starting memory offset from SW Tessellation Base Address (set by the SWTESS_BASE_ADDRESS command) at which the HS thread has written a list of DOMAIN_POINT structures. This field is ignored if Domain Point Count is 0. Format: 64B-aligned offset from SW Tessellation Base Address 5:0 Reserved : MBZ 5-0 31:0 Reserved: MBZ 4.9.2 DOMAIN_POINT Structure In SW Tessellation Mode (i.e., when the TE State is SW_TESS), the TE stage will read a sequence of DOMAIN_POINT structures from memory, starting at the Domain Point Buffer Starting Address field of the patch header. (The DPBSA is treated as an offset from the SW Tessellation Base Address as set by the SWTESS_BASE_ADDRESS command). DOMAIN_POINT Memory Structure (SW Tessellation) DW ord Bit Description 0 31 PrimStart Set on the first domain point of the topology (e.g., first vertex in a TRISTRIP). 30 PrimEnd Set on the last domain point of the topology (e.g., last vertex in a TRISTRIP). Programming note: Software must ensure that incomplete primitives are not output, or Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 139 DW ord Bit Description behavior is UNDEFINED. 29 PatchEnd Set on the last domain point for the patch. By definition, PrimEnd must also be set. Programming Note: Software must ensure that the Domain Point Count coincides with the domain point marked with PatchEnd. 28:24 PrimType This is the primitive topology type. Format: See 3DPRIMITIVE for encodings Valid values:POINTLIST, LINESTRIP, LINELIST, TRISTRIP, TRISTRIP_REV, TRILIST, TRIFAN. 23:19 Reserved 18:17 DS Tag [16:15] This field provides bits [16:15] of the DS Tag value for this domain point. See DS Tag [14:0]. Format: U2 16:0 U Coordinate Format: U1.16 1 31:17 DS Tag [14:0] This field provides bits [14:0] of the DS Tag value for this domain point. In order to utilize the DS cache, the 17-bit DS Tag must be unique for the associated U,V coordinate. If software cannot guarantee this, the DS cache must be disabled when in SW Tessellation mode. Format: U15 16:0 V Coordinate Format: U1.16 4.10 Statistics Gathering 4.10.1 HS Invocations The HS unit controls the HS_INVOCATIONS counter, which counts the number of patches processed by the HS stage. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 140 5. 3D Pipeline – Tessellation Engine (TE) When enabled, the Tessellation Engine (TE) stage performs fixed-function domain tessellation (decomposition into smaller objects) of incoming patches, as referenced by an HS-generated input PDR handle and as controlled by TE state and Tessellation Factors (TFs) read from the Patch URB Entry (patch record). The TE stage is entirely fixed-function and does not spawn threads. The TE stage can also operate in SW Tessellation mode, where it simply reads “pre-tessellated” domain point topologies from memory and passes them down the pipeline. The fixed-function tessellation algorithm is considered an implementation detail and is therefore beyond the scope of this document. That detail includes both the order of output topologies as well as the order of vertices (domain points) within the output topologies. Only a high-level overview is provided to describe how the (few) state variables can be used to control aspects of tessellation behavior. The implementation will generate deterministic results (given the same exact inputs it will produce exactly the same outputs). Several domain types (QUAD, TRI, and ISOLINE) are supported. Depending on the domain type, the TE stage outputs the required point/line/triangle topologies including a domain point per vertex. These topologies will be output to the DS stage, where the domain points will be converted to 3D object vertices, resulting in 3D objects as typically input to the 3D pipeline when HOS tessellation is not used. The HS, TE, and DS stages must be enabled and disabled together. When these stages are disabled, all topologies (including patchlist topologies) simply pass through to the GS stage. When these stages are enabled, only patchlist topologies should be issued to the pipeline, else behavior is UNDEFINED. The MI_TOPOLOGY_FILTER command can be used to ensure this happens, i.e., it can be used to have the Command Stream ignore 3DPRIMITIVE commands that do not match a specific topology type. 5.1 3DSTATE_TE 3DSTATE_TE Source: RenderCS Length Bias: 2 The state used by TE is defined with this inline state packet. 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 1Ch 3DSTATE_TE Format: OpCode 15:8 Reserved Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 141 3DSTATE_TE Project: All Format: MBZ 7:0 DWord Length Default Value: 2h Excludes DWord (0,1) Project: All Format: =n Total Length - 2 1 31:14 Reserved Project: All Format: MBZ 13:12 Partitioning Project: All Format: U2 This field specifies how edges are partitioned based on tessellation factor. Value Name Description Project 0h INTEGER Outside/inside edges are divided into an integer number of All equal-sized segments. 1h ODD_FRACTIONAL Outside/inside edges are divided into an odd number of All possibly-unequal-sized segments. 2h EVEN_FRACTIONAL Outside/inside edges are divided into an even number of All possibly-unequal-sized segments. 11:10 Reserved Project: All Format: MBZ 9:8 Output Topology Project: All Format: U2 This field specifies which primitive types are to be output. Value Name Description Project 0h POINT Points are output (as POINTLIST topologies) All 1h LINE Lines are output (as LINESTRIP topologies). Only valid if ISOLINE All domain is selected. 2h TRI_CW Clockwise-ordered triangles are output (either as TRISTRIP, All TRISTRIP_REV or TRILIST topologies). Not valid if ISOLINE domain is selected. 3h TRI_CCW Count-clockwise-ordered triangles are output (either as TRISTRIP, All TRISTRIP_REV or TRILIST topologies). Not valid if ISOLINE domain is selected. 7:6 Reserved Project: All Format: MBZ 5:4 Domain Project: All Format: U2 This field specifies which type of domain is to be tessellated. Value Name Description Project Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 142 3DSTATE_TE 0h QUAD 2D (U,V) domain is tessellated All 1h TRI Triangular (U,V,W) domain is tessellated All 2h ISOLINE 2D (U,V) domain is tessellated. All 3 Reserved Project: All Format: MBZ 2:1 TE Mode Project: All Format: U2 When TE Enable is ENABLED, this field specifies the overall operation of the TE stage.This field is ignored if TE Enable is DISABLED. Value Name Description Project 0h HW_TESS Normal HW Tessellation Mode. The TessFactors are read from the All patch URB entry, and are used to perform fixed-function hardware tessellation of the specified domain. 1h SW_TESS Software Tessellation Mode. The TE unit will pass down HS-thread- All generated tessellated domain points instead of generating them itself from TessFactors. The TE unit will read the Domain Point Count and Domain Point Buffer Starting Address fields from the patch header, and if the count is 0 it will consider the patch culled and discard it. Otherwise the address is used to start fetching DOMAIN_POINT structures from memory and passing them down the pipeline to DS. 0 TE Enable Project: All Format: Enable If ENABLED, the TE stage will perform tessellation processing on incoming patch primitives. The TE Mode field determines how this tessellation operation proceeds.If DISABLED, the TE goes into pass- through mode. All other state fields are ignored. Programming Notes The tessellation stages (HS, TE and DS) must be enabled/disabled as a group. I.e., draw commands can only be issued if all three stages are enabled or all three stages are disabled, otherwise the behavior is UNDEFINED. 2 31:0 Max TessFactor Odd Project: All Format: FLOAT32 This field specifies the maximum TessFactor for ODD_FRACTIONAL partitioning when in HW_TESS mode. Note that ISOLINE’s LineDensity TF is always subjected to INTEGER partitioning regardless of the Partitioning state.For normal operation (as per API spec) software should set this value to 63.0. 3 31:0 Max TessFactor Not Odd Project: All Format: FLOAT32 This field specifies the maximum TessFactor for EVEN_FRACTIONAL or INTEGER partitioning when in HW_TESS mode. Note that ISOLINE’s LineDensity TF is always subjected to INTEGER partitioning regardless of the Partitioning state.For normal operation (as per API spec) software should set this value to 64.0. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 143 5.2 Domain Types and Output Topologies The major (if only) task of the TE stage is to tessellate a 2D (u,v) domain region—as selected by the Domain state—into some number of 2D object topologies. (If the patch is culled, that number may be zero). The options for Domain state are as follows:  QUAD: A square 2D region within a u,v Cartesian (rectanguar) space. The region extends from the origin to u=1 and v=1. Within the region, tessellation domain locations are determined. The possible output topologies include points, clockwise triangles, and counter-clockwise triangles.  TRI: A triangular 2D region with u,v,w barycentric (areal) coordinates. The three edges correspond to u=0, v=0, and w=0 boundaries. In barycentric coordinates, w = 1 – u – v, therefore points within the region are fully defined as 2D (u,v) coordinates. Within the region, tessellation domain locations are determined. The possible output topologies include points, clockwise triangles, and counter- clockwise triangles.  ISOLINE: A series of points within a QUAD domain, where the points lie on lines parallel to the u axis and extending from [0,1) in the v direction. Either the segmented lines (linestrips) or individual point topologies can be output. 5.3 QUAD Domain Tessellation The four “outside” TFs (TF.UEQ0, TF.VEQ0, TF.UEQ1, TF.VEQ1) are used to specify the level of tessellation along the four corresponding edges of the 2D quad domain. The two “inside” TFs (TF.InsideU, TF.InsideV) are used to determine the level of tessellation within a 2D “interior” region. Typically the interior region appears as a “regularly-tessellated 2D grid”, however under certain conditions the interior region may collapse in which case only the outside TFs are relevant. In general, a transition region exists between each edge of the interior region and the corresponding outside edge. The topologies generated for these regions effectively “stitch together” locations along the outside and inside edges, as each of these edges can contain a different number of tessellated segments. In the case where all TFs in a given direction (e.g., TF.VEQ0, TF.InsideU, and TF.VEQ1) are the same value, it appears as if the regularly-tessellated interior region extends all the way to the outside edges. If this condition simultaneously exists for both u and v directions, the entire domain will appear to be tessellated into a regular grid, with no noticeable transition regions. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 144 QUAD Domain Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 145 5.3.1 TRI Domain Tessellation Tessellation of the TRI domain is similar to the QUAD domain, except only three outside edges/TFs are used, and the tessellation of the interior region is controlled by a single TF. TRI Domain Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 146 5.4 ISOLINE Domain Tessellation Tessellation of the ISOLINE domain is different but much simpler than QUAD and TRI domains. The TF.LineDetail TF controls how finely the U direction is tessellated, while the TF.LineDensity TF controls how finely the V direction is tessellated. When LINE output topology is selected, a series of segmented lines parallel to the U axis (constant V) are output. When POINT output topology is selected, only the line segment endpoints are output (as point objects). In either case there is no topology output for the V=1 edge, which avoids overlapping lines for adjacent patches. ISOLINE Domain 5.5 Patch Culling Normally, if any “outside” TF is <= 0.0 or NaN, the entire patch is culled at the TE stage. Inside TFs are not used to cull patches. In SW Tessellation mode, a Domain Point Count of 0 indicates that a patch is to be culled. 5.6 Tessellation Factor Limits MinTessFactor and MaxTessFactor state variables are used to perform a floating-point range clamp on the TessFactors. See TE_STATE for programming details. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 147 5.7 Partitioning The Partitioning state controls how the TFs are used to divide their corresponding edges.  INTEGER: The edge will be divided into an integral number of equal segments (given some fixed- point tolerance). After clamping, the TF is rounded up to an integer value. The edge will be divided into that many equal segments.  EVEN_FRACTIONAL: The edge will be divided into an even number of possibly-unequal segments. The total number of segments is determined by rounding up the post-clamped TF to an even number. More specifically, the edge is divided exactly in half. Like the endpoints of the edge, the midpoint of the edge is by definition a tessellation point. Each half will contain some number of equal segments and possibly one smaller segment. The size of the smaller segment is determined by the position of the TF value within the range defined by the TF rounded down and up to even numbers. The closer the TF is to the smaller value, the smaller the segment size is. When the TF reaches the smaller even value, the smaller segment disappears. The closer the TF gets to the larger even value, the closer the smaller segment size approaches the size of the other segments. When the TF reaches the larger even value, all segments will be equal. The position of the smaller segment along the half edge varies as a function of the TF value.  ODD_FRACTIONAL: The edge will be divided into an odd number of possibly-unequal segments. The tessellation scheme is very similar to EVEN_FRACTIONAL partitioning, except the edge midpoint is not included as a tessellation point. This, and the fact that the tessellation points are mirrored about the edge midpoint, causes an “odd” segment (which may or may not be the “smaller” segment) to straddle the edge midpoint, therefore resulting in the number of segments for the edge always being odd. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 148 6. 3D Pipeline – Domain Shader (DS) Stage The DS stage is very similar to the VS stage in that it is responsible for dispatching EU threads to shade vertices and maintaining a cache (with reference counts) of the shaded vertex outputs of these threads. Major differences are as follows:  The DS receives topologies with “domain points” instead of vertices. The only data specific to a domain point are its U,V coordinates. These coordinates (plus a default or computed W coordinate) are passed directly in the DS thread payload. There is no other vertex-specific “input vertex data”  The concatenation of the domain point U,V coordinates (vs. a vertex index) is used as the cache tag.  The cache is invalidated between patches. The DS stage accepts state information via the inline 3DSTATE_DS command. 6.1 3DSTATE_DS 3DSTATE_DS Source: RenderCS Length Bias: 2 The state used by DS is defined with this inline state packet 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 1Dh 3DSTATE_DS Format: OpCode 15:8 Reserved Format: MBZ 7:0 DWord Length Default Value: 4h Excludes DWord (0,1) Format: =n Total Length - 2 1 31:6 Kernel Start Pointer Project: All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 149 3DSTATE_DS Format: InstructionBaseOffset[31:6]Kernel This field specifies the starting location of the kernel program run by threads spawned by this FF unit. It is specified as a 64-byte-granular offset from the Instruction Base Address. This field is ignored if DS Function Enable is DISABLED. 5:0 Reserved Project: All Format: MBZ 2 31 Single Domain Point Dispatch Format: U1 Enumerated Type This field can be used to force single domain point SIMD4x2 DS threads. Value Name Description 0h Multiple Dual domain point SIMD4x2 thread dispatches are allowed. 1h Single Single domain point SIMD4x2 thread dispatches are forced. 30 Vector Mask Enable (VME) Format: U1 Enumerated Type When SPF=0, VME specifies which mask to use to initialize the initial channel enables. When SPF=1, VME specifies which mask to use to generate execution channel enables. Value Name Description Project 0h Dmask Channels are enabled based on the dispatch mask 1h Vmask Channels are enabled based on the vector mask 29:27 Sampler Count Format: U3 Specifies how many samplers (in multiples of 4) the kernel uses. Used only for prefetching the associated sampler state entries. This field is ignored if DS Function Enable is DISABLED. Value Name Description Project 0h No Samplers no samplers used All 1h 1-4 Samplers between 1 and 4 samplers used All 2h 5-8 Samplers between 5 and 8 samplers used All 3h 9-12 Samplers between 9 and 12 samplers used All 4h 13-16 Samplers between 13 and 16 samplers used All 26 Reserved Format: MBZ 25:18 Binding Table Entry Count Format: U8 When HW Generated Binding Table is disabled: Specifies how many binding table entries the kernel uses. Used only for prefetching of the binding table entries and associated surface state. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 150 3DSTATE_DS Note:For kernels using a large number of binding table entries, it may be wise to set this field to zero to avoid prefetching too many entries and thrashing the state cache. This field is ignored if DS Function Enable is DISABLED. Value Name [0,255] 17 Reserved Format: MBZ 16 Floating Point Mode Format: U1 Enumerated Type Specifies the initial floating point mode used by the dispatched thread.This field is ignored if DS Function Enable is DISABLED. Value Name Description 0h IEEE-754 Use IEEE-754 Rules 1h Alternate Use alternate rules 15 Reserved Format: MBZ 14 Reserved Format: MBZ 13 Illegal Opcode Exception Enable Format: Enable This bit gets loaded into EU CR0.1[12] (note the bit # difference). See Exceptions and ISA Execution Environment.This field is ignored if DS Function Enable is DISABLED. 12:8 Reserved Format: MBZ 7 Software Exception Enable Format: Enable This bit gets loaded into EU CR0.1[13] (note the bit # difference). See Exceptions and ISA Execution Environment. This field is ignored if DS Function Enable is DISABLED. 6:0 Reserved Format: MBZ 3 31:10 Scratch Space Base Offset Format: GeneralStateOffset[31:10]ScratchSpace Specifies the starting location of the scratch space area allocated to this FF unit as a 1K-byte aligned offset from the General State Base Address. If required, each thread spawned by this FF unit will be Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 151 3DSTATE_DS allocated some portion of this space, as specified by Per-Thread Scratch Space. The computed offset of the thread-specific portion will be passed in the thread payload as Scratch Space Offset. The thread is expected to utilize “stateless” DataPort read/write requests to access scratch space, where the DataPort will cause the General State Base Address to be added to the offset passed in the request header.This field is ignored if DS Function Enable is DISABLED. 9:4 Reserved Format: MBZ 3:0 Per-Thread Scratch Space Format: U4 power of 2 Bytes over 1K Bytes Specifies the amount of scratch space to be allocated to each thread spawned by this FF unit.The driver must allocate enough contiguous scratch space, starting at the Scratch Space Base Pointer, to ensure that the Maximum Number of Threads can each get Per-Thread Scratch Space size without exceeding the driver-allocated scratch space. This field is ignored if DS Function Enable is DISABLED. Value Name [0,11] indicating [1K Bytes, 2M Bytes] 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, but the Data Port will ignore it. 4 31:25 Reserved Format: MBZ 24:20 Dispatch GRF Start Register for URB Data Format: U5 Specifies the starting GRF register number for the URB portion (Constant + Vertices) of the thread payload. This field is ignored if DS Function Enable is DISABLED. Value Name [0,31] indicating GRF [R0,R31] 19:18 Reserved Format: MBZ 17:11 Patch URB Entry Read Length Format: U7 Specifies how much data (in 256-bit units) is to be read from the Patch URB entry and passed in the DS thread payload. This field is ignored if DS Function Enable is DISABLED. Value Name [0, 64] 10 Reserved Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 152 3DSTATE_DS Format: MBZ 9:4 Patch URB Entry Read Offset Specifies the offset (in 256-bit units) at which Patch URB data is to be read from the URB before being included in the thread payload. This field is ignored if DS Function Enable is DISABLED. Value Name [0, 63] 3:0 Reserved Format: MBZ 5 31:25 Maximum Number of Threads Format: U7-1 Thread Count s Specifies the maximum number of simultaneous DS threads allowed to be active. Used to avoid using up the scratch space. Programming the value of the max threads over the number of threads based off number of threads supported in the execution units may improve performance since the architecture allows threads to be buffered between the check for max threads and the actual dispatch into the EU. Programming the max values to a number less than the number of threads supported in the execution units may reduce performance. This field is ignored if DS Function Enable is DISABLED. Value Name Description Project [0,127] indicating thread count of [1,128] [0,35] indicating thread count of [1,36] 24:21 Reserved Format: MBZ 20:11 Reserved 10 Statistics Enable Format: Enable If ENABLED, this FF unit will engage in statistics gathering. If DISABLED, statistics information associated with this FF stage will be left unchanged. This field is ignored if DS Function Enable is DISABLED. 9:3 Reserved 2 Compute W Coordinate Enable Format: Enable If ENABLED, the DS unit will (for each domain point) compute W = 1 – (U + V) and pass the result as a floating point value in the DS thread payload. If DISABLED, 0.0 will be passed. This field must only be ENABLED for the tessellation of TRI domains, where UVW coordinates are required. This field must be DISABLED for other domains (as they only require UV coordinates) otherwise the computed W coordinate is UNDEFINED. This field is ignored if DS Function Enable is DISABLED. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 153 3DSTATE_DS 1 DS Cache Disable Project: Format: Disable This bit controls the operation of the DS Cache. This field is ignored if DS Function Enable is DISABLED. If the DS Cache is DISABLED and the DS Function is ENABLED, the DS Cache is not used and all incoming domain points will be passed to DS threads. If the DS Cache is ENABLED and the DS Function is ENABLED, incoming domain points that do not hit in the DS Cache will be passed to DS threads. The DS Cache is invalidated whenever the DS Cache becomes DISABLED , whenever the DS Function Enable toggles, and between patches. 0 DS Function Enable Format: Enable If ENABLED, DS threads will be spawned to process incoming domain points which miss in the DS cache. If DISABLED, the DS stage goes into pass-through mode and performs no specific processing. This field is always used. Programming Notes The tessellation stages (HS, TE and DS) must be enabled/disabled as a group. I.e., draw commands can only be issued if all three stages are enabled or all three stages are disabled, otherwise the behavior is UNDEFINED. 6.1.1 3DSTATE_PUSH_CONSTANT_ALLOC_DS 3DSTATE_PUSH_CONSTANT_ALLOC_DS Source: RenderCS Length Bias: 2 This command sets up the URB configuration for DS Push Constant Buffer. Programming Notes Programming Restriction:  The sum of the Constant Buffer Offset and the Constant Buffer Size may not exceed the maximum value of the Constant Buffer Size.  The sum of the constant length programmed in 3DSTATE_CONSTANT_DS must be equal or smaller then the size of the allocated space in the URB including the buffering for half cachelines. See Push Constant URB Allocation section for more details.  The 3DSTATE_CONSTANT_DS must be reprogrammed prior to the next 3DPRIMITIVE command after programming the 3DSTATE_PUSH_CONSTANT_ALLOC_DS. DWord Bit Description 0 31:29 Command Type Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 154 3DSTATE_PUSH_CONSTANT_ALLOC_DS 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 GFXPIPE_NONPIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 14h 3DSTATE_PUSH_CONSTANT_ALLOC_DS 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:20 Reserved Format: MBZ 19:16 Constant Buffer Offset Format: U4 Specifies the offset of the DS constant buffer into the URB. Value Name [0,15] (0KB - 15KB) 0h 0KB [Default] 15:5 Reserved Format: MBZ 4:0 Constant Buffer Size Format: U5 Specifies the size of the DS constant buffer. This value will determine the amount of data the command stream can pre-fetch before the buffer is full. Value of zero is only valid when constants are not enabled for DS. Value Name [0,15] (0KB – 15KB) Increments of 1KB 0h 0KB [Default] Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 155 6.1.2 3DSTATE_CONSTANT_DS 3DSTATE_CONSTANT_DS Source: RenderCS Length Bias: 2 This command sets pointers to the push constants for the DS unit. The constant data pointed to by this command is loaded into the DS unit’s push constant buffer (PCB). Programming Notes Project It is invalid to execute this command more than once between 3D_PRIMITIVE commands. Constant buffers must be enabled in order from Constant Buffer 0 to Constant Buffer 3 within this command. For example, It is not allowed to enable Constant Buffer 1 by programming a non-zero value in the DS Constant Buffer 1 Read Length without a non-zero value in DS Constant Buffer 0 Read Length. DWord Bit Description 0 31:29 Command Type Default Value: 3h GFXPIPE Format: OpCode 28:27 Command SubType Default Value: 3h Format: OpCode 26:24 3D Command Opcode Default Value: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 1Ah 3DSTATE_CONSTANT_DS Format: OpCode 15:8 Reserved Format: MBZ 7:0 DWord Length Project: All Format: =n Total Length - 2 Value Name Project 5h Excludes DWord (0,1) [Default] 1..6 191:0 Constant Body Format: 3DSTATE_CONSTANT(Body) Following table is the shared portion of the 3DSTATE_CONSTANT command for VS, HS, DS, and GS Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 156 3DSTATE_CONSTANT(Body) Project: All Source: RenderCS Default Value: 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 DWord Bit Description 0 31:16 Constant Buffer 1 Read Length Project: All Format: U16 read length This field specifies the length of the constant data to be loaded from memory in 256-bit units. Programming Notes  The sum of all four read length fields must be less than or equal to the size of 64  Setting the value of the register to zero will disable buffer 1.  If disabled, the Pointer to Constant Buffer 1 must be programmed to zero. 15:0 Constant Buffer 0 Read Length Project: All Format: U16 read length This field specifies the length of the constant data to be loaded from memory in 256-bit units. Programming Notes  The sum of all four read length fields must be less than or equal to the size of 64  Setting the value of the register to zero will disable buffer 0.  If disabled, the Pointer to Constant Buffer 0 must be programmed to zero. 1 31:16 Constant Buffer 3 Read Length Project: All Format: U16 read length This field specifies the length of the constant data to be loaded from memory in 256-bit units. Programming Notes  The sum of all four read length fields must be less than or equal to the size of 64  Setting the value of the register to zero will disable buffer 3.  If disabled, the Pointer to Constant Buffer 3 must be programmed to zero. 15:0 Constant Buffer 2 Read Length Project: All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 157 3DSTATE_CONSTANT(Body) Format: U16 read length This field specifies the length of the constant data to be loaded from memory in 256-bit units. Programming Notes  The sum of all four read length fields must be less than or equal to the size of 64  Setting the value of the register to zero will disable buffer 2.  If disabled, the Pointer to Constant Buffer 2 must be programmed to zero. 2 31:5 Pointer to Constant Buffer 0 Project: All Format: GraphicsAddress[31:5]ConstantBuffer This field points to the location of Constant Buffer 0. The state of INSTPM determines whether the Dynamic State Base Address is added to this pointer. Programming Notes Constant buffers must be allocated in linear (not tiled) graphics memory. 4:0 Constant Buffer Object Control State Format: MEMORY_OBJECT_CONTROL_STATE Specifies the memory object control state for all constant buffers defined in this command. 3 31:5 Pointer to Constant Buffer 1 Format: GraphicsAddress[31:5]ConstantBuffer This field points to the location of Constant Buffer 1. Programming Notes Constant buffers must be allocated in linear (not tiled) graphics memory. 4:0 Reserved Project: All Format: MBZ 4 31:5 Pointer to Constant Buffer 2 Format: GraphicsAddress[31:5]ConstantBuffer This field points to the location of Constant Buffer 2. Programming Notes Constant buffers must be allocated in linear (not tiled) graphics memory. 4:0 Reserved Project: All Format: MBZ 5 31:5 Pointer to Constant Buffer 3 Format: GraphicsAddress[31:5]ConstantBuffer This field points to the location of Constant Buffer 3. Programming Notes Constant buffers must be allocated in linear (not tiled) graphics memory. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 158 3DSTATE_CONSTANT(Body) 4:0 Reserved Format: MBZ 6.2 Thread Payload The following tables describe the payload delivered to DS threads. DS Thread Payload (SIMD4x2) DWord Bit Description R0.7 31 Snapshot Flag 30:0 Reserved R0.6 31:24 Reserved 23:0 Thread ID: This field uniquely identifies this thread within the threads spawned by this FF unit, over some period of time. Format: Reserved for HW Implementation Use. R0.5 31:10 Scratch Space Offset: Specifies the of the scratch space allocated to the thread, specified as a 1KB-granular offset from the General State Base Address. See Scratch Space Base Offset description in VS_STATE. (See 3D Pipeline for further description on scratch space allocation). Format = GeneralStateOffset[31:10] 9.0 Reserved 8:0 FFTID: This ID is assigned by the FF unit and used to identify the thread within the set of outstanding threads spawned by the FF unit. Format: Reserved for HW Implementation Use. Format: U9 R0.4 31:5 Binding Table Pointer. Specifies the 32-byte aligned pointer to the Binding Table. It is specified as an offset from the Surface State Base Address. Format = SurfaceStateOffset[31:5] 4:0 Reserved R0.3 31:5 Sampler State Pointer. Specifies the location of the Sampler State Table to be used by this thread, specified as a 32-byte granular offset from the General State Base Address or Dynamic State Base Address. Format = DynamicStateOffset[31:5] 4 Reserved 3:0 Per Thread Scratch Space: Specifies the amount of scratch space allowed to be used by this thread. The value specifies the power that two will be raised to (over determine the amount of Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 159 DWord Bit Description scratch space). Format = U4 power of two (in excess of 10) Range = [0,11] indicating [1K Bytes, 2M Bytes] R0.2 31:0 Reserved : delivered as zeros (reserved for message header fields) R0.1 31:26 Reserved 25:16 Handle ID 1: This ID is assigned by the FF unit and used to identify the URB Return Handle 1 to the FF unit (as FF-specific index value, not a URB address). If only one vertex is to be processed (shaded) by the thread, this field will effectively be ignored (no results are stored for these channels, as controlled by the thread’s Channel Mask). Format = Reserved for HW Implementation Use. 15:14 Reserved 13:0 URB Return Handle 1: This is the URB handle where Vertex 1 data (the EU’s upper channels (DWords 7:4)) results are to be stored. If only one vertex is to be processed (shaded) by the thread, this field will effectively be ignored (no results are stored for these channels, as controlled by the thread’s Channel Mask). Format: U12 handle (512-bit granular); Bit 13:12 Reserved R0.0 31:26 Reserved 25:16 Handle ID 0: This ID is assigned by the FF unit and used to identify the URB Return Handle 0 to the FF unit (as FF-specific index value, not a URB address). Format = Reserved for HW Implementation Use. 15:14 Reserved 13:0 URB Return Handle 0: This is the URB handle where Vertex 0 data (the EU’s lower channels (DWords 3:0)) results are to be stored. Format: U12 handle (512-bit granular); Bit 13:12 Reserved R1.7 31:0 PrimitiveID: This is the 32-bit PrimitiveID value associated with the patch. It is common to all output vertices resulting from the tessellation of the patch. Format: U32 R1.6 31:0 Domain Point 1 W Coordinate: (See Domain Point 0 W Coordinate) Format: FLOAT32 R1.5 31:0 Domain Point 1 V Coordinate: (See Domain Point 0 V Coordinate) Format: FLOAT32 R1.4 31:0 Domain Point 1 U Coordinate: (See Domain Point 0 U Coordinate) Format: FLOAT32 R1.3 31:14 Reserved Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 160 DWord Bit Description 13:0 Patch URB Handle: This is the URB handle of the Patch Record (common to both vertices). Format: U12 handle; Bit 13:12 Reserved R1.2 31:0 Domain Point 0 W Coordinate: If Compute W Coordinate Enable is set, this field will receive the computed value (1 – U – V) for Domain Point 0. Otherwise it is passed as 0.0. Format: FLOAT32 R1.1 31:0 Domain Point 0 V Coordinate: V coordinate associated with Domain Point 0. Format: FLOAT32 R1.0 31:0 Domain Point 0 U Coordinate: U coordinate associated with Domain Point 0. Format: FLOAT32 Varies 255:0 Constant Data (optional) : [Optional] Some amount of constant data (possible none) can be extracted from the push constant buffer (PCB) and passed to the thread following the R0 Header. The amount of data provided is defined by the sum of the read lengths in the last 3DSTATE_CONSTANT_DS command (taking the buffer enables into account). The Constant Data arrives in a non-interleaved format. 255:0 Varies Patch URB Data (optional): Some amount of Patch Data (possible none) can be extracted from the URB and passed to the thread in this location in the payload. The amount of data [Optional] provided is defined by the Patch URB Entry Read Length state (3DSTATE_DS) The Patch Data arrives in a non-interleaved format. DS Thread Payload (SIMD8) DWord Bit Description R0.7 31 Snapshot Flag 30:0 Reserved R0.6 31:24 Reserved 23:0 Thread ID: This field uniquely identifies this thread within the threads spawned by this FF unit, over some period of time. Format: Reserved for HW Implementation Use. R0.5 31:10 Scratch Space Offset: Specifies the of the scratch space allocated to the thread, specified as a 1KB-granular offset from the General State Base Address. See Scratch Space Base Offset description in VS_STATE. (See 3D Pipeline for further description on scratch space allocation). Format = GeneralStateOffset[31:10] 9.0 Reserved 8:0 FFTID: This ID is assigned by the FF unit and used to identify the thread within the set of Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 161 DWord Bit Description outstanding threads spawned by the FF unit. Format: Reserved for HW Implementation Use. Format: U9 R0.4 31:5 Binding Table Pointer. Specifies the 32-byte aligned pointer to the Binding Table. It is specified as an offset from the Surface State Base Address. Format = SurfaceStateOffset[31:5] 4:0 Reserved R0.3 31:5 Sampler State Pointer. Specifies the location of the Sampler State Table to be used by this thread, specified as a 32-byte granular offset from the General State Base Address or Dynamic State Base Address. Format = DynamicStateOffset[31:5] 4 Reserved 3:0 Per Thread Scratch Space: Specifies the amount of scratch space allowed to be used by this thread. The value specifies the power that two will be raised to (over determine the amount of scratch space). Format = U4 power of two (in excess of 10) Range = [0,11] indicating [1K Bytes, 2M Bytes] R0.2 31:0 Reserved : delivered as zeros (reserved for message header fields) R0.1 31:0 PrimitiveID: This is the 32-bit PrimitiveID value associated with the patch. It is common to all output domain points resulting from the tessellation of the patch. Format: U32 R0.0 31:27 Reserved 26:16 Patch Handle ID: This ID is assigned by the FF unit and used to identify the patch URB entry to the FF unit (as FF-specific index value, not a URB address). Format = Reserved for HW Implementation Use. 15:0 Patch URB Offset: This is the offset within the URB where the patch data is stored. Format: U14 64B-granular offset into the URB R1.7 31:0 Domain Point 7 U Coordinate. (See Domain Point 0 U Coordinate) R1.6 31:0 Domain Point 6 U Coordinate. (See Domain Point 0 U Coordinate) R1.5 31:0 Domain Point 5 U Coordinate. (See Domain Point 0 U Coordinate) R1.4 31:0 Domain Point 4 U Coordinate. (See Domain Point 0 U Coordinate) R1.3 31:0 Domain Point 3 U Coordinate. (See Domain Point 0 U Coordinate) R1.2 31:0 Domain Point 2 U Coordinate. (See Domain Point 0 U Coordinate) R1.1 31:0 Domain Point 1 U Coordinate. (See Domain Point 0 U Coordinate) R1.0 31:0 Domain Point 0 U Coordinate: U coordinate associated with Domain Point 0. Format: FLOAT32 R2.7 31:0 Domain Point 7 V Coordinate. (See Domain Point 0 V Coordinate) R2.6 31:0 Domain Point 6 V Coordinate. (See Domain Point 0 V Coordinate) R2.5 31:0 Domain Point 5 V Coordinate. (See Domain Point 0 V Coordinate) Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 162 DWord Bit Description R2.4 31:0 Domain Point 4 V Coordinate. (See Domain Point 0 V Coordinate) R2.3 31:0 Domain Point 3 V Coordinate. (See Domain Point 0 V Coordinate) R2.2 31:0 Domain Point 2 V Coordinate. (See Domain Point 0 V Coordinate) R2.1 31:0 Domain Point 1 V Coordinate. (See Domain Point 0 V Coordinate) R2.0 31:0 Domain Point 0 V Coordinate: V coordinate associated with Domain Point 0. Format: FLOAT32 R3.7 31:0 Domain Point 7 W Coordinate. (See Domain Point 0 W Coordinate) R3.6 31:0 Domain Point 6 W Coordinate. (See Domain Point 0 W Coordinate) R3.5 31:0 Domain Point 5 W Coordinate. (See Domain Point 0 W Coordinate) R3.4 31:0 Domain Point 4 W Coordinate. (See Domain Point 0 W Coordinate) R3.3 31:0 Domain Point 3 W Coordinate. (See Domain Point 0 W Coordinate) R3.2 31:0 Domain Point 2 W Coordinate. (See Domain Point 0 W Coordinate) R3.1 31:0 Domain Point 1 W Coordinate. (See Domain Point 0 W Coordinate) R3.0 31:0 Domain Point 0 W Coordinate: If Compute W Coordinate Enable is set, this field will receive the computed value (1 – U – V) for Domain Point 0. Otherwise it is passed as 0.0. Format: FLOAT32 R4.7 31:0 Domain Point 7 URB Return Handle (see R4.0) R4.6 31:0 Domain Point 6 URB Return Handle (see R4.0) R4.5 31:0 Domain Point 5 URB Return Handle (see R4.0) R4.4 31:0 Domain Point 4 URB Return Handle (see R4.0) R4.3 31:0 Domain Point 3 URB Return Handle (see R4.0) R4.2 31:0 Domain Point 2 URB Return Handle (see R4.0) R4.1 31:0 Domain Point 1 URB Return Handle (see R4.0) R4.0 31:16 Reserved 15:0 Domain Point 0 URB Return Handle: This is the offset within the URB where domain point 0 is to be stored. Format: U14 64B-granular offset into the URB Varies 255:0 Constant Data (optional) : [Optional] Some amount of constant data (possible none) can be extracted from the push constant buffer (PCB) and passed to the thread following the R0 Header. The amount of data provided is defined by the sum of the read lengths in the last 3DSTATE_CONSTANT_DS command (taking the buffer enables into account). 255:0 Varies Patch URB Data (optional): [Optional] Some amount of Patch Data (possible none) can be extracted from the URB and passed to the thread in this location in the payload. The amount of data provided is defined by the Patch URB Entry Read Length state (3DSTATE_DS) 6.3 DS Thread Execution A DS kernel assumes it is to operate on two domain points in parallel using the EU’s SIMD4x2 execution model . Refer to ISA chapters for specifics on writing kernels that operate in SIMD4x2 fashion. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 163 DS threads must always write the destination URB handles passed in the payload. DS threads are not permitted to request additional destination handles. Refer to 3D Pipeline Stage Overview ( 3D Overview) for details on how destination vertices are written and any required contents/formats. DS threads must signal thread termination on the last message output to the URB shared function. 6.4 Statistics Gathering The DS stage maintains the DS_INVOCATIONS statistics counter, which counts the number of incoming domain points, irrespective of cache hit/miss. Note that this is different than VS_INVOCATIONS, which counts shader invocations and therefore doesn’t count cache hits. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 164 7. 3D Pipeline – Geometry Shader (GS) Stage 7.1 GS Stage Overview The GS stage of the 3D Pipeline is used to convert objects within incoming primitives into new primitives through use of a spawned thread. When enabled, the GS unit buffers incoming vertices, assembles the vertices of each individual object within the primitives, and passes these object vertices (along with other data) to the subsystem for processing by a GS thread. When the GS stage is disabled, vertices flow through the unit unmodified. Refer to the Common 3D FF Unit Functions subsection in the 3D Pipeline chapter for a general description of a 3D Pipeline stage, as much of the GS stage operation and control falls under these “common” functions; i.e., most stage state variables and GS thread payload parameters are described in 3D Pipeline, and although they are listed here for completeness, that chapter provides the detailed description of the associated functions. Refer to this chapter for an overall description of the GS stage, and any exceptions the GS stage exhibits with respect to common FF unit functions. 7.2 GS Stage Input As a stage of the 3D pipeline, the GS stage receives inputs from the previous ( DS) stage. Refer to 3D Pipeline for an overview of the various types of input to a 3D Pipeline stage. The remainder of this subsection describes the inputs specific to the GS stage. 7.2.1 State 7.2.1.1 3DSTATE_GS The state used by GS is defined with this inline state packet. 3DSTATE_GS Source: RenderCS Length Bias: 2 Controls the GS stage hardware. 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 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 165 3DSTATE_GS 26:24 3D Command Opcode Default Value: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 11h 3DSTATE_GS Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 5h Excludes DWord (0,1) Format: =n 1 31:6 Kernel Start Pointer Project: All Format: InstructionBaseOffset[31:6]Kernel This field specifies the starting location (1st core instruction) of the kernel program run by threads spawned by this FF unit. It is specified as a 64-byte-granular offset from the Instruction Base Address. 5:0 Reserved Project: All Format: MBZ 2 31 Single Program Flow (SPF) Project: All Specifies the initial condition of the kernel program as either a single program flow (SIMDnxm with m = 1) or as multiple program flows (SIMDnxm with m > 1). See CR0 description in ISA Execution Environment. Value Name Description 0h Disable Single Program Flow disabled 1h Enable Single Program Flow enabled 30 Vector Mask Enable (VME) Project: All Format: U1 enumerated type When SPF=0, VME specifies which mask to use to initialize the initial channel enables. When SPF=1, VME specifies which mask to use to generate execution channel enables. Value Name Description 0h Dmask Channels are enabled based on the dispatch mask 1h Vmask Channels are enabled based on the vector mask 29:27 Sampler Count Project: All Format: U3 Specifies how many samplers (in multiples of 4) the geometry shader kernel uses. Used only for prefetching the associated sampler state entries. Value Name Description 0h No Samplers no samplers used 1h 1-4 Samplers between 1 and 4 samplers used 2h 5-8 Samplers between 5 and 8 samplers used Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 166 3DSTATE_GS 3h 9-12 Samplers between 9 and 12 samplers used 4h 13-16 Samplers between 13 and 16 samplers used 5h-7h Reserved Reserved 26 Reserved Project: All Format: MBZ 25:18 Binding Table Entry Count Project: All Format: U8 When HW Generated Binding Table is disabled: Specifies how many binding table entries the kernel uses. Used only for prefetching of the binding table entries and associated surface state. Note: For kernels using a large number of binding table entries, it may be wise to set this field to zero to avoid prefetching too many entries and thrashing the state cache. 17 Thread Priority Project: All Specifies the priority of the thread for dispatch Value Name Description 0h Normal Priority Normal Priority 1h High Priority High Priority 16 Floating Point Mode Project: All Specifies the initial floating point mode used by the dispatched thread. Value Name Description 0h IEEE-754 Use IEEE-754 Rules 1h alternate Use alternate rules 15:14 Reserved Project: All Format: MBZ 13 Illegal Opcode Exception Enable Project: All Format: Enable Double Buffer This bit gets loaded into EU CR0.1[12] (note the bit # difference). See Exceptions Armed By: and ISA Execution Environment. 12 Reserved Format: MBZ 11 Mask Stack Exception Enable Project: All Format: Enable Double Buffer Armed This bit gets loaded into EU CR0.1[11]. See Exceptions and ISA Execution By: Environment. 10:8 Reserved Project: All Format: MBZ 7 Software Exception Enable Project: All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 167 3DSTATE_GS Format: Enable This bit gets loaded into EU CR0.1[13] (note the bit # difference). See Exceptions and ISA Execution Environment. 6 Reserved Project: All Format: MBZ 5:0 Reserved Format: MBZ 3 31:10 Scratch Space Base Pointer Project: All Format: GeneralStateOffset[31:10] Specifies the location of the scratch space area allocated to this FF unit, specified as a 1KB-granular offset from the General State Base Address. If required, each thread spawned by this FF unit will be allocated some portion of this space, as specified by Per-Thread Scratch Space. 9:4 Reserved Project: All Format: MBZ 3:0 Per-Thread Scratch Space Project: All Format: U4 Power of 2 Bytes over 1K Bytes Specifies the amount of scratch space to be allocated to each thread spawned by this FF unit.The driver must allocate enough contiguous scratch space, starting at the Scratch Space Base Pointer, to ensure that the Maximum Number of Threads can each get Per-Thread Scratch Space size without exceeding the driver-allocated scratch space. Value Name [0,11] indicating [1K Bytes, 2M Bytes] 4 31:29 Reserved Project: All Format: MBZ 28:23 Output Vertex Size Project: All Format: U6 [0,62] indicating [1,63] 16B units Specifies the size of each vertex stored in the GS output entry (following any Control Header data) as a number of 128-bit units (minus one). Programming Notes Programming Restrictions: The vertex size must be programmed as a multiple of 32B units with the following exception: Rendering is disabled (as per SOL stage state) and the vertex size output by the GS thread is 16B. If rendering is enabled (as per SOL state) the vertex size must be programmed as a multiple of 32B Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 168 3DSTATE_GS units. In other words, the only time software can program a vertex size with an odd number of 16B units is when rendering is disabled. 22:17 Output Topology Project: All Format: 3DPrimType This field specifies the topology type (3DPrimType) to be associated with GS-thread output vertices (if any). 16:11 Vertex URB Entry Read Length Project: All Format: U6 Specifies the amount of URB data read and passed in the thread payload for each Vertex URB entry, in 256-bit register increments. Value Name [0,63] Programming Notes Programming Restriction:This field must be a non-zero value if Include Vertex Handles is cleared to zero. 10 Include Vertex Handles Project: All Format: Boolean If set, all the input Vertex URB handles are included in the payload. These are referred to as “pull model” URB handles, as the thread will use them to read from the URB. Programming Notes This field must be set if Vertex URB Entry Read Length is cleared to zero. When this field is set and GS is enabled, only PATCHLIST topologies may be submitted. I.e., pull- model vertices are only supported for PATCH objects, other object types must completely push all vertex data into the payload. 9:4 Vertex URB Entry Read Offset Project: All Format: U6 Double Buffer Specifies the offset (in 256-bit units) at which Vertex URB data is to be read from the Armed By: URB before being included in the thread payload. This offset applies to all Vertex URB entries passed to the thread. Value Name [0,63] 3:0 Dispatch GRF Start Register for URB Data Project: All Format: U4 Specifies the starting GRF register number for the URB portion (Constant + Vertices) of the thread payload. Value Name [0,15] indicating GRF [R0,R15] Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 169 3DSTATE_GS Programming Notes If Include Vertex Handles is enabled (pull or hybrid handles case), then For DUAL_OBJECT dispatch mode this field should be: (((2*numVerticesPerObject) + 8 – 1)/8) + 1 For SINGLE and DUAL_INSTANCE dispatch modes this field should be: ((numVerticesPerObject +8 – 1)/8) + 1 If Include Primitive ID is set, then add 1 to the value obtained by using the above 5 31:25 Maximum Number of Threads Format: U7-1 thread count Specifies the maximum number of simultaneous threads allowed to be active. Used to avoid using up the scratch space, or to avoid potential deadlock. Value Name Project [0,127] indicating thread count of [1,128] [0,35] indicating thread count of [1,36] 24 Control Data Format Format: U1 This field specifies the format of the control data header (if any). Value Name Description 0h GSCTL_CUT The control data header contains cut bits. 1h GSCTL_SID The control data header contains StreamID bits. . Output Topology must be set to POINTLIST, or behavior is UNDEFINED. 23:20 Control Data Header Size Project: All Format: U4 Specifies the number of 32B units of control data header located at the start of the GS URB entry. The value 0 indicates there is no control data header, and Control Data Format is ignored.Software must ensure that the Control Data Header Size is sufficient to accommodate the maixumum number of vertices output by the GS thread. It is UNDEFINED for a GS thread to report more output vertices than can be accomodated in a non-zero-sized header. (If the header size is zero, by definition neither cut nor StreamID bits are defined. Value Name [0,8] 32B units 19:15 Instance Control Project: All Format: U5-1 in #instances [0,31] indicating [1,32] instances Specifies the number of instances (minus one) for each input object. To avoid confusion, this document uses the term “InstanceCount” to refer to InstanceControl+1, with a range of [1,32]If Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 170 3DSTATE_GS InstanceCount>1, DUAL_OBJECT mode is invalid. Software will likely want to use DUAL_INSTANCE mode for higher performance, but SINGLE mode is also supported.When InstanceCount=1 (one instance per object) software can decide which dispatch mode to use. DUAL_OBJECT mode would likely be the best choice for performance, followed by SINGLE mode. DUAL_INSTANCE mode is not recommended but is supported. 14:13 Default StreamID Project: All Format: U2 When the GS is enabled, unless the GS output entry contains StreamID bits in the control header, this field specifies the default StreamID associated with any GS-thread output vertices. When the GS is disabled, StreamID will be output as 0. 12:11 Dispatch Mode Project: All Format: U2 This field specifies how the GS unit dispatches multiple instances and/or multiple objects. Value Name Description 0h SINGLE Each thread shades a single instance of one object. 1h DUAL_INSTANCE Each thread shades possibly two instances of one object. If the InstanceCount is odd, a trailing dispatch of only one instance will be made for each object received.Not recommended if InstanceCount = 1, assuming a kernel optimized for SINGLE or DUAL_OBJECT dispatch would outperform a kernel compiled for DUAL_INSTANCE but only passed one instance.The GS must be allocated at least two URB handles or behavior is UNDEFINED. 2h DUAL_OBJECT Each thread shades one instance of possibly two objects. The GS unit attempt to pair objects together into one dispatch, but under some circumstances only one object may be dispatched (as controlled by the DispatchMask generated by the GS unit).Not valid for objects with more than 16 vertices per object. Not valid if InstanceCount > 1 (more than one instance per object).The GS must be allocated at least two URB handles or behavior is UNDEFINED. 3h Reserved 10 GS Statistics Enable Project: All This bit controls whether GS-unit-specific statistics register(s) can be incremented. Value Name Description 0h Disable GS_INVOCATIONS_COUNT and GS_PRIMITIVES_COUNT cannot increment 1h Enable GS_INVOCATIONS_COUNT and GS_PRIMITIVES_COUNT can increment 9:5 GSInvocations Increment Value Project: All Format: U5 Specifies how much to increment the GS_INVOCATIONS_COUNT for each instance of each object. This control is provided to allow software to process multiple instances (from an API POV) in a single kernel invocation.In SINGLE dispatch mode, the counter will increment by this value for each dispatch (as it’s only one instance of one object). In DUAL_INSTANCE mode, the counter will be incremented by the value if only one instance is included in the dispatch (i.e., the last odd instance), otherwise the counter will be incremented by twice this value.In DUAL_OBJECT dispatch mode, the counter will be incremented by the value if only one object is included in the dispatch (i.e., a forced dispatch of one object), otherwise the counter will be incremented by twice this value. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 171 3DSTATE_GS Value Name [0,31] indicating an increment of [1,32] 4 Include Primitive ID Project: All Format: Boolean If set, R1 of the payload is written with Primitive ID value(s).If clear, these Primitive ID values are not included in the payload R1. 3 Hint Project: All Format: U1 This state bit is simply passed in GS thread payloads for use by the GS kernel – it has no other impact on hardware operation. 2 Reorder Enable Format: Enable This bit controls whether the GS unit reorders TRISTRIP/TRISTRIP_REV vertices passed in the GS thread payload.If ENABLED, the GS unit will reorder the vertices for “odd-numbered” triangles originating from TRISTRIP topologies and “even-numbered” triangles originating from TRISTRIP_REV topologies. (Note that the first triangle is considered “triangle 0”, which is even-numbered).With respect to the PrimType passed in the GS thread payload, the GS unit passes TRISTRIP when the vertices are not reordered, and TRISTRIP_REV when the vertices are reordered (regardless of whether a TRISTRIP or TRISTRIP_REV topology was being processed)If DISABLED, TRISTRIP/TRISTRIP_REV vertices are not reordered, and always passed in the order they are received from the pipeline. The GS unit will still toggle PrimType on alternating (as described above) so that the GS thread can perform the reordering internally (or do whatever is necessary to account for the non-reordering of its input). 1 Discard Adjaceny Project: All Format: Enable When set, adjacent vertices will not be passed in the GS payload when objects with adjacency are processed. Instead, only the non-adjacent vertices will be passed in the same fashion as the without- adjacency form of the primitive. Software should set this bit whenever a GS kernel is used that does not expect adjacent vertices. This allows both with-adjacency/without-adjacency variants of the primitive to be submitted to the pipeline (via 3DPRIMITIVE) – the GS unit will silently discard any adjacent vertices and present the GS thread with only the internal object. When clear, adjacent vertices will be passed to the GS thread, as dictated by the incoming primitive type. Software should only clear this bit when a GS kernel is used that does expect adjacent vertices. E.g., if the GS kernel is compiled to expect a TRIANGLE_ADJ object, software must clear this bit.Software should also clear this bit if the GS kernel expects a POINT or PATCHLIST_n object (which don’t have with-adjacency variants).This bit is used to provide limited compatibility between submitted primitive types and the object type expected by the GS kernel. The only hardware assistance is to allow the submission of a with- adjacency variant of a primitive when operating with a GS kernel that expects the without-adjacency variant of the object. (E.g., when the GS kernel is compiled to expect a TRIANGLE object, software should set this bit just in case a TRILIST_ADJ is submitted to the pipeline.) Note that the GS unit is otherwise not aware of the object type that is expected by the GS kernel. It is up to software to ensure that the submitted primitive type (in 3DPRIMITIVE) is otherwise compatible with the object type expected by the GS kernel. (E.g., if the GS kernel expects a LINE_ADJ object, only LINELIST_ADJ or LINESTRIP_ADJ should be submitted, otherwise the GS kernel will produce unpredictable results.)Also Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 172 3DSTATE_GS note that it is possible to craft a GS kernel which can accept any object type that’s thrown at it by first examining the PrimType passed in the payload and then using this info to correctly interpret the number of vertices passed in the payload. 0 GS Enable Project: All Format: Enable Specifies whether the GS stage is enabled or disabled (pass-through). 6 31 Reserved Format: MBZ 30:13 Reserved Project: All Format: MBZ 12 Reserved Format: MBZ 11:0 Semaphore Handle Project: Format: URBOffset[17:6] This is the URB offset pointing to the first of the GS semaphore DWords in the URB. The size of the region is 128 DWs(8 – 512b URB entries). Software is responsible for allocating combined GS and/or HS semaphore Dwords in a single contiguous region of the URB. Software must also make sure the 3D pipeline is IDLE prior to allocating or deallocating the region. The semaphores can be located in an unused area within a FF unit’s URB fenced region or an unused area within the Push Constant region. 7.2.1.2 3DSTATE_CONSTANT_GS 3DSTATE_CONSTANT_GS Source: RenderCS Length Bias: 2 This command sets pointers to the push constants for the GS unit. The constant data pointed to by this command will be loaded into the GS unit’s push constant buffer (PCB). Programming Notes Project It is invalid to execute this command more than once between 3D_PRIMITIVE commands. Constant buffers must be enabled in order from Constant Buffer 0 to Constant Buffer 3 within this command. For example, it is not allowed to enable Constant Buffer 1 by programming a non-zero value in the GS Constant Buffer 1 Read Length without a non-zero value in GS Constant Buffer 0 Read Length. DWord Bit Description 0 31:29 Command Type Default Value: 3h GFXPIPE Format: OpCode 28:27 Command SubType Default Value: 3h Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 173 3DSTATE_CONSTANT_GS Format: OpCode 26:24 3D Command Opcode Default Value: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 16h 3DSTATE_CONSTANT_GS Format: OpCode 15 Reserved Project: All Format: MBZ 14:8 Reserved Format: MBZ 7:0 DWord Length Project: All Format: =n Total Length - 2 Value Name Project 5h Excludes DWord (0,1) [Default] 1..6 191:0 Constant Body Format: 3DSTATE_CONSTANT(Body) Following table is the shared portion of the 3DSTATE_CONSTANT command for VS, HS, DS, and GS 3DSTATE_CONSTANT(Body) Project: All Source: RenderCS Default Value: 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 DWord Bit Description 0 31:16 Constant Buffer 1 Read Length Project: All Format: U16 read length This field specifies the length of the constant data to be loaded from memory in 256-bit units. Programming Notes  The sum of all four read length fields must be less than or equal to the size of 64  Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 174 3DSTATE_CONSTANT(Body) Setting the value of the register to zero will disable buffer 1.  If disabled, the Pointer to Constant Buffer 1 must be programmed to zero. 15:0 Constant Buffer 0 Read Length Project: All Format: U16 read length This field specifies the length of the constant data to be loaded from memory in 256-bit units. Programming Notes  The sum of all four read length fields must be less than or equal to the size of 64  Setting the value of the register to zero will disable buffer 0.  If disabled, the Pointer to Constant Buffer 0 must be programmed to zero. 1 31:16 Constant Buffer 3 Read Length Project: All Format: U16 read length This field specifies the length of the constant data to be loaded from memory in 256-bit units. Programming Notes  The sum of all four read length fields must be less than or equal to the size of 64  Setting the value of the register to zero will disable buffer 3.  If disabled, the Pointer to Constant Buffer 3 must be programmed to zero. 15:0 Constant Buffer 2 Read Length Project: All Format: U16 read length This field specifies the length of the constant data to be loaded from memory in 256-bit units. Programming Notes  The sum of all four read length fields must be less than or equal to the size of 64  Setting the value of the register to zero will disable buffer 2.  If disabled, the Pointer to Constant Buffer 2 must be programmed to zero. 2 31:5 Pointer to Constant Buffer 0 Project: All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 175 3DSTATE_CONSTANT(Body) Format: GraphicsAddress[31:5]ConstantBuffer This field points to the location of Constant Buffer 0. The state of INSTPM determines whether the Dynamic State Base Address is added to this pointer. Programming Notes Constant buffers must be allocated in linear (not tiled) graphics memory. 4:0 Constant Buffer Object Control State Format: MEMORY_OBJECT_CONTROL_STATE Specifies the memory object control state for all constant buffers defined in this command. 3 31:5 Pointer to Constant Buffer 1 Format: GraphicsAddress[31:5]ConstantBuffer This field points to the location of Constant Buffer 1. Programming Notes Constant buffers must be allocated in linear (not tiled) graphics memory. 4:0 Reserved Project: All Format: MBZ 4 31:5 Pointer to Constant Buffer 2 Format: GraphicsAddress[31:5]ConstantBuffer This field points to the location of Constant Buffer 2. Programming Notes Constant buffers must be allocated in linear (not tiled) graphics memory. 4:0 Reserved Project: All Format: MBZ 5 31:5 Pointer to Constant Buffer 3 Format: GraphicsAddress[31:5]ConstantBuffer This field points to the location of Constant Buffer 3. Programming Notes Constant buffers must be allocated in linear (not tiled) graphics memory. 4:0 Reserved Format: MBZ Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 176 7.2.1.3 3DSTATE_PUSH_CONSTANT_ALLOC_GS 3DSTATE_PUSH_CONSTANT_ALLOC_GS Source: RenderCS Length Bias: 2 This command sets up the URB configuration for GS Push Constant Buffer. Programming Notes  The sum of the Constant Buffer Offset and the Constant Buffer Size may not exceed the maximum value of the Constant Buffer Size.  The sum of the constant length programmed in 3DSTATE_CONSTANT_GS must be equal or smaller then the size of the allocated space in the URB including the buffering for half cachelines.  The 3DSTATE_CONSTANT_GS must be reprogrammed prior to the next 3DPRIMITIVE command after programming the 3DSTATE_PUSH_CONSTANT_ALLOC_GS. See Push Constant URB Allocation section for more details. 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 GFXPIPE_NONPIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 15h 3DSTATE_PUSH_CONSTANT_ALLOC_GS Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Format: =n Total Length - 2 Value Name Description 0h 3DSTATE_PUSH_CONSTANT_ALLOC_GS [Default] Excludes DWord (0,1) 1 31:20 Reserved Format: MBZ 19:16 Constant Buffer Offset Format: U5 Specifies the offset of the GS constant buffer into the URB. Value Name [0,15] (0KB - 15KB) 0h 0KB [Default] Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 177 3DSTATE_PUSH_CONSTANT_ALLOC_GS 15:5 Reserved Format: MBZ 4:0 Constant Buffer Size Format: U5 Specifies the size of the GS constant buffer. This value will determine the amount of data the command stream can pre-fetch before the buffer is full. Value of zero is only valid when constants are not enabled for GS. Value Name [0,15] (0KB – 15KB) Increments of 1KB 0h 0KB [Default] 7.3 Object Staging The GS unit’s Object Staging Buffer (OSB) accepts primitive topologies as a stream of incoming vertices, and spawns a thread for each individual object within the topology. 7.4 GS Thread Request Generation 7.4.1 Object Vertex Ordering The following table defines the number and order of object vertices passed in the Vertex Data portion of the GS thread payload, assuming an input topology with N vertices. The ObjectType passed to the thread is, by default, the incoming PrimTopologyType. Exceptions to this rule (for the TRISTRIP variants) are called out. The following table also shows which vertex is selected to provide PrimitiveID (bold, underlined vertex number). In general, the vertex selected is the last vertex for non-adjacent prims, and the next-to-last vertex for adjacent prims. Note, however, that there are exceptions:  reorder-enabled TRISTRIP[_REV]  “odd-numbered” objects in TRISTRIP_ADJ PrimTopologyType Order of Vertices in Payload GS Notes [] = (,…); [ {modified PrimType passed to (N = # of vertices) thread} ] POINTLIST [0] = (0); [1] = (1); …; [N-2] = (N-2); POINTLIST_BF N/A LINELIST [0] = (0,1); Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 178 PrimTopologyType Order of Vertices in Payload GS Notes [] = (,…); [ {modified PrimType passed to (N = # of vertices) thread} ] (N is multiple of 2) [1] = (2,3); …; [(N/2)-1] = (N-2,N-1) LINELIST_ADJ [0] = (0,1,2,3); (N is multiple of 4) [1] = (4,5,6,7); …; [(N/4)-1)] = (N-4,N-3,N-2,N-1) LINESTRIP [0] = (0,1); (N >= 2) [1] = (1,2); …; [N-2] = (N-2,N-1) LINESTRIP_ADJ [0] = (0,1,2,3); (N >= 4) [1] = (1,2,3,4); …; [N-4] = (N-4,N-3,N-2,N-1) LINESTRIP_BF N/A LINESTRIP_CONT Same as LINESTRIP Handled same as LINESTRIP LINESTRIP_CONT_BF Same as LINESTRIP Handled same as LINESTRIP Not supported after GS. LINELOOP [0] = (0,1); (N >= 2) [1] = (1,2); [N] = (N-1,0); TRILIST [0] = (0,1,2); (N is multiple of 3) [1] = (3,4,5); …; [(N/3)-1] = (N-3,N-2,N-1) RECTLIST Same as TRILIST Handled same as TRILIST TRILIST_ADJ [0] = (0,1,2,3,4,5); (N is multiple of 6) [1] = (6,7,8,9,10,11); …; [(N/6)-1] = (N-6,N-5,N-4,N-3,N-2,N- 1) TRISTRIP (Reorder [0] = (0,1,2); {TRISTRIP} “Odd” triangles have vertices reordered , ENABLED) though identified as TRISTRIP_REV so the [1] = (1,3,2); {TRISTRIP_REV} thread knows this (N >= 3) [k even] = (k,k+1,k+2) {TRISTRIP} [k odd] = (k,k+2,k+1) {TRISTRIP_REV} Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 179 PrimTopologyType Order of Vertices in Payload GS Notes [] = (,…); [ {modified PrimType passed to (N = # of vertices) thread} ] [N-3] = (see above) TRISTRIP (Reorder [0] = (0,1,2) {TRISTRIP} “Odd” triangles do not have vertices reordered, DISABLED) though identified as TRISTRIP_REV so the [1] = (1,2,3) {TRISTRIP_REV}; … thread knows this (N >= 3) [N-3] = (N-3,N-2,N-1) {TRISTRIP or TRISTRIP_REV} TRISTRIP_REV (Reorder [0] = (0,2,1) {TRISTRIP_REV}; “Odd” triangles have vertices reordered , ENABLED) though identified as TRISTRIP so the thread [1] = (1,2,3) {TRISTRIP}; …; knows this (N >= 3) [k even] = (k,k+2,k+1) {TRISTRIP_REV} [k odd] = (k,k+1,k+2) {TRISTRIP} [N-3] = (see above) TRISTRIP_REV (Reorder [0] = (0,1,2) {TRISTRIP_REV} “Odd” triangles do not have vertices reordered, DISABLED) though identified as TRISTRIP so the thread [1] = (1,2,3) {TRISTRIP}; …; knows this (N >= 3) [N-3] = (N-3,N-2,N-1) {TRISTRIP or TRISTRIP_REV} TRISTRIP_ADJ N = 6 or 7: “Odd” objects have vertices reordered . (N even, N >= 6) [0] = (0,1,2,5,4,3) N = 8 or 9: [0] = (0,1,2,6,4,3); [1] = (2,5,6,7,4,0); …; N > 10: [0] = (0,1,2,6,4,3); [1] = (2,5,6,8,4,0); …; [k>1, even] = (2k,2k-2, 2k+2, 2k+6,2k+4, 2k+3); [k>2, odd] = (2k, 2k+3, 2k+4, 2k+6, 2k+2, 2k-2);…; Trailing object: [(N/2)-3, even] = (N-6,N-8,N-4,N- 1,N-2,N-3); Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 180 PrimTopologyType Order of Vertices in Payload GS Notes [] = (,…); [ {modified PrimType passed to (N = # of vertices) thread} ] [(N/2)-3, odd] = (N-6,N-3,N-2,N- 1,N-4,N-8); Only used by OGL TRIFAN [0] = (0,1,2); (N > 2) [1] = (0,2,3); …; [N-3] = (0, N-2, N-1); TRIFAN_NOSTIPPLE Same as TRIFAN POLYGON Same as TRIFAN Not supported after GS. QUADLIST [0] = (0,1,2,3); (N is multiple of 4) [1] = (4,5,6,7); …; [(N/4)-1] = (N-4,N-3,N-2,N-1); Not supported after GS. QUADSTRIP [0] = (0,1,3,2); (N is multiple of 2, N >=4) [1] = (2,3,5,4); … ; [(N/2)-2] = (N-4,N-3,N-1,N-2); PATCHLIST_1 [0] = (0); PATCHLIST_2 [1] = (1); …; PATCHLIST_3..32 [N-2] = (N-2); [0] = (0,1); [1] = (2,3); …; [(N/2)-1] = (N-2,N-1) similar to above Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 181 7.4.2 GS Thread Payload High-Level Layout GS Thread Payload High-Level Layoutshows the high-level layout of the payload delivered to GS threads. GS Dispatch Layouts Subsequent sections provide detailed layouts for different processor generations. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 182 7.4.3 GS Thread Payload SIMD 4x2 The table below shows the layout of the payload delivered to GS threads. Refer to the 3D Pipeline Stage Overview section in vol2a 3D Pipelinefor details on those fields that are common among the various pipeline stages. GS Thread Payload SIMD 4x2 GRF DWord Bits Description R0.7 31 31:0 Reserved. R0.6 31 Dereference Thread. This bit is defined to send back the Handle ID back to HS to dereference the input handles for this thread. 30:24 Reserved. 23:0 Thread ID. This field uniquely identifies this thread within the threads spawned by this FF unit, over some period of time. Format: Reserved for HW Implementation Use. R0.5 31:10 Scratch Space Pointer.Specifies the location of the scratch space allocated to this thread, specified as a 1KB-aligned offset from the General State Base Address. Format = GeneralStateOffset[31:10] 9.0 Reserved 8:0 FFTID. This ID is assigned by the fixed function unit and is relative identifier for the thread. It is used to free up resources used by the thread upon thread completion. Format: U7 Range: 0-127 R0.4 31:5 Binding Table Pointer: Specifies the 32-byte aligned pointer to the Binding Table. It is specified as an offset from the Surface State Base Address. Format = SurfaceStateOffset[31:5] 4:0 Reserved. R0.3 31:5 Sampler State Pointer. Specifies the location of the Sampler State Table used by this thread, specified as a 32-byte granular offset from the Dynamic State Base Address. Format = DynamicStateOffset[31:5] 4 Reserved. 3:0 Per Thread Scratch Space.Specifies the amount of scratch space allowed for this thread. The value specifies the power that two is raised to (over determine the amount of scratch space). Programming Notes: Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 183 GRF DWord Bits Description This amount is available to the kernel for information only. It is passed verbatim (if not altered by the kernel) to the Data Port in any scratch space access messages, but the Data Port ignores it. Format = U4 power of two (in excess of 10) Range = [0,11] indicating [1K Bytes, 2M Bytes] R0.2 31:24 Semaphore Index. This is a DWord index used in URB_ATOMIC commands if the thread is using data pulled from input handles. This information is only required for pull-model vertex inputs and InstanceCount > 1. Format = U8 23 Reserved. 22 Hint. This is a copy of the corresponding 3DSTATE_GS bit. Format: U1 21:16 Primitive Topology Type. This field identifies the Primitive Topology Type associated with the primitive containing this object. It indirectly specifies the number of input vertices included in the thread payload. Note that the GS unit may toggle this value between TRISTRIP and TRISTRIP_REV. If the Discard Adjacency bit is set, the topology type passed in the payload is UNDEFINED. Format: See 3D Pipeline. 15:13 Reserved. 12:0 Semaphore Handle. This is the URB offset pointing to the first GS semaphore DWord in the URB. Software is responsible for statically allocating the semaphore DWords in the URB. Refer to Semaphore Handle field in 3DSTATE_GS for size of semaphore allocation. Format: U12 64B-aligned URB offset; bit 12 is reserved R0:1 31:27 GS Instance ID 1. For each input object, the GS unit can spawn multiple threads (instances). This field starts at zero for the first instance of an object and increments for subsequent instances. If “dispatch mode” is DUAL_OBJECT this field is not valid. Format: U5 26:16 Reserved 15:0 URB Return Handle 1. This is the URB offset where the EU’s upper channels (DWords 7:4) results are stored. If only one object/instance is processed (shaded) by the thread, this field is effectively ignored (no results are stored for these channels, as controlled by the thread’s Channel Mask). Format: U12 64B-aligned URB offset; bit 12 is reserved R0.0 31:27 GS Instance ID 0. For each input object, the GS unit can spawn multiple threads (instances). This field starts at zero for the first instance of an object and increments for subsequent instances. If “dispatch mode” is DUAL_OBJECT, this field is not valid. Format: U5 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 184 GRF DWord Bits Description 26:16 Reserved. 15:0 URB Return Handle 0. This is the URB offset where the EU’s lower channels (DWords 3:0) results are stored. Format: U12 64B-aligned URB offset; bit 12 is reserved The following register is included only if Include PrimitiveID is enabled. R1.7-R1.5 31:0 Reserved: MBZ. R1.4 31:0 Primitive ID 1. This field contains the Primitive ID associated with (all instances) of input object 1. Only valid in DUAL_OBJECT mode. Format: U32 R1.3-R1.1 31:0 Reserved: MBZ. R1.0 31:0 Primitive ID 0. This field contains the Primitive ID associated with (all instances) of input object 0. Format: U32 The following register is included only if SINGLE or DUAL_INSTANCE mode and Include Vertex Handles is enabled. Rn.7 31:16 ICP 7 Handle ID 15:0 ICP 7 Handle Rn.6 31:16 ICP 6 Handle ID 15:0 ICP 6 Handle Rn.5 31:16 ICP 5 Handle ID 15:0 ICP 5 Handle Rn.4 31:16 ICP 4 Handle ID 15:0 ICP 4 Handle Rn.3 31:16 ICP 3 Handle ID 15:0 ICP 3 Handle Rn.2 31:16 ICP 2 Handle ID 15:0 ICP 2 Handle Rn.1 31:16 ICP 1 Handle ID 15:0 ICP 1 Handle Rn.0 31:16 ICP 0 Handle ID 15:0 ICP 0 Handle The following register is included only if SINGLE or DUAL_INSTANCE mode and Include Vertex Handles is enabled and ICP Count > 7. Rn+1.7 31:16 ICP 15 Handle ID 15:0 ICP 15 Handle Rn+1.6 31:16 ICP 14 Handle ID 15:0 ICP 14 Handle Rn+1.5 31:16 ICP 13 Handle ID 15:0 ICP 13 Handle Rn+1.4 31:16 ICP 12 Handle ID 15:0 ICP 12 Handle Rn+1.3 31:16 ICP 11 Handle ID 15:0 ICP 11 Handle Rn+1.2 31:16 ICP 10 Handle ID Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 185 GRF DWord Bits Description 15:0 ICP 10 Handle Rn+1.1 31:16 ICP 9 Handle ID 15:0 ICP 9 Handle Rn+1.0 31:16 ICP 8 Handle ID 15:0 ICP 8 Handle The following register is included only if SINGLE or DUAL_INSTANCE mode and Include Vertex Handles is enabled and ICP Count > 15. Rn+2.7 31:16 ICP 23 Handle ID 15:0 ICP 23 Handle Rn+2.6 31:16 ICP 22 Handle ID 15:0 ICP 22 Handle Rn+2.5 31:16 ICP 21 Handle ID 15:0 ICP 21 Handle Rn+2.4 31:16 ICP 20 Handle ID 15:0 ICP 20 Handle Rn+2.3 31:16 ICP 19 Handle ID 15:0 ICP 19 Handle Rn+2.2 31:16 ICP 18 Handle ID 15:0 ICP 18 Handle Rn+2.1 31:16 ICP 17 Handle ID 15:0 ICP 17 Handle Rn+2.0 31:16 ICP 16 Handle ID 15:0 ICP 16 Handle The following register is included only if SINGLE or DUAL_INSTANCE mode and Include Vertex Handles is enabled and ICP Count > 23. Rn+3.7 31:16 ICP 31 Handle ID 15:0 ICP 31 Handle Rn+3.6 31:16 ICP 30 Handle ID 15:0 ICP 30 Handle Rn+3.5 31:16 ICP 29 Handle ID 15:0 ICP 29 Handle Rn+3.4 31:16 ICP 28 Handle ID 15:0 ICP 28 Handle Rn+3.3 31:16 ICP 27 Handle ID 15:0 ICP 27 Handle Rn+3.2 31:16 ICP 26 Handle ID 15:0 ICP 26 Handle Rn+3.1 31:16 ICP 25 Handle ID 15:0 ICP 25 Handle Rn+3.0 31:16 ICP 24 Handle ID 15:0 ICP 24 Handle The following register is included only if DUAL_OBJECT mode and Include Vertex Handles is enabled. Rn.7 31:16 Object 1 ICP 3 Handle ID 15:0 Object 1 ICP 3 Handle Rn.6 31:16 Object 1 ICP 2 Handle ID 15:0 Object 1 ICP 2 Handle Rn.5 31:16 Object 1 ICP 1 Handle ID 15:0 Object 1 ICP 1 Handle Rn.4 31:16 Object 1 ICP 0 Handle ID Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 186 GRF DWord Bits Description 15:0 Object 1 ICP 0 Handle Rn.3 31:16 Object 0 ICP 3 Handle ID 15:0 Object 0 ICP 3 Handle Rn.2 31:16 Object 0 ICP 2 Handle ID 15:0 Object 0 ICP 2 Handle Rn.1 31:16 Object 0 ICP 1 Handle ID 15:0 Object 0 ICP 1 Handle Rn.0 31:16 Object 0 ICP 0 Handle ID 15:0 Object 0 ICP 0 Handle The following register is included only if DUAL_OBJECT mode and Include Vertex Handles is enabled and ICP Count > 3. Rn+1.7 31:16 Object 1 ICP 7 Handle ID 15:0 Object 1 ICP 7 Handle Rn+1.6 31:16 Object 1 ICP 6 Handle ID 15:0 Object 1 ICP 6 Handle Rn+1.5 31:16 Object 1 ICP 5 Handle ID 15:0 Object 1 ICP 5 Handle Rn+1.4 31:16 Object 1 ICP 4 Handle ID 15:0 Object 1 ICP 4 Handle Rn+1.3 31:16 Object 0 ICP 7 Handle ID 15:0 Object 0 ICP 7 Handle Rn+1.2 31:16 Object 0 ICP 6 Handle ID 15:0 Object 0 ICP 6 Handle Rn+1.1 31:16 Object 0 ICP 5 Handle ID 15:0 Object 0 ICP 5 Handle Rn+1.0 31:16 Object 0 ICP 4 Handle ID 15:0 Object 0 ICP 4 Handle The following register is included only if DUAL_OBJECT mode and Include Vertex Handles is enabled and ICP Count > 7. Rn+2.7 31:16 Object 1 ICP 11 Handle ID 15:0 Object 1 ICP 11 Handle Rn+2.6 31:16 Object 1 ICP 10 Handle ID 15:0 Object 1 ICP 10 Handle Rn+2.5 31:16 Object 1 ICP 9 Handle ID 15:0 Object 1 ICP 9 Handle Rn+2.4 31:16 Object 1 ICP 8 Handle ID 15:0 Object 1 ICP 8 Handle Rn+2.3 31:16 Object 0 ICP 11 Handle ID 15:0 Object 0 ICP 11 Handle Rn+2.2 31:16 Object 0 ICP 10 Handle ID 15:0 Object 0 ICP 10 Handle Rn+2.1 31:16 Object 0 ICP 9 Handle ID 15:0 Object 0 ICP 9 Handle Rn+2.0 31:16 Object 0 ICP 8 Handle ID 15:0 Object 0 ICP 8 Handle The following register is included only if DUAL_OBJECT mode and Include Vertex Handles is enabled and ICP Count > 11. Rn+3.7 31:16 Object 1 ICP 15 Handle ID 15:0 Object 1 ICP 15 Handle Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 187 GRF DWord Bits Description Rn+3.6 31:16 Object 1 ICP 14 Handle ID 15:0 Object 1 ICP 14 Handle Rn+3.5 31:16 Object 1 ICP 13 Handle ID 15:0 Object 1 ICP 13 Handle Rn+3.4 31:16 Object 1 ICP 12 Handle ID 15:0 Object 1 ICP 12 Handle Rn+3.3 31:16 Object 0 ICP 15 Handle ID 15:0 Object 0 ICP 15 Handle Rn+3.2 31:16 Object 0 ICP 14 Handle ID 15:0 Object 0 ICP 14 Handle Rn+3.1 31:16 Object 0 ICP 13 Handle ID 15:0 Object 0 ICP 13 Handle Rn+3.0 31:16 Object 0 ICP 12 Handle ID 15:0 Object 0 ICP 12 Handle Varies 31:0 (optional) Constant Data (optional): Some amount of constant data (possibly none) can be extracted from the push constant buffer (PCB) and passed to the thread following the R0 Header. The amount of data provided is defined by the sum of the read lengths in the last 3DSTATE_CONSTANT_GS command (taking the buffer enables into account). The Constant Data arrives in a non-interleaved format. Varies 31:0 Pushed Vertex Data. There can be up to 32 vertices supplied, each with a size defined by the Vertex URB Entry Read Length state. The amount of data provided for each vertex is defined by the Vertex URB Entry Read Length state. For SINGLE or DUAL_INSTANCE dispatch modes, the pushed data for Vertex 0 immediately follows any pushed constant data. The pushed data for Vertex 1 immediately follows Vertex 0, and so on. There is no upper/lower swizzling of data. For DUAL_OBJECT dispatch mode, the pushed vertex data is split into upper and lower halves with Object 0 input vertices in the lower half, and Object 1 input vertices in the upper half. 7.5 GS Thread Execution A GS thread is capable of performing arbritrary algorithms given the thread payload (especially vertex) data and associated data structures (binding tables, sampler state, etc.) as input. Output can take the form of vertices output to the FF pipeline (at the GS unit) and/or data written to memory buffers via the DataPort. The primary usage models for GS threads include (possible combinations of):  Compiled application-provided “GS shader” programs, specifying an algorithm to convert the vertices of an input object into some output primitives. For example, a GS shader may convert lines of a line strip into polygons representing a corresponding segment of a blade of grass centered on the line. Or it could use adjacency information to detect silhouette edges of triangles and output polygons extruding out from the those edges. Or it could output absolutely nothing, effectively terminating the pipeline at the GS stage. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 188  Driver-generated instructions used to write pre-clipped vertices into memory buffers (see Stream Output below). This may be required whether or not an app-provided GS shader is enabled.  Driver-generated instructions used to emulate API functions not supported by specialized hardware. These functions might include (but are not limited to): o Conversion of API-defined topologies into topologies that can be rendered (e.g., LINELOOPLINESTRIP, POLYGONTRIFAN, QUADsTRIFAN, etc.) o Emulation of “Polygon Fill Mode”, where incoming polygons can be converted to points, lines (wireframe), or solid objects. o Emulation of wide/sprite points.  Things best left to the imagination. When rendering is required, concurrent GS threads must use the FF_SYNC message (URB shared function) to request an initial VUE handle and synchronize output of VUEs to the pipeline (see URB in Shared Functions). Only one GS thread can be outputting VUEs to the pipeline at a time. In order to achieve parallelism, GS threads should perform the GS shader algorithm (along with any other required functions) and buffer results (either in the GRF or scratch memory) before issuing the FF_SYNC message. The issuing GS thread will be stalled on the FF_SYNC writeback until it is that thread’s turn to output VUEs. As only one GS thread at a time can output VUEs, the post-FF_SYNC output portion of the kernel should be optimized as much as possible to maximize parallelism. 7.5.1 GS Thread Output 7.5.1.1 GS URB Entry All outputs of a GS thread will be stored in the single GS thread output URB entry. Cut (1 bit/vertex) or StreamID (2 bits/vertex) bits are packed into an optional 1-8 32B header. The Control Data Format and Control Data Header Size states are used to specify the size and contents of the header data (if any). Following the optional header is a variable number of 16B or 32B-aligned/granular vertices:  When rendering is DISABLED, typically output vertices are 32B-aligned, with the exception of 16B-alignment for vertices <= 16B in length. o The absolute worst case size comes from three DW scalars output per vertex. If these are, say, three “.x” outputs, you need to store each DW in a 128b (16B) element, plus another pad 16B to keep the 32B alignment. So you require 4*16B = 64B/vertex. You have to have room for 1024 scalars / 3 scalar/vtx = 341 vertices. 341*64B = 21,824B. Then add 96B to hold 2b/vtx streamID and you get 21,920B entries.  When rendering is ENABLED, each output vertex is 32B-aligned. Here the vertex header and vertex ‘position’ is required and therefore the minimum size vertex is 32B. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 189 o Here the worst case size isn’t as bad as render-disabled, as you have to have a 4DW position output, plus any additional output. So, say you output 5 DW per vertex. You need 64B/vertex (16B vtx header, 16B position, 16B for the 2nd element, and 16B of pad). You have to have room for 1024 scalars / 5 = 204 vertices. 204*64 = 13,056B. Then add 64B to hold 2b/vtx streamID and you get 13,120B entries. The size of the URB entry should be based on the declared maximum # of output vertices and the declared output vertex size (the union of per-stream vertex structures, if required). 7.5.1.2 GS Output Topologies The following table lists which primitive topology types are valid for output by a GS thread. PrimTopologyType Supported for GS Thread Output? LINELIST Yes LINELIST_ADJ No LINESTRIP Yes LINESTRIP_ADJ No LINESTRIP_BF Yes LINESTRIP_CONT Yes LINESTRIP_CONT_BF Yes LINELOOP No POINTLIST Yes POINTLIST_BF Yes POLYGON Yes QUADLIST No QUADSTRIP No RECTLIST Yes TRIFAN Yes TRIFAN_NOSTIPPLE Yes TRILIST Yes TRILIST_ADJ No TRISTRIP Yes TRISTRIP_ADJ No TRISTRIP_REV Yes PATCHLIST_xxx Yes 7.5.1.3 GS Output StreamID When the GS Enable is DISABLED, output vertices will be assigned a StreamID = 0; When the GS Enable is ENABLED, output vertices will be assigned a StreamID = Default StreamID under the following conditions:  Control Data Format = 0, or  Control Data Format > 0 and Control Data Format = GSCTL_CUT When the GS is enabled, Control Data Format > 0 and Control Data Format = GSCTL_SID, output vertices will be assigned a StreamID as programmed in the Control Data output by the thread. 7.5.2 Stream Output The final contents of Stream Output buffers must follow the strict pipeline ordering of vertices. Given this ordering requirement, it will be necessary to run the GS stage in a single-threaded fashion (Maximum Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 190 Number of Threads == 1). Otherwise concurrent GS threads might append vertices to the output buffer out of order. Hardware support for the Stream Output is limited to a special “Streamed Vertex Buffer Write” DataPort message. (Refer to DataPort chapter). Through use of this message type, the GS thread can write from 1 to 4 DWords to specified ‘element’ (indexed entry) in a BUFFER surface. The DataPort will inhibit writes past the end of the buffer. Software will likely need to define separate surface states for each SEB, and separate surface states for each element within the MEB structure. The surfaces are selected via the normal binding table mechanisms. The need for separate SEB surface states is obvious, as the SEBs are separate buffers in memory. The MEB surface-per-element allows the GS kernel to address the MEB using an structure index. Here each surface would be specified as having the same structure pitch, but with different starting addresses corresponding to the different element offsets within the structure – in effect, defining a set of interleaved surfaces. The GS kernel would output one write message per element. (Note that software could, if it wished, treat the MEB as a single 1D array of DWords, though it would then have to write the buffer one DWord at a time, performing the address calculations within the GS kernel. This should not be necessary, and is certainly not recommended due to obvious performance and complexity reasons.) Programming Note: If the GS stage is enabled, software must always allocate at least one GS URB Entry. This is true even if the GS thread never needs to output vertices to the pipeline, e.g., when only performing stream output. This is an artifact of the need to pass the GS thread an initial destination URB handle. 7.5.3 Thread Termination GS threads must terminate by sending a URB_WRITE_xxx message with the EOT and Complete bits set. The message header must contain correct values for the GS Number of Output Handles for Slot 0, Handle ID 0, and URB Handle 0 fields. If in DUAL_INSTANCE or DUAL_OBJECT mode, the corresponding Object 1 fields must also be correct. 7.6 Primitive Output (This section refers to output from the GS unit to the pipeline, not output from the GS thread) The GS unit will output primitives (either passed-through or generated by a GS thread) in the proper order. This includes the buffering of a concurrent GS thread’s output until the preceding GS thread terminates. Note that the requirement to buffer subsequent GS thread output until the preceding GS thread terminates has ramifications on determining the number of VUEs allocated to the GS unit and the number of concurrent GS threads allowed. 7.7 Other Functionality 7.7.1 Statistics Gathering There are a number of GS/StreamOutput pipeline statistics counters associated with the GS stage and GS threads. This subsection describes these counters and controls depending on device, even in the cases where functions outside of the GS stage (e.g., DataPort) are involved in the statistics gathering. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 191 Refer to the Statistics Gathering summary provided earlier in this specification. Refer to the Memory Interface Registers chapter for details on these MMIO pipeline statistics counter registers, as well as the chapters corresponding to the other functions involved (e.g., DataPort, URB shared functions). 7.7.1.1 GS Invocations The GS_INVOCATIONS counter is incremented by the GSInvocations Increment Value state for every input object, with the exception of DUAL_OBJECT dispatch where the counter is incremented by twice that amount. This allows software to (for example) support multiple instances in the GS kernel. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 192 8. 3D Pipeline - Stream Output Logic (SOL) Stage The Stream Output Logic (SOL) stage receives 3D topologies originating in the VF or GS stage. If enabled, the SOL stage uses programmed state information to copy portions of the vertex data associated with the incoming topologies across one or more Stream Output (SO) Buffers. 8.1 Input Buffering For the purposes of stream output, the SOL stage breaks incoming topologies into independent objects without adjacency information. In the process, any adjacent-only vertices are ignored. For example, convert TRISTRIP_ADJ into independent 3-vertex triangles. However, if rendering is enabled, incoming topologies are passed to the Clip stage unmodified and therefore the Clip unit must be enabled if there is any possibility of “ADJ” topologies reaching it. Note that the SOL unit should not see incomplete objects: the VF will remove incomplete input objects, and the GS will remove GS-generated incomplete objects. The OSB (Object Staging Buffer) reorders the vertices of odd-numbered triangles in TRISTRIP topologies to match API requirements. Incoming topologies are tagged with a 2-bit StreamID. The StreamID is 0 for topologies originating from the VF stage (i.e., 3DPRIMITIVE_xxx). For topologies output from the GS stage, the StreamID is set by the GS shader. A Stream n Vertex Length is associated with each stream, and defines how much data is read from the URB for vertices in that stream. The following table specifies how the SOL stage streams out object vertices for each incoming topology type. Order of Vertices PrimTopologyType Streamed Out Any SOL Notes [] = (,…); (N = # of vertices) POINTLIST [0] = (0); POINTLIST_BF [1] = (1); …; [N-2] = (N-2); LINELIST [0] = (0,1); (N is multiple of 2) [1] = (2,3); …; [(N/2)-1] = (N-2,N-1) LINELIST_ADJ [0] = (1,2); (N is multiple of 4) [1] = (5,6); …; [(N/4)-1)] = (N-3,N-2) LINESTRIP [0] = (0,1); LINESTRIP_BF [1] = (1,2); …; LINESTRIP_CONT [N-2] = (N-2,N-1) LINESTRIP_CONT_BF (N >= 2) LINESTRIP_ADJ [0] = (1,2); (N >= 4) [1] = (2,3); …; [N-4] = (N-3,N-2) LINELOOP N/A Not supported after VF. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 193 Order of Vertices PrimTopologyType Streamed Out Any SOL Notes TRILIST [0] = (0,1,2); (N is multiple of 3) [1] = (3,4,5); …; [(N/3)-1] = (N-3,N-2,N-1) RECTLIST Same as TRILIST Handled same as TRILIST. TRILIST_ADJ [0] = (0,2,4); (N is multiple of 6) [1] = (6,8,10); …; [(N/6)-1] = (N-6,N-4,N-2) TRISTRIP [0] = (0,1,2); “Odd” triangles have vertices reordered to yield increasing (N >= 3) [1] = (1,3,2); leading vertices starting with v0. REORDER_LEADING [k even] = (k,k+1,k+2) [k odd] = (k,k+2,k+1) [N-3] = (see above) TRISTRIP [0] = (0,1,2); “Odd” triangles have vertices reordered to yield increasing (N >= 3) [1] = (2,1,3); trailing vertices starting with v2. REORDER_TRAILING [k even] = (k,k+1,k+2) [k odd] = (k+1,k,k+2) [N-3] = (see above) TRISTRIP_REV [0] = (0,2,1) “Even” triangles have vertices reordered to yield (N >= 3) [1] = (1,2,3);…; increasing leading vertices starting with v0. REORDER_LEADING [k even] = (k,k+2,k+1) [k odd] = (k,k+1,k+2) [N-3] = (see above) TRISTRIP_REV [0] = (1,0,2) “Even” triangles have vertices reordered to yield (N >= 3) [1] = (1,2,3);…; increasing trailing vertices starting with v2. REORDER_TRAILING [k even] = (k+1,k,k+2) [k odd] = (k,k+1,k+2) [N-3] = (see above) TRISTRIP_ADJ N = 6 or 7: “Odd” objects have vertices reordered to yield increasing- (N even, N >= 6) [0] = (0,2,4) by-2 leading vertices starting with v0. REORDER_LEADING N = 8 or 9: [0] = (0,2,4); [1] = (2,6,4); …; N > 10: [0] = (0,2,4); [1] = (2,6,4); …; [k>1, even] = (2k, 2k+2, 2k+4); [k>2, odd] = (2k, 2k+4, 2k+2);…; Trailing object: [(N/2)-3, even] = (N-6,N-4,N- 2); [(N/2)-3, odd] = (N-6,N-2,N- 4); TRISTRIP_ADJ N = 6 or 7: “Odd” objects have vertices reordered to yield increasing- (N even, N >= 6) [0] = (0,2,4) by-2 trailing vertices starting with v4. REORDER_TRAILING N = 8 or 9: [0] = (0,2,4); [1] = (4,2,6); …; N > 10: [0] = (0,2,4); [1] = (4,2,6); …; [k>1, even] = (2k, 2k+2, Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 194 Order of Vertices PrimTopologyType Streamed Out Any SOL Notes 2k+4); [k>2, odd] = (2k+2,2k, 2k+4,);…; Trailing object: [(N/2)-3, even] = (N-6,N-4,N- 2); [(N/2)-3, odd] = (N-4,N-6,N- 2); TRIFAN [0] = (0,1,2); (N > 2) [1] = (0,2,3); …; [N-3] = (0, N-2, N-1); TRIFAN_NOSTIPPLE Same as TRIFAN POLYGON Same as TRIFAN QUADLIST N/A Not supported after VF. QUADSTRIP : [0] = (0); PATCHLIST_1 [1] = (1); …; [N-2] = (N-2); : [0] = (0,1); PATCHLIST_2 [1] = (2,3); …; [(N/2)-1] = (N-2,N-1) : similar to above PATCHLIST_3..32 8.2 Stream Output Buffers Up to four SO buffers are supported. The SO buffer parameters (start/end address, etc.) are specified by the 3DSTATE_SO_BUFFER command. The 3DSTATE_STREAMOUT command specifies an SO Buffer Enable bit for each of the buffers. If a buffer is disabled, its state is ignored and no output will be attempted for that buffer. Any attempt to output to that buffer will immediately signal an overflow condition. The SOL stage maintains a current Write Offset register value for each SO buffer. These registers can be written via MI_LOAD_REGISTER_MEM or MI_LOAD_REGISTER_IMM commands. The SOL stage will increment the Write Offsets as a part of the SO function. Software can cause a Write Offset register to be written to memory via an MI_STORE_REGISTER_MEM command, though a preceding flush operation may be required to ensure that any previous SO functions have completed. Project Surface Format Name Security R32G32B32A32_FLOAT R32G32B32A32_SINT R32G32B32A32_UINT R32G32B32_FLOAT R32G32B32_SINT R32G32B32_UINT R32G32_FLOAT R32G32_SINT R32G32_UINT R32_SINT R32_UINT R32_FLOAT Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 195 8.3 Stream Output Function As previously mentioned, incoming 3D topologies are targeted at one of the four streams. The SOL stage contains state information specific to each of the four streams. A stream’s list of SO declarations (SO_DECL structures) is used to perform the SO function for objects targeted to that particular stream. The 3DSTATE_SO_DECL_LIST command is used to specify the list of SO_DECL structures for all four streams in parallel. Software is required to scan the SO_DECL lists of streams to determine which SO buffers are targeted. The Stream To Buffer Selects bits in 3DSTATE_SO_DECL_LIST must be programmed accordingly (if the buffer is targeted, the select bit must set, else it must be cleared). If a stream has no SO_DECL state defined (NumEntries is 0), incoming objects targeting that stream are effectively ignored. As there is no attempt to perform stream output, overflow detection is neither required nor performed. Otherwise, an overflow check is performed. First any attempt to output to a disabled buffer is detected. This occurs when the stream has a Stream To Buffer Selects bit set but the corresponding SO Buffer Enable is clear. Assuming all targeted buffers are enabled, an additional check is made to ensure that there is enough room in each targeted buffer to hold the number of vertices which be output to it (for the input object). Here the buffer’s current end address is compared to what the write offset would be if the output was performed. The latter value is computed as (write_offset + vertex_count * buffer_pitch). If this value is greater than the end address, an overflow is signalled. This check is performed for each buffer included in Stream To Buffer Selects. If an overflow is not signaled, the SO function is performed. The SO_DECL list for the targeted stream is traversed independently for each object vertex, and the operation specified by the SO_DECL structure is performed (typically causing data to be appended to an SO buffer). In the process, SO buffer Write Offsets are incremented. 8.4 3DSTATE_STREAMOUT The 3DSTATE_STREAMOUT command specifies control information for the SOL stage. Included are enables and sizes for input streams and enables for output buffers. Anytime the SOL unit MMIO registers or non-pipeline state are written, the SOL unit needs to receive a pipeline state update with SOL unit dirty state for information programmed in MMIO/NP to get loaded into the SOL unit. The SOL unit incorrectly double buffers MMIO/NP registers and only moves them into the design for usage when control topology is received with the SOL unit dirty state. If the state does not change, need to resend the same state. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 196 Because of corruption, software must flush the whole fixed function pipeline when 3DSTATE_STREAMOUT changes state. 3DSTATE_STREAMOUT Source: RenderCS Length Bias: 2 This command contains pipelined state required by the SOL unit. 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 1Eh 3DSTATE_STREAMOUT Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 1h Format: =n Total Length – 2 1 31 SO Function Enable Project: All Format: U1 If set, the SO function is enabled. Vertex data will be streamed out to memory (subject to overflow detection) as controlled by the various SO-related state variables. If clear, the SO function is disabled, and therefore no vertex data will be streamed out to memory. However, the Rendering Disable and Render Stream Select fields will still be used to determine which vertices (if any) are forwarded down the pipeline for (possible) rendering. 30 Rendering Disable Format: U1 If set, the SO stage will not forward any topologies down the pipeline.If clear, the SO stage will forward topologies associated with Render Stream Select down the pipeline.This bit is used even if SO Function Enable is DISABLED. 29 Reserved Project: All Format: MBZ Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 197 3DSTATE_STREAMOUT 28:27 Render Stream Select Project: All Format: U2 Description Project This field specifies which stream has been selected to be forwarded down the pipeline for possible rendering. Topologies from other streams will not be passed down the pipeline. If Rendering Disable is set, this field is ignored, as no topologies are sent down the pipeline. This bit is used even if SO Function Enable is DISABLED. 26 Reorder Mode Project: All This bit controls how vertices of triangle objects in TRISTRIP[_ADJ] and TRISTRIP_REV are reordered for the purposes of stream-out only (does not impact rendering). See table in Input Buffering. Value Name Description Project 0h REORDER_LEADING Reorder the vertices of alternating triangles of a TRISTRIP[_ADJ] All such that the leading (first) vertices are in consecutive order starting at v0. A similar reordering is performed on alternating triangles in a TRISTRIP_REV. 1h REORDER_TRAILING Reorder the vertices of alternating triangles of a TRISTRIP[_ADJ] All such that the trailing (last) vertices are in consecutive order starting at v2. A similar reordering is performed on alternating triangles in a TRISTRIP_REV. 25 SO Statistics Enable Project: All Format: Enable This bit controls whether StreamOutput statistics register(s) can be incremented. Value Name Description Project 0h Disable SO_NUM_PRIMS_WRITTEN[0..3] and SO_PRIM_STORAGE_NEEDED[0..3] All registers cannot increment. 1h Enable SO_NUM_PRIMS_WRITTEN[0..3] and SO_PRIM_STORAGE_NEEDED[0..3] All registers can increment. 24:23 Reserved Format: MBZ 22:12 Reserved Project: All Format: MBZ 11 SO Buffer Enable [3] Format: U1 (See SO Buffer Enable [0] ) 10 SO Buffer Enable [2] Format: U1 (See SO Buffer Enable [0] ) 9 SO Buffer Enable [1] Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 198 3DSTATE_STREAMOUT Format: U1 (See SO Buffer Enable [0] ) 8 SO Buffer Enable [0] Format: U1 If set, stream output to SO Buffer 0 is enabled. If clear, SO Buffer 0 is considered “not bound” and effectively treated as a zero-length buffer for the purposes of SO output and overflow detection. If an enabled stream’s Stream to Buffer Selects includes this buffer it is by definition an overflow condition. That stream will cause no writes to occur, and only SO_PRIM_STORAGE_NEEDED[] will increment. This bit is ignored if SO Function Enable is DISABLED. 7:0 Reserved Project: All Format: MBZ 2 31:30 Reserved Project: All Format: MBZ 29 Stream 3 Vertex Read Offset Project: All Format: U1 count of 256-bit units Specifies amount of data to skip over before reading back Stream 3 vertex data. (See Stream 0 Vertex Read Offset) 28:24 Stream 3 Vertex Read Length Project: All Format: U5-1 count of 256-bit units (See Stream 0 Vertex Read Length) 23:22 Reserved Project: All Format: MBZ 21 Stream 2 Vertex Read Offset Project: All Format: U1 count of 256-bit units Specifies amount of data to skip over before reading back Stream 2 vertex data. (See Stream 0 Vertex Read Offset) 20:16 Stream 2 Vertex Read Length Project: All Format: U5-1 count of 256-bit units Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 199 3DSTATE_STREAMOUT 15:14 Reserved Project: All Format: MBZ 13 Stream 1 Vertex Read Offset Project: All Format: U1 count of 256-bit units Specifies amount of data to skip over before reading back Stream 1 vertex data. (See Stream 0 Vertex Read Offset) 12:8 Stream 1 Vertex Read Length Project: All Format: U5-1 count of 256-bit units (See Stream 0 Vertex Read Length) 7:6 Reserved Project: All Format: MBZ 5 Stream 0 Vertex Read Offset Project: All Format: U1 count of 256-bit units Specifies amount of data to skip over before reading back Stream 0 vertex data. Must be zero if the GS is enabled and the Output Vertex Size field in 3DSTATE_GS is programmed to 0 (i.e., one 16B unit). 4:0 Stream 0 Vertex Read Length Project: All Format: U5-1 count of 256-bit units Specifies amount of vertex data to read back for Stream 0 vertices, starting at the Stream 0 Vertex Read Offset location. Maximum readback is 17 256-bit units (34 128-bit vertex attributes). Read data past the end of the valid vertex data has undefined contents, and therefore shouldn’t be used to source stream out data. Must be zero (i.e., read length = 256b) if the GS is enabled and the Output Vertex Size field in 3DSTATE_GS is programmed to 0 (i.e., one 16B unit). Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 200 8.5 3DSTATE_SO_DECL_LIST Command The 3DSTATE_SO_DECL_LIST instruction defines a list of Stream Output (SO) declaration entries (SO_DECLs) and associated information for all specific SO streams in parallel. Errata: All 128 decls for all four streams must be included whenever this command is issued. The “Num Entries [n]” fields still contain the actual numbers of valid decls. 3DSTATE_SO_DECL_LIST Source: RenderCS Length Bias: 2 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: 17h 3DSTATE_SO_DECL_LIST Format: OpCode 15:9 Reserved Project: All Format: MBZ 8:0 DWord Length Format: =n Total Length – 2 Format: Q1 Value Name Description 3h Excludes DWord (0,1) [Default] Default value = 2(N-1)+3 h 1 31:16 Reserved Project: All Format: MBZ 15:12 Stream to Buffer Selects [3] Project: All Format: U4 bitmask Index of SO Stream Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 201 3DSTATE_SO_DECL_LIST Identifies to which SO Buffers stream 3 outputs. See Stream To Buffer Selects [0] field description. 11:8 Stream to Buffer Selects [2] Project: All Format: U4 bitmask Identifies to which SO Buffers stream 2 outputs. See Stream To Buffer Selects [0] field description. 7:4 Stream to Buffer Selects [1] Project: All Format: U4 bitmask Identifies to which SO Buffers stream 1 outputs. See Stream To Buffer Selects [0] field description. 3:0 Stream to Buffer Selects [0] Project: All Format: U4 bitmask Identifies to which SO Buffers stream 0 outputs (irrespective of whether those buffers are enabled via 3DSTATE_STREAMOUT). Software is required to scan the SO_DECL list in order to provide this summary information. Note: For “inactive” streams, software must program this field to all zero (no buffers written to) and the corresponding Num Entries field to zero (no valid SO_DECLs). Value Name 1xxxb SO Buffer 3 x1xxb SO Buffer 2 xx1xb SO Buffer 1 xxx1b SO Buffer 0 2 31:24 Num Entries [3] Project: All Format: U8 #entries Specifies the number of valid SO_DECL entries for Stream 3. (See notes in Num Entries [0] field description). Value Name [0,128] entries 23:16 Num Entries [2] Project: All Format: U8 #entries Specifies the number of valid SO_DECL entries for Stream 2. (See notes in Num Entries [0] field description). Value Name [0,128] entries 15:8 Num Entries [1] Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 202 3DSTATE_SO_DECL_LIST Project: All Format: U8 #entries Specifies the number of valid SO_DECL entries for Stream 1. (See notes in Num Entries [0] field description). Value Name [0,128] entries 7:0 Num Entries [0] Project: All Format: U8 #entries Specifies the number of valid SO_DECL entries for Stream 0.Note that the SO_DECLs are programmed in groups of four (one SO_DECL for each of the four streams). Therefore the number of 2- DWord groups of SO_DECLs supplied in this command is derived from the stream(s) with the most valid SO_DECLs. The NumEntries value specific to each stream will indicate how many SO_DECLS are valid for that particular stream. Any trailing invalid SO_DECLs supplied for streams with fewer valid SO_DECLs will be ignored. It is legal to specify Num Entries = 0 for all four streams simultaneously. In this case there will be no SO_DECLs included in the command (only DW 0-2). Note that all Stream to Buffer Selects bits must be zero in this case (as no streams produce output). Value Name [0,128] entries 3..4 63:48 SO_DECL[3,1] Project: All Format: SO_DECL This field contains Stream 3 SO_DECL 0 47:32 SO_DECL[2,1] Project: All Format: SO_DECL This field contains Stream 2 SO_DECL 0 31:16 SO_DECL[1,1] Project: All Format: SO_DECL This field contains Stream 1 SO_DECL 0 15:0 SO_DECL[0,1] Project: All Format: SO_DECL This field contains Stream 0 SO_DECL 0 5..6 63:48 SO_DECL[3,1] Project: All Format: SO_DECL This field contains Stream 3 SO_DECL 1 47:32 SO_DECL[2,1] Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 203 3DSTATE_SO_DECL_LIST Project: All Format: SO_DECL This field contains Stream 2 SO_DECL 1 31:16 SO_DECL[1,1] Project: All Format: SO_DECL This field contains Stream 1 SO_DECL 1 15:0 SO_DECL[0,1] Project: All Format: SO_DECL This field contains Stream 0 SO_DECL 1 7..n 63:48 SO_DECL[3,n] Project: All Format: SO_DECL This field contains Stream 3 SO_DECL n 47:32 SO_DECL[2,n] Project: All Format: SO_DECL This field contains Stream 2 SO_DECL n 31:16 SO_DECL[1,n] Project: All Format: SO_DECL This field contains Stream 1 SO_DECL n 15:0 SO_DECL[0,n] Project: All Format: SO_DECL This field contains Stream 0 SO_DECL n Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 204 8.5.1 SO_DECL Structure Definition SO_DECL Source: RenderCS Default Value: 0x00000000 A list of SO_DECL structures are passed in the 3DSTATE_SO_DECL_LIST command. Each structure specifies either (a) the source and destination of an up-to-4-DWord appending write into an SO buffer, or (b) how many DWords to skip over in the destination SO buffer (i.e., a “hole” where the previous buffer contents are maintained). Workaround for IVBGT2:A0 (ends IVBGT2:B0): because of corruption in IVBGT2:A0, software needs to put a noop decl (Hole flag is 0, Component Mask is 0) as the first decl in every decl list. DWord Bit Description 0 15:14 Reserved Project: All Format: MBZ 13:12 Output Buffer Slot Project: All Format: U2 Buffer Index This field selects the destination output buffer slot. 11 Hole Flag Project: All Format: Flag If set, the Component Mask field indirectly specifies a number of 32-bit locations to skip over (leave unmodified in memory) in the selected output buffer. The Register Index field is ignored. The only permitted Component Mask values are as follows: 0x0 No Dwords are skipped over (SO_DECL performs no operation) 0x1 (X) Skip 1 DWord 0x3 (XY) Skip 2 DWords 0x7 (XYZ) Skip 3 DWords 0xF (XYZW) Skip 4 DWords 10 Reserved Project: All Format: MBZ 9:4 Register Index Project: All Format: U6 128-bit granular offset into the source vertex read data If Hole Flag is clear, this field specifies the 128-bit offset into the source vertex data which supplies the source data to be written to the destination buffer, where the individual 32-component destination locations are selected by Component Mask. e.g., Register Index 0 corresponds with the first 128 bits of the data read from the vertex URB entry (as per corresponding Vertex Read Offset state) There is only enough internal storage for the 128-bit vertex header and 32 128-bit vertex attributes. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 205 SO_DECL Value Name [0,32] 0h [Default] Programming Notes It is the responsibility of software to map any API-visible source data specifications (e.g., vertex register number) into 128-bit granular URB read offsets. 3:0 Component Mask Project: All Format: MASK 4-bit Mask This field is a 4-bit bitmask that selects which contiguous 32-bit component(s) are either written or skipped-over in the destination buffer. If this field is zero the SO_DECL operation is effectively a no-op. No data will be appended to the destination and the destination buffer’s write pointer will not be advanced. If the Hole Flag is set, this field (if non-zero) indirectly specifies how much the destination buffer’s write pointer should be advanced.See Hole Flag description above for restrictions on this field. If the Hole Flag is clear, this field (if non-zero) selects which source components are to be written to the destination buffer. The components must be contiguous, e.g. YZW is legal, but XZW is not. The selected source components are written to the destination buffer starting at the current write pointer, and then the write pointer is advanced past the written data. E.g., if YZW is specified, the three (YZW) components of the source register will be written to the destination buffer at the current write pointer, and the write pointer will be advanced by 3 DWords. Value Name Project 0h [Default] xxx1b SO_DECL_COMPMASK_X All xx1xb SO_DECL_COMPMASK_Y All x1xxb SO_DECL_COMPMASK_Z All 1xxxb SO_DECL_COMPMASK_W All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 206 8.6 3DSTATE_SO_BUFFER The 3DSTATE_SO_BUFFER command specifies the location and characteristics of an SO buffer in memory. 3DSTATE_SO_BUFFER Source: RenderCS Length Bias: 2 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: 18h 3DSTATE_SO_BUFFER 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 Reserved Project: All Format: MBZ 30:29 SO Buffer Index Project: All Format: U2 Specifies which of the four SO Buffers is being defined. 28:25 SO Buffer Object Control State Format: MEMORY_OBJECT_CONTROL_STATE Specifies the memory object control state for the SO buffer. 24:22 Reserved Format: MBZ 21:12 Reserved Project: All Format: MBZ 11:0 Surface Pitch Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 207 3DSTATE_SO_BUFFER Project: All Format: U12 Pitch in Bytes This field specifies the pitch of the SO buffer in #Bytes. Value Name [0,2048] Must be 0 or a multiple of 4 Bytes. Programming Notes A Surface Pitch of 0 indicates an un-bound buffer. No writes are performed. Surface Base Address is ignored. 2 31:2 Surface Base Address Project: All Format: GraphicsAddress[31:2] This field specifies the starting DWord address LSBs of the buffer in Graphics Memory. 1:0 Reserved Project: All Format: MBZ 3 31:2 Surface End Address Format: GraphicsAddress[31:2] This field specifies the ending DWord address of the buffer in Graphics Memory. 1:0 Reserved Project: All Format: MBZ 8.7 Rendering Disable Independent of SOL function enable, if rendering (i.e, 3D pipeline functions past the SOL stage) is enabled (via clearing the Rendering Disable bit), the SOL stage will pass topologies for a specific input stream (as selected by Render Stream Select) down the pipeline, with the exception of PATCHLIST_n topologies which are never passed downstream. Software must ensure that the vertices exiting the SOL stage include a vertex header and position value so that the topologies can be correctly processed by subsequent pipeline stages. Specifically, rendering must be disabled whenever 128-bit vertices are output from a GS thread. If Rendering Disable is set, the SOL stage will prevent any topologies from exiting the SOL stage. 8.8 Statistics The SOL stage controls the incrementing of two 64-bit statistics counter registers for each of the four output buffer slots, SO_NUM_PRIMS_WRITTEN[] and SO_PRIM_STORAGE_NEEDED[]. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 208 9. 3D Pipeline – Clip Stage 9.1 3D Pipeline – CLIP Stage Overview The CLIP stage of the 3D Pipeline is similar to the GS stage in that it can be used to perform general processing on incoming 3D objects via spawned threads. However, the CLIP stage also includes specialized logic to perform a ClipTest function on incoming objects. These two usage models of the CLIP stage are outlined below. Refer to the Common 3D FF Unit Functions subsection in the 3D Overview chapter for a general description of a 3D Pipeline stage, as much of the CLIP stage operation and control falls under these “common” functions. I.e., many of the CLIP stage state variables and CLIP thread payload parameters are described in 3D Overview, and although they are listed here for completeness, that chapter provides the detailed description of the associated functions. Refer to this chapter for an overall description of the CLIP stage, details on the ClipTest function, and any exceptions the CLIP stage exhibits with respect to common FF unit functions. 9.1.1 Clip Stage – General-Purpose Processing Numerous state variable controls are provided to tailor the ClipTest function as required by the API or primitive characteristics. These controls allow a mode where all objects are passed to CLIP threads, and in this regard the CLIP stage can be used as a second GS stage. However, unlike the GS stage, primitives output by CLIP threads will not be subject to 3D Clipping, and therefore any clip-testing/clipping of these primitives (if required) would need to be performed by the CLIP thread itself. 9.1.2 Clip Stage – 3D Clipping The ClipTest fixed function is provided to optimize the CLIP stage for support of generalized 3D Clipping. The CLIP FF unit examines the position of incoming vertices, performs a fixed function VertexClipTest on these positions, and then examines the results for the vertices of each independent object in ClipDetermination. The results of ClipDetermination indicate whether an object is to be processed by a thread (MustClip), discarded (TrivialReject) or passed down the pipeline unmodified (TrivialAccept). In the MustClip case, the spawned thread is responsible for performing the actual 3D Clipping algorithm. The CLIP thread is passed the source object vertex data and is able to output a new, arbitrary 3D primitive (e.g., the clipped primitive), or no output at all. Note that the output primitive is independent in that it is comprised of newly- generated VUEs, and does not share vertices with the source primitive or other CLIP-generated primitives. New vertices produced by the CLIP threads are stored in the URB. Their Vertex Headers are then read from the VUEs in order to insert the relevant information into the 3D pipeline. The CLIP unit maintains the proper ordering of CLIP-generated primitives and any surrounding trivially-accepted primitives. The CLIP unit also supports multiple concurrent CLIP threads and maintains the proper ordering of the thread outputs as dictated by the order of the source objects. The outgoing primitive stream is sent down the pipeline to the Strip/Fan (SF) FF stage (now including the read-back VUE Vertex Header data such as Vertex Rosition (NDC or screen space), RTAIndex, VPIndex, Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 209 PointWidth) and control information (PrimType, PrimStart, PrimEnd) while the remainder of the vertex data remains in the VUE in the URB. 9.1.3 Fixed Function Clipper The GPU supports Fixed Function Clipping. 9.2 Concepts This section provides an overview of 3D clip-testing and clipping concepts. It is provided as background material: some of the concepts impact HW functionality while others impact CLIP kernel functionality. 9.2.1 The Clip Volume 3D objects are optionally clipped to the clip volume. The clip volume is defined as the intersection of a set of clip half-spaces. Six of these half-spaces define the view volume, while additional, user-defined half-spaces can be employed to perform clipping (or at least culling) within the view volume. The CLIP stage design will permit the enable/disable of certain subsets of these clip half-spaces. This capability can be used, for example, to disable viewport, guardband, and near and far clipping as required by the API and other conditions. 9.2.1.1 View Volume The intersection of the six view half-spaces defines the view volume. The view volume is defined in 4D clip space coordinates as: ‘Outside’ Condition View Clip Plane 4D Clip Space NDC space, positive w clip.x < -clip.w ndc.x < -1 XMIN (NDC Left) clip.w < clip.x ndc.x > 1 XMAX (NDC Right) clip.y < -clip.w ndc.y < -1 YMIN (NDC Bottom) clip.w < clip.y ndc.y > 1 YMAX (NDC top) ZMIN OGL: clip.z < -clip.w OGL: ndc.z < -1.0 (NDC Near) clip.w < clip.z ndc.z > 1.0 ZMAX (NDC Far) Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 210 Note that, since the 2D (X,Y) extent of the projected view volume is subsequently mapped to the 2D pixel space viewport, the terms “viewport” and “view volume” are used somewhat interchangeably in this discussion. The CLIP unit will perform view volume clip test using NDC coordinates (the results of the speculative PerspectiveDivide). The treatment of negative ndc.w and invalid (NaN, +/-INF) coordinates is clarified below. Negative W Coordinates Consider for a moment vertices with a negative clip.w coordinate. Examination of the API definitions for “outside” shows that it is impossible for that vertex to be considered inside both the XMIN (NDC Left) and XMAX (NDC Right) planes. The clip.x coordinate would need to be greater than or equal to some positive value (-clip.w) to be considered inside the XMIN plane, while also being less than or equal to the negative (clip.w) value to be considered inside the XMAX plane. Obviously both these conditions cannot be met simultaneously, so a vertex with a negative clip.w coordinate will always appear outside. Surprisingly, it is possible for a vertex to be outside both the XMIN and XMAX planes (and likewise for the Y axis). This arises when clip.w is negative and clip.x falls between clip.w and -clip.w. Note, however, that in NDC space (post perspective-divide), this same vertex would be considered inside. This disparity arises from the loss of information from the perspective divide operation, specifically the signs of the input operands. The CLIP stage will avoid this artifact by supporting an additional clip.w=0 clip plane – a negative ndc.rhw value indicates the point is outside of the clip.w=0 plane. The assumption made in the Clip stage is that only the w>0 portion of clip space is considered visible. The VertexClipTest function tests each incoming 1/w value and, if negative, the vertex is tagged as being outside the w=0 plane. These vertex outcodes are combined in ClipDetermination to determine TA/TR/MC status. A negative w coordinate poses an additional issue due to the fact that VertexClipTest is performed using post-perspection-projection coordinates (NDC or screen space). This disparity arises from the loss of information from the perspective divide operation, specifically the signs of the input operands. For example, to test for (x>w) using NDC coordinates, (x/w>1) must be used when w>0, and (x/w<1) must be used when w<0. The VertexClipTest function therefore uses the sign of the incoming 1/w coordinate to select the appropriate comparison function for each of the VP and GB clip planes. As the CLIP thread performs clipping in 4D clip space, only the truly visible portions of objects (i.e, meeting the 4D clip space visibility criteria) will be considered. The CLIP thread should not output negative w (clip or NDC) coordinates. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 211 9.2.2 User-Specified Clipping The various APIs define mechanisms by which objects can be clipped or culled according to some user- specified parameter(s) in addition to the implied viewport clipping. The HW support of these mechanisms is restricted to use of the 8 UserClipFlags (UCFs) of the VUE Vertex Header. Software is required to provide the remaining support (e.g., the JITTER including GEN4 instructions to cause a distance value to be computed, tested for visibility, and generation of the appropriate UCF bit.) 9.2.3 Guard Band Note: Refer to Vertex X,Y Clamping and Quantization in the SF stage section for device-specific guardband size information. 3DClipping is time consuming. For cases where 2DClipping is sufficient, we are willing to forgo 3DClipping and instead apply 2DClipping during rendering. In the general case, this is possible only Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 212 when an object is totally within the ZMin and ZMax planes, and only clipping to the view volume X/Y MIN/MAX clip planes is required, as 2DClipping is restricted to a screen-aligned 2D rectangle. However, we must ensure that the 2D extent of these objects do not exceed the limitations of the renderer’s coordinate space (see Vertex X,Y Clamping and Quantization in the SF section). Therefore we define a 2D guardband region corresponding to (though likely somewhat smaller than) the maximum 2D extent supported by the renderer. During VertexClipTest, vertices are (optionally) subjected to an additional visibility test based on the 2D guardband region. During ClipDetermination, if an object is not trivially-rejected from the 2D viewport, the XMIN_GB, XMAX_GB, YMIN_GB and YMAX_GB guardband outcodes are used instead of the XMIN, XMAX, YMIN, YMAX view volume outcodes to determine trivial-accept. This will allow objects that fall within the guardband and possibly intersect the viewport to be trivially-accepted and passed down the pipeline. The diagram below shows some examples of objects (triangles) in relation to the viewport and guardband. The shaded triangles are examples of triangles that are not trivially accepted to the viewport but trivially accepted to the guardband and therefore passed to down the pipeline. Without the guardband, these triangles would have to be submitted to a CLIP thread. Normal Guardband Operation The CLIP stage needs to handle the case where the viewport XY is larger than the screen space coordinate range supported by the SF and WM units. This condition may arise when the API defines an Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 213 implicit 2D clip between the viewport XY extent and the rendertarget. In the 3D pipeline, the guardband must used to force explicit clipping in order to ensure legal coordinates are passed out of the CLIP stage. Therefore the CLIP unit supports a guardband that can be larger or smaller than the viewport (in any particular direction). The following diagram illustrates a case with a very large viewport, extending well beyond the guardband. Note that the only trivial accept case is where objects are completely within the guardband. Very Large Viewport Case 9.2.3.1 NDC Guardband Parameters Note: Refer to Vertex X,Y Clamping and Quantization in the SF stage section for device-specific guardband size information. When the CLIP unit performs VertexClipTest in NDC space, the guardband limits must be provided as NDC coordinates. The diagram below shows how the guardband NDC coordinates are derived. Specifically, the XMIN_GB NDC coordinate is simply the ratio of the (screen space) distance from the screen space VP center to the screen space GB XMin boundary over the distance from the VP center to the VP XMin (left) boundary. A similar computation yields the XMAX_GB (right), YMIN_GB (bottom) and YMAX_GB (top) guardband NDC coordinates. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 214 As these guardband parameters are defined relative to the viewport, each of the up-to-16 sets of viewport specifications supported in the 3D pipeline will require a corresponding set of guardband parameters. These guardband parameters are provided as a separate memory-resident state structure (CLIP_VIEWPORT), and referenced via the Clipper Viewport State Pointer contained in the CLIP_STATE structure. Note that the CLIP_VIEWPORT structure has a different definition than the SF_VIEWPORT structure used by the SF unit. 9.2.4 Vertex-Based Clip Testing & Considerations The CLIP unit performs clip test and determines whether objects need to be clipped based solely on information (position, UserClipFlags) provided at the vertices of the object as they arrive at the clip stage. Issues arise if and when the corresponding rendered object is not constrained to the convex hull of the object. Different APIs impose different treatment of these conditions. In addition and in the more general case, a CLIP thread could be used to convert the object (as defined by its vertices) into some arbitrary output primitive. In this case, the CLIP unit’s ClipTest/ClipDetermination logic may not be suitable for determination of when to reject/accept/clip objects. In this case the ClipMode can be used to route all (or all non-rejected) objects to CLIP threads, where the proper clip-test and clipping can occur in the CLIP kernel. One issue that arises is whether a trivial-reject to the VPXY is suitable. If this were allowed, an object might be discarded even if it would have been partially visible in the viewport. A second issue is whether a TA against the GB is suitable. If this were allowed, portions of the rendered object might be visible in the VP even if the object should have been clipped out of the VP. 9.2.4.1 Triangle Objects In the normal processing of triangle-based primitives (tristrip/trilist/polygon/etc.), the footprint of each triangle is constrained to the 2D convex hull. I.e., the rendering of these triangles will not produce pixels outside of the triangle. Therefore the normal operation of the CLIP unit functions will support the proper clip testing and clip determination for triangle objects:  Both the VPXY and GB clip boundaries can be utilized (as described above). If the triangle is TR against the VP, it can be discarded. Otherwise, if the triangle is TA against the GB, it can be passed down the pipeline (assuming it is TA against VPZ, UCFs, etc.) and properly handled by 2DClipping.  The GB parameters can be programmed to coincide with the maximum allowable screen space extent (though making the GB marginally smaller than this max extent is highly recommended). Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 215 9.2.4.2 Non-Wide Line Objects In the normal processing of non-wide, line-based primitives (linestrip/linelist/etc.), the footprint of each line is constrained to the 2D convex hull. I.e., the rendering of these lines will not produce pixels off of the line. Therefore the normal operation of the CLIP unit functions will support the proper clip testing and clip determination for non-wide line objects. (See Triangle Objects above). 9.2.4.3 9.2.4.4 Wide Line Objects The rendering hardware supports wide lines (solid lines with a line width or anti-aliased lines). When rendered, pixels outside of the convex hull will be generated. The following diagram shows an example of a wide line that normally would be TA against the GB. If the TA is allowed, the partially-visible region of the line would be rendered. In general, OpenGL dictates that the partially-visible region must not be rendered. In this case the line must be clipped-out against the VPXY (not TA against the GB). To accomplish this, SW could disable the GB when drawing wide lines. 9.2.4.5 Wide Points The GEN rendering hardware supports a width parameter for native line objects. When rendered, pixels surrounding the point (center) vertex will be generated. The following diagram shows an example wide point that normally would be TR against the VPXY. If the TR is allowed, the partially-visible region of the point would not be rendered. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 216 In general, OpenGL dictates that the partially-visible region must not be rendered. In this case the point must be TR against the VPXY (not TA against the GB). To accomplish this, SW could disable the GB when drawing wide points. 9.2.4.6 RECTLIST The CLIP unit treats RECTLIST exactly like TRILIST. No special consideration is made for the implied 4 th vertex of each rectangle (although ViewportXY and Guardband VertexClipTest theoretically should be sufficient to drive ClipDetermination). Given this, and the fact that RECTLIST is primarily intended for driver-generated “BLT” functions, there are number of restrictions on the use of RECTLIST, especially regarding the CLIP unit. Refer to the RECTLIST definition in 3D Pipeline. 9.2.5 3D Clipping If an object needs to be clipped, it will be passed to the CLIP thread. The CLIP thread will perform some (arbitrary) algorithm to clip the primitive, and subsequently output “new” vertices as a primitive defining the visible region of the input object (assuming there is a visible region). In the process of spawning the CLIP thread, the input vertices may be considered “consumed” and therefore dereferenced. Therefore the CLIP thread will need to copy (if required) any input VUE data to a new output VUE – there is no mechanism to “output” input vertices other than copying. supports only Fixed function Clipping 9.3 CLIP Stage Input As a stage of the 3D pipeline, the CLIP stage receives inputs from the previous (GS) stage. Refer to 3D Overview for an overview of the various types of input to a 3D Pipeline stage. The remainder of this subsection describes the inputs specific to the CLIP stage. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 217 9.3.1 State 9.3.1.1 3DSTATE CLIP The state used by the Clip Stage is defined by this inline state packet. 3DSTATE_CLIP Source: RenderCS Length Bias: 2 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: 0h 3DSTATE_PIPELINE Format: OpCode 23:16 3D Command Sub Opcode Default Value: 12h 3DSTATE_CLIP Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 02h Excludes DWord (0,1) Project: All Format: =n Total Length - 2 1 31:21 Reserved Project: All Format: MBZ 20 Front Winding Project: All Determines whether a triangle object is considered “front facing” if the screen space vertex positions, when traversed in the order, result in a clockwise (CW) or counter-clockwise (CCW) winding order. Does not apply to points or lines. Value Name Description Project 0h FRONTWINDING_CW All 1h FRONTWINDING_CCW All 19 Vertex Sub Pixel Precision Select Project: All Format: U1 Selects the number of fractional bits maintained in the vertex data Value Name Description Project 0h 8 sub pixel precision bits maintained All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 218 3DSTATE_CLIP 1h 4 sub pixel precision bits maintained All 18 EarlyCull Enable Project: All Format: Enable This field is used to enable/disable the EarlyCull function. Programming Notes Project Workaround : Due to Hardware issue "EarlyCull" needs to be enabled only for the cases where the incoming primitive topology into the clipper guaranteed to be Trilist. 17:16 Cull Mode Project: All Format: 3D_CullMode Controls removal (culling) of triangle objects based on orientation. The cull mode only applies to triangle objects and does not apply to lines, points or rectangles. Value Name Description Project 0h CULLMODE_BOTH All triangles are discarded (i.e., no triangle objects are drawn) All 1h CULLMODE_NONE No triangles are discarded due to orientation All 2h CULLMODE_FRONT Triangles with a front-facing orientation are discarded All 3h CULLMODE_BACK Triangles with a back-facing orientation are discarded All Programming Notes Orientation determination is based on the setting of the Front Winding state. 15:11 Reserved Project: All Format: MBZ 10 Clipper Statistics Enable Project: All Format: Enable This bit controls whether Clip-unit-specific statistics register(s) can be incremented. Value Name Description Project 0h Disable CL_INVOCATIONS_COUNT cannot increment All 1h Enable CL_INVOCATIONS_COUNT can increment All 9:8 Reserved Project: All Format: MBZ 7:0 User Clip Distance Cull Test Enable Bitmask Project: All Format: Enable[8] This 8 bit mask field selects which of the 8 user clip distances against which trivial reject / trivial accept determination needs to be made (does not cause a must clip).DX10 allows simultaneous use of ClipDistance and Cull Distance test of up to 8 distances. 2 31 CLIP Enable Project: All Format: Enable Specifies whether the CLIP function is enabled or disabled (pass-through). 30 API Mode Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 219 3DSTATE_CLIP Project: All Controls the definition of the NEAR clipping plane Value Name Description Project 0h APIMODE_OGL NEAR VP boundary == 0.0 (NDC) All 29 Reserved Project: All Format: MBZ 28 Viewport XY ClipTest Enable Project: All Format: Enable This field is used to control whether the Viewport X,Y extents are considered in VertexClipTest. See Tristrip Clipping Errata subsection. 27 Viewport Z ClipTest Enable Project: All Format: Enable This field is used to control whether the Viewport Z extents (near, far) are considered in VertexClipTest. 26 Guardband ClipTest Enable Project: All Format: Enable This field is used to control whether the Guardband X,Y extents are considered in VertexClipTest for non-point objects. If the Guardband ClipTest is DISABLED but the Viewport XY ClipTest is ENABLED, ClipDetermination operates as if the Guardband were coincident with the Viewport. If both the Guardband and Viewport XY ClipTest are DISABLED, all vertices are considered “visible” with respect to the XY directions. 25:24 Reserved Project: All Format: MBZ 23:16 User Clip Distance Clip Test Enable Bitmask Project: All Format: Enable[8] This 8 bit mask field selects which of the 8 user clip distances against which trivial reject / trivial accept / must clip determination needs to be made.DX10 allows simultaneous use of ClipDistance and Cull Distance test of up to 8 distances. 15:13 Clip Mode Project: All This field specifies a general mode of the CLIP unit, when the CLIP unit is ENABLED. Value Name Description Project 0h CLIPMODE_NORMAL TrivialAccept objects are passed down the pipeline, MustClip All objects Clipped in the Fixed Function Clipper HW, TrivialReject and BAD objects are discarded 1h Reserved All 2h Reserved All 3h CLIPMODE_REJECT_ALL All objects are discarded All 4h CLIPMODE_ACCEPT_ALL All objects (except BAD objects) are trivially accepted. This All effectively disables the clip-test/clip-determination function. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 220 3DSTATE_CLIP Note that the CLIP unit will still filter out adacency information, which may be required since the SF unit does not accept primitives with adjacency. 5h-7h Reserved All 12:10 Reserved Project: All Format: MBZ 9 Perspective Divide Disable Project: All Format: Disable This field disables the Perspective Divide function performed on homogeneous position read from the URB. This feature can be used by software to submit pre-transformed “screen-space” geometry for rasterization. This likely requires the W component of positions to contain “rhw” (aka 1/w) in order to support perspective-correct interpolation of vertex attributes. Likewise, the X,Y,Z components will likely be required to be X/W, Y/W, Z/W. Note that the device does not support clipping when perspective divide is disabled. Software must specify CLIPMODE_ACCEPT_ALL whenever it disables perspective divide. This implies that software must ensure that object positions are completely contained within the “guardband” screen-space limits imposed by the SF unit (e.g., by clipping in CPU SW before submitting the objects). 8 Non-Perspective Barycentric Enable Project: All Format: Enable This field enables computation of non-perspective barycentric parameters in the clipper, which are sent to SF unit in the must clip case. This field must be enabled if any non-perspective barycentric parameters are enabled in the Windower. 7:6 Reserved Project: All Format: MBZ 5:4 Triangle Strip/List Provoking Vertex Select Project: All Format: U2 enumerated type This field selects which vertex of a triangle (in a triangle strip or list primitive) is considered the “provoking vertex”. Value Name Project 0h Vertex 0 All 1h Vertex 1 All 2h Vertex 2 All 3h Reserved All 3:2 Line Strip/List Provoking Vertex Select Project: All Format: U2 enumerated type This field selects which vertex of a line (in a line strip or list primitive) is considered the “provoking vertex”. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 221 3DSTATE_CLIP Value Name Project 0h Vertex 0 All 1h Vertex 1 All 2h Reserved All 3h Reserved All 1:0 Triangle Fan Provoking Vertex Select Project: All Format: U32 enumerated type This field selects which vertex of a triangle (in a triangle fan primitive) is considered the “provoking vertex”. Value Name Project 0h Vertex 0 All 1h Vertex 1 All 2h Vertex 2 All 3h Reserved All 3 31:28 Reserved Project: All Format: MBZ 27:17 Minimum Point Width Project: All Format: U8.3 pixels This value is used to clamp read-back PointWidth values. 16:6 Maximum Point Width Project: All Format: U8.3 pixels This value is used to clamp read-back PointWidth values. 5 Force Zero RTAIndex Enable Project: All Format: Enable If set, the Clip unit will ignore the read-back RTAIndex and operate as if the value 0 was read-back. If clear, the read-back value is used. 4 Reserved Project: All Format: MBZ 3:0 Maximum VPIndex Project: All Format: U4-1 index value (# of viewports) This field specifies the maximum valid VPIndex value, corresponding to the number of active viewports. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 222 3DSTATE_CLIP If the source of the VPIndex exceeds this maximum value, a VPIndex value of 0 is passed down the pipeline. Note that this clamping does not affect a VPIndex value stored in the URB. 9.4 Object Staging The CLIP unit’s Object Staging Buffer (OSB) accepts streams of input vertex information packets, along with each vertex’s VertexClipTest result (outCode). This information is buffered until a complete object or the last vertex of the primitive topology is received. The OSB then performs the ClipDetermination function on the object vertices, and takes the actions required by the results of that function. 9.4.1 Partial Object Removal The OSB is responsible for removing incomplete LINESTRIP and TRISTRIP objects that it may receive from the preceding stage (GS). Partial object removal is not supported for other primitive types due to either (a) the GS is not permitted to output those primitive types (e.g., primitives with adjacency info), and the VF unit will have removed the partial objects as part of 3DPRIMITIVE processing, or (b) although the GS thread is allowed to output the primitive type (e.g., LINELIST), it is assumed that the GS kernel will be correctly implemented to avoid outputting partial objects (or pipeline behavior is UNDEFINED). An object is considered ‘partial’ if the last vertex of the primitive topology is encountered (i.e., PrimEnd is set) before a complete set of vertices for that object have been received. Given that only LINESTRIP and TRISTRIP primitive types are subject to CLIP unit partial object removal, the only supported cases of partial objects are 1-vertex LINESTRIPs and 1 or 2-vertex TRISTRIPs. 9.4.2 ClipDetermination Function In ClipDetermination, the vertex outcodes of the primitive are combined in order to determine the clip status of the object (TR: trivially reject; TA: trivial accept; MC: must clip; BAD: invalid coordinate). Only those vertices included in the object are examined (3 vertices for a triangle, 2 for a line, and 1 for a point). The outcode bit arrays for the vertices are separately ANDed (intersection) and ORed (union) together (across vertices, not within the array) to yield objANDCode and objORCode bit arrays. TR/TA against interesting boundary subsets are then computed. The TR status is computed as the logical OR of the appropriate objANDCode bits, as the vertices need only be outside of one common boundary to be trivially rejected. The TA status is computed as the logical NOR of the appropriate objORCode bits, as any vertex being outside of any of the boundaries prevents the object from being trivially accepted. If any vertex contains a BAD coordinate, the object is considered BAD and any computed TR/TA results will effectively be ignored in the final action determination. Next, the boundary subset TR/TA results are combined to determine an overall status of the object. If the object is TR against any viewport or enabled UC plane, the object is considered TR. Note that, by definition, being TR against a VPXY boundary implies that the vertices will be TR agains the corresponding GB boundary, so computing TR_GB is unnecessary. The treatment of the UCF outcodes is conditional on the UserClipFlags MustClip Enable state. If DISABLED, an object that is not TR against the UCFs is considered TA against them. Put another way, objects will only be culled (not clipped) with respect to the UCFs. If ENABLED, the UCF outcodes are Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 223 treated like the other outcodes, in that they are used to determine TR, TA or MC status, and an object can be passed to a CLIP thread simply based on it straddling a UCF. Finally, the object is considered MC if it is neither TR or TA. The following logic is used to compute the final TR, TA, and MC status. // // ClipDetermination // // // Compute objANDCode and objORCode // switch (object type) { case POINT: { objANDCode[…] = v0.outCode[…] objORCode[…] = v0.outCode[…] } break case LINE: { objANDCode[…] = v0.outCode[…] & v1.outCode[…] objORCode[…] = v0.outCode[…] | v1.outCode[…] } break case TRIANGLE: { objANDCode[…] = v0.outCode[…] & v1.outCode[…] & v2.outCode[…] objORCode[…] = v0.outCode[…] | v1.outCode[…] | v2.outCode[…] } break // // Determine TR/TA against interesting boundary subsets // TR_VPXY = (objANDCode[VP_L] | objANDCode[VP_R] | objANDCode[VP_T] | objANDCode[VP_B]) TR_GB = (objANDCode[GB_L] | objANDCode[GB_R] | objANDCode[GB_T] | objANDCode[GB_B]) TA_GB = !(objORCode[GB_L] | objORCode[GB_R] | objORCode[GB_T] | objORCode[GB_B]) TA_VPZ = !(objORCode[VP_N] | objORCode[VP_Z]) Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 224 TR_VPZ = (objANDCode[VP_N] | objANDCode[VP_Z]) TA_UC = !(objORCode[UC0] | objORCode[UC1] | … | objORCode[UC7]) TR_UC = (objANDCode[UC0] | objANDCode[UC1] | … | objANDCode[UC7]) BAD = objORCode[BAD] TA_NEGW = !objORCode[NEGW] TR_NEGW = objANDCode[NEGW] // // Trivial Reject // // An object is considered TR if all vertices are TR against any common boundary // Note that this allows the case of the VPXY being outside the GB // TR = TR_GB || TR_VPXY || TR_VPZ || TR_UC || TR_NEGW // // Trivial Accept // // For an object to be TA, it must be TA against the VPZ and GB, not TR, // and considered TA against the UC planes and NEGW // If the UCMC mode is disabled, an object is considered TA against the UC // as long as it isn’t TR against the UC. // If the UCMC mode is enabled, then the object really has to be TA against the UC // to be considered TA // In this way, enabling the UCMC mode will force clipping if the object is neither // TA or TR against the UC // TA = !TR && TA_GB && TA_VPZ && TA_NEGW UCMC = CLIP_STATE.UserClipFlagsMustClipEnable TA = TA && ( (UCMC && TA_UC) || (!UCMC && !TR_UC) ) // // MustClip // This is simply defined as not TA or TR // Note that exactly one of TA, TR and MC will be set // Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 225 MC = !(TA || TR) 9.4.3 ClipMode The ClipMode state determines what action the CLIP unit takes given the results of ClipDetermination. The possible actions are:  PASSTHRU: Pass the object directly down the pipeline. A CLIP thread is not spawned.  DISCARD: Remove the object from the pipeline and dereference object vertices as required (i.e., dereferencing will not occur if the vertices are shared with other objects).  SPAWN: Pass the object to a CLIP thread. In the process of initiating the thread, the object vertices may be dereferenced. The following logic is used to determine what to do with the object (PASSTHRU or DISCARD or SPAWN). // // Use the ClipMode to determine the action to take // switch (CLIP_STATE.ClipMode) { case NORMAL: { PASSTHRU = TA && !BAD DISCARD = TR || BAD SPAWN = MC && !BAD } case CLIP_ALL: { PASSTHRU = 0 DISCARD = 0 SPAWN = 1 } case CLIP_NOT_REJECT: { PASSTHRU = 0 DISCARD = TR || BAD SPAWN = !(TR || BAD) } case REJECT_ALL: { PASSTHRU = 0 DISCARD = 1 SPAWN = 0 } case ACCEPT_ALL: { PASSTHRU = !BAD Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 226 DISCARD = BAD SPAWN = 0 } } endswitch 9.4.3.1 NORMAL ClipMode In NORMAL mode, objects will be discarded if TR or BAD, passed through if TA, and passed to a CLIP thread if MC. Those mode is typically used when the CLIP kernel is only used to perform 3D Clipping (the expected usage model). 9.4.3.2 CLIP_ALL ClipMode In CLIP_ALL mode, all objects (regardless of classification) will be passed to CLIP threads. Note that this includes BAD objects. This mode can be used to perform arbritrary processing in the CLIP thread, or as a backup if for some reason the CLIP unit fixed functions (VertexClipTest, ClipDetermination) are not sufficient for controlling 3D Clipping. 9.4.3.3 CLIP_NON_REJECT ClipMode This mode is similar to CLIP_ALL mode, but TR and BAD objects are discarded an all other (TA, MC) objects are passed to CLIP threads. Usage of this mode assumes that the CLIP unit fixed functions (VertexClipTest, ClipDetermination) are sufficient at least in respect to determining trivial reject. 9.4.3.4 REJECT_ALL ClipMode In REJECT_ALL mode, all objects (regardless of classification) are discarded. This mode effectively clips out all objects. 9.4.3.5 ACCEPT_ALL ClipMode In ACCEPT_ALL mode, all non-BAD objects are passed directly down the pipeline. This mode partially disables the CLIP stage. BAD objects will still be discarded, and incomplete primitives (generated by a GS thread) will be discarded. Primitive topologies with adjacency are also handled, in that the adjacent-only vertices are dereferenced and only non-adjacent objects are passed down the pipeline. This condition can arise when primitive topologies with adjacency are generated but the GS stage is disabled. If this condition is allowed, the CLIP stage must not be completely disabled – as this would allow adjacent vertices to pass through the CLIP stage and lead to UNPREDICATBLE results as the rest of the pipeline does not comprehend adjacency. 9.5 Object Pass-Through Depending on ClipMode, objects may be passed directly down the pipeline. The PrimTopologyType associated with the output objects may differ from the input PrimTopologyType, as shown in the table below. Programming Note: The CLIP unit does not tolerate primitives with adjacency that have “dangling vertices”. This should not be an issue under normal conditions, as the VF unit will not generate these Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 227 sorts of primitives and the GS thread is restricted (though by specification only) to not output these sorts of primitives. Input Pass-Through Output PrimTopologyType PrimTopologyType Notes POINTLIST POINTLIST POINTLIST_BF POINTLIST_BF LINELIST LINELIST LINELIST_ADJ LINELIST Adjacent vertices removed. LINESTRIP LINESTRIP LINESTRIP_ADJ LINESTRIP Adjacent vertices removed. LINESTRIP_BF LINESTRIP_BF LINESTRIP_CONT LINESTRIP_CONT LINESTRIP_CONT_BF LINESTRIP_CONT_BF LINELOOP N/A Not supported after GS. TRILIST TRILIST RECTLIST RECTLIST TRILIST_ADJ TRILIST Adjacent vertices removed. TRISTRIP TRISTRIP or Depends on where the incoming strip is broken (if at all) by TRISTRIP_REV discarded or clipped objects See Tristrip Clipping Errata subsection. TRISTRIP_REV TRISTRIP or Depends on where the incoming strip is broken (if at all) by TRISTRIP_REV discarded or clipped objects See Tristrip Clipping Errata subsection. TRISTRIP_ADJ TRISTRIP or Depends on where the incoming strip is broken (if at all) by TRISTRIP_REV discarded or clipped objects Adjacent vertices removed. See Tristrip Clipping Errata subsection. TRIFAN TRIFAN TRIFAN_NOSTIPPLE TRIFAN_NOSTIPPLE POLYGON POLYGON QUADLIST N/A Not supported after GS. QUADSTRIP N/A Not supported after GS. 9.6 Primitive Output (This section refers to output from the CLIP unit to the pipeline, not output from the CLIP thread) The CLIP unit will output primitives (either passed-through or generated by a CLIP thread) in the proper order. This includes the buffering of a concurrent CLIP thread’s output until the preceding CLIP thread terminates. Note that the requirement to buffer subsequent CLIP thread output until the preceding CLIP Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 228 thread terminates has ramifications on determining the number of VUEs allocated to the CLIP unit and the number of concurrent CLIP threads allowed. 9.7 Other Functionality 9.7.1 Statistics Gathering The CLIP unit includes logic to assist in the gathering of certain pipeline statistics, primarily in support of the Asynchronous Query function of the APIs. The statistics take the form of MI counter registers (see Memory Interface Registers), where the CLIP unit provides signals causing those counters to increment. Software is responsible for controlling (enabling) these counters in order to provide the required statistics at the DDI level. For example, software might need to disable the statistics gathering before submitting non-API-visible objects (e.g., RECTLISTs) for processing. The CLIP unit must be ENABLED (via the CLIP Enable bit of PIPELINED_STATE_POINTERS) in order to it to affect the statistics counters. This might lead to a pathological case where the CLIP unit needs to be ENABLED simply to provide statistics gathering. If no clipping functionality is desired, Clip Mode can be set to ACCEPT_ALL to effectively inhibit clipping while leaving the CLIP stage ENABLED. The two statistics the CLIP unit affects (if enabled) are:  CL_INVOCATION_COUNT:  Incremented for every object received from the GS stage. 9.7.1.1 CL_INVOCATION_COUNT If the Statistics Enable bit (CLIP_STATE) is set, the CLIP unit increments the CL_INVOCATION_COUNT register for every complete object received from the GS stage. In order to maintain a count of application-generated objects, software will need to clear the CLIP unit’s Statistic Enable whenever driver-generated objects are rendered. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 229 10. 3D Pipeline - Strips and Fans (SF) Stage 10.1 Overview The Strips and Fan (SF) stage of the 3D pipeline is responsible for performing “setup” operations required to rasterize 3D objects. 10.1.1 Inputs from CLIP The following table describes the per-vertex inputs passed to the SF unit from the previous (CLIP) stage of the pipeline. SF’s Vertex Pipeline Inputs Variable Type Description primType enum Type of primitive topology the vertex belongs to. Primitive Assembly for a list of primitive types supported by the SF unit. See 3D Pipeline for descriptions of these topologies. Notes: The CLIP unit will convert any primitive with adjacency (3DPRIMxxx_ADJ) it receives from the pipeline into the corresponding primitive without adjacency (3DPRIMxxx). QUADLIST, QUADSTRIP, LINELOOP primitives are not supported by the SF unit. Software must use a GS thread to convert these to some other (supported) primitive type. If an object is clipped by the hardware clipper, the CLunit would force this field to “3DPRIM_POLYGON”. SFunit would process this incoming object just as it would any other “3DPRIM_POLYGON”. SFunit selects vertex 0 as the provoking vertex. primStart,primEnd boolean Indicate vertex’s position within the primitive topology vInX[] float Vertex X position (screen space or NDC space) vInY[] float Vertex Y position (screen space or NDC space) vInZ[] float Vertex Z position (screen space or NDC space) vInInvW[] float Reciprocal of Vertex homogeneous (clip space) W hVUE[] URB Points to the vertex’s data stored in the URB (one VUE handle per vertex) address renderTargetArrayIndex uint Index of the render target (array element or 3D slice), clamped to 0 by the GS unit if the max value was exceeded. If this vertex is the leading vertex of an object within the primitive topology, this value will be associated with that object in subsequent processing. viewPortIndex uint Index of a viewport transform matrix within the SF_VIEWPORT structure used to perform Viewport Transformation on object vertices and scissor operations on an object. If this vertex is the leading vertex of an object within the primitive topology, this Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 230 Variable Type Description value will be associated with that object in the Viewport Transform and Scissor subfunctions, otherwise the value is ignored. Note that for primitive topologies with vertices shared between objects, this means a shared vertex may be subject to multiple Viewport Transformation operations if the viewPortIndex varies within the topology. pointSize uint If this vertex is within a POINTLIST[_BF] primitive topology, this value specifies the screen space size (width,height) of the square point to be rasterized about the vertex position. Otherwise the value is ignored. 10.1.2 Attribute Setup/Interpolation Process The following sections describe the Attribute Setup/Interpolation Process. 10.1.2.1 Attribute Setup/Interpolation Process Hardware computes all needed parameters, as there is no setup thread. 10.1.3 Outputs to WM The outputs from the SF stage to the WM stage are mostly comprised of implementation-specific information required for the rasterization of objects. The types of information is summarized below, but as the interface is not exposed to software a detailed discussion is not relevant to this specification.  PrimType of the object  VPIndex, RTAIndex associated with the object  Coefficients for Z, 1/W, perspective and non-perspective b1 and b2 per vertex, and attribute vertex deltas a0, a1, and a2 per attribute.  Information regarding the X,Y extent of the object (e.g., bounding box, etc.).  Edge or line interpolation information (e.g., edge equation coefficients, etc.).  Information on where the WM is to start rasterization of the object.  Object orientation (front/back-facing).  Last Pixel indication (for line drawing). 10.2 Primitive Assembly The first subfunction within the SF unit is Primitive Assembly. Here 3D primitive vertex information is buffered and, when a sufficient number of vertices are received, converted into basic 3D objects which are then passed to the Viewport Transformation subfunction. The number of vertices passed with each primitive is constrained by the primitive type. Primitive Assembly. Passing any other number of vertices results in UNDEFINED behavior. Note that this restriction only applies to primitive output by GS threads (which is under control of the GS kernel). See the Vertex Fetch chapter for details on how the VF unit automatically removes incomplete objects resulting from processing a 3DPRIMITIVE command. SF-Supported Primitive Types & Vertex Count Restrictions primType VertexCount Restriction 3DPRIM_TRILIST nonzero multiple of 3 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 231 primType VertexCount Restriction >=3 3DPRIM_TRISTRIP 3DPRIM_TRISTRIP_REVERSE >=3 3DPRIM_TRIFAN 3DPRIM_TRIFAN_NOSTIPPLE 3DPRIM_POLYGON 3DPRIM_LINELIST nonzero multiple of 2 >=2 3DPRIM_LINESTRIP 3DPRIM_LINESTRIP_CONT 3DPRIM_LINESTRIP_BF 3DPRIM_LINESTRIP_CONT_BF 3DPRIM_RECTLIST nonzero multiple of 3 nonzero 3DPRIM_POINTLIST 3DPRIM_POINTLIST_BF Primitive Assembly for a list of the 3D object types. 3D Object Types objectType generated by primType Vertices/Object 3DOBJ_POINT 1 3DPRIM_POINTLIST 3DPRIM_POINTLIST_BF 3DOBJ_LINE 2 3DPRIM_LINELIST 3DPRIM_LINESTRIP 3DPRIM_LINESTRIP_CONT 3DPRIM_LINESTRIP_BF 3DPRIM_LINESTRIP_CONT_BF 3DOBJ_TRIANGLE 3 3DPRIM_TRILIST 3DPRIM_TRISTRIP 3DPRIM_TRISTRIP_REVERSE 3DPRIM_TRIFAN 3DPRIM_TRIFAN_NOSTIPPLE 3DPRIM_POLYGON 3DOBJ_RECTANGLE 3 (expanded to 4 in RectangleCompletion) 3DPRIM_RECTLIST Primitive Assembly for the outputs of Primitive Decomposition. Primitive Decomposition Outputs Variable Type Description Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 232 Variable Type Description objectType enum Type of object. Primitive Assembly nV uint The number of object vertices passed to Object Setup. Primitive Assembly v[0..nV-1]* various Data arrays associated with object vertices. Data in the array consists of X, Y, Z, invW and a pointer to the other vertex attributes. These additional attributes are not used by directly by the 3D fixed functions but are made available to the SF thread. The number of valid vertices depends on the object type. Primitive Assembly invertOrientation enum Indicates whether the orientation (CW or CCW winding order) of the vertices of a triangle object should be inverted. Ignored for non-triangle objects. backFacing enum Valid only for points and line objects, indicates a back facing object. This is used later for culling. provokingVtx uint Specifies the index (into the v[] arrays) of the vertex considered the “provoking” vertex (for flat shading). The selection of the provoking vertex is programmable via SF_STATE (xxx Provoking Vertex Select state variables.) polyStippleEnable boolean TRUE if Polygon Stippling is enabled. FALSE for TRIFAN_NOSTIPPLE. Ignored for non- triangle objects. continueStipple boolean Only applies to line objects. TRUE if Line Stippling should be continued (i.e., not reset) from where the previous line left off. If FALSE, Line Stippling is reset for each line object. renderTargetIndex uint Index of the render target (array element or 3D slice), clamped to 0 by the GS unit if the max value was exceeded. This value is simply passed in SF thread payloads and not used within the SF unit. viewPortIndex uint Index of a viewport transform matrix within the SF_VIEWPORT structure used to perform Viewport Transformation on object vertices and scissor operations on an object. pointSize unit For point objects, this value specifies the screen space size (width,height) of the square point to be rasterized about the vertex position. Otherwise the value is ignored. The following table defines, for each primitive topology type, which vertex’s VPIndex/RTAIndex applies to the objects within the topology. VPIndex/RTAIndex Selection PrimTopologyType Viewport Index Usage POINTLIST Each vertex supplies the VPIndex for the corresponding point object POINTLIST_BF LINELIST The leading vertex of each line supplies the VPIndex for the corresponding line object. V0.VPIndex Line(V0,V1) V2.VPIndex Line(V2,V3) … LINESTRIP The leading vertex of each line segment supplies the VPIndex for the corresponding line object. LINESTRIP_BF V0.VPIndex Line(V0,V1) LINESTRIP_CONT V1.VPIndex Line(V1,V2) LINESTRIP_CONT_BF … NOTE: If the VPIndex changes within the topology, shared vertices will be processed Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 233 (mapped) multiple times. TRILIST The leading vertex of each triangle/rect supplies the VPIndex for the corresponding triangle/rect objects. RECTLIST V0.VPIndex Tri(V0,V1,V2) V3.VPIndex Tri(V3,V4,V5) … TRISTRIP The leading vertex of each triangle supplies the VPIndex for the corresponding triangle object. TRISTRIP_REVERSE V0.VPIndex Tri(V0,V1,V2) V1.VPIndex Tri(V1,V2,V3) … NOTE: If the VPIndex changes within the primitive, shared vertices will be processed (mapped) multiple times. The first vertex (V0) supplies the VPIndex for all triangle objects. TRIFAN TRIFAN_NOSTIPPLE POLYGON 10.2.1 Point List Decomposition The 3DPRIM_POINTLIST and 3DPRIM_POINTLIST_BACKFACING primitives specify a list of independent points. 3DPRIM_POINTLIST Primitive The decomposition process divides the list into a series of basic 3DOBJ_POINT objects that are then passed individually and in order to the Object Setup subfunction. The provokingVertex of each object is, by definition, v[0]. Points have no winding order, so the primitive command is used to explicitly state whether they are back- facing or front-facing points. Primitives of type 3DPRIM_POINTLIST_BACKFACING are decomposed exactly the same way as 3DPRIM_POINTLIST primitives, but the backFacing variable is set for resulting point objects being passed on to object setup. PointListDecomposition() { objectType = 3DOBJ_POINT Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 234 nV = 1 provokingVtx = 0 if (primType == 3DPRIM_POINTLIST) backFacing = FALSE else // primType == 3DPRIM_POINTLIST_BACKFACING backFacing = TRUE for each (vertex I in [0..vertexCount-1]) { v[0] vIn[i]// copy all arrays (e.g., v[]X, v[]Y, etc.) ObjectSetup() } } 10.2.2 Line List Decomposition The 3DPRIM_LINELIST primitive specifies a list of independent lines. 3DPRIM_LINELIST Primitive The decomposition process divides the list into a series of basic 3DOBJ_LINE objects that are then passed individually and in order to the Object Setup stage. The lines are generated with the following object vertex order: v0, v1; v2, v3; and so on. The provokingVertex of each object is taken from the Line List/Strip Provoking Vertex Select state variable, as programmed via SF_STATE. LineListDecomposition() { objectType = 3DOBJ_LINE nV = 2 provokingVtx = Line List/Strip Provoking Vertex Select continueStipple = FALSE for each (vertex I in [0..vertexCount-2] by 2) { v[0] arrays vIn[i] arrays v[1] arrays vIn[i+1] arrays ObjectSetup() } Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 235 } 10.2.3 Line Strip Decomposition The 3DPRIM_LINESTRIP, 3DPRIM_LINESTRIP_CONT, 3DPRIM_LINESTRIP_BF, and 3DPRIM_LINESTRIP_CONT_BF primitives specify a list of connected lines. 3DPRIM_LINESTRIP_xxx Primitive The decomposition process divides the strip into a series of basic 3DOBJ_LINE objects that are then passed individually and in order to the Object Setup stage. The lines are generated with the following object vertex order: v0,v1; v1,v2; and so on. The provokingVertex of each object is taken from the Line List/Strip Provoking Vertex Select state variable, as programmed via SF_STATE. Lines have no winding order, so the primitive command is used to explicitly state whether they are back- facing or front-facing lines. Primitives of type 3DPRIM_LINESTRIP[_CONT]_BF are decomposed exactly the same way as 3DPRIM_LINESTRIP[_CONT] primitives, but the backFacing variable is set for the resulting line objects being passed on to object setup. Likewise 3DPRIM_LINESTRIP_CONT[_BF] primitives are decomposed identically to basic line strips, but the continueStipple variable is set to true so that the line stipple pattern will pick up from where it left off with the last line primitive, rather than being reset. LineStripDecomposition() { objectType = 3DOBJ_LINE nV = 2 provokingVtx = Line List/Strip Provoking Vertex Select if (primType == 3DPRIM_LINESTRIP) { backFacing = FALSE continueStipple = FALSE } else if (primType == 3DPRIM_LINESTRIP_BF) { backFacing = TRUE continueStipple = FALSE } else if (primType == 3DPRIM_LINESTRIP_CONT) { backFacing = FALSE continueStipple = TRUE } else if (primType == 3DPRIM_LINESTRIP_CONT_BF) { Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 236 backFacing = TRUE continueStipple = TRUE } for each (vertex I in [0..vertexCount-1]) { v[0] arrays vIn[i] arrays v[1] arrays vIn[i+1] arrays ObjectSetup() continueStipple = TRUE } } 10.2.4 Triangle List Decomposition The 3DPRIM_TRILIST primitive specifies a list of independent triangles. 3DPRIM_TRILIST Primitive The decomposition process divides the list into a series of basic 3DOBJ_TRIANGLE objects that are then passed individually and in order to the Object Setup stage. The triangles are generated with the following object vertex order: v0,v1,v2; v3,v4,v5; and so on. The provokingVertex of each object is taken from the Triangle List/Strip Provoking Vertex Select state variable, as programmed via SF_STATE. TriangleListDecomposition() { objectType = 3DOBJ_TRIANGLE nV = 3 invertOrientation = FALSE provokingVtx = Triangle List/Strip Provoking Vertex Select polyStippleEnable = TRUE for each (vertex I in [0..vertexCount-3] by 3) { v[0] arrays vIn[i] arrays v[1] arrays vIn[i+1] arrays v[2] arrays vIn[i+2] arrays Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 237 ObjectSetup() } } 10.2.5 Triangle Strip Decomposition The 3DPRIM_TRISTRIP and 3DPRIM_TRISTRIP_REVERSE primitives specify a series of triangles arranged in a strip, as illustrated below. 3DPRIM_TRISTRIP[_REVERSE] Primitive The decomposition process divides the strip into a series of basic 3DOBJ_TRIANGLE objects that are then passed individually and in order to the Object Setup stage. The triangles are generated with the following object vertex order: v0,v1,v2; v1,v2,v3; v2,v3,v4; and so on. Note that the winding order of the vertices alternates between CW (clockwise), CCW (counter-clockwise), CW, etc. The provokingVertex of each object is taken from the Triangle List/Strip Provoking Vertex Select state variable, as programmed via SF_STATE. The 3D pipeline uses the winding order of the vertices to distinguish between front-facing and back-facing triangles (Triangle Orientation Face Culling below). Therefore, the 3D pipeline must account for the alternation of winding order in strip triangles. The invertOrientation variable is generated and used for this purpose. To accommodate the situation where the driver is forced to break an input strip primitive into multiple tristrip primitive commands (e.g., due to ring or batch buffer size restrictions), two tristrip primitive types are supported. 3DPRIM_TRISTRIP is used for the initial section of a strip, and wherever a continuation of a strip starts with a triangle with a CW winding order. 3DPRIM_TRISTRIP_REVERSE is used for a continuation of a strip that starts with a triangle with a CCW winding order. TriangleStripDecomposition() { objectType = 3DOBJ_TRIANGLE nV = 3 provokingVtx = Triangle List/Strip Provoking Vertex Select if (primType == 3DPRIM_TRISTRIP) invertOrientation = FALSE else // primType == 3DPRIM_TRISTRIP_REVERSE invertOrientation = TRUE polyStippleEnable = TRUE Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 238 for each (vertex I in [0..vertexCount-3]) { v[0] arrays vIn[i] arrays v[1] arrays vIn[i+1] arrays v[2] arrays vIn[i+2] arrays ObjectSetup() invertOrientation = ! invertOrientation } } 10.2.6 Triangle Fan Decomposition The 3DPRIM_TRIFAN and 3DPRIM_TRIFAN_NOSTIPPLE primitives specify a series of triangles arranged in a fan, as illustrated below. 3DPRIM_TRIFAN Primitive The decomposition process divides the fan into a series of basic 3DOBJ_TRIANGLE objects that are then passed individually and in order to the Object Setup stage. The triangles are generated with the following object vertex order: v0,v1,v2; v0,v2,v3; v0,v3,v4; and so on. As there is no alternation in the vertex winding order, the invertOrientation variable is output as FALSE unconditionally. The provokingVertex of each object is taken from the Triangle Fan Provoking Vertex state variable, as programmed via SF_STATE. Primitives of type 3DPRIM_TRIFAN_NOSTIPPLE are decomposed exactly the same way, except the polyStippleEnable variable is FALSE for the resulting objects being passed on to object setup. This will inhibit polygon stipple for these triangle objects. TriangleFanDecomposition() { objectType = 3DOBJ_TRIANGLE nV = 3 invertOrientation = FALSE provokingVtx = Triangle Fan Provoking Vertex Select if (primType == 3DPRIM_TRIFAN) polyStippleEnable = TRUE else // primType == 3DPRIM_TRIFAN_NOSTIPPLE Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 239 polyStippleEnable = FALSE v[0] arrays vIn[0] arrays// the 1st vertex is common for each (vertex I in [1..vertexCount-2]) { v[1] arrays vIn[i] arrays v[2] arrays vIn[i+1] arrays ObjectSetup() } } 10.2.7 Polygon Decomposition The 3DPRIM_POLYGON primitive is identical to the 3DPRIM_TRIFAN primitive with the exception that the provokingVtx is overridden with 0. This support has been added specifically for OpenGL support, avoiding the need for the driver to change the provoking vertex selection when switching between trifan and polygon primitives. 10.2.8 Rectangle List Decomposition The 3DPRIM_RECTLIST primitive command specifies a list of independent, axis-aligned rectangles. Only the lower right, lower left, and upper left vertices (in that order) are included in the command – the upper right vertex is derived from the other vertices (in Object Setup). 3DPRIM_RECTLIST Primitive The decomposition of the 3DPRIM_RECTLIST primitive is identical to the 3DPRIM_TRILIST decomposition, with the exception of the objectType variable. RectangleListDecomposition() { objectType = 3DOBJ_RECTANGLE nV = 3 invertOrientation = FALSE provokingVtx = 0 for each (vertex I in [0..vertexCount-3] by 3) { v[0] arrays vIn[i] arrays Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 240 v[1] arrays vIn[i+1] arrays v[2] arrays vIn[i+2] arrays ObjectSetup() } } 10.3 Object Setup The Object Setup subfunction of the SF stage takes the post-viewport-transform data associated with each vertex of a basic object and computes various parameters required for scan conversion. This includes generation of implied vertices, translations and adjustments on vertex positions, and culling (removal) of certain classes of objects. The final object information is passed to the Windower/Masker (WM) stage where the object is rasterized into pixels. 10.3.1 Invalid Position Culling (Pre/Post-Transform) At input the the SF stage, any objects containing a floating-point NaN value for Position X, Y, Z, or RHW will be unconditionally discarded. Note that this occurs on an object (not primitive) basis. If Viewport Transformation is enabled, any objects containing a floating-point NaN value for post- transform Position X, Y or Z will be unconditionally discarded. 10.3.2 Viewport Transformation If the Viewport Transform Enable bit of SF_STATE is ENABLED, a viewport transformation is applied to each vertex of the object. The VPIndex associated with the leading vertex of the object is used to obtain the Viewport Matrix Element data from the corresponding element of the SF_VIEWPORT structure in memory. For each object vertex, the following scale and translate transformation is applied to the position coordinates: x’ = m00 * x + m30 y’ = m11 * y + m31 z’ = m22 * z + m32 Software is responsible for computing the matrix elements from the viewport information provided to it from the API. 10.3.3 Destination Origin Bias The positioning of the pixel sampling grid is programmable and is controlled by the Destination Origin Horizontal/Vertical Bias state variables (set via SF_STATE). If these bias values are both 0, pixels are sampled on an integer grid. Pixel (0,0) will be considered inside the object if the sample point at XY coordinate (0,0) falls within the primitive. If the bias values are both 0.5, pixels are sampled on a “half” integer grid (i.e., X.5, Y.5). Pixel (0,0) will be considered inside the object if the sample point at XY coordinate (0.5,0.5) falls within the primitive. This positioning of the sample grid corresponds with the OpenGL rasterization rules, where “fragment centers” lay on a half-integer grid. It also corresponds with the Intel740 rasterizer (though that device did not employ “top left” rules). Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 241 Note that subsequent descriptions of rasterization rules for the various objects will be with reference to the pixel sampling grid. Destination Origin Bias 10.3.4 Point Rasterization Rule Adjustment POINT objects are rasterized as square RECTANGLEs, with one exception: The Point Rasterization Rule state variable (in SF_STATE) controls the rendering of point object edges that fall directly on pixel sample points, as the treatment of these edge pixels varies between APIs. The following diagram shows the rasterization of a 2-pixel wide point centered at (2,2) given current DX rasterization rules (where changed the rasterization of points to match the rasterization of an identical (square) polygon). Here the pixel sample grid coincides with the integer pixel coordinates, and the Point Rasterization Rule is set to RASTRULE_UPPER_LEFT. Note that the pixels which lie only on the upper and/or left edges are lit. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 242 RASTRULE_UPPER_LEFT 10.3.5 Drawing Rectangle Offset Application The Drawing Rectangle Offset subfunction offsets the object’s vertex X,Y positions by the pixel-exact, unclipped drawing rectangle origin (as programmed via the Drawing Rectangle Origin X,Y values in the 3DSTATE_DRAWING_RECTANGLE command). The Drawing Rectangle Offset subfunction (at least with respect to Color Buffer access) is , and therefore to (effectively) turn off the offset function the origin would need to be set to (0,0). A non-zero offset is typically specified when window-relative or viewport-relative screen coordinates are input to the device. Here the drawing rectangle origin would be loaded with the absolute screen coordinates of the window’s or viewport’s upper-left corner. Clipping of objects which extend outside of the Drawing Rectangle occurs later in the pipeline. Note that this clipping is based on the “clipped” draw rectangle (as programmed via the Clipped Drawing Rectangle values in the 3DSTATE_DRAWING_RECTANGLE command), which must be clamped by software to the rendertarget boundaries. The unclipped drawing rectangle origin, however, can extend outside the screen limits in order to support windows whose origins are moved off-screen. This is illustrated in the following diagrams. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 243 Onscreen Draw Rectangle Partially-offscreen Draw Rectangle 10.3.5.1 3DSTATE_DRAWING_RECTANGLE 3DSTATE_DRAWING_RECTANGLE Project: All Source: RenderCS Length Bias: 2 The 3DSTATE_DRAWING_RECTANGLE command is used to set the 3D drawing rectangle and related state. 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: 00h 3DSTATE_DRAWING_RECTANGLE Format: OpCode Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 244 3DSTATE_DRAWING_RECTANGLE 15:14 Reserved Format: MBZ 13:8 Reserved Format: MBZ 7:0 DWord Length Default Value: 2h Excludes DWord (0,1) Project: All Format: =n Total Length - 2 1 31:16 Clipped Drawing Rectangle Y Min Project: All Format: U16 in Pixels from Color Buffer origin (upper left corner) Specifies Ymin value of (inclusive) intersection of Drawing rectangle with the Color (Destination) Buffer, used for clipping. Pixels with Y coordinates less than Ymin will be clipped out. Value Name Project [0,16383] Device ignores bits 31:30 Programming Notes Project This value can be larger than Clipped Drawing Rectangle Y Max. If Ymin>Ymax, the clipped drawing rectangle is null, all polygons are discarded. If Ymin==Ymax, the clipped drawing rectangle is 1 pixel wide in the Y direction. 15:0 Clipped Drawing Rectangle X Min Project: All Format: U16 in Pixels from Color Buffer origin (upper left corner) Specifies Xmin value of (inclusive) intersection of Drawing rectangle with the Color (Destination) Buffer, used for clipping. Pixels with X coordinates less than Xmin will be clipped out. Value Name Project [0,16383] Device ignores bits 15:14 Programming Notes Project This value can be larger than Clipped Drawing Rectangle X Max. If Xmin>Xmax, the clipped drawing rectangle is null, all polygons are discarded. If Xmin==Xmax, the clipped drawing rectangle is 1 pixel wide in the X direction. 2 31:16 Clipped Drawing Rectangle Y Max Project: All Format: U16 in Pixels from Color Buffer origin (upper left corner) Specifies Ymax value of (inclusive) intersection of Drawing rectangle with the Color (Destination) Buffer, used for clipping. Pixels with coordinates greater than Ymax will be clipped out. Value Name Project [0,16383] Device ignores bits 31:30 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 245 3DSTATE_DRAWING_RECTANGLE Programming Notes Project This value can be less than Clipped Drawing Rectangle Y Min. If Ymax xmax or ymin > ymax will cause all polygons to be discarded for a given viewport (effectively a null scissor rectangle). 10.3.12 Line Rasterization The device supports three styles of line rendering: zero-width (cosmetic) lines, non-antialiased lines, and antialiased lines. (These rules also satisfy the OpenGL conformance requirements.) Non-antialiased lines are rendered as a polygon having a specified width as measured parallel to the major axis of the line. Antialiased lines are rendered as a rectangle having a specified width measured perpendicular to the line connecting the vertices. The functions required to render lines is split between the SF and WM units. The SF unit is responsible for computing the overall geometry of the object to be rendered, including the pixel-exact bounding box, edge equations, etc., and therefore is provided with the screen-geometry-related state variables. The WM unit performs the actual scan conversion, determining the exact pixel included/excluded and coverage value for anti-aliased lines. 10.3.12.1 Zero-Width (Cosmetic) Line Rasterization (The specification of zero-width line rasterization would be more correctly included in the WM Unit chapter, though is being included here to keep it with the rasterization details of the other line types). When the Line Width is set to zero, the device will use special rules to rasterize zero-width (“cosmetic”) lines. The Anti-Aliasing Enable state variable is ignored when Line Width is zero. When the LineWidth is set to zero, the device will use special rules to rasterize “cosmetic” lines. The rasterization rules also comply with the OpenGL conformance requirements (for 1-pixel wide non-smooth lines). Refer to the appropriate API specifications for details on these requirements. The GIQ rules basically intersect the directed, ideal line connecting two endpoints with an array of diamond-shaped areas surrounding pixel sample points. Wherever the line  a diamond (including passing through a diamond), the corresponding pixel is lit. Special rules are used to define the subpixel locations which are considered interior to the diamonds, as a function of the slope of the line. When a line ends in a diamond (and therefore does not exit that diamond), the corresponding pixel is not drawn. When a line starts in a diamond and exits that diamond, the corresponding pixel is drawn. 10.3.12.2 1GIQ (Diamond) Sampling Rules – Legacy Mode When the Legacy Line Rasterization Enable bit in WM_STATE is , zero-width lines are rasterized according to the algorithm presented in this subsection. Also note that the Last Pixel Enable bit of SF_STATE controls whether the last pixel of the last line in a LINESTRIP_xxx primitive or the last pixel of each line in a LINELIST_xxx primitive is rendered. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 250 Refer to the following figure, which shows the neighborhood of subpixels around a given pixel sample point. Note that the device divides a pixel into a 16x16 array of subpixels, referenced by their upper left corners. The solid-colored subpixels are considered “interior” to the diamond centered on the pixel sample point. Here the Manhattan distance to the pixel sample point (center) is less than ½. The subpixels falling on the edges of the diamond (Manhattan distance = ½) are exclusive, with the following exceptions: 1. The bottom corner subpixel is always inclusive. This is to ensure that lines with slopes in the open range (-1,1) touch a diamond even when they cross exactly between pixel diamonds. 2. The right corner subpixel is inclusive as long as the line slope is not exactly one, in which case the left corner subpixel is inclusive. Including the right corner subpixel ensures that lines with slopes in the range (1, +infinity] or [-infinity, -1) touch a diamond even when they cross exactly between pixel diamonds. Including the left corner on slope=1 lines is required for proper handling of slope=1 lines (see (3) below) – where if the right corner was inclusive, a slope=1 line falling exactly between pixel centers would wind up lighting pixel on both sides of the line (not desired). 3. The subpixels along the bottom left edge are inclusive only if the line slope = 1. This is to correctly handle the case where a slope=1 line falls enters the diamond through a left or bottom corner and ends on the bottom left edge. One does not consider this “passing through” the diamond (where the normal rules would have us light the pixel). This is to avoid the following case: One slope=1 line segment enters through one corner and ends on the edge, and another (continuation) line segments starts at that point on the edge and exits through the other corner. If simply passing through a corner caused the pixel to be lit, this case would case the pixel to be lit twice – breaking the rule that connected line segments should not cause double-hits or missing pixels. So, by considering the entire bottom left edge as “inside” for slope=1 lines, we will only light the pixel when a line passes through the entire edge, or starts on the edge (or the left or bottom corner) and exits the diamond. 4. The subpixels along the bottom right edge are inclusive only if the line slope = -1. Similar case as (3), except slope=-1 lines require the bottom right edge to be considered inclusive. The following equation determines whether a point (point.x, point.y) is inside the diamond of the pixel sample point (sample.x, sample.y), given additional information about the slope (slopePosOne, slopeNegOne). delta_x = point.x – sample.x Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 251 delta_y = point.y – sample.y distance = abs(delta_x) + abs(delta_y) interior = (distance < 0.5) bottom_corner = (delta_x == 0.0) && (delta_y == 0.5) left_corner = (delta_x == –0.5) && (delta_y == 0.0) right_corner = (delta_x == 0.5) && (delta_y == 0.0) bottom_left_edge = (distance == 0.5) && (delta_x < 0) && (delta_y > 0) bottom_right_edge = (distance == 0.5) && (delta_x > 0) && (delta_y > 0) inside = interior || bottom_corner || (slopePosOne ? left_corner : right_corner) || (slopePosOne && left_edge) || (slopeNegOne && right_edge) 10.3.12.3 GIQ (Diamond) Sampling Rules – DX10 Mode When the Legacy Line Rasterization Enable bit in WM_STATE is , zero-width lines are rasterized according to the algorithm presented in this subsection. Also note that the Last Pixel Enable bit of SF_STATE controls whether the last pixel of the last line in a LINESTRIP_xxx primitive or the last pixel of each line in a LINELIST_xxx primitive is rendered. Refer to the following figure, which shows the neighborhood of subpixels around a given pixel sample point. Note that the device divides a pixel into a 16x16 array of subpixels, referenced by their upper left corners. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 252 The solid-colored subpixels are considered “interior” to the diamond centered on the pixel sample point. Here the Manhattan distance to the pixel sample point (center) is less than ½. The subpixels falling on the edges of the diamond (Manhattan distance = ½) are exclusive, with the following exceptions: 1. The bottom corner subpixel is always inclusive. This is to ensure that lines with slopes in the open range (-1,1) touch a diamond even when they cross exactly between pixel diamonds. 2. The right corner subpixel is inclusive as long as the line is not X Major ( X Major is defined as -1 <= slope <= 1). Including the right corner subpixel ensures that lines with slopes in the range (>1, +infinity] or [-infinity, <-1) touch a diamond even when they cross exactly between pixel diamonds. 3. The left corner subpixel is never inclusive. For Y Major lines, having the right corner subpixel as always inclusive requires that the left corner subpixel should never be inclusive, since a line falling exactly between pixel centers would wind up lighting pixel on both sides of the line (not desired). 4. The subpixels along the bottom left edge are always inclusive. This is to correctly handle the case where a line enters the diamond through a left or bottom corner and ends on the bottom left edge. One does not consider this “passing through” the diamond (where the normal rules would have us light the pixel). This is to avoid the following case: One line segment enters through one corner and ends on the edge, and another (continuation) line segments starts at that point on the edge and exits through the other corner. If simply passing through a corner caused the pixel to be lit, this case would case the pixel to be lit twice – breaking the rule that connected line segments should not cause double-hits or missing pixels. So, by considering the entire bottom left edge as “inside”, we will only light the pixel when a line passes through the entire edge, or starts on the edge (or the left or bottom corner) and exits the diamond. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 253 5. The subpixels along the bottom right edge are always inclusive. Same as case as (4), except slope=-1 lines require the bottom right edge to be considered inclusive. The following equation determines whether a point (point.x, point.y) is inside the diamond of the pixel sample point (sample.x, sample.y), given additional information about the slope (XMajor). delta_x = point.x – sample.x delta_y = point.y – sample.y distance = abs(delta_x) + abs(delta_y) interior = (distance < 0.5) bottom_corner = (delta_x == 0.0) && (delta_y == 0.5) left_corner = (delta_x == –0.5) && (delta_y == 0.0) right_corner = (delta_x == 0.5) && (delta_y == 0.0) bottom_left_edge = (distance == 0.5) && (delta_x < 0) && (delta_y > 0) bottom_right_edge = (distance == 0.5) && (delta_x > 0) && (delta_y > 0) inside = interior || bottom_corner || (!XMajor && right_corner) || ( bottom_left_edge) || ( bottom_right_edge) 10.3.12.4 Non-Antialiased Wide Line Rasterization Non-anti-aliased, non-zero-width lines are rendered as parallelograms that are centered on, and aligned to, the line joining the endpoint vertices. Pixels sampled interior to the parallelogram are rendered; pixels sampled exactly on the parallelogram edges are rendered according to the polygon “top left” rules. The parallelogram is formed by first determining the major axis of the line (diagonal lines are considered x-major). The corners of the parallelogram are computed by translating the line endpoints by +/-(Line Width / 2) in the direction of the minor axis, as shown in the following diagram. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 254 Non-Antialiased Line Rasterization 10.3.12.5 Anti-aliased Line Rasterization Anti-aliased lines are rendered as rectangles that are centered on, and aligned to, the line joining the endpoint vertices. For each pixel in the rectangle, a fractional coverage value (referred to as Antialias Alpha) is computed – this coverage value will normally be used to attenuate the pixel’s alpha in the pixel shader thread. The resultant alpha value is therefore available for use in those downstream pixel pipeline stages in order to generate the desired effect (e.g., use the attenuated alpha value to modulate the pixel’s color, and add the result to the destination color, etc.). Note that software is required to explicitly program the pixel shader and pixel pipeline to obtain the desired anti-aliasing effect – the device will simply make the coverage-attenuated pixel alpha values available for use in the pixel shader. The dimensions of the rendered rectangle, and the parameters controlling the coverage value computation, are programmed via the Line Width, Line AA Region, and Line Cap AA Region state variables, as shown below. The edges parallel to the line are located at the distance ( LineWidth/2) from the line (measured in screen pixel units perpendicular to the line). The end-cap edges are perpendicular to the line and located at the distance (LineCapAARegion) from the endpoints. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 255 Anti-aliased Line Rasterization Along the parallel edges, the coverage values ramp from the value 0 at the very edges of the rectangle to the value 1 at the perpendicular distance (LineAARegion/2) from a given edge (in the direction of the line). A pixel’s coverage value is computed with respect to the closest edge. In the cases where (LineAARegion/2) < (LineWidth/2), this results in a region of fractional coverage values near the edges of the rectangle, and a region of “fully-covered” coverage values (i.e., the value 1) at the interior of the line. When (LineAARegion/2) == (LineWidth/2), only pixel sample points falling exactly on the line can generate fully-covered coverage values. If (LineAARegion/2) > (LineWidth/2), no pixels can be fully-covered (it is expected that this case is not typically desired). Along the end cap edges, the coverage values ramp from the value 1 at the line endpoint to the value 0 at the cap edge – itself at a perpendicular distance (LineCapAARegion) from the endpoint. Note that, unlike the line-parallel edges, there is only a single parameter (LineCapAARegion) controlling the extension of the line at the end caps and the associated coverage ramp. The regions near the corners of the rectangle have coverage values influenced by distances from both the line-parallel and end cap edges – here the two coverage values are multiplied together to provide a composite coverage value. The computed coverage value for each pixel is passed through the Windower Thread Dispatch payload. The Pixel Shader kernel should be passed (unmodified) by the shader to the Render Cache as part of it’s output message. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 256 10.3.13 3DSTATE_SF 3DSTATE_SF Source: RenderCS Length Bias: 2 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: 0h 3DSTATE Format: OpCode 23:16 3D Command Sub Opcode Default Value: 13h 3DSTATE_SF Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 5h Excludes DWord (0,1) Project: All Format: =n Total Length - 2 1 31:15 Reserved Format: MBZ 14:12 Depth Buffer Surface Format Project: All Format: U3 Enumerated Type Specifies the format of the depth buffer. This must exactly match the Surface Format programmed via 3DSTATE_DEPTH_BUFFER. The SF requires this information in order to compute Global Depth Bias. Value Name Description Project 0h D32_FLOAT_S8X24_UINT D32_FLOAT_S8X24_UINT All 1h D32_FLOAT D32_FLOAT All 2h D24_UNORM_S8_UINT D24_UNORM_S8_UINT All 3h D24_UNORM_X8_UINT D24_UNORM_X8_UINT All 4h Reserved Reserved All 5h D16_UNORM D16_UNORM All 6h-7h Reserved Reserved All 11 Legacy Global Depth Bias Enable Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 257 3DSTATE_SF Project: All Format: Enable Enables the SF to use the Global Depth Offset Constant state unmodified. If this bit is not set, the SF will scale the Global Depth Offset Constant as described in section Error! Reference source not found. of this document. Programming Notes This bit should be set whenever non zero depth bias (Slope, Bias) values are used. Setting this bit may have some degradation of performance for some workloads. 10 Statistics Enable Project: All Format: Enable If ENABLED, this FF unit will increment CL_PRIMITIVES_COUNT on behalf of the CLIP stage. If DISABLED, CL_PRIMITIVES_COUNT will be left unchanged. Programming Notes This bit should be set whenever clipping is enabled and the Statistics Enable bit is set in CLIP_STATE. It should be cleared if clipping is disabled or Statistics Enable in CLIP_STATE is clear. 9 Global Depth Offset Enable Solid Project: All Format: Enable Enables computation and application of Global Depth Offset for SOLID objects. Programming Notes Project This bit should be set whenever non zero depth bias (Slope, Bias) values are used. Setting this bit may have some degradation of performance for some workloads. Due to an HW issue driver needs to send a pipe control with stall when ever there is state change in depth bias related state 8 Global Depth Offset Enable Wireframe Project: All Format: Enable Enables computation and application of Global Depth Offset when triangles are rendered in WIREFRAME mode. Programming Notes Project This bit should be set whenever non zero depth bias (Slope, Bias) values are used. Setting this bit may have some degradation of performance for some workloads. Due to an HW issue driver needs to send a pipe control with stall when ever there is state change in depth bias related state 7 Global Depth Offset Enable Point Project: All Format: Enable Enables computation and application of Global Depth Offset when triangles are rendered in POINT mode. Programming Notes Project This bit should be set whenever non zero depth bias (Slope, Bias) values are used. Setting this bit may have some degradation of performance for some workloads. Due to an HW issue driver needs to send a pipe control with stall when ever there is state change in depth bias related state 6:5 FrontFace Fill Mode Project: All Format: U2 enumerated type Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 258 3DSTATE_SF This state controls how front-facing triangle and rectangle objects are rendered. Value Name Description Project 0h SOLID Any triangle or rectangle object found to be front-facing is rendered as a All solid object. This setting is required when rendering rectangle (RECTLIST) objects. 1h WIREFRAME Any triangle object found to be front-facing is rendered as a series of lines All along the triangle boundaries (as determined by the topology type and controlled by the vertex EdgeFlags). 2h POINT Any triangle object found to be front-facing is rendered as a set of point primitives at the triangle vertices (as determined by the topology type and controlled by the vertex EdgeFlags).NOTE: If the triangle is clipped, points will not be rendered at clip-inserted vertices. Point will only be rendered at original vertices (if visible). 3h Reserved 4:3 BackFace Fill Mode Project: All Format: U2 enumerated type This state controls how back-facing triangle and rectangle objects are rendered. Value Name Description Project 0h SOLID Any triangle or rectangle object found to be back-facing is rendered as a All solid object. This setting is required when rendering rectangle (RECTLIST) objects. 1h WIREFRAME Any triangle object found to be back-facing is rendered as a series of lines All along the triangle boundaries (as determined by the topology type and controlled by the vertex EdgeFlags). 2h POINT Any triangle object found to be back-facing is rendered as a set of point primitives at the triangle vertices (as determined by the topology type and controlled by the vertex EdgeFlags).NOTE: If the triangle is clipped, points will not be rendered at clip-inserted vertices. Point will only be rendered at original vertices (if visible). 3h Reserved 2 Reserved Project: All Format: MBZ 1 View Transform Enable Project: All Format: Enable This bit controls the Viewport Transform function. 0 Front Winding Project: All Determines whether a triangle object is considered “front facing” if the screen space vertex positions, when traversed in the order, result in a clockwise (CW) or counter-clockwise (CCW) winding order. Does not apply to points or lines. 2 31 Anti-Aliasing Enable Project: All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 259 3DSTATE_SF Format: Enable This field enables “alpha-based” line anti-aliasing. Programming Notes This field must be disabled if any of the render targets have integer (UINT or SINT) surface format. 30:29 Cull Mode Project: All Format: 3D_CullMode Controls removal (culling) of triangle objects based on orientation. The cull mode only applies to triangle objects and does not apply to lines, points or rectangles. Value Name Description Project 0h CULLMODE_BOTH All triangles are discarded (i.e., no triangle objects are drawn) All 1h CULLMODE_NONE No triangles are discarded due to orientation All 2h CULLMODE_FRONT Triangles with a front-facing orientation are discarded All 3h CULLMODE_BACK Triangles with a back-facing orientation are discarded All Programming Notes Orientation determination is based on the setting of the Front Winding state. 27:18 Line Width Project: All Format: U3.7 Range: [0.0, 7.9921875] Controls width of line primitives.Setting a Line Width of 0.0 specifies the rasterization of the “thinnest” (one-pixel-wide), non-antialiased lines. Note that this effectively overrides the effect of AAEnable (though the AAEnable state variable is not modified). Lines rendered with zero Line Width are rasterized using GIQ (Grid Intersection Quantization) rules as specified by the GDI APIs. Programming Notes Software must not program a value of 0.0 when running in MSRASTMODE_ON_xxx modes – zero- width lines are not available when multisampling rasterization is enabled. 17:16 Line End Cap Antialiasing Region Width Project: All Format: U2 This field specifies the distances over which the coverage of anti-aliased line end caps are computed. Value Name Description Project 0h 0.5 pixels All 1h 1.0 pixels All 2h 2.0 pixels All 3h 4.0 pixels All 15 Reserved Project: All Format: MBZ 14 Reserved Format: MBZ 11 Scissor Rectangle Enable Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 260 3DSTATE_SF Project: All Format: Enable Enables operation of Scissor Rectangle. 10 Reserved Format: MBZ 9:8 Multisample Rasterization Mode Project: All Format: U2 enumerated type This state is duplicated in 3DSTATE_WM and both must be set to the same value. See the field in 3DSTATE_WM for definition details. 7:0 Reserved Project: All Format: MBZ 3 31 Last Pixel Enable Project: All Format: Enable If ENABLED, the last pixel of a diamond line will be lit. This state will only affect the rasterization of Diamond lines (will not affect wide lines or anti-aliased lines). Programming Notes Last pixel is applied to all lines of a LINELIST, and only the last line of a LINESTRIP. 30:29 Triangle Strip/List Provoking Vertex Select Project: All Format: 0-based vertex index Selects which vertex of a triangle (in a triangle strip or list primitive) is considered the “provoking vertex”. Used for flat shading of primitives.Does current implementation send provoking vertex first? Value Name Project 0h Vertex 0 All 1h Vertex 1 All 2h Vertex 2 All 3h Reserved All 28:27 Line Strip/List Provoking Vertex Select Project: All Format: 0-based vertex index Selects which vertex of a line (in a line strip or list primitive) is considered the “provoking vertex”. Value Name Description Project 0h Vertex 0 All 1h Vertex 1 All 2h Reserved All 3h Reserved All 26:25 Triangle Fan Provoking Vertex Select Project: All Format: 0-based vertex index Selects which vertex of a triangle (in a triangle fan primitive) is considered the “provoking vertex”. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 261 3DSTATE_SF Value Name Project 0h Vertex 0 All 1h Vertex 1 All 2h Vertex 2 All 3h Reserved All 24:15 Reserved Project: All Format: MBZ 14 AA Line Distance Mode Project: All Format: U1 This bit controls the distance computation for antialiased lines. Value Name Description Project 1h AALINEDISTANCE_TRUE True distance computation. This is the normal setting which All should yield WHQL compliance. 13 Reserved Project: All Format: MBZ 12 Vertex Sub Pixel Precision Select Project: All Format: U1 Selects the number of fractional bits maintained in the vertex data Value Name Description Project 0h Disable 8 sub pixel precision bits maintained All 1h Enable 4 sub pixel precision bits maintained All 11 Use Point Width State Project: All Format: U1 Controls whether the point width passed on the vertex or from state is used for rendering point primitives. Value Name Description Project 0h Use Point Width on Vertex All 1h Use Point Width from State All 10:0 Point Width Project: All Format: U8.3 Range: [0.125, 255.875] pixels This field specifies the size (width) of point primitives in pixels. This field is overridden (though not overwritten) whenever point width information is passed in the FVF 4 31:0 Global Depth Offset Constant Project: All Format: IEEE_FP Specifies the constant term in the Global Depth Offset function. 5 31:0 Global Depth Offset Scale Project: All Format: IEEE_FP Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 262 3DSTATE_SF Specifies the scale term used in the Global Depth Offset function. 6 31:0 Global Depth Offset Clamp Project: All Format: IEEE_FP Specifies the clamp term used in the Global Depth Offset function. 10.3.14 3DSTATE_SBE The state used by “setup backend” is defined by this inline state packet. 3DSTATE_SBE Source: RenderCS Length Bias: 2 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 1Fh 3DSTATE_SBE Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 0Ch Excludes DWord (0,1) Project: All Format: =n Total Length - 2 1 31:29 Reserved Project: All Format: MBZ 28 Attribute Swizzle Control Mode Format: U1 enumerated type Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 263 3DSTATE_SBE When Attribute Swizzle Enable is ENABLED, this bit controls whether attributes 0-15 or 16-31 are subject to the following swizzle controls:  Attribute n Component Override X/Y/Z/W  Attribute n Constant Source  Attribute n Swizzle Select  Attribute n Source Attribute  Attribute n Wrap Shortest Enables Note that the Number of SF Output Attributes field specifies how many attributes are output. Note: This field does not impact any functions which provide separate states for all 32 attributes (e.g., Point sprite, Constant interpolation). Value Name Description Project 0h SWIZ_0_15 Attributes 0-15 are subject to swizzling, and attributes 16-31 are not. 1h SWIZ_16_31 Attributes 16-31 are subject to swizzling, and attributes 0-15 are not. Only valid when 16 or more attributes are output. 27:22 Number of SF Output Attributes Format: U6 count of attributes Specifies the number of vertex attributes passed from the SF stage to the WM stage (does not include Position). Value Name [0,32] 21 Attribute Swizzle Enable Project: All Format: Enable Enables the SF to perform swizzling on (up to the first 16) vertex attributes. If DISABLED, all vertex attributes are passed through. 20 Point Sprite Texture Coordinate Origin Project: All Format: U1 enumerated type This state controls how Point Sprite Texture Coordinates are generated (when enabled on a per- attribute basis by Point Sprite Texture Coordinate Enable). Value Name Description Project 0h UPPERLEFT Top Left = (0,0,0,1)Bottom Left = (0,1,0,1)Bottom Right = (1,1,0,1) All 1h LOWERLEFT Top Left = (0,1,0,1)Bottom Left = (0,0,0,1)Bottom Right = (1,0,0,1) All 19:16 Reserved Project: All Format: MBZ 15:11 Vertex URB Entry Read Length Project: All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 264 3DSTATE_SBE Format: U5 Specifies the amount of URB data read for each Vertex URB entry, in 256-bit register increments. Value Name [1,16] Programming Notes It is UNDEFINED to set this field to 0 indicating no Vertex URB data to be read.This field should be set to the minimum length required to read the maximum source attribute. The maximum source attribute is indicated by the maximum value of the enabled Attribute # Source Attribute if Attribute Swizzle Enable is set, Number of Output Attributes-1 if enable is not set. read_length = ceiling((max_source_attr+1)/2) 10 Reserved Project: All 9:4 Vertex URB Entry Read Offset Project: All Format: U6 Specifies the offset (in 256-bit units) at which Vertex URB data is to be read from the URB. Value Name [0,63] 3:0 Reserved Project: All Format: MBZ 2..9 31 Attribute [2n+1] Component Override W Project: All Format: Enable If set, the W component of output Attribute 1 is overridden by the W component of the constant vector specified by ConstantSource[1]. 30 Attribute [2n+1] Component Override Z Project: All Format: Enable If set, the Z component of output Attribute 1 is overridden by the Z component of the constant vector specified by ConstantSource[1]. 29 Attribute [2n+1] Component Override Y Project: All Format: Enable If set, the Y component of output Attribute 1 is overridden by the Y component of the constant vector specified by ConstantSource[1]. 28 Attribute [2n+1] Component Override X Project: All Format: Enable If set, the X component of output Attribute 1 is overridden by the X component of the constant vector Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 265 3DSTATE_SBE specified by ConstantSource[1]. 27 Reserved Project: All Format: MBZ 26:25 Attribute [2n+1] Constant Source Project: All Format: U2 enumerated type This state selects a constant vector which can be used to override individual components of Attribute 1 Value Name Description Project 0h CONST_0000 Constant.xyzw = 0.0,0.0,0.0,0.0 All 1h CONST_0001_FLOAT Constant.xyzw = 0.0,0.0,0.0,1.0 All 2h CONST_1111_FLOAT Constant.xyzw = 1.0,1.0,1.0,1.0 All 3h PRIM_ID Constant.xyzw = PrimID (replicated) All 24 Reserved Project: All Format: MBZ 23:22 Attribute [2n+1] Swizzle Select Project: All Format: U2 enumerated type This state, along with Attribute 1 Source Attribute, specifies the source for output Attribute 1. Value Name Description Project 0h INPUTATTR This attribute is sourced from AttrInputReg[SourceAttribute] All 1h INPUTATTR_FACING If the object is front-facing, this attribute is sourced from All AttrInputReg[SourceAttribute].If the object is back-facing, this attribute is sourced from AttrInputReg[SourceAttribute+1]. 2h INPUTATTR_W This attribute is sourced from AttrInputReg[SourceAttribute]. All The W component is copied to the X component. 3h INPUTATTR_FACING_W If the object is front-facing, this attribute is sourced from All AttrInputReg[SourceAttribute].If the object is back-facing, this attribute is sourced from AttrInputReg[SourceAttribute+1]. The W component is copied to the X component. 21 Reserved Project: All Format: MBZ 20:16 Attribute [2n+1] Source Attribute Project: All Format: U5 This field selects the source attribute for Attribute 1. Source attribute 0 corresponds to the first 128 bits of data indicated by Vertex URB Entry Read Offset 15 Attribute [2n] Component Override W Project: All Format: Enable If set, the W component of output Attribute 0 is overridden by the W component of the constant vector Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 266 3DSTATE_SBE specified by ConstantSource[1]. 14 Attribute [2n] Component Override Z Project: All Format: Enable If set, the Z component of output Attribute 0 is overridden by the Z component of the constant vector specified by ConstantSource[1]. 13 Attribute [2n] Component Override Y Project: All Format: Enable If set, the Y component of output Attribute 0 is overridden by the Y component of the constant vector specified by ConstantSource[1]. 12 Attribute [2n] Component Override X Project: All Format: Enable If set, the X component of output Attribute 0 is overridden by the X component of the constant vector specified by ConstantSource[1]. 11 Reserved Project: All Format: MBZ 10:9 Attribute [2n] Constant Source Project: All Format: U2 enumerated type This state selects a constant vector which can be used to override individual components of Attribute 0 Value Name Description Project 0h CONST_0000 Constant.xyzw = 0.0,0.0,0.0,0.0 All 1h CONST_0001_FLOAT Constant.xyzw = 0.0,0.0,0.0,1.0 All 2h CONST_1111_FLOAT Constant.xyzw = 1.0,1.0,1.0,1.0 All 3h PRIM_ID Constant.xyzw = PrimID (replicated) All 8 Reserved Project: All Format: MBZ 7:6 Attribute [2n] Swizzle Select Project: All Format: U2 enumerated type This state, along with Attribute 0 Source Attribute, specifies the source for output Attribute 0. Value Name Description Project 0h INPUTATTR This attribute is sourced from AttrInputReg[SourceAttribute] All 1h INPUTATTR_FACING If the object is front-facing, this attribute is sourced from All AttrInputReg[SourceAttribute].If the object is back-facing, this attribute is sourced from AttrInputReg[SourceAttribute+1]. 2h INPUTATTR_W This attribute is sourced from AttrInputReg[SourceAttribute]. All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 267 3DSTATE_SBE The W component is copied to the X component. 3h INPUTATTR_FACING_W If the object is front-facing, this attribute is sourced from All AttrInputReg[SourceAttribute].If the object is back-facing, this attribute is sourced from AttrInputReg[SourceAttribute+1]. The W component is copied to the X component. 5 Reserved Project: All Format: MBZ 4:0 Attribute [2n] Source Attribute Project: All Format: U5 This field selects the source attribute for Attribute 0. Source attribute 0 corresponds to the first 128 bits of data indicated by Vertex URB Entry Read Offset 10 31:0 Point Sprite Texture Coordinate Enable Project: All Format: 32-bit bitmask When processing point primitives, the attributes from the incoming point vertex are typically copied to the point object corner vertices. However, if a bit is set in this field, the corresponding Attribute is selected as a Point Sprite Texture Coordinate, in which case each corner vertex is assigned a pre- defined texture coordinate as defined by the Point Sprite Texture Coordinate Origin state bit. Bit 0 corresponds to output Attribute 0. This field must be programmed to 0 when non-point primitives are rendered. 11 31:0 Constant Interpolation Enable[31:0] Project: All This field is a bitmask containing a Constant Interpolation Enable bit for each corresponding attribute. If a bit is set, that attribute will undergo constant interpolation, and the corresponding WrapShortest Enable bits (if defined) will be ignored. If a bit is clear, components which are not enabled for WrapShortest interpolation (if defined) will be linearly interpolated. 12 31:28 Attribute 7 WrapShortest Enables Project: All Format: Enable[4] This state selects which components (if any) of Attribute 7 are to be interpolated in a “wrap shortest” fashion. Operation is UNDEFINED if any of these bits are set and the Constant Interpolation Enable bit associated with this attribute is set. Note that wrap-shortest interpolation is only supported for Attributes 0-15.Bit 0: WrapShortest X ComponentBit 1: WrapShortest Y ComponentBit 2: WrapShortest Z ComponentBit 3: WrapShortest W Component 27:24 Attribute 6 WrapShortest Enables Project: All (See above). 23:20 Attribute 5 WrapShortest Enables Project: All (See above). 19:16 Attribute 4 WrapShortest Enables Project: All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 268 3DSTATE_SBE (See above). 15:12 Attribute 3 WrapShortest Enables Project: All (See above). 11:8 Attribute 2 WrapShortest Enables Project: All (See above). 7:4 Attribute 1 WrapShortest Enables Project: All (See above). 3:0 Attribute 0 WrapShortest Enables Project: All (See above). 13 31:28 Attribute 15 WrapShortest Enables Project: All Format: Enable[4] This state selects which components (if any) of Attribute 15 are to be interpolated in a “wrap shortest” fashion. Operation is UNDEFINED if any of these bits are set and the Constant Interpolation Enable bit associated with this attribute is set.Bit 0: WrapShortest X ComponentBit 1: WrapShortest Y ComponentBit 2: WrapShortest Z ComponentBit 3: WrapShortest W Component 27:24 Attribute 14 WrapShortest Enables Project: All (See above). 23:20 Attribute 13 WrapShortest Enables Project: All (See above). 19:16 Attribute 12 WrapShortest Enables Project: All (See above). 15:12 Attribute 11 WrapShortest Enables Project: All (See above). 11:8 Attribute 10 WrapShortest Enables Project: All (See above). 7:4 Attribute 9 WrapShortest Enables Project: All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 269 3DSTATE_SBE (See above). 3:0 Attribute 8 WrapShortest Enables Project: All (See above). 10.3.15 SF_CLIP_VIEWPORT The viewport-specific state used by both the SF and CL units (SF_CLIP_VIEWPORT) is stored as an array of up to 16 elements, each of which contains the DWords described below. The start of each element is spaced 16 DWords apart. The location of first element of the array, as specified by both Pointer to SF_VIEWPORT and Pointer to CLIP_VIEWPORT, is aligned to a 64-byte boundary. SF_CLIP_VIEWPORT Source: RenderCS Default 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, Value: 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 DWord Bit Description 0 31:0 Viewport Matrix Element m00 Format: IEEE_Float 1 31:0 Viewport Matrix Element m11 Format: IEEE_Float 2 31:0 Viewport Matrix Element m22 Format: IEEE_Float Total Length - 2 3 31:0 Viewport Matrix Element m30 Format: IEEE_Float Total Length - 2 4 31:0 Viewport Matrix Element m31 Format: IEEE_Float 5 31:0 Viewport Matrix Element m32 Format: IEEE_Float 6 31:0 Reserved 7 31:0 Reserved Project: All Format: MBZ 8 31:0 X Min Clip Guardband Default Value: 0h Excludes DWord (0,1) Format: FLOAT32 . This 32-bit float represents the XMin guardband boundary (normalized to Viewport.XMin == -1.0f). This corresponds to the left boundary of the NDC guardband. 9 31:0 X Max Clip Guardband Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 270 SF_CLIP_VIEWPORT Default Value: 0h Excludes DWord (0,1) Format: FLOAT32 This 32-bit float represents the XMax guardband boundary (normalized to Viewport..XMax == 1.0f). This corresponds to the right boundary of the NDC guardband. 10 31:0 Y Min Clip Guardband Format: FLOAT32 This 32-bit float represents the YMin guardband boundary (normalized to Viewport.YMin == -1.0f). This corresponds to the bottom boundary of the NDC guardband. 11 31:0 Y Max Clip Guardband: Format: FLOAT32 This 32-bit float represents the YMax guardband boundary (normalized to Viewport.YMax == 1.0f). This corresponds to the top boundary of the NDC guardband. 12 12..15 31:0 Reserved Format: MBZ 10.3.16 SCISSOR_RECT SCISSOR_RECT Source: RenderCS Default Value: 0x00000000, 0x00000000 The viewport-specific state used by the SF unit (SCISSOR_RECT) is stored as an array of up to 16 elements, each of which contains the DWords described below. The start of each element is spaced 2 DWords apart. The location of first element of the array, as specified by Pointer to SCISSOR_RECT, is aligned to a 32-byte boundary. DWord Bit Description 0 31:16 Scissor Rectangle Y Min Project: All Format: U16 Pixels from Drawing Rectangle origin (upper left corner) Specifies Y Min coordinate of (inclusive) Scissor Rectangle used for scissor test. Pixels with (Draw Rectangle-relative) Y coordinates less than Y Min will be clipped out if Scissor Rectangle is enabled. NOTE: If Y Min is set to a value greater than Y Max, all primitives will be discarded for this viewport. Value Name Project [0,16383] 15:0 Scissor Rectangle X Min Project: All Format: U16 Pixels from Drawing Rectangle origin (upper left corner) Specifies X Min coordinate of (inclusive) Scissor Rectangle used for scissor test. Pixels with (Draw Rectangle-relative) X coordinates less than X Min will be clipped out if Scissor Rectangle is enabled. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 271 SCISSOR_RECT NOTE: If X Min is set to a value greater than X Max, all primitives will be discarded for this viewport. Value Name Project [0,16383] 1 31:16 Scissor Rectangle Y Max Project: All Format: U16 Pixels from Drawing Rectangle origin (upper left corner) Specifies Y Max coordinate of (inclusive) Scissor Rectangle used for scissor test. Pixels with (Draw Rectangle-relative) Y coordinates greater than Y Max will be clipped out if Scissor Rectangle is enabled. Value Name Project [0,16383] 15:0 Scissor Rectangle X Max Project: All Format: U16 Pixels from Drawing Rectangle origin (upper left corner) Specifies X Max coordinate of (inclusive) Scissor Rectangle used for scissor test. Pixels with (Draw Rectangle-relative) Y coordinates greater than X Max will be clipped out if Scissor Rectangle is enabled. Value Name Project 0-16383 10.4 Attribute Interpolation Setup With the attribute interpolation setup function being implemented in hardware for, a number of state fields in 3DSTATE_SF are utilized to control interpolation setup. Number of SF Output Attributes sets the number of attributes that will be output from the SF stage, not including position. This can be used to specify up to 32, and may differ from the number of input attributes. The number of input attributes is derived from the Vertex URB Entry Read Length field. Note that this field is also used to specify whether swizzling is to be performed on Attributes 0-15 or Attributes 16-32. See the state field definition for details. 10.4.1 Attribute Swizzling The first or last set of 16 attributes can be swizzled according to certain state fields. Attribute Swizzle Enable enables the swizzling for all 16 of these attributes, and each of the attributes has a 2-bit Swizzle Select field that controls swizzling with the following settings:  INPUTATTR – This attribute is sourced from AttrInputReg[SourceAttribute].  INPUTATTR_FACING – This attribute is sourced from AttrInputReg[SourceAttribute] if the object is front-facing, otherwise it is sourced from AttrInputReg[SourceAttribute+1].  INPUTATTR_W – This attribute is sourced from AttrInputReg[SourceAttribute]. WYZW (the W component of the source is copied to the X component of the destination).  INPUTATTR_FACING – If the object is front-facing, this attribute is sourced from AttrInputReg[SourceAttribute]. WYZW (the W component of the source is copied to the X Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 272 component of the destination). If the object is front-facing, this attribute is sourced from AttrInputReg[SourceAttribute+1]. WYZW. Each of the first or last set of 16 attributes also has a 5-bit Source Attribute field which specify, per output attribute (not component), which input attribute sources the output attribute when INPUTATTR is selected for Swizzle Select. A Source Attribute value of 0 corresponds to the 128-bit attribute immediately following the vertex 4D position. If INPUTATTR_FACING is selected, this specifies the first of two consecutive (front,back) input attributes, where the SourceAttribute value can be an odd or even number (just not 31, as that would place the back-face input attribute past the end of the input max complement of input attributes). Constant overriding is also available for the first or last set of 16 attributes. Each attribute has a Constant Source field which specifies the constant values per swizzled attribute, with the following settings available:  XYZW = 0000  XYZW = 0001  XYZW = 1111 Each channel of each attribute has a Component Override field to control whether the corresponding channel is overridden with the constant value defined in Constant Source. 10.4.2 1Interpolation Modes All 32 attributes have a Constant Interpolation Enable state field bit to specify whether all components of the attribute are to be interpolated as constant values (not varying over the pixels of the object). If set, the attribute at the provoking vertex is copied to a0, and a1 and a2 are set to zero – this results in a constant interpolation of the provoking vertex value. If clear, the attribute is linearly interpolated. Attributes 0-15 are further subjected to Wrap Shortest processing on a per-component basis, via the Attribute WrapShortest Enables state bitfields. WrapShortest processing modifies the a1 and/or a2 values depending on attribute deltas. All The table below indicates the output values of a0, a1, and a2 depending on interpolation mode settings. a0 a1 a2 Constant A0 0.0 0.0 Linear A0 A1-A0 A2-A0 A0 (A1-A0)+1 (A1-A0) <= -0.5 (A2-A0)+1 (A2-A0) <= -0.5 (A1-A0)-1 (A1-A0) >= 0.5 (A2-A0)-1 (A2-A0) >= 0.5 (A1-A0) otherwise (A2-A0) otherwise Wrap Shortest 10.4.3 Point Sprites Normally all vertex attributes (including texture coordinates) other than position are simply replicated from the incoming point center vertex to the generated point object (corner) vertices. However, both DX9 and OGL support “sprite points”, where some/all texture coordinates are replaced with full-scale 2D texture coordinates. A 32-bit PointSprite TextureCoordinate Enable bit mask controls whether the corresponding vertex attribute is to be replaced by a sprite point texture coordinate. The global (not per-attribute) Point Sprite TextureCoordinate Origin field controls how the point object vertex (top/bottom, left/right) texture coordinates are generated: Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 273 Left Right UPPERLEFT Top (0,0,0,1) (1,0,0,1) Bottom (0,1,0,1) (1,1,0,1) Left Right LOWERLEFT Top (0,1,0,1) (1,1,0,1) Bottom (0,0,0,1) (1,0,0,1) 10.5 Depth Offset The state for depth offset in 3DSTATE_SF controls the depth offset function. Since this function was previously contained in the Windower stage, refer to the “Depth Offset” section in the Windower chapter for more details on this function. 10.6 Other SF Functions 10.6.1 Statistics Gathering The SF stage itself does not have any associated pipeline statistics; however, it counts the number of objects being output by the clipper on the clipper’s behalf, since it less feasible to have the CLIP unit figure out how many objects have been output by a clip thread. It is easy for the SF unit to count the number of objects it receives from the CLIP stage since it is decomposing the output primitive topologies into objects anyway. If the Statistics Enable bit is set in SF_STATE, then SF will increment the CL_PRIMITIVES_COUNT Register (see Memory Interface Registers in Volume Ia, GPU) once for each object in each primitive topology it receives from the CLIP stage. This bit should always be set if clipping is enabled and pipeline statistics are desired. Software should always clear the Statistics Enable bit in SF_STATE if the clipper is disabled since objects SF receives are not considered “primitives output by the clipper” unless the clipper is enabled. Note that the clipper can be disabled either using bypass mode via a PIPELINE_STATE_POINTERS command with Clip Enable clear or by setting Clip Mode in CLIP_STATE to CLIPMODE_ACCEPT_ALL. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 274 11. 3D Pipeline – Windower (WM) Stage 11.1 Overview As mentioned in the SF Unit chapter, the SF stage prepares an object for scan conversion by the Window/Masker (WM) unit Refer to the SF Unit chapter for details on the screen-space geometry of objects to be rendered The WM unit uses the parameters provided by the SF unit in the object-specific rasterization algorithms. The WM stage of the 3D pipeline performs the following operations (at a high level)  Pre-scan-conversion modification of some primitive attributes, including o Application of Depth Offset to the position Z attribute  Scan-conversion of the various primitive types, including o 2D clipping to the scissor/draw rectangle intersection  Spawning of Pixel Shader (PS) threads to process the pixels resulting from scan-conversion The spawned Pixel Shader (PS) threads are responsible for the following (high-level) operations  interpolation of vertex attributes (other than X,Y,Z) to the pixel location  performing any “Pixel Shader” operations dictated by the API PS program o Using the Sampler shared function to sample data from “texture” surfaces o Using the DataPort to perform general memory I/O  Submitting the shaded pixel results to the DataPort for any subsequent “blending” (aka Output Merger) operation and write to the RenderCache. The WM unit keeps a scoreboard of pixels being processed in outstanding PS threads in order to guarantee in-order rasterization results This allows the WM unit to overlap processing of several objects. 11.1.1 Inputs from SF to WM The outputs from the SF stage to the WM stage are mostly comprised of implementation-specific information required for the rasterization of objects The types of information is summarized below, but as the interface is not exposed to software a detailed discussion is not relevant to this specification.  PrimType of the object  VPIndex, RTAIndex associated with the object  Handle of the Primitive URB Entry (PUE) that was written by the SF (Setup) thread This handle will be passed to all WM (PS) threads spawned from the WM’s rasterization process.  Information regarding the X,Y extent of the object (e.g., bounding box, etc.)  Edge or line interpolation information (e.g., edge equation coefficients, etc.)  Information on where the WM is to start rasterization of the object  Object orientation (front/back-facing)  Last Pixel indication (for line drawing) Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 275 11.2 Windower Pipelined State {WA}: The driver must make sure a PIPE_CONTROL with the Depth Stall Enable bit set after all the following states are programmed: o 3DSTATE_PS o 3DSTATE_VIEWPORT_STATE_POINTERS_CC o 3DSTATE_CONSTANT_PS o 3DSTATE_BINDING_TABLE_POINTERS_PS o 3DSTATE_SAMPLER_STATE_POINTERS_PS o 3DSTATE_CC_STATE_POINTERS o 3DSTATE_BLEND_STATE_POINTERS o 3DSTATE_DEPTH_STENCIL_STATE_POINTERS 11.2.1 3DSTATE_WM 3DSTATE_WM Source: RenderCS Length Bias: 2 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 14h 3DSTATE_WM Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 01h Excludes DWord (0,1) Project: All Format: =n Total Length - 2 1 31 Statistics Enable Project: All Format: Enable If ENABLED, the Windower and pixel pipeline will engage in statistics gathering. If DISABLED, statistics information associated with this FF stage will be left unchanged. See Statistics Gathering. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 276 3DSTATE_WM 30 Depth Buffer Clear Project: All Format: Enable When set, the depth buffer is initialized as a side-effect of rendering pixels. Programming Notes If this field is enabled, 2. the Depth Test Enable field in DEPTH_STENCIL_STATE must be disabled. 3. 3DSTATE_DEPTH_BUFFER::Depth Write Enable must be set. 4. 3DSTATE_DEPTH_BUFFER::Stencil Write Enable must be set if 3DSTATE_STENCIL_BUFFER::Stencil buffer enable is set. Additionally the following must be set to the correct values. B. DEPTH_STENCIL_STATE::Stencil Write Mask must be 0xFF C. DEPTH_STENCIL_STATE::Stencil Test Mask must be 0xFF D. DEPTH_STENCIL_STATE::Back Face Stencil Write Mask must be 0xFF E. DEPTH_STENCIL_STATE::Back Face Stencil Test Mask must be 0xFF Refer to section 0 "Depth Buffer Clear" for additional restrictions when this field is enabled. If this field is enabled,Pixel Shader Kill Pixel must be disabled. 29 Thread Dispatch Enable Project: All Format: Enable This bit, if set, indicates that it is possible for a PS thread to modify a render target, i.e.,at least one render target is enabled (is not of type SURFTYPE_NULL and has at least one channel enabled for writes) and the PS kernel contains a code path that may issue a write to that/those enabled RTs. Programming Notes This bit is used for performance optimizations and does not directly control writing to render targets. If this bit is DISABLED, no pixel shader threads will be dispatched.For correct behavior, this bit must be set consistently with the behavior of the PS kernel, i.e. if this bit is DISABLED the PS kernel must not write color or depth to any render targets.If this field is disabled, Pixel Shader Kill Pixel must be disabled. 28 Depth Buffer Resolve Enable Project: All Format: Enable When set, the depth buffer is made to be consistent with the hierarchical depth buffer as a side-effect of rendering pixels. This is intended to be used when the depth buffer is to be used as a surface outside of the 3D rendering operation. Programming Notes If this field is enabled, 2. the Depth Buffer Clear and Hierarchical Depth Buffer Resolve Enable fields must both be disabled. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 277 3DSTATE_WM 3. 3DSTATE_DEPTH_BUFFER::Depth Write Enable must be set. Refer to section 11.5.4.2 "Depth Buffer Resolve" for additional restrictions when this field is enabled. If Hierarchical Depth Buffer Enable is disabled, enabling this field will have no effect. 27 Hierarchical Depth Buffer Resolve Enable Project: All Format: Enable When set, the hierarchical depth buffer is made to be consistent with the depth buffer as a side-effect of rendering pixels. This is intended to be used when the depth buffer has been modified outside of the 3D rendering operation. Programming Notes Project If this field is enabled, 2. the Depth Buffer Clear and Depth Buffer Resolve Enable fields must both be disabled. 3. 3DSTATE_DEPTH_BUFFER::Depth Write Enable must be set. Refer to section 11.5.4.3 "Hierarchical Depth Buffer Resolve" for additional restrictions when this field is enabled. If Hierarchical Depth Buffer Enable is disabled, enabling this field will have no effect. Performance Note: expect the hierarchical depth buffer's impact on performance to be reduced for some period of time after this operation is performed, as the hierarchical depth buffer is initialized to a state that makes it ineffective. Further rendering will tend to bring the hierarchical depth buffer back to a more effective state. Software needs to do an ambiguate after allocating the surface for the first time if the depth buffer width and height are NOT aligned to 8 and 4 respectively. 26 Legacy Diamond Line Rasterization Project: All Format: Enable This bit, if ENABLED, indicates that the Windower will rasterize zero width lines using the DX9 rasterization rules. If DISABLED, the Windower will rasterize zero width lines using the DX10 rasterization rules (see Strips Fans chapter). 25 Pixel Shader Kill Pixel Project: All Format: Enable This bit, if ENABLED, indicates that the PS kernel or color calculator has the ability to kill (discard) pixels or samples, other than due to depth or stencil testing. This bit is required to be ENABLED in the following situations:  The API pixel shader program contains “killpix” or “discard” instructions, or other code in the pixel shader kernel that can cause the final pixel mask to differ from the pixel mask received on dispatch.  A sampler with chroma key enabled with kill pixel mode is used by the pixel shader. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 278 3DSTATE_WM  Any render target has Alpha Test Enable or AlphaToCoverage Enable enabled.  The pixel shader kernel generates and outputs oMask. Note: As ClipDistance clipping is fully supported in hardware and therefore not via PS instructions, there should be no need to ENABLE this bit due to ClipDistance clipping. 24:23 Pixel Shader Computed Depth Mode Format: U2 Enumerated Type This field specifies the computed depth mode for the pixel shader. Value Name Description Project 0h PSCDEPTH_OFF Pixel shader does not compute depth All 1h PSCDEPTH_ON Pixel shader computes depth with no guarantee as to its All value 2h PSCDEPTH_ON_GE Pixel shader computes depth and guarantees that oDepth All >= SourceDepth 3h PSCDEPTH_ON_LE Pixel shader computes depth and guarantees that oDepth All <= SourceDepth Programming Notes When bit 5 is set in WM_STATE(i.e. RT independent rasterization is enabled), this field can not be programmed to values: 2h or 3h. 22:21 Early Depth/Stencil Control Format: U2 Enumerated Type This field specifies the behavior of early depth/stencil test. Value Name Description Project 0h EDSC_NORMAL Depth/Stencil Test/Write behaves as if it happens post-shader, All however the pixel shader is not necessarily executed if the pixel fails depth or stencil test (this is the legacy behavior) 1h EDSC_PSEXEC Depth/Stencil Test/Write behaves as if it happens post-shader, All and the pixel shader is executed if the pixel fails depth or stencil test (although pre-shader actions such as primitive inclusion, stipple, etc. will still cause the shader not to execute) 2h EDSC_PREPS Depth/Stencil Test/Write behaves as if it happens pre-shader. All The pixel shader is not executed if the pixel fails depth or stencil test. Depth and stencil writes occur even if the pixel is killed by the shader or post-shader by alpha test, etc. Depth output by the pixel shader is ignored. 3h Reserved All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 279 3DSTATE_WM Programming Notes If EDSC_PSEXEC mode is selected, Thread Dispatch Enable must be set. Errata Description Project When value of “2h” is programmed, PS_INVOCATIONs_COUNT may not be accurate. 20 Pixel Shader Uses Source Depth Project: All Format: Enable This bit, if ENABLED, indicates that the PS kernel requires the source depth value (vPos.z) to be passed in the payload.The source depth value is interpolated according to the Position ZW Interpolation Mode state. 19 Pixel Shader Uses Source W Project: All Format: Enable This bit, if ENABLED, indicates that the PS kernel requires the interpolated source W value (vPos.w) to be passed in the payload. The W value is interpolated according to the Position ZW Interpolation Mode state. 18:17 Position ZW Interpolation Mode Project: All Format: U2 Enumerated Type This field elects “interpolation mode” associated with the Position Z (source depth) and W coordinates passed in the PS payload when the PS requires Position as input. This field does not determine whether these coordinates are actually included in the payload (see Pixel Shader Requires Depth, Pixel Shader Requires W). Value Name Description Project 0h INTERP_PIXEL Evaluate Z & W at the pixel center or UL corner (as All specified by Pixel Location of 3DSTATE_MULTISAMPLE) 1h Reserved All 2h INTERP_CENTROID All 3h INTERP_SAMPLE All Programming Notes When bit 5 is set in WM_STATE, value of 3h is not defined for this field. Programming Note: When bit 5 in dword 1 (RT Independent Rasterization Enable) is set and bit 30 in dword 2 (PS UAV-only) is not set in WM_STATE, value of 3h is not defined for this field. 16:11 Barycentric Interpolation Mode Project: All Format: Enable[6] Controls which barycentric interpolation terms must be passed into the pixel shader kernel. Bit 0: Perspective Pixel Location barycentric is required Bit 1: Perspective Centroid barycentric is required Bit 2: Perspective Sample barycentric is required Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 280 3DSTATE_WM Bit 3: Non-perspective Pixel Location barycentric is required Bit 4: Non-perspective Centroid barycentric is required Bit 5: Non-perspective Sample barycentric is required Programming Notes If contiguous dispatch modes are enabled, only bit 3 (non-perspective pixel location) can be set, all other bits in this field must be zero.Pixel Location below refers to either the upper left corner or pixel center depending on the Pixel Location state of 3DSTATE_MULTISAMPLING). MSDISPMODE_PERSAMPLE is required in order to select Perspective Sample or Non-perspective Sample barycentric coordinates. Errata: When Centroid Barycentric mode is required, HW may produce incorrect interpolation results when a 2X2 pixels have unlit pixels. 10 Pixel Shader Uses Input Coverage Mask Project: All Format: Enable This bit, if ENABLED, indicates that the PS kernel requires the input coverage mask to be passed in the payload. 9:8 Line End Cap Antialiasing Region Width Project: All Format: U2 This field specifies the distances over which the coverage of anti-aliased line end caps are computed. Value Name Description Project 0h 0.5 pixels All 1h 1.0 pixels All 2h 2.0 pixels All 3h 4.0 pixels All 7:6 Line Antialiasing Region Width Project: All Format: U2 This field specifies the distance over which the anti-aliased line coverage is computed. Value Name Description Project 0h 0.5 pixels All 1h 1.0 pixels All 2h 2.0 pixels All 3h 4.0 pixels All 5 Reserved Format: MBZ 4 Polygon Stipple Enable Project: All Format: Enable Enables the Polygon Stipple function. 3 Line Stipple Enable Project: All Format: Enable Enables the Line Stipple function. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 281 3DSTATE_WM 2 Point Rasterization Rule Project: All Format: 3D_RasterizationRule This field specifies the rasterization rules to be applied whenever the edges of a point primitive fall exactly on a pixel sampling point. Value Name Description Project 0h RASTRULE_UPPER_LEFT To match “normal” upper left rules for surface All primitives 1h RASTRULE_UPPER_RIGHT To match OpenGL point rasterization rules (round All to + infinity, where this is the upper right direction wrt OpenGL screen origin of lower left). 1:0 Multisample Rasterization Mode Project: All Format: U2 enumerated type This field determines whether multisample rasterization is turned on/off, and how the pixel sample point(s) are defined. Software sets this according to the API, the API's multisample enable state setting (if any), and whether 1X or 4X MSRTs are bound. This state is duplicated in 3DSTATE_SF and both must be set to the same value. Refer to the "Multisampling" section for details on the settings of this field. Value Name Project 0h MSRASTMODE_OFF_PIXEL All 1h MSRASTMODE_OFF_PATTERN All 2h MSRASTMODE_ON_PIXEL All 3h MSRASTMODE_ON_PATTERN All 2 31 Multisample Dispatch Mode Project: All Format: U1 Enumerated Type This bit, along with Number of Multisamples, determines how PS threads are dispatched. Software programs this bit depending on the per-pixel v.s per-sample PS execution requirement. When RT Independent Rasterization Enable = 1, value of 0h for this field is not allowed. Value Name Description Project 0h MSDISPMODE_PERSAMPLE This is the high-quality DX10.1 multisample mode All where (over and above PERPIXEL mode) the PS is run for each covered sample. This mode is also used for “normal” non-multisample rendering (aka 1X), given Number of Multisamples is programmed to NUMSAMPLES_1. 1h MSDISPMODE_PERPIXEL This is the classic multisample mode of operation, All typically used for both antialiasing and transparency. Setup and rasterization operate in full multisample mode, testing coverage and depth/stencil test at the sample level but only running the PS once per pixel. 30:0 Reserved Format: MBZ Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 282 11.2.2 3DSTATE_PS This command is used to set state used by the pixel shader dispatch stage. 3DSTATE_PS Source: RenderCS Length Bias: 2 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 20h 3DSTATE_PS Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 06h Excludes DWord (0,1) Project: All Format: =n Total Length - 2 1 31:6 Kernel Start Pointer[0] Project: All Format: InstructionBaseOffset[31:6]Kernel Specifies the 64-byte aligned address offset of the first instruction in the kernel[0]. This pointer is relative to the Instruction Base Address. 5:0 Reserved Project: All Format: MBZ 2 31 Single Program Flow (SPF) Project: All Specifies the initial condition of the kernel program as either a single program flow (SIMDnxm with m = 1) or as multiple program flows (SIMDnxm with m > 1). See CR0 description in ISA Execution Environment. Value Name Description Project 0h Multiple Multiple Program Flows All 1h Single Single Program Flows All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 283 3DSTATE_PS 30 Vector Mask Enable (VME) Project: All Format: U1 Enumerated Type When SPF=0, VME specifies which mask to use to initialize the initial channel enables. When SPF=1, VME specifies which mask to use to generate execution channel enables. Value Name Description Project 0h Dmask Channels are enabled based on the dispatch mask All 1h Vmask Channels are enabled based on the vector mask All 29:27 Sampler Count Project: All Format: U3 Specifies how many samplers (in multiples of 4) the pixel shader 0 kernel uses. Used only for prefetching the associated sampler state entries. Value Name Description Project [0,4] 0h no samplers used All 1h between 1 and 4 samplers used All 2h between 5 and 8 samplers used All 3h between 9 and 12 samplers used All 4h between 13 and 16 samplers used All 5h-7h Reserved All 26 Denormal Mode Project: All Specifies the denornal mode used by the dispatched thread. Value Name Description Project 0h FTZ Denormals are flushed to zero All 1h RET Denormals are retained All 25:18 Binding Table Entry Count Project: All Format: U8 Specifies how many binding table entries the kernel uses. Used only for prefetching of the binding table entries and associated surface state.Note: For kernels using a large number of binding table entries, it may be advantageous to set this field to zero to avoid prefetching too many entries and thrashing the state cache. This field is ignored if VS Function Enable is DISABLED. Value Name [0,255] Programming Notes When HW binding table bit is set, it is assumed that the Binding Table Entry Count field will be generated at JIT time. 17 Reserved Format: MBZ 16 Floating Point Mode Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 284 3DSTATE_PS Project: All Specifies the floating point mode used by the dispatched thread. Value Name Description Project 0h IEEE-745 Use IEEE-754 rules All 1h Alt Use alternate rules All 15:14 Rounding Mode Project: All Specifies the rounding mode used by the dispatched thread. Value Name Description Project 0h RTNE Round to Nearest Even All 1h RU Round toward +infinity All 2h RD Round toward –infinity All 3h RTZ Round toward zero All 13 Illegal Opcode Exception Enable Project: All Format: Enable This bit gets loaded into EU CR0.1[12] (note the bit # difference). See Exceptions and ISA Execution Environment. 12 Reserved Project: All Format: MBZ 11 MaskStack Exception Enable Project: All Format: Enable This bit gets loaded into EU CR0.1[12] (note the bit # difference). See Exceptions and ISA Execution Environment. 10:8 Reserved Project: All Format: MBZ 7 Software Exception Enable Project: All Format: Enable This bit gets loaded into EU CR0.1[13] (note the bit # difference). See Exceptions and ISA Execution Environment. 6:0 Reserved Project: All Format: MBZ 3 31:10 Scratch Space Base Pointer Project: All Format: GeneralStateOffset[31:10]ScratchSpace Specifies the 1k-byte aligned address offset to scratch space for use by the kernel. This pointer is relative to the General State Base Address. 9:4 Reserved Project: All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 285 3DSTATE_PS Format: MBZ 3:0 Per Thread Scratch Space Project: All Format: U4 Specifies the amount of scratch space allowed to be used by each thread. The driver must allocate enough contiguous scratch space, pointed to by the Scratch Space Pointer, to ensure that the Maximum Number of Threads each get Per Thread Scratch Space size without exceeding the driver- allocated scratch space. Value Name [0,11] indicating [1k bytes, 2M bytes] in powers of two 4 31:24 Maximum Number of Threads Format: U8-1 representing thread count Description Project Range: WIZ Hashing Disable in GT_MODE register enabled: Range = [7,171] --> [8,172] threads. Only odd values are allowed (resulting in even max number of threads) WIZ Hashing Disable in GT_MODE register disabled: Range = [3,85] --> [4,86] threads. Only odd values are allowed (resulting in even max number of threads) Specifies the maximum number of simultaneous threads allowed to be active. Used to avoid using up the scratch space, or to avoid potential deadlock. Value Name Description Project [3h,2fh] Range [4,48] threads Programming Notes If this field is changed between 3DPRIMITIVE commands, a PIPE_CONTROL command with Stall at Pixel Scoreboard set is required to be issued. This field must have an odd value so that the max number of PS threads is even. 23:12 Reserved Format: MBZ 11 Push Constant Enable Project: All Format: Enable This field must be enabled if the sum of the PS Constant Buffer [3:0] Read Length fields in 3DSTATE_CONSTANT_PS is nonzero, and must be disabled if the sum is zero. 10 Attribute Enable Project: All Format: Enable This field must be enabled if the Number of SF Output Attributes field in 3DSTATE_SBE is nonzero, and must be disabled if that field is zero. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 286 3DSTATE_PS 9 oMask Present to RenderTarget Project: All Format: Enable This bit is inserted in the PS payload header and made available to the DataPort (either via the message header or via header bypass) to indicate that oMask data (one or two phases) is included in Render Target Write messages. If present, the oMask data is used to mask off samples. 8 Render Target Fast Clear Enable Project: All Format: Enable This field is set to enable fast clear of the bound render targets. See “Render Target Fast Clear” for restrictions on enabling this field. 7 Dual Source Blend Enable Project: All Format: Enable This field is set if dual source blend is enabled. If this bit is disabled, the data port dual source message reverts to a single source message using source 0. 6 Render Target Resolve Enable Project: All Format: Enable This field is set to enable clear value resolve on non-multisampled render targets. See “Render Target Resolve” for restrictions on enabling this field. 5 Reserved Format: MBZ 4:3 Position XY Offset Select Project: All Format: U2 Enumerated Type This field specifies if/what Position XY Offset values are passed in the PS payload. Note that these are per-slot (pixel|sample) offsets, and therefore separate from the subspan XY coordinates passed in R1. Value Name Description Project 0h POSOFFSET_NONE No Position XY Offsets are included in the PS All payload. 1h Reserved All 2h POSOFFSET_CENTROID Position XY Offsets will be passed in the PS payload, All and these will reflect the Centroid position(s). 3h POSOFFSET_SAMPLE Position XY Offsets will be passed in the PS payload, All and these will reflect the multisample position(s). Programming Notes SW Recommendation: If the PS kernel needs the Position Offsets to compute a Position XY value, this field should match Position ZW Interpolation Mode to ensure a consistent position.xyzw computation If the PS kernel does not need the Position XY Offsets to compute a Position Value, then this field should be programmed to POSOFFSET_NONE, as the PS kernel should be using the various Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 287 3DSTATE_PS barycentric inputs to evaluate other-than-position attributes. However, this field can be used to pass Centroid or Sample offsets in the payload for special test modes (e.g., where barycentric coordinates are computed in the PS vs. being HW-generated and passed in the payload). MSDISPMODE_PERSAMPLE is required in order to select POSOFFSET_SAMPLE. 2 32 Pixel Dispatch Enable Project: All Format: Enable Description Project Enables the Windower to dispatch 8 subspans in one payload. Note: in the table below, the Valid column indicates which products that combination is supported on. Combinations of dispatch enables not listed in the table are not available on any product. A: Valid B: Valid D: Valid, except when in non-1x PERSAMPLE mode. E: Valid, except when in PERSAMPLE mode with number of multisamples >= 8. F: Valid. Each of the three KSP values are separately specified. In addition, each kernel has a separately-specified GRF register count. Variable Pixel Dispatch Section: Pixel Grouping (Dispatch size) control for valid pixel dispatch combinations. 1 16 Pixel Dispatch Enable Project: All Format: Enable Description Project Enables the Windower to dispatch 4 subspans in one payload. Note: in the table below, the Valid column indicates which products that combination is supported on. Combinations of dispatch enables not listed in the table are not available on any product. A: Valid B: Valid D: Valid, except when in non-1x PERSAMPLE mode. E: Valid, except when in PERSAMPLE mode with number of multisamples >= 8. F: Valid. Each of the three KSP values are separately specified. In addition, each kernel has a separately-specified GRF register count. Variable Pixel Dispatch Section: Pixel Grouping (Dispatch size) control for valid pixel dispatch combinations. 0 8 Pixel Dispatch Enable Project: All Format: Enable Description Project Enables the Windower to dispatch 2 subspans in one payload. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 288 3DSTATE_PS Note: in the table below, the Valid column indicates which products that combination is supported on. Combinations of dispatch enables not listed in the table are not available on any product. A: Valid B: Valid D: Valid, except when in non-1x PERSAMPLE mode. E: Valid, except when in PERSAMPLE mode with number of multisamples >= 8. F: Valid.. Each of the three KSP values are separately specified. In addition, each kernel has a separately-specified GRF register count. Variable Pixel Dispatch Section: Pixel Grouping (Dispatch size) control for valid pixel dispatch combinations. 5 31:23 Reserved Project: All Format: MBZ 22:16 Dispatch GRF Start Register for Constant/Setup Data [0] Project: All Format: U7 Specifies the starting GRF register number for the Constant/Setup portion of the thread payload for kernel[0]. Value Name [0,127] 15 Reserved Project: All Format: MBZ 14:8 Dispatch GRF Start Register for Constant/Setup Data [1] Project: All Format: U7 Specifies the starting GRF register number for the Constant/Setup portion of the thread payload for kernel[1]. Value Name [0,127] 7 Reserved Project: All Format: MBZ 6:0 Dispatch GRF Start Register for Constant/Setup Data [2] Project: All Format: U7 Specifies the starting GRF register number for the Constant/Setup portion of the thread payload for kernel[2]. Value Name [0,127] 6 31:6 Kernel Start Pointer[1] Project: All Format: InstructionBaseOffset[31:6]Kernel Specifies the 64-byte aligned address offset of the first instruction in kernel[1]. This pointer is relative to the Instruction Base Address. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 289 3DSTATE_PS 5:0 Reserved Project: All Format: MBZ 7 31:6 Kernel Start Pointer[2] Project: All Format: InstructionBaseOffset[31:6]Kernel Specifies the 64-byte aligned address offset of the first instruction in kernel[2]. This pointer is relative to the Instruction Base Address. 5:0 Reserved Project: All Format: MBZ Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 290 11.2.3 3DSTATE_CONSTANT_PS 3DSTATE_CONSTANT_PS Source: RenderCS Length Bias: 2 This command sets pointers to the push constants for the PS unit. The constant data pointed to by this command is loaded into the PS unit’s push constant buffer (PCB). Programming Notes Project It is invalid to execute this command more than once between 3D_PRIMITIVE commands. Constant buffers must be enabled in order from Constant Buffer 0 to Constant Buffer 3 within this command. For example, it is not allowed to enable Constant Buffer 1 by programming a non-zero value in the PS Constant Buffer 1 Read Length without a non-zero value in PS Constant Buffer 0 Read Length. 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 17h 3DSTATE_CONSTANT_PS Format: OpCode 15:8 Reserved Format: MBZ 7:0 Dword Length Project: All Format: =n Total Length – 2 Value Name Project 5h Excludes DWord (0,1) [Default] 1..6 191:0 Constant Body Format: 3DSTATE_CONSTANT(Body) Following table is the shared portion of the 3DSTATE_CONSTANT command for VS, HS, DS, and GS Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 291 11.2.4 3DSTATE_PUSH_CONSTANT_ALLOC_PS 3DSTATE_PUSH_CONSTANT_ALLOC_PS Source: RenderCS Length Bias: 2 Description Project This command sets up the URB configuration for PS Push Constant Buffer. A PIPE_CONTOL command with the CS Stall bit set must be programmed in the ring after this instruction. Programming Notes Restriction:  The sum of the Constant Buffer Offset and the Constant Buffer Size may not exceed the maximum value of the Constant Buffer Size.  The sum of the constant length programmed in 3DSTATE_CONSTANT_PS must be equal or smaller then the size of the allocated space in the URB including the buffering for half cachelines. See Push Constant URB Allocation section for more details.  The 3DSTATE_CONSTANT_PS must be reprogrammed prior to the next 3DPRIMITIVE command after programming the 3DSTATE_PUSH_CONSTANT_ALLOC_PS. 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: 16h 3DSTATE_PUSH_CONSTANT_ALLOC_PS 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:20 Reserved Format: MBZ Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 292 3DSTATE_PUSH_CONSTANT_ALLOC_PS 19:16 Constant Buffer Offset Format: U5 Specifies the offset of the PS constant buffer into the URB. Value Name [0,15] (0KB - 15KB) 0h 0KB [Default] 15:5 Reserved Format: MBZ 4:0 Constant Buffer Size Format: U5 Specifies the size of the PS constant buffer. This value will determine the amount of data the command stream can pre-fetch before the buffer is full. Value of zero is only valid when constants are not enabled for PS. Value Name [0,15] (0KB – 15KB) Increments of 1KB 0h 0KB [Default] 11.2.5 3DSTATE_SAMPLE_MASK The sample mask state used by the windower stage is defined with this inline state packet. 3DSTATE_SAMPLE_MASK Source: RenderCS Length Bias: 2 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 18h 3DSTATE_SAMPLE_MASK Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 Dword Length Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 293 3DSTATE_SAMPLE_MASK Default Value: 0h Excludes Dword (0,1) Project: All Format: =n Total Length – 2 1 31:8 Reserved Format: MBZ 7:0 Sample Mask Format: 8 bit mask Right-justified bitmask (Bit 0 = Sample0). Number of bits that are used is determined by Num Multisamples (3DSTATE_MULTISAMPLE) A per-multisample-position mask state variable that is immediately and unconditionally ANDed with the sample coverage mask as part of the rasterization process. This mask is applied prior to centroid selection. Programming Notes  If Number of Multisamples is NUMSAMPLES_1, bits 7:1 of this field must be zero.  If Number of Multisamples is NUMSAMPLES_4, bits 7:4 of this field must be zero. 11.3 Rasterization The WM unit uses the setup computations performed by the SF unit to rasterize objects into the corresponding set of pixels Most of the controls regarding the screen-space geometry of rendered objects are programmed via the SF unit. The rasterization process generates pixels in 2x2 groups of pixels called subspans (see UNRESOLVED CROSS REFERENCE, Pixels with a SubSpan) which, after being subjected to various inclusion/discard tests, are grouped and passed to spawned Pixel Shader (PS) threads for subsequent processing Once these PS threads are spawned, the WM unit provides only bookkeeping functions on the pixels Note that the WM unit can proceed on to rasterize subsequent objects while PS threads from previous objects are still executing. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 294 Pixels with a SubSpan 11.3.1 Drawing Rectangle Clipping The Drawing Rectangle defines the maximum extent of pixels which can be rendered Portions of objects falling outside the Drawing Rectangle will be clipped (pixels discarded) Implementations will typically discard objects falling completely outside of the Drawing Rectangle as early in the pipeline as possible There is no control to turn off Drawing Rectangle clipping – it is unconditional. For the purposes of clipping, the Drawing Rectangle must itself be clipped to the destination buffer extents (The Drawing Rectangle Origin, used to offset relative X,Y coordinates earlier in the pipeline, is permitted to lie offscreen). The Clipped Drawing Rectangle X,Y Min,Max state variables (programmed via 3DSTATE_DRAWING_RECTANGLE – See SF Unit) defines the intersection of the Drawing Rectangle and the Color Buffer It is specified with non-negative integer pixel coordinates relative to the Destination Buffer upper-left origin. Pixels with coordinates outside of the Drawing Rectangle cannot be rendered (i.e., the rectangle is inclusive) For example, to render to a full-screen 1280x1024 buffer, the following values would be required: Xmin=0, Ymin=0, Xmax=1279 and Ymax=1023 For “full screen” rendering, the Drawing Rectangle coincides with the screen-sized buffer For “front-buffer windowed” rendering it coincides with the destination “window”. 11.3.2 Line Rasterization See SF Unit chapter for details on the screen-space geometry of the various line types. 11.3.2.1 Coverage Values for Anti-Aliased Lines The WM unit is provided with both the Line Anti-Aliasing Region Width and Line End Cap Anti- aliasing Region Width state variables (in WM_STATE) in order to compute the coverage values for anti- aliased lines Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 295 11.3.2.2 3DSTATE_AA_LINE_PARAMS 3DSTATE_AA_LINE_PARAMETERS Source: RenderCS Length Bias: 2 The 3DSTATE_AA_LINE_PARAMS command is used to specify the slope and bias terms used in the improved alpha coverage computation (specifically for DX WHQL compliance). Note that in these devices the coverage values passed to PS threads are full U0.8 values. 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: 0Ah 3DSTATE_AA_LINE_PARAMS Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 Dword Length Default Value: 1h Excludes Dword (0,1) Project: All Format: =n Total Length – 2 1 31:24 Reserved Format: MBZ 23:16 AA Coverage Bias Project: All Format: U0.8 This field specifies the bias term to be used in the aa coverage computation for edges 0 and 3. 15:8 Reserved Format: MBZ 7:0 AA Coverage Slope Project: All Format: U0.8 This field specifies the slope term to be used in the aa coverage computation for edges 0 and 3.If this field is zero, the Windower will revert to legacy aa line coverarge computation (though still output expanded U0.8 coverage values). Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 296 3DSTATE_AA_LINE_PARAMETERS 2 31:24 Reserved Format: MBZ 23:16 AA Coverage EndCap Bias Project: All Format: U0.8 This field specifies the bias term to be used in the aa coverage computation for edges 1 and 2. 15:8 Reserved Format: MBZ 7:0 AA Coverage EndCap Slope Project: All Format: U0.8 This field specifies the slope term to be used in the aa coverage computation for edges 1 and 2. The slope and bias values should be computed to closely match the reference rasterizer results Based on empirical data, the following recommendations are offered: The final alpha for the center of the line needs to be 148 to match the reference rasterizer In this case, the Lo to edge 0 and edge 3 will be the same Since the alpha for each edge is multiplied together, we get: edge0alpha * edge1alpha = 148/255 = 0.580392157 Since edge0alpha = edge3alpha we get: (edge0alpha)2 = 0.580392157 edge0alpha = sqrt(0.580392157) = 0.761834731 at the center pixel The desired alpha for pixel 1 = 54/255 = 0.211764706 The slope is (0.761834731 – 0.211764706) = 0.550070025 Since we are using 8 bit precision, the slope becomes AA Coverage [EndCap] Slope = 0.55078125 The alpha value for Lo = 0 (second pixel from center) determines the bias term and is equal to (0.211764706 – 0.550070025) = -0.338305319 With 8 bits of precision the programmed bias value AA Coverage [EndCap] Bias = 0.33984375 11.3.2.3 Line Stipple Line stipple, controlled via the Line Stipple Enable state variable in WM_STATE, discards certain pixels that are produced by non-AA line rasterization. The line stipple rule is specified via the following state variables programmed via 3DSTATE_LINE_STIPPLE: the 16-bit Line Stipple Pattern (p), Line Stipple Repeat Count I, and Line Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 297 Stipple Inverse Repeat Count. Sofware must compute Line Stipple Inverse Repeat Count as 1.0f / Line Stipple Repeat Count and then converted from float to the required fixed point encoding (see 3STATE_LINE_STIPPLE). The WM unit maintains an internal Line Stipple Counter state variable (s) The initial value of s is zero; s is incremented after production of each pixel of a line segment (pixels are produced in order, beginning at the starting point and working towards the ending point). S is reset to 0 whenever a new primitive is processed (unless the primitive type is LINESTRIP_CONT or LINESTRIP_CONT_BF), and before every line segment in a group of independent segments (LINELIST primitive). During the rasterization of lines, the WM unit computes: A pixel is rendered if the bth bit of p is 1, otherwise it is discarded. The bits of p are numbered with 0 being the least significant and 15 being the most significant. 11.3.2.4 3DSTATE_LINE_STIPPLE 3DSTATE_LINE_STIPPLE Source: RenderCS Length Bias: 2 The 3DSTATE_LINE_STIPPLE command is used to specify state variables used in the Line Stipple function. 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: 08h 3DSTATE_LINE_STIPPLE Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 Dword Length Default Value: 1h Excludes Dword (0,1) Project: All Format: =n Total Length – 2 1 31 Modify Enable (Current Repeat Counter, Current Stipple Index) Project: All Format: Enable Modify enable for Current Repeat Counter and Current Stipple Index fields. Programming Notes Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 298 3DSTATE_LINE_STIPPLE Software should never set this field to enabled. It is provided only for HW-generated commands as part of context save/restore. 30 Reserved Project: All Format: MBZ 29:21 Current Repeat Counter Project: All Format: U9 This field sets the HW-internal repeat counter state. Note: Software should never attempt to set this value – this state is only provided for HW-generated commands as part of context save/restore. 20 Reserved Project: All Format: MBZ 19:16 Current Stipple Index Project: All Format: U4 This field sets the HW-internal stipple pattern index. Note: Software should never attempt to set this value – this state is only provided for HW-generated commands as part of context save/restore. 15:0 Line Stipple Pattern Project: All Format: 16 bit mask Bit 15 = most significant bit, Bit 0 = least significant bit Specifies a pattern used to mask out bit specific pixels while rendering lines. 2 31:15 Line Stipple Inverse Repeat Count Project: All Format: U1.16 Range: [0.00390625, 1.0] Specifies the inverse (truncated) of the repeat count for the line stipple function. 14:9 Reserved Project: All Format: MBZ 8:0 Line Stipple Repeat Count Project: All Format: U9 Specifies the repeat count for the line stipple function. Value Name [1, 256] Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 299 11.3.3 Polygon (Triangle and Rectangle) Rasterization The rasterization of LINE, TRIANGLE, and RECTANGLE objects into pixels requires a “pixel sampling grid” to be defined This grid is defined as an axis-aligned array of pixel sample points spaced exactly 1 pixel unit apart If a sample point falls within one of these objects, the pixel associated with the sample point is considered “inside” the object, and information for that pixel is generated and passed down the pipeline For TRIANGLE and RECTANGLE objects, if a sample point intersects an edge of the object, the associated pixel is considered “inside” the object if the intersecting edge is a “left” or “top” edge (or, more exactly, the intersected edge is not a “right” or “bottom” edge) Note that “top” and “bottom” edges are by definition exactly horizontal. See UNRESOLVED CROSS REFERENCE, TRIANGLE and RECTANGLE Edge Types, for the edge types for representative TRIANGLE and RECTANGLE objects (solid edges are inclusive, dashed edges are exclusive). TRIANGLE and RECTANGLE Edge Types Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 300 11.3.3.1 Polygon Stipple The Polygon Stipple function, controlled via the Polygon Stipple Enable state variable in WM_STATE, allows only selected pixels of a repeated 32x32 pixel pattern to be rendered Polygon stipple is applied only to the following primitive types: 3DPRIM_POLYGON 3DPRIM_TRIFAN 3DPRIM_TRILIST 3DPRIM_TRISTRIP 3DPRIM_TRISTRIP_REVERSE Note that the 3DPRIM_TRIFAN_NOSTIPPLE object is never subject to polygon stipple. The stipple pattern is defined as a 32x32 bit pixel mask via the 3DSTATE_POLY_STIPPLE_PATTERN command. This is a non-pipelined command which incurs an implicit pipeline flush when executed. The origin of the pattern is specified via Polygon Stipple X,Y Offset state variables programmed via the 3DSTATE_POLY_STIPPLE_OFFSET command The offsets are pixel offsets from the Color Buffer origin to the upper left corner of the stipple pattern. This is a non-pipelined command which incurs an implicit pipeline flush when executed. 11.3.3.2 3DSTATE_POLY_STIPPLE_OFFSET 3DSTATE_POLY_STIPPLE_OFFSET Project: All Source: RenderCS Length Bias: 2 The 3DSTATE_POLY_STIPPLE_OFFSET command is used to specify the origin of the repeated screen-space Polygon Stipple Pattern as an X,Y offset from the Color Buffer origin. 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: 06h 3DSTATE_POLY_STIPPLE_OFFSET Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 Dword Length Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 301 3DSTATE_POLY_STIPPLE_OFFSET Default Value: 0h Excludes Dword (0,1) Project: All Format: =n Total Length – 2 1 31:13 Reserved Project: All Format: MBZ 12:8 Polygon Stipple X Offset Project: All Format: U5 Specifies a 5 bit x address offset in the poly stipple pattern Value Name [0,31] 7:5 Reserved Project: All Format: MBZ 4:0 Polygon Stipple Y Offset Project: All Format: U5 Specifies a 5 bit y address offset in the poly stipple pattern Value Name [0,31] 11.3.3.3 3DSTATE_POLY_STIPPLE_PATTERN 3DSTATE_POLY_STIPPLE_PATTERN Project: All Source: RenderCS Length Bias: 2 The 3DSTATE_POLY_STIPPLE_PATTERN command is used to specify the 32x32 Polygon Stipple Pattern used in the Polygon Stipple function of the WM unit. 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: 07h 3DSTATE_POLY_STIPPLE_PATTERN Format: OpCode Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 302 3DSTATE_POLY_STIPPLE_PATTERN 15:8 Reserved Project: All Format: MBZ 7:0 Dword Length Default Value: 1Fh Excludes Dword (0,1) Project: All Format: =n Total Length – 2 1 31:0 Polygon Stipple Pattern Row 1 (top most) Project: All Format: 32 bit mask Bit 31 = upper left corner, Bit 0 = upper right corner of first row. Specifies a pattern used by Polygon Stipple to mask out specific pixels of every 32x32 area rendered. 2..32 31:0 Polygon Stipple Pattern Rows 2-32 (bottom most) Project: All Format: 32 bit mask Bit 31 = upper left corner, Bit 0 = upper right corner of first row. Specifies a pattern used by Polygon Stipple to mask out specific pixels of every 32x32 area rendered. 11.4 Multisampling The multisampling function has two components:  Multisample Rasterization: multisample rasterization occurs at a subpixel level, wherein each pixel consists of a number of “samples” at state-defined positions within the pixel footprint Coverage of the primitive as well as color calculator operations (stencil test, depth test, color buffer blending, etc.) are done at the sample level In addition the pixel shader itself can optionally run at the sample level depending on a separate state field.  Multisample Render Targets (MSRT): The render targets, as well as the depth and stencil buffers, now have the ability to store per-sample values When combined with multisample rasterization, color calculator operations such as stencil test, depth test, and color buffer blending are done with the destination surface containing potentially different values per sample. 11.4.1 Multisample Modes/State A number of state variables control the operation of the multisampling function. The following list indicates the state and their location. Refer to the state definition for more details.  Multisample Rasterization Mode (3DSTATE_SF and 3DSTATE_WM): controls whether rasterization of non-lines is performed on a pixel or sample basis (PIXEL vs. PATTERN), and whether multisample rasterization of lines enabled (OFF vs. ON). Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 303  Multisample Dispatch Mode (3DSTATE_WM ): controls whether the pixel shader is executed per pixel or per sample.  Number of Multisamples (3DSTATE_MULTISAMPLE and SURFACE_STATE): indicates the number of samples per pixel contained on the surface. This field in 3DSTATE_MULTISAMPLE must match the corresponding field in SURFACE_STATE for each render target. The depth, hierarchical depth, and stencil buffers inherit this field from 3DSTATE_MULTISAMPLE.  Pixel Location (3DSTATE_MULTISAMPLE): indicates the subpixel location where values specified as “pixel” are sampled. This is either the upper left corner or the center.  MSAA Sample Offsets (3DSTATE_MULTISAMPLE ] ): for each of the N samples, specifies the subpixel location of each sample. 11.4.2 3DSTATE_MULTISAMPLE 3DSTATE_MULTISAMPLE Source: RenderCS Length Bias: 2 The 3DSTATE_MULTISAMPLE command is used to specify multisample state associated with the current render target/depth buffer. This is non-pipelined state. Programming Restriction: Driver must ierarchi that all the caches in the depth pipe are flushed before this command is parsed. This requires driver to send a PIPE_CONTROL with a CS stall along with a Depth Flush prior to this command. When this command is issued, the currently active depth buffer, hierarchical depth buffer, stencil buffer, and render target(s) must be cleared (meaning that every pixel must be overwritten). Alternatively, other surfaces can be activated before issuing the next 3DPRIMITIVE that were previously rendered with the same values of all state fields in this command. In other words, it is illegal to render to these surfaces with multiple different values of the state fields in this command. Programming Notes When programming the sample offsets (for NUMSAMPLES_4 or _8 and MSRASTMODE_xxx_PATTERN), the order of the samples 0 to 3 (or 7 for 8X) must have monotonically increasing distance from the pixel center. This is required to get the correct centroid computation in the device. 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: 0Dh 3DSTATE_MULTISAMPLE Format: OpCode 15:8 Reserved Project: All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 304 3DSTATE_MULTISAMPLE Format: MBZ 7:0 Dword Length Project: All Format: =n Total Length – 2 Excludes Dword (0,1) Value Name Project 2h [Default] 1 31:6 Reserved Project: All Format: MBZ 5 Reserved Format: MBZ 4 Pixel Location Project: All Format: U1 This field specifies where the device evaluates “pixel” (vs. centroid or sample) values/attributes. Value Name Description Project 0h PIXLOC_CENTER Use the pixel center (0.5, 0.5 offset) All 1h PIXLOC_UL_CORNER Use the pixel upper-left corner All Programming Notes The programming of this field is assumed to be a function of the API being supported. Specifically, it is expected that OpenGL and DX10+ APIs require CENTER selection, while DX9- APIs require UL_CORNER selection. 3:1 Number of Multisamples Project: All Format: U3 enumerated value This field specifies how many samples/pixel exist in all RTs and the Depth Buffer, as log2(#samples). This field is valid regardless of the setting of Multisample Rasterization Mode. Value Name Description Project 0h NUMSAMPLES_1 1 sample/pixel All 1h Reserved All 2h NUMSAMPLES_4 4 samples/pixel All 3h NUMSAMPLES_8 8 samples/pixel All [4h,7h] Reserved All Programming Notes Setting Multisample Rasterization Mode to MSRASTMODE_xxx_PATTERN when Number of Multisamples == NUMSAMPLES_1 is UNDEFINED. The setting of this field must match the Number of Multisamples field in SURFACE_STATE of all Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 305 3DSTATE_MULTISAMPLE bound render targets. 0 Reserved Project: All Format: MBZ 2 31:28 Sample3 X Offset Project: All Format: U0.4 Description Project Subpixel X offset of Sample 3 relative to the UL pixel origin. Valid only when NUMSAMPLES_4 or _8. Setting ignored when not in MSRASTMODE_xxx_PATTERN mode. Valid when NUMSAMPLES_1 Value Name [0,15] [0,0.9375] 27:24 Sample3 Y Offset Project: All Format: U0.4 Description Project Subpixel Y offset of Sample 3 relative to the UL pixel origin. Valid only when NUMSAMPLES_4 or _8. Setting ignored when not in MSRASTMODE_xxx_PATTERN mode. Valid when NUMSAMPLES_1 Value Name [0,15] [0,0.9375] 23:20 Sample2 X Offset Project: All Format: U0.4 Description Project Subpixel X offset of Sample 2 relative to the UL pixel origin. Valid only when NUMSAMPLES_4 or _8. Setting ignored when not in MSRASTMODE_xxx_PATTERN mode. Valid when NUMSAMPLES_1 Value Name [0,15] [0,0.9375] 19:16 Sample2 Y Offset Project: All Format: U0.4 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 306 3DSTATE_MULTISAMPLE Description Project Subpixel Y offset of Sample 2 relative to the UL pixel origin. Valid only when NUMSAMPLES_4 or _8. Setting ignored when not in MSRASTMODE_xxx_PATTERN mode. Valid when NUMSAMPLES_1 Value Name [0,15] [0,0.9375] 15:12 Sample1 X Offset Project: All Format: U0.4 Description Project Subpixel X offset of Sample 1 relative to the UL pixel origin. Valid only when NUMSAMPLES_4 or _8. Setting ignored when not in MSRASTMODE_xxx_PATTERN mode. Valid when NUMSAMPLES_1 Value Name [0,15] [0,0.9375] 11:8 Sample1 Y Offset Project: All Format: U0.4 Description Project Subpixel Y offset of Sample 1 relative to the UL pixel origin. Valid only when NUMSAMPLES_4 or _8. Setting ignored when not in MSRASTMODE_xxx_PATTERN mode. Valid when NUMSAMPLES_1 Value Name [0,15] [0,0.9375] 7:4 Sample0 X Offset Project: All Format: U0.4 Description Project Subpixel X offset of Sample 0 relative to the UL pixel origin. Valid only when NUMSAMPLES_4 or _8. Setting ignored when not in MSRASTMODE_xxx_PATTERN mode. Valid when NUMSAMPLES_1 Value Name [0,15] [0,0.9375] 3:0 Sample0 Y Offset Project: All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 307 3DSTATE_MULTISAMPLE Format: U0.4 Description Project Subpixel Y offset of Sample 0 relative to the UL pixel origin. Valid only when NUMSAMPLES_4 or _8. Setting ignored when not in MSRASTMODE_xxx_PATTERN mode. Valid when NUMSAMPLES_1 Value Name [0,15] [0,0.9375] 3 31:28 Sample7 X Offset Format: U0.4 Subpixel X offset of Sample 7 relative to the UL pixel origin. Valid only when NUMSAMPLES_8. Setting ignored when not in MSRASTMODE_xxx_PATTERN mode. Value Name [0,15] [0,0.9375] 27:24 Sample7 Y Offset Format: U0.4 Subpixel Y offset of Sample 7 relative to the UL pixel origin. Valid only when NUMSAMPLES_8. Setting ignored when not in MSRASTMODE_xxx_PATTERN mode. Value Name [0,15] [0,0.9375] 23:20 Sample6 X Offset Format: U0.4 Subpixel X offset of Sample 6 relative to the UL pixel origin. Valid only when NUMSAMPLES_8. Setting ignored when not in MSRASTMODE_xxx_PATTERN mode. Value Name [0,15] [0,0.9375] 19:16 Sample6 Y Offset Format: U0.4 Subpixel Y offset of Sample 6 relative to the UL pixel origin. Valid only when NUMSAMPLES_8. Setting ignored when not in MSRASTMODE_xxx_PATTERN mode. Value Name [0,15] [0,0.9375] 15:12 Sample5 X Offset Format: U0.4 Subpixel X offset of Sample 5 relative to the UL pixel origin. Valid only when NUMSAMPLES_8. Setting ignored when not in MSRASTMODE_xxx_PATTERN mode. Value Name [0,15] [0,0.9375] 11:8 Sample5 Y Offset Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 308 3DSTATE_MULTISAMPLE Format: U0.4 Subpixel Y offset of Sample 5 relative to the UL pixel origin. Valid only when NUMSAMPLES_8. Setting ignored when not in MSRASTMODE_xxx_PATTERN mode. Value Name [0,15] [0,0.9375] 7:4 Sample4 X Offset Format: U0.4 Subpixel X offset of Sample 4 relative to the UL pixel origin. Valid only when NUMSAMPLES_8. Setting ignored when not in MSRASTMODE_xxx_PATTERN mode. Value Name [0,15] [0,0.9375] 3:0 Sample4 Y Offset Format: U0.4 Subpixel Y offset of Sample 4 relative to the UL pixel origin. Valid only when NUMSAMPLES_8. Setting ignored when not in MSRASTMODE_xxx_PATTERN mode. Value Name [0,15] [0,0.9375] 11.5 Early Depth/Stencil Processing The Windower/IZ unit provides the Early Depth Test function, a major performance-optimization feature where an attempt is made to remove pixels that fail the Depth and Stencil Tests prior to pixel shading. This requires the WM unit to perform the interpolation of pixel (“source”) depth values, read the current (“destination”) depth values from the cached depth buffer, and perform the Depth and Stencil Tests As the WM unit has per-pixel source and destination Z values, these values are passed in the PS thread payload, if required. 11.5.1 Depth Offset The depth offset function is contained in SF unit, thus the state to control it is also contained in SF unit. There are occasions where the Z position of some objects need to be slightly offset in order to reduce artifacts due to coplanar or near-coplanar primitives A typical example is drawing the edges of triangles as wireframes – the lines need to be drawn slightly closer to the viewer to ensure they will not be occluded by the underlying polygon Another example is drawing objects on a wall – without a bias on the z positions, they might be fully or partially occluded by the wall. The device supports global depth offset, applied only to triangles, that bases the offset on the object’s z slope Note that there is no clamping applied at this stage after the Z position is offset – clamping to [0,1] can be performed later after the Z position is interpolated to the pixel This is preferable to clamping prior to interpolation, as the clamping would change the Z slope of the entire object. The Global Depth Offset function is controlled by the Global Depth Offset Enable state variable in WM_STATE Global Depth Offset is only applied to 3DOBJ_TRIANGLE objects. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 309 When Global Depth Offset Enable is ENABLED, the pipeline will compute: MaxDepthSlope = max(abs(dZ/dX),abs(dz/dy)) // approximation of max depth slope for polygon When UNORM Depth Buffer is at Output Merger (or no Depth Buffer): Bias = GlobalDepthOffsetConstant * r + GlobalDepthOffsetScale * MaxDepthSlope Where r is the minimum representable value > 0 in the depth buffer format, converted to float32 (note: If state bit Legacy Global Depth Bias Enable is set, the r term will be forced to 1.0) When Floating Point Depth Buffer at Output Merger: Bias = GlobalDepthOffsetConstant * 2^(exponent(max z in primitive) – r) + GlobalDepthOffsetScale * MaxDepthSlope Where r is the # of mantissa bits in the floating point representation (excluding the hidden bit), e.g. 23 for float32 (note: If state bit Legacy Global Depth Bias Enable is set, no scaling is applied to the GobalDepthOffsetConstant). Adding Bias to z: if (GlobalDepthOffsetClamp > 0) Bias = min(DepthBiasClamp, Bias) else if(GlobalDepthOffsetClamp < 0) Bias = max(DepthBiasClamp, Bias) // else if GlobalDepthOffsetClamp == 0, no clamping occurs z = z + Bias Biasing is constant for a given primitive The biasing formulas are performed with float32 arithmetic Global Depth Bias is not applied to any point or line primitives 11.5.2 Early Depth Test/Stencil Test/Write When Early Depth Test Enable is ENABLED, the WM unit will attempt to discard depth-occluded pixels during scan conversion (before processing them in the Pixel Shader) Pixels are only discarded when the WM unit can ensure that they would have no impact to the ColorBuffer or DepthBuffer This function is therefore only a performance feature. Note: The Early Depth Test Enable bit is no longer present. This function is always enabled. If some pixels within a subspan are discarded, only the pixel mask is affected indicating that the discarded pixels are not active If all pixels within a subspan are discarded, that subspan will not even be dispatched. 11.5.2.1 Software-Provided PS Kernel Info In order for the WM unit to properly perform Early Depth Test and supply the proper information in the PS thread payload (and even determine if a PS thread needs to be dispatched), it requires information regarding the PS kernel operation This information is provided by a number of state bits in WM_STATE, as summarized in the following table. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 310 State Bit Description Pixel Shader This must be set when there is a chance that valid pixels passed to a PS thread may be discarded. Kill Pixel This includes the discard of pixels by the PS thread resulting from a “killpixel” or “alphatest” function or as dictated by the results of the sampling of a “chroma-keyed” texture The WM unit needs this information to prevent early depth/stencil writes for pixels which might be killed by the PS thread, etc. See WM_STATE/3DSTATE_WM for more information. Pixel Shader This must be set when the PS thread computes the “source” depth value (i.e., from the API POV, Computed writes to the “oDepth” output) In this case the WM unit can’t make any decisions based on the WM- Depth interpolated depth value. See WM_STATE/3DSTATE_WM for more information. Pixel Shader Must be set if the PS thread requires the WM-interpolated source depth value This will force the Uses Source source depth to be passed in the thread payload where otherwise the WM unit would not have seen Depth it as required. See WM_STATE/3DSTATE_WM for more information. 11.5.3 Hierarchical Depth Buffer A hierarchical depth buffer is supported beginning with to reduce memory traffic due to depth buffer accesses This buffer is supported only in Tile Y memory. The Surface Type, Height, Width, Depth, Minimum Array Element, Render Target View Extent, and Depth Coordinate Offset X/Y of the hierarchical depth buffer are inherited from the depth buffer The height and width of the hierarchical depth buffer that must be allocated are computed by the following formulas, where HZ is the hierarchical depth buffer and Z is the depth buffer The Z_Height, Z_Width, and Z_Depth values given in these formulas are those present in 3DSTATE_DEPTH_BUFFER incremented by one. : The value of Z_Height and Z_Width must each be multiplied by 2 before being applied to the table below if Number of Multisamples is set to NUMSAMPLES_4. The value of Z_Height must be multiplied by 2 and Z_Width must be multiplied by 4 before being applied to the table below if Number of Multisamples is set to NUMSAMPLES_8.. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 311 Since Hierarchical Depth Buffer supports multiple LODs. The HZ_height is different as shown in the table below: Surface Type HZ_Width (bytes) HZ_Height (rows) SURFTYPE_1D ceiling(Z_Width / 16) * 16 Ceiling ( ( Q_pitch * Z_depth/2) /8 ) * 8 SURFTYPE_2D ceiling(Z_Width / 16) * 16 Ceiling ( ( Q_pitch * Z_depth/2) /8 ) * 8 SURFTYPE_3D ceiling(Z_Width / 16) * 16 see below SURFTYPE_CUBE ceiling(Z_Width / 16) * 16 Ceiling ( ( Q_pitch * Z_depth * 6/2) /8 ) * 8 where, Qpitch is computed using vertical alignment j=8, please refer to the GPU overview volume for Qpitch definition. The minimum HZ_Height required for a 3D surface must be computed based on hL parameters documented in the GPU Overview volume, and the maximum LOD m: In order to compute the minimum QPitch for the HZ surface, the height of each LOD in pixels is determined using the equations for hL in the GPU Overview volume, using a vertical alignment j=8. The following equation gives the minimum HZ_QPitch based on largest LOD m defined in the surface: If m is less than 2, treat all hL with L > m as zero and use the above equation. The minimum HZ_Height required for a 3D surface must be computed based on hL parameters documented in the GPU Overview volume, and the maximum LOD m: The format of the data in the hierarchical depth buffer is not documented here, as this surface needs only to be allocated by software Hardware will read and write this surface during operation and its contents are discarded once the last primitive is rendered that uses the hierarchical depth buffer. The hierarchical depth buffer can be enabled whenever a depth buffer is defined, with its effect being invisible other than generally higher performance The only exception is the hierarchical depth buffer must be disabled when using software tiled rendering. If HiZ is enabled, you must initialize the clear value by either a.Perform a depth clear pass to initialize the clear value. b.Send a 3dstate_clear_params packet with valid = 1 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 312 Without one of these events, context switching will fail, as it will try to save off a clear value even though no valid clear value has been set When context restore happens, HW will restore an uninitialized clear value. 11.5.3.1 Depth Buffer Clear With the hierarchical depth buffer enabled, performance is generally improved by using the special clear mechanism described here to clear the hierarchical depth buffer and the depth buffer This is enabled though the Depth Buffer Clear field in WM_STATE or 3DSTATE_WM This bit can be used to clear the depth buffer in the following situations:  Complete depth buffer clear  Partial depth buffer clear with the clear value the same as the one used on the previous clear  Partial depth buffer clear with the clear value different than the one used on the previous clear can use this mechanism if a depth buffer resolve is performed first. The following is required when performing a depth buffer clear with this field:  If other rendering operations have preceded this clear, a PIPE_CONTROL with depth cache flush enabled, Depth Stall bit enabled must be issued before the rectangle primitive used for the depth buffer clear operation.  The fields in 3DSTATE_CLEAR_PARAMS are set to indicate the source of the clear value and (if source is in this command) the clear value itself.  A rectangle primitive representing the clear area is delivered. The primitive must adhere to the following restrictions on size: o If Number of Multisamples is NUMSAMPLES_1, the rectangle must be aligned to an 8x4 pixel block relative to the upper left corner of the depth buffer, and contain an integer number of these pixel blocks, and all 8x4 pixels must be lit. o If Number of Multisamples is NUMSAMPLES_4, the rectangle must be aligned to a 4x2 pixel block (8x4 sample block) relative to the upper left corner of the depth buffer, and contain an integer number of these pixel blocks, and all samples of the 4x2 pixels must be lit. o If Number of Multisamples is NUMSAMPLES_8, the rectangle must be aligned to a 2x2 pixel block (8x4 sample block) relative to the upper left corner of the depth buffer, and contain an integer number of these pixel blocks, and all samples of the 2x2 pixels must be list.  Depth Test Enable must be disabled and Depth Buffer Write Enable must be enabled (if depth is being cleared).  Stencil buffer clear can be performed at the same time by enabling Stencil Buffer Write Enable Stencil Test Enable must be enabled and Stencil Pass Depth Pass Op set to REPLACE, and the clear value that is placed in the stencil buffer is the Stencil Reference Value from COLOR_CALC_STATE.  Note also that stencil buffer clear can be performed without depth buffer clear For stencil only clear, Depth Test Enable and Depth Buffer Write Enable must be disabled.  Pixel Shader Dispatch, Alpha Test, Pixel Shader Kill Pixel and Pixel Shader Computed Depth must all be disabled. Several cases exist where Depth Buffer Clear cannot be enabled (the legacy method of clearing must be performed): Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 313  If the depth buffer format is D32_FLOAT_S8X24_UINT or D24_UNORM_S8_UINT.  If stencil test is enabled but the separate stencil buffer is disabled. 11.5.3.2 Depth Buffer Resolve If the hierarchical depth buffer is enabled, the depth buffer may contain incorrect results after rendering is complete If the depth buffer is retained and used for another purpose (i.e as input to the sampling engine as a shadow map), it must first be “resolved” This is done by setting the Depth Buffer Resolve Enable field in WM_STATE or 3DSTATE_WM and rendering a full render target sized rectangle Once this is complete, the depth buffer will contain the same contents as it would have had the rendering been performed with the hierarchical depth buffer disabled. In a typical usage model, depth buffer needs to be resolved after rendering on it and before using a depth buffer as a source for any consecutive operation. Depth buffer can be used as a source in three different cases: using it as a texture for the nest rendering sequence, honoring a lock on the depth buffer to the host OR using the depth buffer as a blit source. The following is required when performing a depth buffer resolve:  A rectangle primitive of the same size as the previous depth buffer clear operation must be delivered, and depth buffer state cannot have changed since the previous depth buffer clear operation.  Depth Test Enable must be enabled with the Depth Test Function set to NEVER Depth Buffer Write Enable must be enabled Stencil Test Enable and Stencil Buffer Write Enable must be disabled.  Pixel Shader Dispatch, Alpha Test, Pixel Shader Kill Pixel and Pixel Shader Computed Depth must all be disabled. 11.5.3.3 Hierarchical Depth Buffer Resolve If the hierarchical depth buffer is enabled, the hierarchical depth buffer may contain incorrect results if the depth buffer is written to outside of the 3D rendering operation If this occurs, the hierarchical depth buffer must be “resolved”to avoid incorrect device behavior This is done by setting the Hierarchical Depth Buffer Resolve Enable field in WM_STATE or 3DSTATE_WM and rendering a full render target sized rectangle Once this is complete, the hierarchical depth buffer will contain contents such that rendering will give the same results as it would have had the rendering been performed with the hierarchical depth buffer disabled. The following is required when performing a hierarchical depth buffer resolve:  A rectangle primitive covering the full render target must be delivered.  Depth Test Enable must be disabled Depth Buffer Write Enable must be enabled Stencil Test Enable and Stencil Buffer Write Enable must be disabled.  Pixel Shader Dispatch, Alpha Test, Pixel Shader Kill Pixel and Pixel Shader Computed Depth must all be disabled. 11.5.4 Separate Stencil Buffer The separate stencil buffer is always enabled, thus the field in 3DSTATE_DEPTH_BUFFER to explicitly enable the separate stencil buffer has been removed Surface formats with interleaved depth and stencil are no longer supported Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 314 The stencil buffer has a format of S8_UINT, and shares Surface Type, Height, Width, and Depth, Minimum Array Element, Render Target View Extent, Depth Coordinate Offset X/Y, LOD, and Depth Buffer Object Control State fields of the depth buffer. 11.5.5 Depth/Stencil Buffer State 11.5.5.1 3DSTATE_DEPTH_BUFFER 3DSTATE_DEPTH_BUFFER Source: RenderCS Length Bias: 2 The depth buffer surface state is delivered as a pipelined state packet. However, the state change pipelining isn’t completely transparent (see restriction below). Programming Notes Project Restriction: Prior to changing Depth/Stencil Buffer state (i.e., any combination of 3DSTATE_DEPTH_BUFFER, 3DSTATE_CLEAR_PARAMS, 3DSTATE_STENCIL_BUFFER, 3DSTATE_HIER_DEPTH_BUFFER) SW must first issue a pipelined depth stall (PIPE_CONTROL with Depth Stall bit set), followed by a pipelined depth cache flush (PIPE_CONTROL with Depth Flush Bit set, followed by another pipelined depth stall (PIPE_CONTROL with Depth Stall Bit set), unless SW can otherwise guarantee that the pipeline from WM onwards is already flushed (e.g., via a preceding MI_FLUSH). 3DSTATE_DEPTH_BUFFER must always be programmed along with the other Depth/Stencil state commands(i.e. 3DSTATE_CLEAR_PARAMS, 3DSTATE_STENCIL_BUFFER, or 3DSTATE_HIER_DEPTH_BUFFER). Driver must send a least one PIPE_CONTROL command with CS Stall and a post sync operation prior to the group of depth commands(3DSTATE_DEPTH_BUFFER, 3DSTATE_CLEAR_PARAMS, 3DSTATE_STENCIL_BUFFER, and 3DSTATE_HIER_DEPTH_BUFFER). The depth buffer is always Tile-Y 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 05h 3DSTATE_DEPTH_BUFFER 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 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 315 3DSTATE_DEPTH_BUFFER 1 31:29 Surface Type Project: All 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 All 4h-6h Reserved All 7h SURFTYPE_NULL Defines a null surface All Programming Notes The Surface Type of the depth buffer must be the same as the Surface Type of the render target(s) (defined in SURFACE_STATE), unless either the depth buffer or render targets are SURFTYPE_NULL 28 Depth Write Enable Project: All Format: Enable This field enables depth writes to the depth buffer surface. Both this field and the Depth Buffer Write Enable field in DEPTH_STENCIL_STATE must be enabled in order for depth writes to occur. 27 Stencil Write Enable Project: All Format: Enable This field enables stencil writes to the depth buffer or stencil buffer surface, depending on where stencil is located. Both this field and the Stencil Buffer Write Enable field in DEPTH_STENCIL_STATE must be enabled in order for stencil writes to occur. 26:23 Reserved Project: All Format: MBZ 22 Hierarchical Depth Buffer Enable Project: All Format: Enable If enabled, indicates that a hierarchical depth buffer is defined. Programming Notes If this field is enabled, the Software Tiled Rendering Mode must be NORMAL.This field must be disabled if Early Depth Test Enable is disabled. 21 Reserved Project: All Format: MBZ 20:18 Surface Format Project: All Specifies the format of the depth buffer. See Stencil Test Enable field in DEPTH_STENCIL_STATE field for restrictions on the use of some of these formats. Value Name Description Project Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 316 3DSTATE_DEPTH_BUFFER 0h Reserved Reserved All 1h D32_FLOAT D32_FLOAT All 2h Reserved Reserved All 3h D24_UNORM_X8_UINT D24_UNORM_X8_UINT All 4h Reserved Reserved All 5h D16_UNORM D16_UNORM All 6h-7h Reserved Reserved All 17:0 Surface Pitch Project: All Format: U18-1 Pitch in Bytes This field specifies the pitch of the depth buffer in (#Bytes – 1). Value Name Description [127, 3FFFFh] corresponding to [128B, 256KB] also restricted to a multiple of 128B Programming Notes The pitch specified must be a multiple of the tile pitch, in the range [128B, 128KB]. 2 31:0 Surface Base Address Project: All Format: GraphicsAddress[31:0]Depth_Buffer This field specifies the starting Dword address of the buffer in mapped Graphics Memory. Programming Notes The Depth Buffer can only be mapped to Main Memory (uncached).If the surface is tiled, the base address must conform to the Per-Surface Tiling Alignment Rules. If the buffer is linear, the surface must be 64-byte aligned. 3 31:18 Height Project: All Format: U14 Range: SURFTYPE_1D: must be zeroSURFTYPE_2D: height of surface – 1 (y/v dimension) [0,16383]SURFTYPE_3D: height of surface – 1 (y/v dimension) [0,2047]SURFTYPE_CUBE: height of surface – 1 (y/v dimension) [0, 16383] This field specifies the height of the surface. If the surface is MIP-mapped, this field contains the height of the base MIP level. Programming Notes The Height of the depth buffer must be the same as the Height of the render target(s) (defined in SURFACE_STATE), unless Surface Type is SURFTYPE_1D or SURFTYPE_2D with Depth = 0 (non- array) and LOD = 0 (non-mip mapped). 17:4 Width Project: All Format: U14-1 Range: SURFTYPE_1D: width of surface – 1 (x/u dimension) [0, 16383]SURFTYPE_2D: width of surface – 1 (x/u dimension) [0, 16383]SURFTYPE_3D: width of surface – 1 (x/u dimension) Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 317 3DSTATE_DEPTH_BUFFER [0,2047]SURFTYPE_CUBE: width of surface – 1 (x/u dimension) [0, 16383] 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. Programming Notes The Width specified by this field must be less than or equal to the surface pitch (specified in bytes via the Surface Pitch field).For cube maps, Width must be set equal to Height.The Width of the depth buffer must be the same as the Width of the render target(s) (defined in SURFACE_STATE), unless Surface Type is SURFTYPE_1D or SURFTYPE_2D with Depth = 0 (non-array) and LOD = 0 (non-mip mapped). 3:0 LOD Project: All Format: U4 in LOD units This field defines the MIP level that is currently being rendered into. Value Name [0, 14] Programming Notes The LOD of the depth buffer must be the same as the LOD of the render target(s) (defined in SURFACE_STATE) 4 31:21 Depth Project: All Format: U11-1 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. Value Name [0, 2047] SURFTYPE_1D number of array elements – 1 [0, 2047] SURFTYPE_2D number of array elements – 1 [0, 2047] SURFTYPE_3D depth of surface – 1 (r/z dimension) 0 SURFTYPE_CUBE (must be zero) Programming Notes The Depth of the depth buffer must be the same as the Depth of the render target(s) (defined in SURFACE_STATE). 20:10 Minimum Array Element Project: All Format: U11 For 1D and 2D Surfaces: This field indicates the minimum array element that can be accessed as part of this surface. The delivered array index is added to this field before being used to address the surface. For 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 Other Surfaces: Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 318 3DSTATE_DEPTH_BUFFER This field is ignored. Value Name [0, 2047] SURFTYPE_1D/2D [0, 2047] SURFTYPE_3D 9:4 Reserved Project: All Format: MBZ 3:0 Depth Buffer Object Control State Project: All Format: MEMORY_OBJECT_CONTROL_STATE Specifies the memory object control state for the depth buffer. 5 31:16 Depth Coordinate Offset Y Format: S15 in Screen Space (pixels)(3 LSBs MBZ) Range: [-8192,8191] Bits 31:30 should be a sign extension Specifies a signed pixel offset to be added to the RenderTarget Y coordinate in order to generate a DepthBuffer Y coordinate. (See Depth Coordinate in Windower). Programming Notes The 3 LSBs of both offsets must be zero to ensure correct alignmentSoftware must ensure that the resulting (sum) coordinate value is non-negative This field must be zero when rendering to field-mode (interlaced) Color Buffers (i.e., when Surface State’s VerticalLineStride==1). This field can only be nonzero when rendering to surfaces of type SURFTYPE_1D and SURFTYPE_2D with Depth = 0 (non-array) and LOD = 0 (non-mip mapped). The offsets need to be aligned to the hashing mode set for WM in the GT_MODE register (0x7008) bits[12:10]. For eg if the hashing mode is set to 16x16, the Depth Coordinate Y offset needs to be aligned to the 16x16 pixel block. 15:0 Depth Coordinate Offset X Format: S15 in Screen Space (pixels)(3 LSBs MBZ) Range: [-8192,8191] Bits 15:14 should be a sign extension Specifies a signed pixel offset to be added to the RenderTarget X coordinate in order to generate a DepthBuffer X coordinate. (See Depth Coordinate in Windower). Programming Notes The 3 LSBs of both offsets must be zero to ensure correct alignmentSoftware must ensure that the resulting (sum) coordinate value is non-negative. This field must be zero when rendering to field-mode (interlaced) Color Buffers (i.e., when Surface State’s VerticalLineStride==1). This field can only be nonzero when rendering to surfaces of type SURFTYPE_1D and Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 319 3DSTATE_DEPTH_BUFFER SURFTYPE_2D with Depth = 0 (non-array) and LOD = 0 (non-mip mapped). The offsets need to be aligned to the hashing mode set for WM in the GT_MODE register (0x7008) bits[12:10]. For eg if the hashing mode is set to 16x16, the Depth Coordinate X offset needs to be aligned to the 16x16 pixel block. 6 31:21 Render Target View Extent Project: All Format: U11 Range: SURFTYPE_1D/2D: same value as Depth field Range: SURFTYPE_3D: [0, 2047] to indicate extent of [1, 2048] For 3D Surfaces: This field indicates the extent of the accessible ‘R’ coordinates minus 1 on the LOD currently being rendered to. For 1D and 2D Surfaces: This field must be set to the same value as the Depth field. For Other Surfaces: This field is ignored. 20:0 Reserved Project: All Format: MBZ 11.5.5.2 3DSTATE_STENCIL_BUFFER 3DSTATE_STENCIL_BUFFER Source: RenderCS Length Bias: 2 This command sets the surface state of the separate stencil buffer, delivered as a pipelined state command. However, the state change pipelining isn’t completely transparent (see restriction below). Programming Notes Project Restriction: Prior to changing Depth/Stencil Buffer state (i.e., any combination of 3DSTATE_DEPTH_BUFFER, 3DSTATE_CLEAR_PARAMS, 3DSTATE_STENCIL_BUFFER, 3DSTATE_HIER_DEPTH_BUFFER) SW must first issue a pipelined depth stall (PIPE_CONTROL with Depth Stall bit set, followed by a pipelined depth cache flush (PIPE_CONTROL with Depth Flush Bit set, followed by another pipelined depth stall (PIPE_CONTROL with Depth Stall Bit set), unless SW can otherwise guarantee that the pipeline from WM onwards is already flushed (e.g., via a preceding MI_FLUSH). 3DSTATE_STENCIL_BUFFER must always be programmed in the along with the other Depth/Stencil state commands(i.e. 3DSTATE_DEPTH_BUFFER, 3DSTATE_CLEAR_PARAMS, or 3DSTATE_HIER_DEPTH_BUFFER) Driver must send a least one PIPE_CONTROL command with CS Stall and a post sync operation prior to the group of depth commands(3DSTATE_DEPTH_BUFFER, 3DSTATE_CLEAR_PARAMS, 3DSTATE_STENCIL_BUFFER, and 3DSTATE_HIER_DEPTH_BUFFER). The stencil buffer is always Tile-Y DWord Bit Description 0 31:29 Command Type Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 320 3DSTATE_STENCIL_BUFFER Default Value: 3h GFXPIPE Format: OpCode 28:27 Command SubType Default Value: 3h GFXPIPE_3D Format: OpCode 26:24 3D Command Opcode Default Value: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 06h 3DSTATE_STENCIL_BUFFER Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 Dword Length Project: All Format: =n Total Length – 2 Value Name Project 1h Excludes Dword (0,1) [Default] 1 31 Reserved Format: MBZ 30:29 Reserved Project: All Format: MBZ 28:25 Stencil Buffer Object Control State Format: MEMORY_OBJECT_CONTROL_STATE Description Project Specifies the memory object control state for the stencil buffer. Stencil Buffer Object Control State [3:0] This field is not context save and restored by hardware. If this field is programmed to any value other than zero, it must be programmed after the following commands or events:  MI_SET_CONTEXT  MI_WAIT_FOR_EVENT (Specifically waits on vblank or display flip)  Render engine goes IDLE due to head point equal to tail pointer 24:22 Reserved Format: MBZ 21:17 Reserved Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 321 3DSTATE_STENCIL_BUFFER Project: All Format: MBZ 16:0 Surface Pitch Project: All Format: U17-1 Pitch in Bytes This field specifies the pitch of the stencil buffer in (#Bytes – 1). Value Name Description [127, 3FFFFh] corresponding to [128B, 128KB]also restricted to a multiple of 128B Programming Notes Since this surface is tiled, the pitch specified must be a multiple of the tile pitch, in the range [128B, 128KB]. 2 31:0 Surface Base Address_low Project: All Format: GraphicsAddress[31:0]Stencil_Buffer This field specifies the starting Dword address of the buffer in mapped Graphics Memory. Programming Notes The Stencil Buffer can only be mapped to Main Memory (uncached). Since this surface is tiled, the base address must conform to the Per-Surface Tiling Alignment Rules. 11.5.5.3 3DSTATE_HIER_DEPTH_BUFFER 3DSTATE_HIER_DEPTH_BUFFER Source: RenderCS Length Bias: 2 This command sets the surface state of the hierarchical depth buffer, delivered as a pipelined state command. However, the state change pipelining isn’t completely transparent (see restriction below). Programming Notes Project Restriction: Prior to changing Depth/Stencil Buffer state (i.e., any combination of 3DSTATE_DEPTH_BUFFER, 3DSTATE_CLEAR_PARAMS, 3DSTATE_STENCIL_BUFFER, 3DSTATE_HIER_DEPTH_BUFFER) SW must first issue a pipelined depth stall (PIPE_CONTROL with Depth Stall bit set, followed by a pipelined depth cache flush (PIPE_CONTROL with Depth Flush Bit set, followed by another pipelined depth stall (PIPE_CONTROL with Depth Stall Bit set), unless SW can otherwise guarantee that the pipeline from WM onwards is already flushed (e.g., via a preceding MI_FLUSH). 3DSTATE_HIER_DEPTH_BUFFER must always be programmed in the along with the other Depth/Stencil state commands(i.e. 3DSTATE_DEPTH_BUFFER, 3DSTATE_CLEAR_PARAMS, or 3DSTATE_STENCIL_BUFFER) Driver must send a least one PIPE_CONTROL command with CS Stall and a post sync operation prior to the group of depth commands(3DSTATE_DEPTH_BUFFER, 3DSTATE_CLEAR_PARAMS, 3DSTATE_STENCIL_BUFFER, and 3DSTATE_HIER_DEPTH_BUFFER). DWord Bit Description 0 31:29 Command Type Default Value: 3h GFXPIPE Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 322 3DSTATE_HIER_DEPTH_BUFFER Format: OpCode 28:27 Command SubType Default Value: 3h GFXPIPE_3D Format: OpCode 26:24 3D Command Opcode Default Value: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Default Value: 07h 3DSTATE_HIER_DEPTH_BUFFER Format: OpCode 15:8 Reserved Project: All Format: MBZ 7:0 Dword Length Project: All Format: =n Total Length – 2 Value Name Project 1h Excludes Dword (0,1) [Default] 1 31:29 Reserved Format: MBZ 28:25 Hierarchical Depth Buffer Object Control State Format: MEMORY_OBJECT_CONTROL_STATE Description Project Specifies the memory object control state for the hierarchical depth buffer. This field is not context save and restored by hardware. If this field is programmed to any value other than zero, it must be programmed after the following commands or events:  MI_SET_CONTEXT  MI_WAIT_FOR_EVENT (Specifically waits on vblank or display flip)  Render engine goes IDLE due to head point equal to tail pointer 24:17 Reserved Project: All Format: MBZ 16:0 Surface Pitch Project: All Format: U17-1 Pitch in Bytes This field specifies the pitch of the hierarchical depth buffer in (#Bytes – 1). Value Name Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 323 3DSTATE_HIER_DEPTH_BUFFER [127, 3FFFFh] corresponding to [128B, 128KB] also restricted to a multiple of 128B Programming Notes Since this surface is tiled, the pitch specified must be a multiple of the tile pitch, in the range [128B, 128KB]. 2 31:0 Surface Base Address [31:0] Project: All Format: GraphicsAddress[31:0]HierarchicalDepthBuffer This field specifies the starting Dword address of the buffer in mapped Graphics Memory. Programming Notes The Hierarchical Depth Buffer can only be mapped to Main Memory (uncached). Since this surface is tiled, the base address must conform to the Per-Surface Tiling Alignment Rules. 11.5.5.4 3DSTATE_CLEAR_PARAMS 3DSTATE_CLEAR_PARAMS Source: RenderCS Length Bias: 2 This command defines the depth clear value delivered as a pipelined state command. However, the state change pipelining isn’t completely transparent (see restriction below). Programming Notes Project Restriction: Prior to changing Depth/Stencil Buffer state (i.e., any combination of 3DSTATE_DEPTH_BUFFER, 3DSTATE_CLEAR_PARAMS, 3DSTATE_STENCIL_BUFFER, 3DSTATE_HIER_DEPTH_BUFFER) SW must first issue a pipelined depth stall (PIPE_CONTROL with Depth Stall bit set), followed by a pipelined depth cache flush (PIPE_CONTROL with Depth Flush Bit set, followed by another pipelined depth stall (PIPE_CONTROL with Depth Stall Bit set), unless SW can otherwise guarantee that the pipeline from WM onwards is already flushed (e.g., via a preceding MI_FLUSH). 3DSTATE_CLEAR_PARAMS must always be programmed in the along with the other Depth/Stencil state commands(i.e. 3DSTATE_DEPTH_BUFFER, 3DSTATE_STENCIL_BUFFER, or 3DSTATE_HIER_DEPTH_BUFFER) Driver must send a least one PIPE_CONTROL command with CS Stall and a post sync operation prior to the group of depth commands(3DSTATE_DEPTH_BUFFER, 3DSTATE_CLEAR_PARAMS, 3DSTATE_STENCIL_BUFFER, and 3DSTATE_HIER_DEPTH_BUFFER). 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: 0h 3DSTATE_PIPELINED Format: OpCode 23:16 3D Command Sub Opcode Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 324 3DSTATE_CLEAR_PARAMS Default Value: 04h 3DSTATE_CLEAR_PARAMS Format: OpCode 15:8 Reserved Format: MBZ 7:0 Dword Length Default Value: 1h Excludes Dword (0,1) Format: =n Total Length – 2 1 31:0 Depth Clear Value Format: for Surface Format of depth buffer:D32_FLOAT_S8X24_UINT: IEEE_FloatD32_FLOAT: IEEE_FloatD24_UNORM_S8_UINT: U24 UNORM in bits [23:0]D24_UNORM_X8_UINT: U24 UNORM in bits [23:0]D16_UNORM: U16 UNORM in bits [15:0] This field defines the clear value that will be applied to the depth buffer if the Depth Buffer Clear field is enabled. It is valid only if Depth Buffer Clear Value Valid is set. 2 31:1 Reserved Format: MBZ 0 Depth Clear Value Valid Format: Boolean This field enables the Depth Clear Value. If clear, the depth clear value is obtained from interpolated depth of an arbitrary pixel of the primitive rendered with Depth Buffer Clear set in WM_STATE or 3DSTATE_WM. If set, the depth clear value is obtained from the Depth Clear Value field of this command. 11.6 Barycentric Attribute Interpolation Given hardware clipper and setup, some of the previous flexibility in the algorithm used to interpolate attributes is no longer available Hardware uses barycentric parameters to aid in attribute interpolation, and these parameters are computed in hardware per-pixel (or per-sample) and delivered in the thread payload to the pixel shader Also delivered in the payload are a set of vertex deltas (a0, a1, and a2) per channel of each attribute. There are six different barycentric parameters that can be enabled for delivery in the pixel shader payload These are enabled via the Barycentric Interpolation Mode bits in 3DSTATE_WM. In the pixel shader kernel, the following computation is done for each attribute channel of each pixel/sample given the corresponding attribute channel a0/a1/a2 and the pixel/sample’s b1/b2 barycentric parameters, where A is the value of the attribute channel at that pixel/sample: A = a0 + (a1 * b1) + (a2 * b2) 11.7 MCS Buffer for Render Target(s) MCS buffer can be enabled for two purposes described below. MCS buffer can be controlled using two mechanisms: 1) MMIO bit Cache Mode 1 (0x2124) register bit 5 and 2) RT surface state. Following table summarizes modes of operation related to MCS buffer. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 325 Operation Cache MSC Mode Enable MMIO Bit (Surface (Please State) refer to Vol 1c) 1 (feature disable) X Normal mode of operation i.e. no MSAA compression and no color clear 0 0 Normal mode of operation i.e. no MSAA compression and no color clear 0 1 Depending on the Number of multi- samples, either MSAA compression OR color clear is enabled  MSAA Compression: Multi-sample render target is bound to the pipeline and MSAA compression feature is enabled. In this case, MCS buffer stores the information required for MSAA compression algorithm. The size and layout of the MCS buffer is based on per-pixel RT. For 4X and 8X MSAA, MCS buffer element is 8bpp and 32bpp respectively. Height, width and layout of MCS buffer in this case needs must match with Render Target height, width and layout. MCS buffer is tiledY. When MCS buffer is enabled and bound to MSRT, it is required that it is cleared prior to any rendering. A clear value can be specified optionally in the surface state of the corresponding RT. Clear pass for this case requires that scaled down primitive is sent down with upper left co-ordinate to coincide with actual rectangle being cleared. For MSAA, clear rectangle’s height and width need to as show in the following table in terms of (width,height) of the RT. Width of Clear MSAA Rect Height of Clear Rect 4X Ceil(1/8*width) Ceil(1/2*height) 8X Ceil(1/2*width) Ceil(1/2*height)  Fast Color Clear: When non multi-sample render target is bond to the pipeline and MSC buffer is enabled, MCS buffer is used as an intermediate (coarse granular) buffer per RT. Hence, MCS buffer is used to improve render target clear. When MCS is buffer is used for color clear of non- multisampler render target, the following restrictions apply.  Support is limited to tiled render targets.  Support is for non-mip-mapped and non-array surface types only.  Clear is supported only on the full RT; i.e., no partial clear or overlapping clears. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 326 The following table describes the RT alignment Pixels Lines TiledY RT CL bpp 32 8 4 64 4 4 128 2 4 TiledX RT CL bpp 32 16 2 64 8 2 128 4 2  MCS buffer for non-MSRT is supported only for RT formats 32bpp, 64bpp and 128bpp.  Clear pass must have a clear rectangle that must follow alignment rules in terms of pixels and lines as shown in the table below. Further, the clear-rectangle height and width must be multiple of the following dimensions. If the height and width of the render target being cleared do not meet these requirements, an MCS buffer can be created such that it follows the requirement and covers the RT. Pixels Lines TiledY RT bpp 32 128 128 64 64 128 128 32 128 TiledX RT bpp 32 256 64 64 128 64 128 64 64 In order to optimize the performance MCS buffer (when bound to 1X RT) clear similarly to MCS buffer clear for MSRT case, clear rect is required to be scaled by the following factors in the horizontal and vertical directions: Horizontal scale Vertical scale down factor down factor MCS CL for TiledY RCC bpp 32 64 64 64 32 64 128 16 64 MCS CL for TiledX Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 327 RCC bpp 32 128 32 64 64 32 128 32 32 Following are the SW requirements for MCS buffer clear functionality:  At the time of Render Target creation, SW needs to create clear-buffer; i.e., MCS buffer.  At the clear time, clear value for that RT must be programmed and clear enable bit must be set in the surface state of the corresponding RT.  SW must clear the RT with setting a RT clear bit set in the PS state during the clear pass as described in the following sub-section.  Since only one RT is bound with a clear pass, only one RT can be cleared at a time. In order to clear multiple RTs, multiple clear passes are required.  Before binding the “cleared” RT to texture OR honoring a CPU lock OR submitting for flip, SW must ensure a resolve pass. Such a resolve pass is described in the following sub-section. 11.8 Render Target Fast Clear Fast clear of the render target is performed by setting the Render Target Fast Clear Enable field in 3DSTATE_PS and rendering a rectangle The size of the rectangle is related to the size of the MCS. The following is required when performing a render target fast clear:  The render target(s) is/are bound as they normally would be, with the MCS surface defined in SURFACE_STATE.  A rectangle primitive of the same size as the MCS surface is delivered.  The pixel shader kernel requires no attributes, and delivers a value of 0xFFFFFFFF in all channels of the render target write message The replicated color message should be used.  Depth Test Enable, Depth Buffer Write Enable, Stencil Test Enable, Stencil Buffer Write Enable, and Alpha Test Enable must all be disabled.  After Render target fast clear, pipe-control with color cache write-flush must be issued before sending any DRAW commands on that render target. 11.9 Render Target Resolve If the MCS is enabled on a non-multisampled render target, the render target must be resolved before being used for other purposes (display, texture, CPU lock) The clear value from SURFACE_STATE is written into pixels in the render target indicated as clear in the MCS. This is done by setting the Render Target Resolve Enable field in 3DSTATE_PS and rendering a full render target sized rectangle. Once this is complete, the render target will contain the same contents as it would have had the rendering been performed with MCS surface disabled. In a typical usage model, the render target(s) need to be resolved after rendering and before using it as a source for any consecutive operation. The following is required when performing a render target resolve: Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 328  PIPE_CONTROL with end of pipe sync must be delivered.  A rectangle primitive must be scaled down by the following factors with respect to render target being resolved. Resolve rectangle scaling for TiledY RCC width scale down factor height scale down factor bpp 32 4 2 64 2 2 128 1 2 Resolve rectangle scaling for TiledX RCC bpp 32 8 1 64 4 1 128 2 1  : The pixel shader kernel requires no attributes, but must deliver a render target write message covering all pixels and all render targets desired to be resolved The color data in these messages is ignored (the replicated color message is required).  Depth Test Enable, Depth Buffer Write Enable, Stencil Test Enable, Stencil Buffer Write Enable, and Alpha Test Enable must all be disabled. Note that this render target resolve procedure is not supported on multisampled render targets. Unresolved multisampled render targets are directly supported by the sampling engine, which resolves clear values in addition to decompressing the surface This applies to both ld2dms and sample2dms messages. 11.10 Pixel Shader Thread Generation After a group of object pixels have been rasterized, the Pixel Shader function is invoked to further compute pixel color/depth information and cause results to be written to rendertargets and/or depth buffers For each pixel, the Pixel Shader calculates the values of the various vertex attributes that are to be interpolated across the object using the interpolation coefficients It then executes an API-supplied Pixel Shader Program Instructions in this program permit the accessing of texture map data, where Texture Samplers are employed to sample and filter texture maps (see the Shared Functions chapter) Arithmetic operations can be performed on the texture data, input pixel information and Pixel Shader Constants in order to compute the resultant pixel color/depth The Pixel Shader program also allows the pixel to be discarded from further processing For pixels that are not discarded, the pixel shader must send messages to update one or more render targets with the pixel results. 11.10.1 Pixel Grouping (Dispatch Size) Control The WM unit can pass a grouping of 2 subspans (8 pixels), 4 subspans (16 pixels) or 8 subspans (32 pixels) to a Pixel Shader thread Software should take into account the following considerations when determining which groupings to support/enable during operation This determination involves a tradeoff of these likely conflicting issues Note that the size of the dispatch has significant impact on the kernel program (it is certainly not transparent to the kernel) Also note that there is no implied spatial relationship between the subspans passed to a PS thread, other than the fact that they come from the same object. 1. Thread Efficiency: In general, there is some amount of overhead involved with PS thread dispatch, and if this can be amortized over a larger number of pixels, efficiency will likely Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 329 increase This is especially true for very short PS kernels, as may be used for desktop composition, etc. 2. GRF Consumption: Processing more pixels per thread will require a larger thread payload and likely more temporary register usage, both of which translate into a requirement for a larger GRF register allocation for the threads. If this increased GRF usage could lead to increased use of scratch space (for spill/fill, etc.) and possibly less efficient use of the Eus (as it would be less likely to find an EU with enough free physical GRF registers to service the thread). 3. Object Size: If the number of very small objects (e.g., covering 2 subspans or fewer) is expected to comprise a significant portion of the workload, supporting the 8-pixel dispatch mode may be advantageous Otherwise there could be a large number of 16-pixel dispatches with only 1 or 2 valid subspans, resulting in low efficiency for those threads. 4. Intangibles: Kernel footprint & Instruction Cache impact; Complexity; …. The groupings of subspans that the WM unit is allowed to include in a PS thread payload is controlled by the 32,16,8 Pixel Dispatch Enable state variables programmed in WM_STATE. Using these state variables, the WM unit will attempt to dispatch the largest allowed grouping of subspans The following table lists the possible combinations of these state variables. Please note that, the valid column in table indicates which products supports the combination dispatch. Combinations that are not listed in the table are not available on any product. A: Valid on all products B: Valid only on Not valid on if 4x PERPIXEL mode with pixel shader computed depth. D: Valid on all products, except when in non-1x PERSAMPLE mode (applies to only) . F: Valid on all products. Variable Pixel Dispatch IP for n-pixel Dispatch IP for n-pixel (KSP offsets are in Contiguous Contiguous Contiguous 128-bit instruction units) 64 Pixel 32 Pixel 32 Pixel 16 Pixel 8 Pixel Dispatch Dispatch Dispatch Dispatch Dispatch Dispatch Enable Enable Enable Enable Enable Valid n=64 n=32 n=32 n=16 n=8 0 0 0 0 1 A KSP[0] 0 0 0 1 0 F KSP[0] 0 0 0 1 1 D KSP[2] KSP[0] 0 0 1 0 0 B KSP[0] 0 0 1 1 0 E KSP[1] KSP[2] 0 0 1 1 1 D KSP[1] KSP[2] KSP[0] 0 1 0 0 0 C KSP[0] 0 1 1 0 0 C KSP[1] KSP[0] 0 1 1 1 0 D KSP[2] KSP[1] KSP[0] 1 0 0 0 0 C KSP[0] 1 0 1 0 0 C KSP[1] KSP[0] 1 0 1 1 0 D KSP[2] KSP[1] KSP[0] 1 1 0 0 0 C KSP[1] KSP[0] 1 1 1 0 0 C KSP[2] KSP[1] KSP[0] Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 330 : Each of the four KSP values is separately specified (three for ). In addition, each kernel has a separately- specified GRF register count, whereas on , all kernels share the same GRF register count field, with the one with the maximum register count required applying to all Depending on the subspan grouping selected, the WM unit will modify the starting PS Instruction Pointer (derived from the Kernel Start Pointer in WM_STATE) as a means to inform the PS kernel of the number of subspans included in the payload. The modified IP is a function of the enabled modes and the dispatch size, as shown in the table below. The driver must ensure that the PS kernel begins with a corresponding jump table to properly handle the number of subspans dispatched. The WM unit will “OR” in the two lsbs of the Kernel Pointer (bits 5:4) to create an instruction level address (note that the pointer from WM_STATE is 64 byte aligned which ierarchica to four instructions). If only one dispatch mode is enabled, the Jitter should not include any jump table entries at the beginning of the PS kernel If multiple dispatch modes are enabled, a two entry jump table should always be inserted, regardless of which modes are enabled (jump table entry for 8 pixel dispatch, followed by jump table entry for 32 pixel dispatch). Note that for a 32 pixel dispatch, the Windower will ierarch the Dispatch GRF Start Register for URB Data state by 2 to account for the extra payload data required. The Pixel Shader kernel needs to comprehend this modification for the 32 pixel kernel code. if (32PixelDispatchEnable && n>7) Dispatch 32 Pixels else if (16PixelDispatchEnable && (n>2 || !8PixelDispatchEnable)) Dispatch 16 Pixels else Dispatch 8 Pixels 11.10.1.1 Contiguous Dispatch Modes There are three cases to consider depending on which dispatch modes are enabled based on the legal combinations in the table above: Only normal dispatch modes are enabled. This is the normal operating mode in which all features are supported. Only contiguous dispatch modes are enabled. In this case, software must ensure that the fast composite restrictions are met. Both normal and contiguous dispatch modes are enabled In this case, a combination of software and the setup kernel must check all of the restrictions required by the contiguous dispatch pixel shader code The result of the check in the setup kernel is indicated in the message descriptor of the URB write message The windower then chooses a dispatch mode from either the normal category or the contiguous category depending on whether the restriction check fails or passes, respectively. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 331 If both the 32- and 64-pixel contiguous dispatch modes are enabled together, the windower will choose which one to use based on whether at least one pixel from the upper and lower 8x4 halves of the 8x8 block is active If one half has no pixel active, the half that does have pixels active will be dispatched as a 32-pixel thread. The following logic describes how the windower chooses the dispatch mode based on which modes are enabled: d32 = normal 32-pixel dispatch mode enabled d16 = normal 16-pixel dispatch mode enabled d8 = normal 8-pixel dispatch mode enabled c64 = contiguous 64-pixel dispatch mode enabled c32 = contiguous 32-pixel dispatch mode enabled ContiguousSelect = (c64 || c32) && [!(d32 || d16 || d8) || RestrictionCheckPass] For ContiguousSelect true: contiguous area available first priority second priority both superspan halves c64 c32 one superspan half c32 c64 For ContiguousSelect false: subspans available first priority second priority third priority s >= 4 d32 d16 d8 4 > s >= 2 d16 d8 d32 2 > s >= 1 d8 d16 d32 11.10.2 Multisampling Effects on Pixel Shader Dispatch The pixel shader payloads are defined in terms of subspans and pixels The slots in the pixel shader thread previously mapped 1:1 with pixels With multisampling, a slot could contain a pixel or may just contain a single sample, depending on the mode Payload definitions now refer to “slot” to make the definition independent of multisampling mode. 11.10.2.1 MSDISPMODE_PERPIXEL Thread Dispatch In PERPIXEL mode, the pixel shader kernel still works on 2/4/8 separate subspans, depending on dispatch mode. The fact that rasterization and the depth/stencil tests are being performed on a per- sample (not per-pixel) basis is transparent to the pixel shader kernel. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 332 11.10.2.2 MSDISPMODE_PERSAMPLE Thread Dispatch In PERSAMPLE mode, the pixel shader needs to operate on a sample vs. pixel basis (although this collapses in NUMSAMPLES_1 mode) Instead of processing strictly different subspans in parallel , the PS kernel processes different sample indices of one or more subspans in parallel For example, a SIMD16 dispatch in PERSAMPLE/NUMSAMPLES_4 mode would operate on a single subspan, with the usual “4 Subspan0 pixel slots” used for the “4 Sample0 locations of the (single) subspan” Subspan1 slots would be used for the Sample1 locations, and so on This layout allows the pixel shader to compute derivatives/LOD based on deltas between corresponding sample locations in the subspan in the same fashion as LEGACY pixel shader execution, and as required by DX10.1. Depending on the dispatch mode (8/16/32 pixels) and multisampling mode (1X/4X), there are different mappings of subspans/samples onto dispatches and slots-within-dispatch In some cases, more than one subspan may be included in a dispatch, while in other cases multiple dispatches are be required to process all samples for a single subspan In the latter case, the StartingSamplePairIndex value is included in the payload header so the Render Target Write message will access the correct samples with each message. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 333 PERSAMPLE SIMD16 4X Dispatch PERSAMPLE SIMD8 4X Dispatch The following table provides the complete dispatch/slot mappings for all the MS/Dispatch combinations. Dispatch Size Num Samples Slot Mapping (SSPI = Starting Sample Pair Index) SIMD32 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] 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] Slot[31:28] = Subspan[3].Pixel[3:0].Sample[1] 4X Slot[3:0] = Subspan[0].Pixel[3:0].Sample[0] Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 334 Dispatch Size Num Samples Slot Mapping (SSPI = Starting Sample Pair Index) 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] 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] SIMD16 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] 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[1].Pixel[3:0].Sample[0] Slot[15:12] = Subspan[1].Pixel[3:0].Sample[1] 8X Dispatch[i]: (i=0, 2) SSPI = i Slot[3:0] = Subspan[0].Pixel[3:0].Sample[SSPI*2+0] Slot[7:4] = Subspan[0].Pixel[3:0].Sample[SSPI*2+1] Slot[11:8] = Subspan[0].Pixel[3:0].Sample[SSPI*2+2] Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 335 Dispatch Size Num Samples Slot Mapping (SSPI = Starting Sample Pair Index) Slot[15:12] = Subspan[0].Pixel[3:0].Sample[SSPI*2+3] 16X Dispatch[i]: (i=0, 2, 4, 6) SSPI = i Slot[3:0] = Subspan[0].Pixel[3:0].Sample[SSPI*2+0] Slot[7:4] = Subspan[0].Pixel[3:0].Sample[SSPI*2+1] Slot[11:8] = Subspan[0].Pixel[3:0].Sample[SSPI*2+2] Slot[15:12] = Subspan[0].Pixel[3:0].Sample[SSPI*2+3] SIMD8 1X Slot[3:0] = Subspan[0].Pixel[3:0].Sample[0] Slot[7:4] = Subspan[1].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] 4X Dispatch[i]: (i=0..1) SSPI = i Slot[3:0] = Subspan[0].Pixel[3:0].Sample[SSPI*2+0] Slot[7:4] = Subspan[0].Pixel[3:0].Sample[SSPI*2+1] 8X Dispatch[i]: (i=0, 1, 2, 3) SSPI = i Slot[3:0] = Subspan[0].Pixel[3:0].Sample[SSPI*2+0] Slot[7:4] = Subspan[0].Pixel[3:0].Sample[SSPI*2+1] 16X Dispatch[i]: (i=0, 1, 2, 3, 4, 5, 6, 7) SSPI = i Slot[3:0] = Subspan[0].Pixel[3:0].Sample[SSPI*2+0] Slot[7:4] = Subspan[0].Pixel[3:0].Sample[SSPI*2+1] 11.10.3 PS Thread Payload for Normal Dispatch The following table lists all possible contents included in a PS thread payload, in the order they are provided Certain portions of the payload are optional, in which case the corresponding phase is skipped. This payload does not apply to the contiguous dispatch modes on The payload for these modes are documented in the section titled PS Thread Payload for Contiguous Dispatch. 11.10.3.1 PS Thread Payload for Normal Dispatch The following payload (UNRESOLVED CROSS REFERENCE, PS Thread Payload for Normal Dispatch) applies to All registers are numbered starting at 0, but many registers are skipped depending on Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 336 configuration This causes all registers below to be renumbered to fill in the skipped locations The only case where actual registers may be skipped is immediately before the constant data and again before the setup data. PS Thread Payload for Normal Dispatch Dword Bit Description R0.7 31 Reserved 30:24 23:0 Primitive Thread ID: This field contains the primitive thread count passed to the Windower from the Strips Fans Unit. Format: Reserved for HW Implementation Use. R0.6 Reserved 31:24 23:0 Thread ID: This field contains the thread count which is incremented by the Windower for every thread that is dispatched. Format: Reserved for HW Implementation Use. R0.5 31:10 Scratch Space Pointer: Specifies the 1K-byte aligned pointer to the scratch space available for this PS thread This is specified as an offset to the General State Base Address. Format = GeneralStateOffset[31:10] Reserved 9:8 7:0 FFTID: This ID is assigned by the WM unit and is a identifier for the thread It is used to free up resources used by the thread upon thread completion. Format: Reserved for HW Implementation Use. R0.4 31:5 Binding Table Pointer: Specifies the 32-byte aligned pointer to the Binding Table It is specified as an offset from the Surface State Base Address. Format = SurfaceStateOffset[31:5] Reserved 4:0 R0.3 31:5 Sampler State Pointer: Specifies the 32-byte aligned pointer to the Sampler State table It is specified as an offset from the Dynamic State Base Address. Format = DynamicStateOffset[31:5] Reserved 4 3:0 Per Thread Scratch Space: Specifies the amount of scratch space allowed to be used by this thread. 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 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 337 Dword Bit Description messages, but the Data Port will ignore it Format = U4 Range = [0,11] indicating [1k bytes, 2M bytes] in powers of two R0.2 Reserved : delivered as zeros (reserved for message header fields) 31:0 R0.1 31:6 Color Calculator State Pointer:Specifies the 64-byte aligned pointer to the Color Calculator state (COLOR_CALC_STATE structure in memory) It is specified as an offset from the Dynamic State Base Address This value is eventually passed to the ColorCalc function in the DataPort and is used to fetch the corresponding CC_STATE data. Format = DynamicStateOffset[31:5] Reserved 5:0 R0.0 Reserved 31 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,2047] SURFTYPE_2D: specifies the array index Range = [0,2047] SURFTYPE_3D: specifies the “r” coordinate Range = [0,2047] SURFTYPE_CUBE: specifies the face identifier Range = [0,5] face Render Target Array Index +x 0 -x 1 +y 2 -y 3 +z 4 -z 5 Format = U11 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 Reserved 14 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 338 Dword Bit Description 13 Source Depth to Render Target: Indicates that source depth will be sent to the render target 12 oMask to Render Target: Indicates that oMask will be sent to the render target Reserved 11:9 8 Reserved for expansion of Starting Sample Pair Index 7:6 Starting Sample Pair Index: indicates the index of the first sample pair of the dispatch Format = U2 Range = [0,3] Reserved 5 4:0 Primitive Topology Type: This field identifies the Primitive Topology Type associated with the primitive spawning this object The WM unit does not modify this value (e.g., objects within POINTLIST topologies see POINTLIST). Format: (See 3DPRIMITIVE command in 3D Pipeline) R1.7 31:16 Pixel/Sample Mask (SubSpan[3:0]) : Indicates which pixels within the four subspans are lit If 32 pixel dispatch is enabled, this field contains the pixel mask for the first four subspans. Note: This is not a duplicate of the Dispatch Mask that is delivered to the thread The dispatch mask has all pixels within a subspan as active if any of them are lit to enable LOD calculations to occur correctly. This field must not be modified by the Pixel Shader kernel. 15:0 Pixel/Sample Mask Copy (SubSpan[3:0]) : This is a duplicate copy of the pixel mask This copy can be modified as the pixel shader thread executes in order to turn off pixels based on kill instructions. R1.6 Reserved 31:0 R1.5 31:16 Y3: Y coordinate (screen space) for upper-left pixel of subspan 3 (slot 12) Format = U16 15:0 X3: X coordinate (screen space) for upper-left pixel of subspan 3 (slot 12) Format = U16 R1.4 31:16 Y2 : Y coordinate (screen space) for upper-left pixel of subspan 2 (slot 8) Format = U16 15:0 X2 : X coordinate (screen space) for upper-left pixel of subspan 2 (slot 8) Format = U16 R1.3 31:16 Y1 : Y coordinate (screen space) for upper-left pixel of subspan 1 (slot 4) Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 339 Dword Bit Description Format = U16 15:0 X1 : X coordinate (screen space) for upper-left pixel of subspan 1 (slot 4) Format = U16 R1.2 31:16 Y0 : Y coordinate (screen space) for upper-left pixel of subspan 0 (slot 0) Format = U16 15:0 X0 : X coordinate (screen space) for upper-left pixel of subspan 0 (slot 0) Format = U16 R1.1 Reserved 31:0 R1.0 Reserved 31:16 15:12 Slot 3 SampleID Format = U4 1X MSAA range: [0] 2X MSAA range [0,1] 4X MSAA range [0..3] 8X MSAA range [0..7] 16X MSAA range [0..15] 11:8 Slot 2 SampleID Format = U4 1X MSAA range: [0] 2X MSAA range [0,1] 4X MSAA range [0..3] 8X MSAA range [0..7] 16X MSAA range [0..15] 7:4 Slot 1 SampleID Format = U4 1X MSAA range: [0] 2X MSAA range [0,1] 4X MSAA range [0..3] Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 340 Dword Bit Description 8X MSAA range [0..7] 16X MSAA range [0..15] 3:0 Slot 0 SampleID Format = U4 1X MSAA range: [0] 2X MSAA range [0,1] 4X MSAA range [0..3] 8X MSAA range [0..7] 16X MSAA range [0..15] R2: delivered only if this is a 32-pixel dispatch. R2.7 31:16 Pixel/Sample Mask (SubSpan[7:4]) : Indicates which pixels within the upper four subspans are lit This field is valid only when the 32 pixel dispatch state is enabled This field must not be modified by the pixel shader thread. Note: This is not a duplicate of the dispatch mask that is delivered to the thread The dispatch mask has all pixels within a subspan as active if any of them are lit to enable LOD calculations to occur correctly. This field must not be modified by the Pixel Shader kernel. 15:0 Pixel/Sample Mask Copy (SubSpan[7:4]) : This is a duplicate copy of pixel mask for the upper 16 pixels This copy will be modified as the pixel shader thread executes to turn off pixels based on kill instructions. R2.6 Reserved 31:0 R2.5 31:16 Y7: Y coordinate (screen space) for upper-left pixel of subspan 7 (slot 28) Format = U16 15:0 X7: X coordinate (screen space) for upper-left pixel of subspan 7 (slot 28) Format = U16 R2.4 31:16 Y6 15:0 X6 R2.3 31:16 Y5 15:0 X5 R2.2 31:16 Y4 15:0 X4 R2.1 Reserved 31:0 R2.0 Reserved 31:15 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 341 Dword Bit Description 15:12 Slot 7 SampleID Format = U4 1X MSAA range: [0] 2X MSAA range [0,1] 4X MSAA range [0..3] 8X MSAA range [0..7] 16X MSAA range [0..15] 11:8 Slot 6 SampleID Format = U4 1X MSAA range: [0] 2X MSAA range [0,1] 4X MSAA range [0..3] 8X MSAA range [0..7] 16X MSAA range [0..15] 7:4 Slot 5 SampleID Format = U4 1X MSAA range: [0] 2X MSAA range [0,1] 4X MSAA range [0..3] 8X MSAA range [0..7] 16X MSAA range [0..15] 3:0 Slot 4 SampleID Format = U4 1X MSAA range: [0] 2X MSAA range [0,1] 4X MSAA range [0..3] 8X MSAA range [0..7] 16X MSAA range [0..15] Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 342 Dword Bit Description R3-R26: delivered only if the corresponding Barycentric Interpolation Mode bit is set Register phases containing Slot 8-15 data are not delivered in 8-pixel dispatch mode. R3.7 31:0 Perspective Pixel Location Barycentric[1] for Slot 7 This and the next register phase is only included if the corresponding enable bit in Barycentric Interpolation Mode is set. Format = IEEE_Float R3.6 31:0 Perspective Pixel Location Barycentric[1] for Slot 6 R3.5 31:0 Perspective Pixel Location Barycentric[1] for Slot 5 R3.4 31:0 Perspective Pixel Location Barycentric[1] for Slot 4 R3.3 31:0 Perspective Pixel Location Barycentric[1] for Slot 3 R3.2 31:0 Perspective Pixel Location Barycentric[1] for Slot 2 R3.1 31:0 Perspective Pixel Location Barycentric[1] for Slot 1 R3.0 31:0 Perspective Pixel Location Barycentric[1] for Slot 0 R4 Perspective Pixel Location Barycentric[2] for Slots 7:0 R5.7 31:0 Perspective Pixel Location Barycentric[1] for Slot 15 R5.6 31:0 Perspective Pixel Location Barycentric[1] for Slot 14 R5.5 31:0 Perspective Pixel Location Barycentric[1] for Slot 13 R5.4 31:0 Perspective Pixel Location Barycentric[1] for Slot 12 R5.3 31:0 Perspective Pixel Location Barycentric[1] for Slot 11 R5.2 31:0 Perspective Pixel Location Barycentric[1] for Slot 10 R5.1 31:0 Perspective Pixel Location Barycentric[1] for Slot 9 R5.0 31:0 Perspective Pixel Location Barycentric[1] for Slot 8 R6 Perspective Pixel Location Barycentric[2] for Slots 15:8 R7:10 Perspective Centroid Barycentric R11:14 Perspective Sample Barycentric R15:18 Linear Pixel Location Barycentric R19:22 Linear Centroid Barycentric R23:26 Linear Sample Barycentric R27: delivered only if Pixel Shader Uses Source Depth is set. R27.7 31:0 Interpolated Depth for Slot 7 Format = IEEE_Float This and the next register phase is only included if Pixel Shader Uses Source Depth (WM_STATE) is set. R27.6 31:0 Interpolated Depth for Slot 6 R27.5 31:0 Interpolated Depth for Slot 5 R27.4 31:0 Interpolated Depth for Slot 4 R27.3 31:0 Interpolated Depth for Slot 3 R27.2 31:0 Interpolated Depth for Slot 2 R27.1 31:0 Interpolated Depth for Slot 1 R27.0 31:0 Interpolated Depth for Slot 0 R28: delivered only if Pixel Shader Uses Source Depth is set and this is not an 8-pixel dispatch. R28.7 31:0 Interpolated Depth for Slot 15 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 343 Dword Bit Description R28.6 31:0 Interpolated Depth for Slot 14 R28.5 31:0 Interpolated Depth for Slot 13 R28.4 31:0 Interpolated Depth for Slot 12 R28.3 31:0 Interpolated Depth for Slot 11 R28.2 31:0 Interpolated Depth for Slot 10 R28.1 31:0 Interpolated Depth for Slot 9 R28.0 31:0 Interpolated Depth for Slot 8 R29: delivered only if Pixel Shader Uses Source W is set. R29.7 31:0 Interpolated W for Slot 7 Format = IEEE_Float This and the next register phase is only included if Pixel Shader Uses Source W (WM_STATE) is set R29.6 31:0 Interpolated W for Slot 6 R29.5 31:0 Interpolated W for Slot 5 R29.4 31:0 Interpolated W for Slot 4 R29.3 31:0 Interpolated W for Slot 3 R29.2 31:0 Interpolated W for Slot 2 R29.1 31:0 Interpolated W for Slot 1 R29.0 31:0 Interpolated W for Slot 0 R30: delivered only if Pixel Shader Uses Source W is set and this is not an 8-pixel dispatch. R30.7 31:0 Interpolated W for Slot 15 R30.6 31:0 Interpolated W for Slot 14 R30.5 31:0 Interpolated W for Slot 13 R30.4 31:0 Interpolated W for Slot 12 R30.3 31:0 Interpolated W for Slot 11 R30.2 31:0 Interpolated W for Slot 10 R30.1 31:0 Interpolated W for Slot 9 R30.0 31:0 Interpolated W for Slot 8 R31: delivered only if Position XY Offset Select is either POSOFFSET_CENTROID or POSOFFSET_SAMPLE R31.7 31:24 Position Offset Y for Slot 15 This field contains either the CENTROID or SAMPLE position offset for Y, depending on the state of Position XY Offset Select. Format = U4.4 Range = [0.0,1.0) 23:16 Position Offset X for Slot 15 This field contains either the CENTROID or SAMPLE position offset for X, depending on the state of Position XY Offset Select. Format = U4.4 Range = [0.0,1.0) Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 344 Dword Bit Description 15:8 Position Offset Y for Slot 14 7:0 Position Offset X for Slot 14 R31.6 31:24 Position Offset Y for Slot 13 23:16 Position Offset X for Slot 13 15:8 Position Offset Y for Slot 12 7:0 Position Offset X for Slot 12 R31.5:4 Position Offset X/Y for Slot[11:8] R31.3:2 Position Offset X/Y for Slot[7:4] R31.1:0 Position Offset X/Y for Slot[3:0] R32: delivered only if Pixel Shader Uses Input Coverage Mask is set. R32.7 31:0 Input Coverage Mask for Slot 7 Format = U32 This and the next register phase is only included if Pixel Shader Uses Input Coverage Mask (3DSTATE_PS) is set. R32.6 31:0 Input Coverage Mask for Slot 6 R32.5 31:0 Input Coverage Mask for Slot 5 R32.4 31:0 Input Coverage Mask for Slot 4 R32.3 31:0 Input Coverage Mask for Slot 3 R32.2 31:0 Input Coverage Mask for Slot 2 R32.1 31:0 Input Coverage Mask for Slot 1 R32.0 31:0 Input Coverage Mask for Slot 0 R33: delivered only if Pixel Shader Uses Input Coverage Mask is set and this is not an 8- pixel dispatch. R33.7 31:0 Input Coverage Mask for Slot 15 R33.6 31:0 Input Coverage Mask for Slot 14 R33.5 31:0 Input Coverage Mask for Slot 13 R33.4 31:0 Input Coverage Mask for Slot 12 R33.3 31:0 Input Coverage Mask for Slot 11 R33.2 31:0 Input Coverage Mask for Slot 10 R33.1 31:0 Input Coverage Mask for Slot 9 R33.0 31:0 Input Coverage Mask for Slot 8 R34-R57: delivered only if the corresponding Barycentric Interpolation Mode bit is set and this is a 32-pixel dispatch. R34.7 31:0 Perspective Pixel Location Barycentric[1] for Slot 23 This and the next register phase is only included if the corresponding enable bit in Barycentric Interpolation Mode is set. Format = IEEE_Float R34.6 31:0 Perspective Pixel Location Barycentric[1] for Slot 22 R34.5 31:0 Perspective Pixel Location Barycentric[1] for Slot 21 R34.4 31:0 Perspective Pixel Location Barycentric[1] for Slot 20 R34.3 31:0 Perspective Pixel Location Barycentric[1] for Slot 19 R34.2 31:0 Perspective Pixel Location Barycentric[1] for Slot 18 R34.1 31:0 Perspective Pixel Location Barycentric[1] for Slot 17 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 345 Dword Bit Description R34.0 31:0 Perspective Pixel Location Barycentric[1] for Slot 16 R35 Perspective Pixel Location Barycentric[2] for Slots 23:16 R36.7 31:0 Perspective Pixel Location Barycentric[1] for Slot 31 R36.6 31:0 Perspective Pixel Location Barycentric[1] for Slot 30 R36.5 31:0 Perspective Pixel Location Barycentric[1] for Slot 29 R36.4 31:0 Perspective Pixel Location Barycentric[1] for Slot 28 R36.3 31:0 Perspective Pixel Location Barycentric[1] for Slot 27 R36.2 31:0 Perspective Pixel Location Barycentric[1] for Slot 26 R36.1 31:0 Perspective Pixel Location Barycentric[1] for Slot 25 R36.0 31:0 Perspective Pixel Location Barycentric[1] for Slot 24 R37 Perspective Pixel Location Barycentric[2] for Slots 31:24 R38:41 Perspective Centroid Barycentric R42:45 Perspective Sample Barycentric R46:49 Linear Pixel Location Barycentric R50:53 Linear Centroid Barycentric R54:57 Linear Sample Barycentric R58-R59: delivered only if Pixel Shader Uses Source Depth is set and this is a 32-pixel dispatch. R58.7 31:0 Interpolated Depth for Slot 23 Format = IEEE_Float This and the next register phase is only included if Pixel Shader Uses Source Depth (WM_STATE) bit is set. R58.6 31:0 Interpolated Depth for Slot 22 R58.5 31:0 Interpolated Depth for Slot 21 R58.4 31:0 Interpolated Depth for Slot 20 R58.3 31:0 Interpolated Depth for Slot 19 R58.2 31:0 Interpolated Depth for Slot 18 R58.1 31:0 Interpolated Depth for Slot 17 R58.0 31:0 Interpolated Depth for Slot 16 R59.7 31:0 Interpolated Depth for Slot 31 R59.6 31:0 Interpolated Depth for Slot 30 R59.5 31:0 Interpolated Depth for Slot 29 R59.4 31:0 Interpolated Depth for Slot 28 R59.3 31:0 Interpolated Depth for Slot 27 R59.2 31:0 Interpolated Depth for Slot 26 R59.1 31:0 Interpolated Depth for Slot 25 R59.0 31:0 Interpolated Depth for Slot 24 R60-R61: delivered only if Pixel Shader Uses Source W is set and this is a 32-pixel dispatch. R60.7 31:0 Interpolated W for Slot 23 Format = IEEE_Float This and the next register phase is only included if Pixel Shader Uses Source W (WM_STATE) bit is set. R60.6 31:0 Interpolated W for Slot 22 R60.5 31:0 Interpolated W for Slot 21 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 346 Dword Bit Description R60.4 31:0 Interpolated W for Slot 20 R60.3 31:0 Interpolated W for Slot 19 R60.2 31:0 Interpolated W for Slot 18 R60.1 31:0 Interpolated W for Slot 17 R60.0 31:0 Interpolated W for Slot 16 R61.7 31:0 Interpolated W for Slot 31 R61.6 31:0 Interpolated W for Slot 30 R61.5 31:0 Interpolated W for Slot 29 R61.4 31:0 Interpolated W for Slot 28 R61.3 31:0 Interpolated W for Slot 27 R61.2 31:0 Interpolated W for Slot 26 R61.1 31:0 Interpolated W for Slot 25 R61.0 31:0 Interpolated W for Slot 24 R62: delivered only if Position XY Offset Select is either POSOFFSET_CENTROID or POSOFFSET_SAMPLE and this is a 32-pixel dispatch. R62.7 31:24 Position Offset Y for Slot 31 This field contains either the CENTROID or SAMPLE position offset for Y, depending on the state of Position XY Offset Select. Format = U4.4 Range = [0.0,1.0) 23:16 Position Offset X for Slot 31 This field contains either the CENTROID or SAMPLE position offset for X, depending on the state of Position XY Offset Select. Format = U4.4 Range = [0.0,1.0) 15:8 Position Offset Y for Slot 30 7:0 Position Offset X for Slot 30 R62.6 31:24 Position Offset Y for Slot 29 23:16 Position Offset X for Slot 29 15:8 Position Offset Y for Slot 28 7:0 Position Offset X for Slot 28 R62.5:4 Position Offset X/Y for Slot[27:24] R62.3:2 Position Offset X/Y for Slot[23:20] R62.1:0 Position Offset X/Y for Slot[19:16] R63-R64: delivered only if Pixel Shader Uses Input Coverage Mask is set and this is a 32- pixel dispatch. R63.7 31:0 Input Coverage Mask for Slot 23 Format = U32 This and the next register phase is only included if Pixel Shader Uses Input Coverage Mask (3DSTATE_PS) is set. R63.6 31:0 Input Coverage Mask for Slot 22 Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 347 Dword Bit Description R63.5 31:0 Input Coverage Mask for Slot 21 R63.4 31:0 Input Coverage Mask for Slot 20 R63.3 31:0 Input Coverage Mask for Slot 19 R63.2 31:0 Input Coverage Mask for Slot 18 R63.1 31:0 Input Coverage Mask for Slot 17 R63.0 31:0 Input Coverage Mask for Slot 16 R64.7 31:0 Input Coverage Mask for Slot 31 R64.6 31:0 Input Coverage Mask for Slot 30 R64.5 31:0 Input Coverage Mask for Slot 29 R64.4 31:0 Input Coverage Mask for Slot 28 R64.3 31:0 Input Coverage Mask for Slot 27 R64.2 31:0 Input Coverage Mask for Slot 26 R64.1 31:0 Input Coverage Mask for Slot 25 R64.0 31:0 Input Coverage Mask for Slot 24 Optional Padding before the Start of Constant/Setup Data The locations between the end of the Optional Payload Header and the location programmed via Dispatch GRF Start Register for Constant/Setup Data are considered “padding” and Reserved (see below) optional, Reserved 31:0 multiple of 8 DWs The Dispatch GRF Start Register for Constant/Setup Data state variable in 3DSTATE_WM is used to define the starting location of the constant and setup data within the PS thread payload This control is provided to allow this data to be located at a fixed location within thread payloads, regardless of the amount of data in the Optional Payload Header This permits the kernel to use direct GRF addressing to access the constant/setup data, regardless of the optional parameters being passed (as these are determined on-the-fly by the WM unit) Constant Data (optional) : Some amount of constant data (possible none) can be extracted from the push constant buffer (PCB) and passed to the thread following the R0 Header The amount of data provided is defined by the sum of the read lengths in the last 3DSTATE_CONSTANT_PS command (taking the buffer enables into account). The Constant Data arrives in a non-interleaved format. 31:0 Optional, Constant Data multiple of 8 DWs Setup Data (Attribute Vertex Deltas) Output data from the SF stage is delivered in the PS thread payload The amount of data is determined by the Number of Output Attributes field Each register contains two channels of one attribute Thus, the total number of registers sent is equal to 2 * Number of Output Attributes. Rp.7 31:0 a0[0].y – a0 vertex delta for Attribute0.y Format = IEEE_Float Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 348 Dword Bit Description Rp.6 Reserved 31:0 Rp.5 31:0 a2[0].y – a2 vertex delta for Attribute0.y Format = IEEE_Float Rp.4 31:0 a1[0].y – a1 vertex delta for Attribute0.y Format = IEEE_Float Rp.3 31:0 a0[0].x – a0 vertex delta for Attribute0.x Rp.2 Reserved 31:0 Rp.1 31:0 a2[0].x – a2 vertex delta for Attribute0.x Rp.0 31:0 a1[0].x – a1 vertex delta for Attribute0.x R(p+1).7 31:0 a0[0].w – a0 vertex delta for Attribute0.w R(p+1).6 Reserved 31:0 R(p+1).5 31:0 a2[0].w – a2 vertex delta for Attribute0.w R(p+1).4 31:0 a1[0].w – a1 vertex delta for Attribute0.w R(p+1).3 31:0 a0[0].z – a0 vertex delta for Attribute0.z R(p+1).2 Reserved 31:0 R(p+1).1 31:0 a2[0].z – a2 vertex delta for Attribute0.z R(p+1).0 31:0 a1[0].z – a1 vertex delta for Attribute0.z R(p+2):Rq Vertex deltas for additional attributes in numerical order See definition of Rp and R(p+1) for formats. 11.11 Other WM Functions 11.11.1 Statistics Gathering If Statistics Enable is set in WM_STATE or 3DSTATE_WM, the Windower increments the PS_INVOCATIONS_COUNT register once for each unmasked pixel (or sample) that is dispatched to a Pixel Shader thread. PS_INVOCATIONS_COUNT register counts all the pixels/samples present in a 2X2 dispatched to Pixel Shader. If Early Depth Test Enable is set it is possible for pixels or samples to be discarded prior to reaching the Pixel Shader due to failing the depth or stencil test PS_INVOCATIONS_COUNT will still be incremented for these pixels or samples since the depth test occurs after the pixel shader from the point of view of SW. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 349 A0 Erratum BWT004 states that there is no way to indicate a true “null” pixel shader (in the sense that the pixel shader dispatch will be skipped). The “dummy” PS thread required for a “null” pixel shader will still cause PS_INVOCATIONS_COUNT to increment on pixel dispatches; if the “null” pixel dispatches are not to be counted , Statistics Enable must be cleared when changing to a “null” pixel shader Clearing Statistics Enable may also prevent PS_DEPTH_COUNT from incrementing properly Therefore, in certain pipeline configurations, it may be impossible to maintain both PS_INVOCATIONS_COUNT and PS_DEPTH_COUNT accurately. When Early Depth Test is forced and when Statistics Enable is set, PS_INVOCATIONS_COUNT register may not have the correct value. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 350 12. 3D Pipeline – Color Calculator (Output Merger) 12.1 Overview Note:The Color Calculator logic resides in the Render Cache backing Data Port (DAP) shared function. It is described in this chapter as the Color Calc functions are naturally an extension of the 3D pipeline past the WM stage. See the DataPort chapter for details on the messages used by the Pixel Shader to invoke Color Calculator functionality. The Color Calculator (referred to as “Output Merger in the DX Spec) function within the Data Port shared function completes the processing of rasterized pixels after the pixel color and depth have been computed by the Pixel Shader. This processing is initiated when the pixel shader thread sends a Render Target Write message (see Shared Functions) to the Render Cache. (Note that a single pixel shader thread may send multiple Render Target Write messages, with the result that multiple render targets get updated). The pixel variables pass through a pipeline of fixed (yet programmable) functions, and the results are conditionally written into the appropriate buffers. The word “pixel” used in this section is effectively replaced with the word “sample” if multisample rasterization is enabled. Pipeline Stage Description Alpha Coverage It generates coverage masks using AlphaToCoverage AND/OR AlphaToOne functions based on src0.alpha. Alpha Test Compare pixel alpha with reference alpha and conditionally discard pixel Stencil Test Compare pixel stencil value with reference and forward result to Buffer Update stage Depth Test Compare pix.Z with corresponding Z value in the Depth Buffer and forward result to Buffer Update stage Color Blending Combine pixel color with corresponding color in color buffer according to programmable function Gamma Adjust pixel’s color according to gamma function for SRGB destination surfaces. Correction Color Convert “full precision” pixel color values to fixed precision of the color buffer format Quantization Logic Ops Combine pixel color logically with existing color buffer color (mutually exclusive with Color Blending) Buffer Update Write final pixel values to color and depth buffers or discard pixel without update The following logic describes the high-level operation of the Pixel Processing pipeline: PixelProcessing() { AlphaCoverage() AlphaTest() DepthBufferCoordinateOffsetDisable StencilTest() DepthTest() ColorBufferBlending() Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 351 GammaCorrection() ColorQuantization() LogicalOps() BufferUpdate() } 12.1.1 Alpha Coverage Alpha coverage logic is supported and can be controlled using three state variables:  AlphaToCoverage Enable, when enabled Color Calculator modifies the sample mask. This function (along with AlphaToOne) come at the top of the pixel pipeline. The sample’s Source0.Alpha value (possibly being replicated from the pixel’s Source0.Alpha) is used to compute a (optionally dithered) 1/2/4-bit mask (depending on NumSamples).  The AlphaToCoverage Dither Enable SV is used to control the dithering of the AlphaToCoverage mask. The bit corresponding to the sample# is then ANDed with the sample’s incoming mask bits – allowing the sample to be masked off depending on alpha.  AlphaToOne Enable, when enabled, Color Calculator must replace Source0.Alpha (if present) with 1.0f.  If AlphaToCoverage is disabled, AlphaToCoverage Dither does not have any impact. NOTE:  Src0.alpha needs to be first multiplied with AA alpha before applying AlphaToCoverage and AlphaToOne functions.  An alpha value of NaN results in a no coverage (zero) mask.  Alpha values from the pixel shader are treated as FLOAT32 format for computing the AlphaToCoverage Mask. 12.1.2 Alpha Test The Alpha Test function can be used to discard pixels based on a comparison between the incoming pixel’s alpha value and the Alpha Test Reference state variable in COLOR_CALC_STATE. This operation can be used to remove transparent or nearly-transparent pixels, though other uses for the alpha channel and alpha test are certainly possible. This function is enabled by the Alpha Test Enable state variable in COLOR_CALC_STATE. If ENABLED, this function compares the incoming pixel’s alpha value (pixColor.Alpha) and the reference alpha value specified by via the Alpha Test Reference state variable in COLOR_CALC_STATE. The comparison performed is specified by the Alpha Test Function state variable in COLOR_CALC_STATE. The Alpha Test Format state variable is used to specify whether Alpha Test is performed using fixed- point (UNORM8) or FLOAT32 values. Accordingly, it determines whether the Alpha Reference Value is passed in a UNORM8 or FLOAT32 format. If UNORM8 is selected, the pixel’s alpha value will be converted from floating-point to UNORM8 before the comparison. Pixels that pass the Alpha Test proceed for further processing. Those that fail are discarded at this point in the pipeline. If Alpha Test Enable is DISABLED, this pipeline stage has no effect. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 352 The Alpha Test function is supported in conjunction with Multiple Render Targets (MRTs). If delivered in the incoming render target write message, source 0 alpha is used to perform the alpha test. If source 0 alpha is not delivered, the normal alpha value is used to perform the alpha test. 12.1.3 Depth Coordinate Offset The Depth Coordinate Offset function applies a programmable constant offset to the RenderTarget X,Y screen space coordinates in order to generate DepthBuffer coordinates. The function has been specifically added to allow the OpenGL driver to deal with a RenderTarget and DepthBuffer of differing sizes. In contrast, OpenGL defines a lower-left screen coordinate origin. This requires the driver to incorporate a “Y coordinate flipping” transformation into the viewport mapping function. The Y extent of the RT is used in this flipping transformation. If the DepthBuffer extent is different, the wrong pixel Y locations within the DepthBuffer will be accessed. The least expensive solution is to provide a translation offset to be applied to the post-viewport-mapped DepthBuffer Y pixel coordinate, effectively allowing the alignment of the lower-left origins of the RT and DepthBuffer. [Note that the previous DBCOD feature performed an optional translation of post-viewport- mapping RT pixel (screen) coordinates to generate DepthBuffer pixel (window) coordinates. Specifically, the Draw Rect Origin X,Y state could be subtracted from the RT pixel coordinates.] This function uses Depth Coordinate Offset X,Y state (signed 16-bit values in 3DSTATE_DEPTH_RECTANGLE) that is unconditionally added to the RT pixel coordinates to generate DepthBuffer pixel coordinates. The previous DBCOB feature can be supported by having the driver program Depth Coordinate X,Y Offset to the two’s complement of the the Draw Rect Origin. By programming Depth Coordinate X,Y Offset to zeros, the current “normal” operation (DBCOD disabled) can be achieved. Programming Restrictions:  Only simple 2D RTs are supported (no mipmaps)  Software must ensure that the resultant DepthBuffer Coordinate X,Y values are non-negative.  There are alignment restrictions – see 3DSTATE_DEPTH_BUFFER command. 12.1.4 Stencil Test The Stencil Test function can be used to discard pixels based on a comparison between the [Backface] Stencil Test Reference state variable and the pixel’s stencil value. This is a general purpose function used for such effects as shadow volumes, per-pixel clipping, etc. The result of this comparison is used in the Stencil Buffer Update function later in the pipeline. This function is enabled by the Stencil Test Enable state variable. If ENABLED, the current stencil buffer value for this pixel is read. Programming Note:  If the Depth Buffer is either undefined or does not have a surface format of D32_FLOAT_S8X24_UINT or D24_UNORM_S8_UINT and separate stencil buffer is disabled, Stencil Test Enable must be DISABLED. A 2nd set of the stencil test state variables is provided so that pixels from back-facing objects, assuming they are not culled, can have a stencil test performed on them separate from the test for normal front- facing objects. The separate stencil test for back-facing objects can be enabled via the Double Sided Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 353 Stencil Enable state variable. Otherwise, non-culled back-facing objects will use the same test function, mask and reference value as front-facing objects. The 2nd stencil state for back-facing objects is most commonly used to improve the performance of rendering shadow volumes which require a different stencil buffer operation depending on whether pixels rendered are from a front-facing or back-facing object. The backface stencil state removes the requirement to render the shadow volumes in 2 passes or sort the objects into front-facing and back-facing lists. The remainder of this subsection describes the function in term of [Backface] . The Backface set of state variables are only used if Double Sided Stencil Enable is ENABLED and the object is considered back-facing. Otherwise the normal (front-facing) state variables are used. This function then compares the [Backface] Stencil Test Reference value and the pixel’s stencil value value after logically ANDing both values by [Backface] Stencil Test Mask. The comparison performed is specified by the [Backface] Stencil Test Function state variable. The result of the comparison is passed down the pipeline for use in the Stencil Buffer Update function. The Stencil Test function does not in itself discard pixels. If Stencil Test Enable is DISABLED, a result of “stencil test passed” is propagated down the pipeline. 12.1.5 Depth Test The Depth Test function can be used to discard pixels based on a comparison between the incoming pixel’s depth value and the current depth buffer value associated with the pixel. This function is typically used to perform the “Z Buffer” hidden surface removal. The result of this pipeline function is used in the Stencil Buffer Update function later in the pipeline. This function is enabled by the Depth Test Enable state variable. If enabled, the pixel’s (“source”) depth value is first computed. After computation the pixel’s depth value is clamped to the range defined by Minimum Depth and Maximum Depth in the selected CC_VIEWPORT state. Then the current (“destination”) depth buffer value for this pixel is read. This function then compares the source and destination depth values. The comparison performed is specified by the Depth Test Function state variable. The result of the comparison is propogated down the pipeline for use in the subsequent Depth Buffer Update function. The Depth Test function does not in itself discard pixels. If Depth Test Enable is DISABLED, a result of “depth test passed” is propagated down the pipeline. Programming Note:  Enabling the Depth Test function without defining a Depth Buffer is UNDEFINED. 12.1.6 Pre-Blend Color Clamping Pre-Blend Color Clamping, controlled via Pre-Blend Color Clamp Enable OR Pre-Blend Source Only Clamp Enable and Color Clamp Range states in COLOR_CALC_STATE, is affected by the enabling of Color Buffer Blend as described below. The following table summarizes the requirements involved with Pre-/Post-Blend Color Clamping. Blending RT Format Pre-Blend Color Clamp Post-Blend Color Clamp Off UNORM, Must be enabled with range = RT n/a, state ignored UNORM_SRGB,YCRCB range or [0,1] (same function) SNORM Must be enabled with range = RT n/a, state ignored range or [-1,1] (same function) FLOAT (except for Must be enabled (with any desired n/a, state ignored Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 354 Blending RT Format Pre-Blend Color Clamp Post-Blend Color Clamp R11G11B10_FLOAT) range) R11G11B10_FLOAT Must be enabled with either [0,1] n/a, state ignored or RT range UINT, SINT State ignored, implied clamp to n/a, state ignored RT range UNORM, UNORM_SRGB Must be enabled with range = RT Must be enabled with range = RT On range or [0,1] (same function) range or [0,1] (same function) (where permitted) SNORM Must be enabled with range = RT Must be enabled with range = RT range or [-1,1] (same function) range or [-1,1] (same function) FLOAT (except for Can be disabled or enabled (with Must be enabled (with any desired R11G11B10_FLOAT) any desired range) range) R11G11B10_FLOAT Can be disabled or enabled (with Must be enabled with either [0,1] any desired range) or RT range 12.1.6.1 Pre-Blend Color Clamping when Blending is Disabled The clamping of source color components is controlled by Pre-Blend Color Clamp Enable. If ENABLED, all source color components are clamped to the range specified by Color Clamp Range. If DISABLED, no clamping is performed. Programming Notes:  Given the possibility of writing UNPREDICTABLE values to the Color Buffer, it is expected and highly recommended that, when blending is disabled, software set Pre-Blend Color Clamp Enable to ENABLED and select an appropriate Color Clamp Range.  When using SINT or UINT rendertarget surface formats, Blending must be DISABLED. The Pre- Blend Color Clamp Enable and Color Clamp Range fields are ignored, and an implied clamp to the rendertarget surface format is performed. 12.1.6.2 Pre-Blend Color Clamping when Blending is Enabled The clamping of source, destination and constant color components is controlled by Pre-Blend Color Clamp Enable. If ENABLED, all these color components are clamped to the range specified by Color Clamp Range. If DISABLED, no clamping is performed on these color components prior to blending. 12.1.7 Color Buffer Blending The Color Buffer Blending function is used to combine one or two incoming “source” pixel color+alpha values with the “destination” color+alpha read from the corresponding location in a RenderTarget. Blending is enabled on a global basis by the Color Buffer Blend Enable state variable (in COLOR_CALC_STATE). If DISABLED, Blending and Post-Blend Clamp functions are disabled for all RenderTargets, and the pixel values (possibly subject to Pre-Blend Clamp) are passed through unchanged. . The Color Buffer Blend Enable is in the per-render-target BLEND_STATE, and the field in SURFACE_STATE is no longer supported. Programming Notes: Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 355  Color Buffer Blending and Logic Ops must not be enabled simultaneously, or behavior is UNDEFINED.  Dual source blending:  Only certain surface formats support Color Buffer Blending. Refer to the Surface Format tables in Sampling Engine. Blending must be disabled on a RenderTarget if blending is not supported. The incoming “source” pixel values are modulated by a selected “source” blend factor, and the possibly gamma-decorrected “destination” values are modulated by a “destination” blend factor. These terms are then combined with a “blend function”. In general: src_term = src_blend_factor * src_color dst_term = dst_blend_factor * dst_color color output = blend_function( src_term, dst_term) If there is no alpha value contained in the Color Buffer, a default value of 1.0 is used and, correspondingly, there is no alpha component computed by this function. Dual Source Blending: When using “Dual Source” Render Target Write messages, the Source1 pixel color+alpha passed in the message can be selected as a src/dst blend factor. See Color Buffer Blending. In single-source mode, those blend factor selections are invalid. If SRC1 is included in a src/dst blend factor and a DualSource RT Write message is not utilized, results are UNDEFINED. (This reflects the same restriction in DX APIs, where undefined results are produced if “o1” is not written by a PS – there are no default values defined). If SRC1 is not included in a src/dst blend factor, dual source blending must be disabled. The blending of the color and alpha components is controlled with two separate (color and alpha) sets of state variables. However, if the Independent Alpha Blend Enable state variable in COLOR_CALC_STATE is DISABLED, then the “color” (rather than “alpha”) set of state variables is used for both color and alpha. Note that this is the only use of the Independent Alpha Blend Enable state – it does not control whether Blending occurs, only how. Per Render Target Blend State: Blend state is selected based on Render Target Index contained in the message header, and appropriate blend state is applied to Render Target Write messages. The following table describes the color source and destination blend factors controlled by the Source [Alpha] Blend Factor and Destination [Alpha] Blend Factor state variables in COLOR_CALC_STATE. Note that the blend factors applied to the R,G,B channels are always controlled by the Source/Destination Blend Factor, while the blend factor applied to the alpha channel is controlled either by Source/Destination Blend Factor or Source/Destination Alpha Blend Factor. Color Buffer Blend Color Factors Blend Factor Applied for R,G,B,A channels (oN = output from PS to RT#N) (o1 = 2nd output from PS in Dual-Souce mode only) (rtN = destination color from RT#N) (CC = Constant Color) Blend Factor Selection BLENDFACTOR_ZERO 0.0, 0.0, 0.0, 0.0 BLENDFACTOR_ONE 1.0, 1.0, 1.0, 1.0 BLENDFACTOR_SRC_COLOR oN.r, oN.g, oN.b, oN.a BLENDFACTOR_INV_SRC_COLOR 1.0-oN.r, 1.0-oN.g, 1.0-oN.b, 1.0-oN.a BLENDFACTOR_SRC_ALPHA oN.a, oN.a, oN.a, oN.a BLENDFACTOR_INV_SRC_ALPHA 1.0-oN.a, 1.0-oN.a, 1.0-oN.a, 1.0-oN.a Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 356 Blend Factor Applied for R,G,B,A channels (oN = output from PS to RT#N) (o1 = 2nd output from PS in Dual-Souce mode only) (rtN = destination color from RT#N) (CC = Constant Color) Blend Factor Selection BLENDFACTOR_SRC1_COLOR o1.r, o1.g, o1.b, o1.a BLENDFACTOR_INV_SRC1_COLOR 1.0-o1.r, 1.0-o1.g, 1.0-o1.b, 1.0-o1.a BLENDFACTOR_SRC1_ALPHA o1.a, o1.a, o1.a, o1.a BLENDFACTOR_INV_SRC1_ALPHA 1.0-o1.a, 1.0-o1.a, 1.0-o1.a, 1.0-o1.a BLENDFACTOR_DST_COLOR rtN.r, rtN.g, rtN.b, rtN.a BLENDFACTOR_INV_DST_COLOR 1.0-rtN.r, 1.0-rtN.g, 1.0-rtN.b, 1.0-rtN.a BLENDFACTOR_DST_ALPHA rtN.a, rtN.a, rtN.a, rtN.a BLENDFACTOR_INV_DST_ALPHA 1.0-rtN.a, 1.0-rtN.a, 1.0-rtN.a, 1.0-rtN.a BLENDFACTOR_CONST_COLOR CC.r, CC.g, CC.b, CC.a BLENDFACTOR_INV_CONST_COLOR 1.0-CC.r, 1.0-CC.g, 1.0-CC.b, 1.0-CC.a BLENDFACTOR_CONST_ALPHA CC.a, CC.a, CC.a, CC.a BLENDFACTOR_INV_CONST_ALPHA 1.0-CC.a, 1.0-CC.a, 1.0-CC.a, 1.0-CC.a BLENDFACTOR_SRC_ALPHA_SATURATE f,f,f,1.0 where f = min(1.0 – rtN.a, oN.a) The following table lists the supported blending operations defined by the Color Blend Function state variable and the Alpha Blend Function state variable (when in independent alpha blend mode). Color Buffer Blend Functions Operation (for each color component) Blend Function BLENDFUNCTION_ADD SrcColor*SrcFactor + DstColor*DstFactor BLENDFUNCTION_SUBTRACT SrcColor*SrcFactor - DstColor*DstFactor BLENDFUNCTION_REVERSE_SUBTRACT DstColor*DstFactor - SrcColor*SrcFactor BLENDFUNCTION_MIN min (SrcColor*SrcFactor, DstColor*DstFactor) Programming Note: This is a superset of the OpenGL “min” function. BLENDFUNCTION_MAX max (SrcColor*SrcFactor, DstColor*DstFactor) Programming Note: This is a superset of the OpenGL “max” function. 12.1.8 Post-Blend Color Clamping (See Pre-Blend Color Clamping above for a summary table regarding clamping) Post-Blend Color clamping is available only if Blending is enabled. If Blending is enabled, the clamping of blending output color components is controlled by Post-Blend Color Clamp Enable. If ENABLED, the color components output from blending are clamped to the range specified by Color Clamp Range. If DISABLED, no clamping is performed at this point. Regardless of the setting of Post-Blend Color Clamp Enable, when Blending is enabled color components will be automatically clamped to (at least) the rendertarget surface format range at this stage of the pipeline. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 357 12.1.9 Dithering Dithering is used to give the illusion of a higher resolution when using low-bpp channels in color buffers (e.g., with 16bpp color buffer). By carefully choosing an arrangement of lower resolution colors, colors otherwise not representable can be approximated, especially when seen at a distance where the viewer’s eyes will average adjacent pixel colors. Color dithering tends to diffuse the sharp color bands seen on smooth-shaded objects. A four-bit dither value is obtained from a 4x4 Dither Constant matrix depending on the pixel’s X and Y screen coordinate. The pixel’s X and Y screen coordinates are first offset by the Dither Offset X and Dither Offset Y state variables (these offsets are used to provide window-relative dithering). Then the two LSBs of the pixel's screen X coordinate are used to address a column in the dither matrix, and the two LSBs of the pixel's screen Y coordinate are used to address a row. This way, the matrix repeats every four pixels in both directions. The value obtained is appropriately shifted to align with (what would be otherwise) truncated bits of the component being dithered. It is then added with the component and the result is truncated to the bit depth of the component given the color buffer format. Dithering Process (5-Bit Example) 12.1.10 Logic Ops The Logic Ops function is used to combine the incoming “source” pixel color/alpha values with the corresponding “destination” color/alpha contained in the ColorBuffer, using a logic function. The Logic Op function is enabled by the LogicOp Enable state variable. If DISABLED, this function is ignored and the incoming pixel values are passed through unchanged. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 358 Programming Notes:  Color Buffer Blending and Logic Ops must not be enabled simultaneously, or behavior is UNDEFINED.  Logic Ops are only supported on *_UNORM surfaces, otherwise Logic Ops must be DISABLED. The following table lists the supported logic ops. The logic op is selected using the Logic Op Function field in COLOR_CALC_STATE. Logic Ops LogicOp Function Definition (S=Source, D=Destination) LOGICOP_CLEAR all 0’s LOGICOP_NOR NOT (S OR D) LOGICOP_AND_INVERTED (NOT S) AND D LOGICOP_COPY_INVERTED NOT S LOGICOP_AND_REVERSE S AND NOT D LOGICOP_INVERT NOT D LOGICOP_XOR S XOR D LOGICOP_NAND NOT (S AND D) LOGICOP_AND S AND D LOGICOP_EQUIV NOT (S XOR D) LOGICOP_NOOP D LOGICOP_OR_INVERTED (NOT S) OR D LOGICOP_COPY S LOGICOP_OR_REVERSE S OR NOT D LOGICOP_OR S OR D LOGICOP_SET all 1’s 12.1.11 Buffer Update The Buffer Update function is responsible for updating the pixel’s Stencil, Depth and Color Buffer contents based upon the results of the Stencil and Depth Test functions. Note that Kill Pixel and/or Alpha Test functions may have already discarded the pixel by this point. 12.1.11.1 Stencil Buffer Updates If and only if stencil testing is enabled, the Stencil Buffer is updated according to the Stencil Fail Op, Stencil Pass Depth Fail Op, and Stencil Pass Depth Pass Op state (or their backface counterparts if Double Sided Stencil Enable is ENABLED and the pixel is from a back-facing object) and the results of the Stencil Test and Depth Test functions. Stencil Fail Op and Backface Stencil Fail Op specify how/if the stencil buffer is modified if the stencil test fails. Stencil Pass Depth Fail Op and Backface Stencil Pass Depth Fail Op specify how/if the stencil buffer is modified if the stencil test passes but the depth test fails. Stencil Pass Depth Pass Op and Backface Stencil Pass Depth Pass Op specify how/if the stencil buffer is modified if both the stencil and depth tests pass. The operations (on the stencil buffer) that are to be performed under one of these (mutually exclusive) conditions is summarized in the following table. Stencil Buffer Operations Stencil Operation Description STENCILOP_KEEP Do not modify the stencil buffer Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 359 Stencil Operation Description STENCILOP_ZERO Store a 0 STENCILOP_REPLACE Store the StencilTestReference reference value STENCILOP_INCRSAT Saturating increment (clamp to max value) STENCILOP_DECRSAT Saturating decrement (clamp to 0) STENCILOP_INCR Increment (possible wrap around to 0) STENCILOP_DECR Decrement (possible wrap to max value) STENCILOP_INVERT Logically invert the stencil value Any and all writes to the stencil portion of the depth buffer are enabled by the Stencil Buffer Write Enable state variable. When writes are enabled, the Stencil Buffer Write Mask and Backface Stencil Buffer Write Mask state variables provide an 8-bit mask that selects which bits of the stencil write value are modified. Masked-off bits (i.e., mask bit == 0) are left unmodified in the Stencil Buffer. Programming Notes:  The Stencil Buffer can be written even if depth buffer writes are disabled via Depth Buffer Write Enable. 12.1.11.2 Depth Buffer Updates Any and all writes to the Depth Buffer are enabled by the Depth Buffer Write Enable state variable. If there is no Depth Buffer, writes must be explicitly disabled with this state variable, or operation is UNDEFINED. If depth testing is disabled or the depth test passed, the incoming pixel’s depth value is written to the Depth Buffer. If depth testing is enabled and the depth test failed, the pixel is discarded – with no modification to the Depth or Color Buffers (though the Stencil Buffer may have been modified). 12.1.11.3 Color Gamma Correction Computed RGB (not A) channels can be gamma-corrected prior to update of the Color Buffer. This function is automatically invoked whenever the destination surface (render target) has an SRGB format (see surface formats in Sampling Engine). For these surfaces, the computed RGB values are converted from gamma=1.0 space to gamma=2.4 space by applying a ^(2.4) exponential function. 12.1.11.4 Color Buffer Updates Finally, if the pixel has not been discarded by this point, the incoming pixel color is written into the Color Buffer. The Surface Format of the color buffer indicates which channel(s) are written (e.g., R8G8_UNORM are written with the Red and Green channels only). The Color Buffer Component Write Disables from the Color Buffer’s SURFACE_STATE provide an independent write disable for each channel of the Color Buffer. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 360 12.2 Pixel Pipeline State Summary 12.2.1 COLOR_CALC_STATE COLOR_CALC_STATE Default Value: 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 This register is pointed to by a field in 3DSTATE_CC_STATE_POINTERS, and stored at a 64-byte aligned boundary. DWord Bit Description 0 31:24 Stencil Reference Value Format: U8.0 This field specifies the stencil reference value to compare against in the (front face) StencilTest function. 23:16 BackFace Stencil Reference Value Format: U8.0 This field specifies the stencil reference value to compare against in the StencilTest function. 15 Round Disable Function Disable Project: All Format: U8.0 Disables the round-disable function of the color calculator. If this bit is zero, dithering is cancelled based on the data used by blend to avoid drift. If this bit is one, this is not done. 14:1 Reserved Project: All Format: MBZ 0 Alpha Test Format Project: All This field selects the format for Alpha Reference Value and the format in which Alpha Test is performed. Value Name Description Project 0h ALPHATEST_UNORM8 UNorm8 All 1h ALPHATEST_FLOAT32 Float32 All Programming Notes Alpha-test format is independent of RT format. When PS outputs UNIT/SINT alpha-value, it will be treated as IEEE 32bit float number for the purpose of alpha-test. 1 31:0 Alpha Reference Value Project: All Exists If: Alpha Test Format == ALPHATEST_ FLOAT32 Format: IEEE_Float This field specifies the alpha reference value to compare against in the Alpha Test function. 31:0 Alpha Reference Value Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 361 COLOR_CALC_STATE Project: All Exists If: Alpha Test Format == ALPHATEST_UNORM8 Format: UNORM8 Upper 24 bits MBZ This field specifies the alpha reference value to compare against in the Alpha Test function. 2 31:0 Blend Constant Color Red Format: IEEE_Float This field specifies the Red channel of the Constant Color used in Color Buffer Blending. 3 31:0 Blend Constant Color Green Format: IEEE_Float This field specifies the Green channel of the Constant Color used in Color Buffer Blending. 4 31:0 Blend Constant Color Blue Format: IEEE_Float This field specifies the Blue channel of the Constant Color used in Color Buffer Blending. 5 31:0 Blend Constant Color Alpha Format: IEEE_Float This field specifies the Alpha channel of the Constant Color used in Color Buffer Blending. 12.2.2 DEPTH_STENCIL_STATE DEPTH_STENCIL_STATE Default Value: 0x00000000, 0x00000000, 0x00000000 The DEPTH_STENCIL_STATE is pointed to by a field in 3DSTATE_CC_STATE_POINTERS. It is stored at a 64- byte aligned boundary. DWord Bit Description 0 31 Stencil Test Enable Project: All Format: Enable Enables StencilTest function of the Pixel Processing pipeline. Programming Notes If any of the render targets are YUV format, this field must be disabled. 30:28 Stencil Test Function Project: All Format: 3D_CompareFunction This field specifies the comparison function used in the (front face) StencilTest function. Value Name Project 0h COMPAREFUNCTION_ALWAYS All 1h COMPAREFUNCTION_NEVER All 2h COMPAREFUNCTION_LESS All 3h COMPAREFUNCTION_EQUAL All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 362 DEPTH_STENCIL_STATE 4h COMPAREFUNCTION_LEQUAL All 5h COMPAREFUNCTION_GREATER All 6h COMPAREFUNCTION_NOTEQUAL All 7h COMPAREFUNCTION_GEQUAL All 27:25 Stencil Fail Op Project: All Format: 3D_StencilOperation This field specifies the operation to perform on the Stencil Buffer when the (front face) stencil test fails. Note: if all three stencil ops (Stencil Fail, Stencil Pass Depth Fail, and Stencil Pass Depth Pass) are KEEP, ZERO, or REPLACE, the stencil buffer is not read. Value Name Project 0 STENCILOP_KEEP All 1 STENCILOP_ZERO All 2 STENCILOP_REPLACE All 3 STENCILOP_INCRSAT All 4 STENCILOP_DECRSAT All 5 STENCILOP_INCR All 6 STENCILOP_DECR All 7 STENCILOP_INVERT All 24:22 Stencil Pass Depth Fail Op Project: All Format: 3D_StencilOperation see Stencil Fail Op This field specifies the operation to perform on the Stencil Buffer when the (front face) stencil test passes but the depth pass fails. 21:19 Stencil Pass Depth Pass Op Project: All Format: 3D_StencilOperation see Stencil Fail Op This field specifies the operation to perform on the Stencil Buffer when the (front face) stencil test passes and the depth pass passes (or is disabled). 18 Stencil Buffer Write Enable Project: All Format: Enable Enables writes to the Stencil Buffer. Programming Notes If this field is enabled, Stencil Test Enable must also be enabled. 17:16 Reserved Project: All Format: MBZ 15 Double Sided Stencil Enable Project: All Format: Enable Enable doubled sided stencil operations. Value Name Description Project Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 363 DEPTH_STENCIL_STATE 1 Enable Double Sided Stencil Enabled All 0 Disable Double Sided Stencil Disabled All Programming Notes Back-facing primitives have a vertex winding order opposite to the currently selected Front Winding state.Culling of primitives is not affected by the double sided stencil stateBack-facing primitives will be rendered, honoring all current device state, as though it were a front-facing primitive with no implicitly overloaded state. 14:12 BackFace Stencil Test Function Project: All Format: 3D_CompareFunction This field specifies the comparison function used in the StencilTest function. Value Name Project 0h COMPAREFUNCTION_ALWAYS All 1h COMPAREFUNCTION_NEVER All 2h COMPAREFUNCTION_LESS All 3h COMPAREFUNCTION_EQUAL All 4h COMPAREFUNCTION_LEQUAL All 5h COMPAREFUNCTION_GREATER All 6h COMPAREFUNCTION_NOTEQUAL All 7h COMPAREFUNCTION_GEQUAL All 11:9 Backface Stencil Fail Op Project: All Format: 3D_StencilOperation This field specifies the operation to perform on the Stencil Buffer when the stencil test fails. Value Name Description Project 0 STENCILOP_KEEP STENCILOP_KEEP All 1 STENCILOP_ZERO STENCILOP_ZERO All 2 STENCILOP_REPLACE STENCILOP_REPLACE All 3 STENCILOP_INCRSAT STENCILOP_INCRSAT All 4 STENCILOP_DECRSAT STENCILOP_DECRSAT All 5 STENCILOP_INCR STENCILOP_INCR All 6 STENCILOP_DECR STENCILOP_DECR All 7 STENCILOP_INVERT STENCILOP_INVERT All 8:6 Backface Stencil Pass Depth Fail Op Project: All Format: 3D_StencilOperation see Stencil Fail Op This field specifies the operation to perform on the Stencil Buffer when the stencil test passes but the depth pass fails. 5:3 Backface Stencil Pass Depth Pass Op Project: All Format: 3D_StencilOperation see Stencil Fail Op This field specifies the operation to perform on the Stencil Buffer when the stencil test passes and the Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 364 DEPTH_STENCIL_STATE depth pass passes (or is disabled). 2:0 Reserved Project: All Format: MBZ 1 31:24 Stencil Test Mask Project: All Format: U8 This field specifies a bit mask applied to stencil test values. Both the stencil reference value and value read from the stencil buffer will be logically ANDed with this mask before the stencil comparison test is performed. 23:16 Stencil Write Mask Project: All Format: U8 This field specifies a bit mask applied to stencil buffer writes. Only those stencil buffer bits corresponding to bits set in this mask will be modified. 15:8 Backface Stencil Test Mask Project: All Format: U8 This field specifies a bit mask applied to backface stencil test values. Both the stencil reference value and value read from the stencil buffer will be logically ANDed with this mask before the stencil comparison test is performed. 7:0 Backface Stencil Write Mask Project: All Format: U8 This field specifies a bit mask applied to backface stencil buffer writes. Only those stencil buffer bits corresponding to bits set in this mask will be modified. 2 31 Depth Test Enable Project: All Format: Enable Enables the DepthTest function of the Pixel Processing pipeline. Programming Notes If any of the render targets are YUV format, this field must be disabled. 30 Reserved Project: All Format: MBZ 29:27 Depth Test Function Project: All Format: 3D_DepthTestFunction Specifies the comparison function used in DepthTest function. Value Name Project 0h COMPAREFUNCTION_ALWAYS All 1h COMPAREFUNCTION_NEVER All 2h COMPAREFUNCTION_LESS All 3h COMPAREFUNCTION_EQUAL All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 365 DEPTH_STENCIL_STATE 4h COMPAREFUNCTION_LEQUAL All 5h COMPAREFUNCTION_GREATER All 6h COMPAREFUNCTION_NOTEQUAL All 7h COMPAREFUNCTION_GEQUAL All Programming Notes if the Depth Test Function is ALWAYS or NEVER, the depth buffer is not read. 26 Depth Buffer Write Enable Project: All Format: Enable Enables writes to the Depth Buffer. Programming Notes A Depth Buffer must be defined before enabling writes to it, or operation is UNDEFINED. 25:0 Reserved Project: All Format: MBZ 12.2.3 BLEND_STATE BLEND_STATE Default Value: 0x00000000, 0x00000000 The blend 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 2 DWords apart. The first element of the blend state array is aligned to a 64-byte boundary, which is pointed to by a field in 3DSTATE_CC_STATE_POINTERS. The 3-bit Render Target Index field in the Render Target Write data port message header is used to select which of the 8 elements from BLEND_STATE that is used on the current message. DWord Bit Description 0 31 Color Buffer Blend Enable Project: All Format: Enable Enables the ColorBufferBlending (nee “alpha blending”) function of the Pixel Processing Pipeline for this render target. Programming Notes Enabling LogicOp and ColorBufferBlending at the same time is UNDEFINED 30 Independent Alpha Blend Enable Project: All Format: Enable When enabled, the other fields in this instruction control the combination of the alpha components in the Color Buffer Blend stage. When disabled, the alpha components are combined in the same fashion as the color components. 29 Reserved Project: All Format: MBZ Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 366 BLEND_STATE 28:26 Alpha Blend Function Project: All Format: 3D_ColorBufferBlendFunction This field specifies the function used to combine the alpha components in the Color Buffer blend stage of the Pixel Pipeline when the IndependentAlphaBlend state is enabled. Value Name Project 0 BLENDFUNCTION_ADD All 1 BLENDFUNCTION_SUBTRACT All 2 BLENDFUNCTION_REVERSE_SUBTRACT All 3 BLENDFUNCTION_MIN All 4 BLENDFUNCTION_MAX All 5-7 Reserved All 25 Reserved Project: All Format: MBZ 24:20 Source Alpha Blend Factor Project: All Format: 3D_ColorBufferBlendFactor Controls the “source factor” in alpha Color Buffer Blending stage.Note: For the source/destination alpha blend factors, the encodings indicating “COLOR” are the same as the encodings indicating “ALPHA”, as the alpha component of the color is selected. Value Name Project 00h Reserved All 01h BLENDFACTOR_ONE All 02h BLENDFACTOR_SRC_COLOR All 03h BLENDFACTOR_SRC_ALPHA All 04h BLENDFACTOR_DST_ALPHA All 05h BLENDFACTOR_DST_COLOR All 06h BLENDFACTOR_SRC_ALPHA_SATURATE All 07h BLENDFACTOR_CONST_COLOR All 08h BLENDFACTOR_CONST_ALPHA All 09h BLENDFACTOR_SRC1_COLOR All 0Ah BLENDFACTOR_SRC1_ALPHA All 0Bh-10h Reserved All 11h BLENDFACTOR_ZERO All 12h BLENDFACTOR_INV_SRC_COLOR All 13h BLENDFACTOR_INV_SRC_ALPHA All 14h BLENDFACTOR_INV_DST_ALPHA All 15h BLENDFACTOR_INV_DST_COLOR All 16h Reserved All 17h BLENDFACTOR_INV_CONST_COLOR All 18h BLENDFACTOR_INV_CONST_ALPHA All 19h BLENDFACTOR_INV_SRC1_COLOR All 1Ah BLENDFACTOR_INV_SRC1_ALPHA All 19:15 Destination Alpha Blend Factor Project: All Format: 3D_ColorBufferBlendFactor Controls the “destination factor” in alpha Color Buffer Blending stage. Refer to Source Alpha Blend Factor for encodings. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 367 BLEND_STATE 14 Reserved Project: All Format: MBZ 13:11 Color Blend Function Project: All Format: 3D_ColorBufferBlendFunction This field specifies the function used to combine the color components in the ColorBufferBlending function of the Pixel Processing Pipeline. If Independent Alpha Blend Enable is disabled, this field will also control the blending of the alpha components in the ColorBufferBlending function. Value Name Project 0 BLENDFUNCTION_ADD All 1 BLENDFUNCTION_SUBTRACT All 2 BLENDFUNCTION_REVERSE_SUBTRACT All 3 BLENDFUNCTION_MIN All 4 BLENDFUNCTION_MAX All 10 Reserved Project: All Format: MBZ 9:5 Source Blend Factor Project: All Format: 3D_ColorBufferBlendFactor Controls the “source factor” in the ColorBufferBlending function.Refer to Source Alpha Blend Factor for encodings. 4:0 Destination Blend Factor Project: All Format: 3D_ColorBufferBlendFactor Controls the “destination factor” in the ColorBufferBlending function. Refer to Source Alpha Blend Factor for encodings. 1 31 AlphaToCoverage Enable Project: All Format: Enable If set, Source0 Alpha is converted to a temporary 1/2/4-bit coverage mask and the mask bit corresponding to the sample# ANDed with the sample mask bit. If set, sample coverage is computed based on src0 alpha value. Value of 0 disables all samples and value of 1 enables all samples for that pixel. The same coverage needs to apply to all the RTs in MRT case. Further, any value of src0 alpha between 0 and 1 monotonically increases the number of enabled pixels.The same coverage needs to be applied to all the RTs in MRT case. 30 AlphaToOne Enable Project: All Format: Enable If set, Source0 Alpha is set to 1.0f after (possibly) being used to generate the AlphaToCoverage coverage mask.The same coverage needs to be applied to all the RTs in MRT case.If Dual Source Blending is enabled, this bit must be disabled. Errata Description Project This bit must be disabled. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 368 BLEND_STATE 29 AlphaToCoverage Dither Enable Project: All Format: Enable If set, sample coverage is computed based on src0 alpha value and it modulates the sample coverage based on screen coordinates. Value of 0 disables all samples and value of 1 enables all samples for that pixel. The same coverage needs to apply to all the RTs in MRT case. Further, any value of src0 alpha between 0 and 1 monotonically increases the number of enabled pixels. The same coverage needs to be applied to all the RTs in MRT case.If AlphaToCoverage is disabled, AlphaToCoverage Dither does not have any impact. 28 Reserved Project: All Format: MBZ 27 Write Disable Alpha Project: All Format: Disable This field controls the writing of the alpha component into the Render Target. Value Name Description Project 0b Enabled Alpha component can be overwritten All 1b Disabled Writes to the color buffer will not modify Alpha. All Programming Notes For YUV surfaces, this field must be set to 0B (enabled). Errata Description Project This field should not be set to 0 if the alpha component is not present in the Render Target surface format. 26 Write Disable Red Project: All Format: Disable This field controls the writing of the red component into the Render Target. Value Name Description Project 0b Enabled Red component can be overwritten All 1b Disabled Writes to the color buffer will not modify Red. All Programming Notes For YUV surfaces, this field must be set to 0B (enabled). Errata Description Project This field should not be set to 0 if the Red component is not present in the Render Target surface format. 25 Write Disable Green Project: All Format: Disable This field controls the writing of the green component into the Render Target. Value Name Description Project Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 369 BLEND_STATE 0b Enabled Green component can be overwritten All 1b Disabled Writes to the color buffer will not modify Green. All Programming Notes For YUV surfaces, this field must be set to 0B (enabled). Errata Description Project This field should not be set to 0 if the Green component is not present in the Render Target surface format 24 Write Disable Blue Project: All Format: Disable This field controls the writing of the Blue component into the Render Target. Value Name Description Project 0b Enabled Blue component can be overwritten All 1b Disabled Writes to the color buffer will not modify Blue. All Programming Notes For YUV surfaces, this field must be set to 0B (enabled). Errata Description Project This field should not be set to 0 if the Red component is not present in the Render Target surface format 23 Reserved Project: All Format: MBZ 22 Logic Op Enable Project: All Format: Enable Enables the LogicOp function of the Pixel Processing pipeline. Programming Notes Enabling LogicOp and Color Buffer Blending at the same time is UNDEFINED 21:18 Logic Op Function Project: All Format: 3D_LogicOpFunction This field specifies the function to be performed (when enabled) in the Logic Op stage of the Pixel Processing pipeline. Note that the encoding of this field is one less than the corresponding “R2_” ROP code defined in WINGDI.H, and is a rather contorted mapping of the OpenGL LogicOp encodings. However, this field was defined such that, when the 4 bits are replicated to 8 bits, they coincide with the ROP codes used in the Blter. Note: if the Logic Op Function does not depend on “D”, the dest buffer is not read. Value Name Description Project 0h LOGICOP_CLEAR BLACK; all 0’s All 1h LOGICOP_NOR NOTMERGEPEN; NOT (S OR D) All 2h LOGICOP_AND_INVERTED MASKNOTPEN; (NOT S) AND D All 3h LOGICOP_COPY_INVERTED NOTCOPYPEN; NOT S All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 370 BLEND_STATE 4h LOGICOP_AND_REVERSE MASKPENNOT; S AND NOT D All 5h LOGICOP_INVERT NOT; NOT D All 6h LOGICOP_XOR XORPEN; S XOR D All 7h LOGICOP_NAND NOTMASKPEN; NOT (S AND D) All 8h LOGICOP_AND MASKPEN; S AND D All 9h LOGICOP_EQUIV NOTXORPEN; NOT (S XOR D) All Ah LOGICOP_NOOP NOP; D All Bh LOGICOP_OR_INVERTED MERGENOTPEN; (NOT S) OR D All Ch LOGICOP_COPY COPYPEN; S All Dh LOGICOP_OR_REVERSE MERGEPENNOT; S OR NOT D All Eh LOGICOP_OR MERGEPEN; S OR D All Fh LOGICOP_SET WHITE; all 1’s All 17 Reserved Project: All Format: MBZ 16 Alpha Test Enable Project: All Format: Enable Enables the AlphaTest function of the Pixel Processing pipeline. Programming Notes Project Alpha Test can only be enabled if Pixel Shader outputs a float alpha value. Alpha Test is applied independently on each render target by comparing that render target’s alpha value against the alpha reference value. If the alpha test fails, the corresponding pixel write will be supressed only for that render target. The depth/stencil update will occur if alpha test passes for any render target. When Alpha Test is disabled, Alpha Test Function must be COMPAREFUNCTION_ALWAYS. 15:13 Alpha Test Function Project: All Format: 3D_CompareFunction This field specifies the comparison function used in the AlphaTest function Value Name Description Project 0h COMPAREFUNCTION_ALWAYS Always pass All 1h COMPAREFUNCTION_NEVER Never pass All 2h COMPAREFUNCTION_LESS Pass if the value is less than the reference All 3h COMPAREFUNCTION_EQUAL Pass if the value is equal to the reference All 4h COMPAREFUNCTION_LEQUAL Pass if the value is less than or equal to the All reference 5h COMPAREFUNCTION_GREATER Pass if the value is greater than the reference All 6h COMPAREFUNCTION_NOTEQUAL Pass if the value is not equal to the reference All 7h COMPAREFUNCTION_GEQUAL Pass if the value is greater than or equal to the All reference 12 Color Dither Enable Project: All Format: Enable Enables dithering of colors (including any alpha component) before they are written to the Color Buffer. 11:10 X Dither Offset Project: All Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 371 BLEND_STATE Format: U2 Specifies offset to apply to pixel X coordinate LSBs when accessing dither table. 9:8 Y Dither Offset Project: All Format: U2 Specifies offset to apply to pixel Y coordinate LSBs when accessing dither table. 7:4 Reserved Project: All Format: MBZ 3:2 Color Clamp Range Project: All Specifies the clamped range used in Pre-Blend and Post-Blend Color Clamp functions if one or both of those functions are enabled. Note that this range selection is shared between those functions. This field is ignored if both of the Color Clamp Enables are disabled Value Name Description Project 0 COLORCLAMP_UNORM Clamp Range [0,1] All 1 COLORCLAMP_SNORM Clamp Range [-1,1] All 2 COLORCLAMP_RTFORMAT Clamp to the range of the RT surface format (Note: The All Alpha component is clamped to FLOAT16 for R11G11B10_FLOAT format). 3 Reserved Reserved All 1 Pre-Blend Color Clamp Enable Project: All Format: Enable This field specifies whether the source, destination and constant color channels are clamped prior to blending, regardless of whether blending is enabled.If DISABLED, no clamping is performed prior to blending.If ENABLED, all inputs to the blend function are clamped prior to the blend to the range specified by Color Clamp Range. Value Name Description Project 0 Disabled No clamping is performed prior to blending. All 1 Enabled All inputs to the blend function are clamped prior to the blend to the range All specified by Color Clamp Range. Programming Notes See table in Pre-Blending Color Clamp subsection for programming restrictions as a function of RT format. This field is ignored (treated as DISABLED) for UINT and SINT RT surface formats. Blending is not supported for those RT surface formats. The device will automatically clamp source color channels to the respective RT surface range. 0 Post-Blend Color Clamp Enable Project: All Format: Enable If blending is enabled, this field specifies whether the blending output channels are first clamped to the range specified by Color Clamp Range. Regardless of whether this clamping is enabled, the blending output channels will be clamped to the RT surface format just prior to being written. Programming Notes See table in Pre-Blending Color Clamp subsection for programming restrictions as a function of RT format. This field is ignored (treated as DISABLED) for UINT and SINT RT surface formats. Blending is Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 372 BLEND_STATE not supported for those RT surface formats. The device will automatically clamp source color channels to the respective RT surface range. Programming Note: CC Unit also receives 3DSTATE_WM_HZ_OP and 3DSTATE_PS_EXTRA. Description AlphaTestEnable Formula = BLEND_STATE::AlphaTestEnable && !3DSTATE_WM_HZ_OP::DepthBufferResolveEnable && !3DSTATE_WM_HZ_OP::DepthBufferClear && !3DSTATE_WM_HZ_OP::StencilBufferClear Description AlphaToCoverageEnable Formula = BLEND_STATE::AlphaToCoverageEnable && !3DSTATE_PS_EXTRA::PixelShaderDisableAlphaToCoverage 12.2.4 CC_VIEWPORT CC_VIEWPORT Default Value: 0x00000000, 0x00000000 The viewport 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 2 DWords apart. The first element of the viewport state array is aligned to a 32- byte boundary.The Minimum Depth field in CC_Viewport state must be be greater than or equal to zero on D16_UNORM, D24_UNORM_X8_UINT, or D24_UNORM_S8_UINT depth formats DWord Bit Description 0 31:0 Minimum Depth Project: All Format: IEEE_Float Indicates the minimum depth. The interpolated or computed depth is clamped to this value prior to the depth test. 1 31:0 Maximum Depth Project: All Format: IEEE_Float Indicates the maximum depth. The interpolated or computed depth is clamped to this value prior to the depth test. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 373 12.3 Other Pixel Pipeline Functions 12.3.1 Statistics Gathering If Statistics Enable is set in 3DSTATE_WM, the PS_DEPTH_COUNT register (see Memory Interface Registers in Volume Ia, GPU) will be incremented once for each pixel (or sample) that passes the depth, stencil and alpha tests. Note that each of these tests is treated as passing if disabled. This count is accurate regardless of whether Early Depth Test Enable is set. In order to obtain the value from this register at a deterministic place in the primitive stream without flushing the pipeline, however, the PIPE_CONTROL command must be used. See the 3D Pipeline chapter in this volume for details on PIPE_CONTROL. Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 374 Revision History Revision Number Description Revision Date 1.0 First 2012 OpenSource edition May 2012 §§ Doc Ref #: IHD-OS-V2 Pt 1 – 05 12 6/21/2012 375