Intel® OpenSource HD Graphics Programmer’s Reference Manual (PRM) Volume 1 Part 4: Graphics Core™ – Blitter Engine (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-V1 Pt 4 – 05 12 Creative Commons License You are free to Share — to copy, distribute, display, and perform the work Under the following conditions: Attribution. You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work). No Derivative Works. You may not alter, transform, or build upon this work. ® INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. A "Mission Critical Application" is any application in which failure of the Intel Product could result, directly or indirectly, in personal injury or death. SHOULD YOU PURCHASE OR USE INTEL'S PRODUCTS FOR ANY SUCH MISSION CRITICAL APPLICATION, YOU SHALL INDEMNIFY AND HOLD INTEL AND ITS SUBSIDIARIES, SUBCONTRACTORS AND AFFILIATES, AND THE DIRECTORS, OFFICERS, AND EMPLOYEES OF EACH, HARMLESS AGAINST ALL CLAIMS COSTS, DAMAGES, AND EXPENSES AND REASONABLE ATTORNEYS' FEES ARISING OUT OF, DIRECTLY OR INDIRECTLY, ANY CLAIM OF PRODUCT LIABILITY, PERSONAL INJURY, OR DEATH ARISING IN ANY WAY OUT OF SUCH MISSION CRITICAL APPLICATION, WHETHER OR NOT INTEL OR ITS SUBCONTRACTOR WAS NEGLIGENT IN THE DESIGN, MANUFACTURE, OR WARNING OF THE INTEL PRODUCT OR ANY OF ITS PARTS. Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined". Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. The information here is subject to change without notice. Do not finalize a design with this information. The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request. Implementations of the I2C bus/protocol may require licenses from various entities, including Philips Electronics N.V. and North American Philips Corporation. Intel and the Intel logo are trademarks of Intel Corporation in the U.S. and other countries. *Other names and brands may be claimed as the property of others. Copyright © 2012, Intel Corporation. All rights reserved. 2 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 Contents 1. BLT Engine ........................................................................................................................... 6 1.1 Introduction .................................................................................................................... 6 1.2 Classical BLT Engine Functional Description ................................................................. 6 1.2.1 Basic BLT Functional Considerations..................................................................... 7 1.2.2 Basic Graphics Data Considerations .................................................................... 19 1.2.3 BLT Programming Examples ............................................................................... 24 1.3 BLT Instruction Overview ............................................................................................. 29 1.4 BLT Engine State ......................................................................................................... 29 1.5 Cacheable Memory Support......................................................................................... 30 1.6 Device Cache Coherency: Render & Texture Caches ................................................. 30 1.7 BLT Engine Instructions ............................................................................................... 30 1.7.1 BLT Programming Restrictions............................................................................. 30 1.8 Fill/Move Instructions.................................................................................................... 31 1.8.1 COLOR_BLT (Fill) ................................................................................................ 31 1.8.2 SRC_COPY_BLT (Move) ..................................................................................... 32 1.9 2D (X,Y) BLT Instructions ............................................................................................. 33 1.9.1 XY_SETUP_BLT .................................................................................................. 36 1.9.2 XY_SETUP_MONO_PATTERN_SL_BLT ............................................................ 38 1.9.3 XY_SETUP_CLIP_ BLT ....................................................................................... 40 1.9.4 XY_PIXEL_BLT .................................................................................................... 41 1.9.5 XY_SCANLINES_BLT .......................................................................................... 42 1.9.6 XY_TEXT_BLT ..................................................................................................... 43 1.9.7 XY_TEXT_IMMEDIATE_BLT ............................................................................... 44 1.9.8 XY_COLOR_BLT ................................................................................................. 45 1.9.9 XY_PAT_BLT ....................................................................................................... 47 1.9.10 XY_PAT_CHROMA_BLT ..................................................................................... 48 1.9.11 XY_PAT_BLT_IMMEDIATE ................................................................................. 50 1.9.12 XY_PAT_CHROMA_BLT_IMMEDIATE ............................................................... 52 1.9.13 XY_MONO_PAT_BLT .......................................................................................... 54 1.9.14 XY_SRC_COPY_BLT .......................................................................................... 62 1.9.15 XY_SRC_COPY_CHROMA_BLT ........................................................................ 64 1.9.16 XY_MONO_SRC_COPY_BLT ............................................................................. 66 1.9.17 XY_MONO_SRC_COPY_ IMMEDIATE_BLT ...................................................... 68 1.9.18 XY_FULL_BLT ..................................................................................................... 70 1.9.19 XY_FULL_IMMEDIATE_PATTERN_BLT ............................................................. 72 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 3 1.9.20 XY_FULL_MONO_SRC_BLT .............................................................................. 74 1.9.21 XY_FULL_MONO_SRC_IMMEDIATE_PATTERN_BLT ...................................... 77 1.9.22 XY_FULL_MONO_PATTERN_BLT ..................................................................... 79 1.9.23 XY_FULL_MONO_PATTERN_MONO_SRC_BLT ............................................... 82 1.10 BLT Engine Instruction Field Definitions....................................................................... 84 1.10.1 BR00—BLT Opcode & Control ............................................................................. 85 1.10.2 BR01—Setup BLT Raster OP, Control, and Destination Offset ........................... 87 1.10.3 BR05—Setup Expansion Background Color ........................................................ 89 1.10.4 BR06—Setup Expansion Foreground Color ......................................................... 90 1.10.5 BR07— Setup Blit Color Pattern Address ............................................................ 90 1.10.6 BR09—Destination Address ................................................................................. 91 1.10.7 BR11—BLT Source Pitch (Offset) ........................................................................ 91 1.10.8 BR12—Source Address ....................................................................................... 92 1.10.9 BR13—BLT Raster OP, Control, and Destination Pitch ....................................... 92 1.10.10 BR14—Destination Width & Height .................................................................. 94 1.10.11 BR15—Color Pattern Address.......................................................................... 94 1.10.12 BR16—Pattern Expansion Background & Solid Pattern Color ......................... 95 1.10.13 BR17—Pattern Expansion Foreground Color................................................... 95 1.10.14 BR18—Source Expansion Background, and Destination Color ....................... 95 1.10.15 BR19—Source Expansion Foreground Color ................................................... 96 2. Blitter (Blt) Engine Command Streamer ........................................................................... 97 2.1 Registers for Blitter Engine ........................................................................................... 97 2.1.1 Introduction .......................................................................................................... 97 2.1.2 GAB PWR CTX STORAGE REGISTERS ............................................................ 97 2.1.3 GFX TLB In Use Virtual Address Registers. ......................................................... 98 2.1.4 GFX Pending TLB cycles information registers. ................................................. 102 2.1.5 GAB Error Reporting Register ............................................................................ 105 2.1.6 Virtual Memory Control ....................................................................................... 106 2.1.7 Mode and Misc Ctrl Registers ............................................................................ 108 2.1.8 BCS_EXCC — BCS Execute Condition Code Register ..................................... 112 2.1.9 BCS_RINGBUF—Ring Buffer Registers ............................................................ 115 2.1.10 Interrupt Control Registers ................................................................................. 122 2.1.11 Logical Context Support ..................................................................................... 127 2.1.12 Software Control Bit Definitions .......................................................................... 133 2.2 Memory Interface Commands for Blitter Engine ......................................................... 134 2.2.1 Introduction ........................................................................................................ 134 2.2.2 MI_ARB_CHECK ............................................................................................... 135 4 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 2.2.3 I_BATCH_BUFFER_END .................................................................................. 135 2.2.4 MI_BATCH_BUFFER_START ........................................................................... 136 2.2.5 MI_FLUSH_DW.................................................................................................. 137 2.2.6 MI_LOAD_REGISTER_IMM .............................................................................. 140 2.2.7 MI_NOOP ........................................................................................................... 141 2.2.8 MI_REPORT_HEAD .......................................................................................... 142 2.2.9 MI_SEMAPHORE_MBOX .................................................................................. 142 2.2.10 MI_STORE_REGISTER_MEM .......................................................................... 144 2.2.11 MI_STORE_DATA_IMM .................................................................................... 146 2.2.12 MI_STORE_DATA_INDEX ................................................................................ 147 2.2.13 MI_SUSPEND_FLUSH ...................................................................................... 149 2.2.14 MI_UPDATE_GTT.............................................................................................. 149 2.2.15 MI_USER_INTERRUPT ..................................................................................... 150 2.2.16 MI_WAIT_FOR_EVENT ..................................................................................... 151 2.2.17 MI_LOAD_REGISTER_MEM ............................................................................. 153 2.2.18 MI_DISPLAY_FLIP............................................................................................. 155 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 5 1. BLT Engine 1.1 Introduction 2D Rendering can be divided into 2 categories: classical BLTs, described here, and 3D BLTs. 3D BLTs are operations which can take advantage of the 3D drawing engine’s functionality and access patterns. Functions such as Alpha BLTs, arithmetic (bilinear) stretch BLTs, rotations, transposing pixel maps, color space conversion, and DIBs are all considered 3D BLTs and are covered in the 3D rendering section. DIBs can be thought of as an indexed texture which uses the texture palette for performing the data translation. All drawing engines have swappable context. The same hardware can be used by multiple driver threads where the current state of the hardware is saved to memory and the appropriate state is loaded from memory on thread switches. All operands for both 3D and classical BLTs can be in graphics aperture or cacheable system memory. Some operands can be immediates which are sent through the command stream. Immediate operands are: patterns, monochrome sources, DIB palettes, and DIB source operands. All non-monochrome operands which are not tiled have a stride granularity of a double-word (4 bytes). The classical BLT commands support both linear addressing and X, Y coordinates with and without clipping. All X1 and Y1 destination and clipping coordinates are inclusive, while X2 and Y2 are exclusive. Currently, only destination coordinates can be negative. The source and clipping coordinates must be positive. If clipping is disabled, but a negative destination coordinate is specified, the negative coordinate is clipped to 0. Linear address BLT commands must supply a non-zero height and width. If either height or width = 0, then no accesses occur. 1.2 Classical BLT Engine Functional Description The graphics controller provides a hardware-based BLT engine to off load the work of moving blocks of graphics data from the host CPU. Although the BLT engine is often used simply to copy a block of graphics data from the source to the destination, it also has the ability to perform more complex functions. The BLT engine is capable of receiving three different blocks of graphics data as input as shown in the figure below. The source data may exist in the frame buffer or the Graphics aperture. The pattern data always represents an 8x8 block of pixels that can be located in the frame buffer, Graphics aperture, or passed through a command packet. The pattern data must be located in linear memory. The data already residing at the destination may also be used as an input. The destination data can also be located in the frame buffer or graphics aperture. 6 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 Block Diagram and Data Paths of the BLT Engine The BLT engine may use any combination of these three different blocks of graphics data as operands, in both bit-wise logical operations to generate the actual data to be written to the destination, and in per- pixel write-masking to control the writing of data to the destination. It is intended that the BLT engine will perform these bit-wise and per-pixel operations on color graphics data that is at the same color depth that the rest of the graphics system has been set. However, if either the source or pattern data is monochrome, the BLT engine has the ability to put either block of graphics data through a process called “color expansion” that converts monochrome graphics data to color. Since the destination is often a location in the on-screen portion of the frame buffer, it is assumed that any data already at the destination will be of the appropriate color depth. 1.2.1 Basic BLT Functional Considerations 1.2.1.1 Color Depth Configuration and Color Expansion The graphics system and BLT engine can be configured for color depths of 8, 16, and 32 bits per pixel. The configuration of the BLT engine for a given color depth dictates the number of bytes of graphics data that the BLT engine will read and write for each pixel while performing a BLT operation. It is assumed that any graphics data already residing at the destination which is used as an input is already at the color depth to which the BLT engine is configured. Similarly, it is assumed that any source or pattern data used as an input has this same color depth, unless one or both is monochrome. If either the source or pattern Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 7 data is monochrome, the BLT engine performs a process called “color expansion” to convert such monochrome data to color at the color depth to which the BLT engine has been set. During “color expansion” the individual bits of monochrome source or pattern data that correspond to individual pixels are converted into 1, 2, or 4 bytes (which ever is appropriate for the color depth to which the BLT engine has been set). If a given bit of monochrome source or pattern data carries a value of 1, then the byte(s) of color data resulting from the conversion process are set to carry the value of a specified foreground color. If a given bit of monochrome source or pattern data carries a value of 0, the resulting byte(s) are set to the value of a specified background color or not written if transparency is selected. The BLT engine is set to a default configuration color depth of 8, 16, or 32 bits per pixel through BLT command packets. Whether the source and pattern data are color or monochrome must be specified using command packets. Foreground and background colors for the color expansion of both monochrome source and pattern data are also specified through the command packets. The source foreground and background colors used in the color expansion of monochrome source data are specified independently of those used for the color expansion of monochrome pattern data. 1.2.1.2 Graphics Data Size Limitations The BLT engine is capable of transferring very large quantities of graphics data. Any graphics data read from and written to the destination is permitted to represent a number of pixels that occupies up to 65,536 scan lines and up to 32,768 bytes per scan line at the destination. The maximum number of pixels that may be represented per scan line’s worth of graphics data depends on the color depth. Any source data used as an input must represent the same number of pixels as is represented by any data read from or written to the destination, and it must be organized so as to occupy the same number of scan lines and pixels per scan line. The actual number of scan lines and bytes per scan line required to accommodate data read from or written to the destination are set in the destination width & height registers or using X and Y coordinates within the command packets. These two values are essential in the programming of the BLT engine, because the engine uses these two values to determine when a given BLT operation has been completed. 1.2.1.3 Bit-Wise Operations The BLT engine can perform any one of 256 possible bit-wise operations using various combinations of the three previously described blocks of graphics data that the BLT engine can receive as input. The choice of bit-wise operation selects which of the three inputs will be used, as well as the particular logical operation to be performed on corresponding bits from each of the selected inputs. The BLT engine automatically foregoes reading any form of graphics data that has not been specified as an input by the choice of bit-wise operation. An 8-bit code written to the raster operation field of the command packets chooses the bit-wise operation. The following table lists the available bit-wise operations and their corresponding 8-bit codes. Bit-Wise Operations and 8-Bit Codes (00-3F) Value Written to Bits at Value Written to Bits at Code Destination Code Destination 00 writes all 0’s 20 D and ( P and ( notS )) 01 not( D or ( P or S ))) 21 not( S or( D xor P )) 02 D and ( not( P or S )) 22 D and ( notS ) 8 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 Value Written to Bits at Value Written to Bits at Code Destination Code Destination 03 not( P or S ) 23 not( S or ( P and ( notD ))) 04 S and ( not( D or P )) 24 ( S xor P ) and ( D xor S ) 05 not( D or P ) 25 not( P xor ( D and ( not( S and P )))) 06 not( P or ( not( D xor S ))) 26 S xor ( D or ( P and S )) 07 not( P or ( D and S )) 27 S xor ( D or ( not( P xor S ))) 08 S and ( D and ( notP )) 28 D and ( P xor S ) 09 not( P or ( D xor S )) 29 not( P xor ( S xor ( D or ( P and S )))) 0A D and ( notP ) 2A D and ( not( P and S )) 0B not( P or ( S and ( notD ))) 2B not( S xor (( S xor P ) and ( P xor D ))) 0C S and ( notP ) 2C S xor ( P and ( D or S )) 0D not( P or ( D and ( notS ))) 2D P xor ( S or ( notD )) 0E not( P or ( not( D or S ))) 2E P xor ( S or ( D xor P )) 0F notP 2F not( P and ( S or ( notD ))) 10 P and ( not( D or S )) 30 P and ( notS ) 11 not( D or S ) 31 not( S or ( D and ( notP ))) 12 not( S or ( not( D xor P ))) 32 S xor ( D or ( P or S )) 13 not( S or ( D and P )) 33 notS 14 not( D or ( not( P xor S ))) 34 S xor ( P or ( D and S )) 15 not( D or ( P and S )) 35 S xor ( P or ( not( D xor S ))) 16 P xor ( S xor (D and ( not( P and S )))) 36 S xor ( D or P ) 17 not( S xor (( S xor P ) and ( D xor S ))) 37 not( S and ( D or P )) 18 ( S xor P ) and ( P xor D ) 38 P xor ( S and ( D or P )) 19 not( S xor ( D and ( not( P and S )))) 39 S xor ( P or ( notD )) 1A P xor ( D or ( S and P )) 3A S xor ( P or ( D xor S )) 1B not( S xor ( D and ( P xor S ))) 3B not( S and ( P or ( notD ))) 1C P xor ( S or ( D and P )) 3C P xor S 1D not( D xor ( S and ( P xor D ))) 3D S xor ( P or ( not( D or S ))) 1E P xor ( D or S ) 3E S xor ( P or ( D and ( notS ))) 1F not( P and ( D or S )) 3F not( P and S ) Notes: S = Source Data P = Pattern Data D = Data Already Existing at the Destination Bit-Wise Operations and 8-bit Codes (40 - 7F) Value Written to Bits at Code Destination Code Value Written to Bits at Destination 40 P and ( S and ( notD )) 60 P and ( D xor S ) 41 not( D or ( P xor S )) 61 not( D xor ( S xor ( P or ( D and S )))) 42 ( S xor D ) and ( P xor D ) 62 D xor ( S and ( P or D )) 43 not( S xor ( P and ( not( D and S )))) 63 S xor ( D or ( notP )) 44 S and ( notD ) 64 S xor ( D and ( P or S )) 45 not( D or ( P and ( notS ))) 65 D xor ( S or ( notP )) 46 D xor ( S or ( P and D )) 66 D xor S 47 not( P xor ( S and ( D xor P ))) 67 S xor ( D or ( not( P or S ))) 48 S and ( D xor P ) 68 not( D xor ( S xor ( P or ( not( D or S Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 9 Value Written to Bits at Code Destination Code Value Written to Bits at Destination ))))) 49 not( P xor ( D xor ( S or ( P and D )))) 69 not( P xor ( D xor S )) 4A D xor ( P and ( S or D )) 6A D xor ( P and S ) 4B P xor ( D or ( notS )) 6B not( P xor ( S xor ( D and ( P or S )))) 4C S and ( not( D and P )) 6C S xor ( D and P ) 4D not( S xor (( S xor P ) or ( D xor S ))) 6D not( P xor ( D xor ( S and ( P or D )))) 4E P xor ( D or ( S xor P )) 6E S xor ( D and ( P or ( notS ))) 4F not( P and ( D or ( notS ))) 6F not( P and ( not( D xor S ))) 50 P and ( notD ) 70 P and ( not( D and S )) 51 not( D or ( S and ( notP ))) 71 not( S xor (( S xor D ) and ( P xor D ))) 52 D xor (P or ( S and D )) 72 S xor ( D or ( P xor S )) 53 not( S xor ( P and ( D xor S ))) 73 not( S and ( D or ( notP ))) 54 not( D or ( not( P or S ))) 74 D xor ( S or ( P xor D )) 55 notD 75 not( D and ( S or ( notP ))) 56 D xor ( P or S ) 76 S xor ( D or ( P and ( notS ))) 57 not( D and ( P or S )) 77 not( D and S ) 58 P xor ( D and ( S or P )) 78 P xor ( D and S ) 59 D xor ( P or ( notS )) 79 not( D xor ( S xor ( P and ( D or S )))) 5A D xor P 7A D xor ( P and ( S or ( notD ))) 5B D xor ( P or ( not( S or D ))) 7B not( S and ( not( D xor P ))) 5C D xor ( P or ( S xor D )) 7C S xor ( P and ( D or ( notS ))) 5D not( D and ( P or ( notS ))) 7D not( D and ( not( P xor S ))) 5E D xor ( P or ( S and ( notD ))) 7E ( S xor P ) or ( D xor S ) 5F not( D and P ) 7F not( D and ( P and S )) Notes: S = Source Data P = Pattern Data D = Data Already Existing at the Destination Bit-Wise Operations and 8-bit Codes (80 - BF) Value Written to Bits at Value Written to Bits at Code Destination Code Destination 80 D and ( P and S ) A0 D and P 81 not(( S xor P ) or ( D xor S )) A1 not( P xor ( D or ( S and ( notP )))) 82 D and ( not( P xor S )) A2 D and ( P or ( notS )) 83 not( S xor ( P and ( D or ( notS )))) A3 not( D xor ( P or ( S xor D ))) 84 S and ( not( D xor P )) A4 not( P xor ( D or ( not( S or P )))) 85 not( P xor ( D and ( S or ( notP )))) A5 not( P xor D ) 86 D xor ( S xor ( P and ( D or S ))) A6 D xor ( S and ( notP )) 87 not( P xor ( D and S )) A7 not( P xor ( D and ( S or P ))) 88 D and S A8 D and ( P or S ) 89 not( S xor ( D or ( P and ( notS )))) A9 not( D xor ( P or S )) 8A D and ( S or ( notP )) AA D 8B not( D xor ( S or ( P xor D ))) AB D or ( not( P or S)) 8C S and ( D or ( notP )) AC S xor (P and ( D xor S )) 8D not( S xor ( D or ( P xor S ))) AD not( D xor ( P or ( S and D ))) 8E S xor (( S xor D ) and ( P xor D )) AE D or ( S and ( notP )) 10 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 Value Written to Bits at Value Written to Bits at Code Destination Code Destination 8F not( P and ( not( D and S ))) AF D or ( notP ) 90 P and ( not( D xor S )) B0 P and ( D or ( notS )) 91 not( S xor ( D and ( P or ( notS )))) B1 not( P xor ( D or ( S xor P ))) 92 D xor ( P xor ( S and ( D or P ))) B2 S xor (( S xor P ) or ( D xor S )) 93 not( S xor ( P and D )) B3 not( S and ( not( D and P ))) 94 P xor ( S xor ( D and ( P or S ))) B4 P xor ( S and ( notD )) 95 not( D xor ( P and S )) B5 not( D xor ( P and ( S or D ))) 96 D xor ( P xor S ) B6 D xor ( P xor ( S or ( D and P ))) 97 P xor ( S xor ( D or ( not( P or S )))) B7 not( S and ( D xor P )) 98 not( S xor ( D or ( not( P or S )))) B8 P xor ( S and ( D xor P )) 99 not( D xor S ) B9 not( D xor ( S or ( P and D ))) 9A D xor ( P and ( notS )) BA D or ( P and ( notS )) 9B not( S xor ( D and ( P or S ))) BB D or ( notS ) 9C S xor ( P and ( notD )) BC S xor ( P and ( not( D and S ))) 9D not( D xor ( S and ( P or D ))) BD not(( S xor D ) and ( P xor D )) 9E D xor ( S xor ( P or ( D and S ))) BE D or ( P xor S ) 9F not( P and ( D xor S )) BF D or ( not( P and S )) Notes: S = Source Data P = Pattern Data D = Data Already Existing at the Destination Bit-Wise Operations and 8-bit Codes (C0 - FF) Code Value Written to Bits at Destination Code Value Written to Bits at Destination C0 P and S E0 P and ( D or S ) C1 not( S xor ( P or ( D and ( notS )))) E1 not( P xor ( D or S )) C2 not( S xor ( P or ( not( D or S )))) E2 D xor ( S and ( P xor D )) C3 not( P xor S ) E3 not( P xor ( S or ( D and P ))) C4 S and ( P or ( notD )) E4 S xor ( D and ( P xor S )) C5 not( S xor ( P or ( D xor S ))) E5 not( P xor ( D or ( S and P ))) C6 S xor ( D and ( notP )) E6 S xor ( D and ( not( P and S ))) C7 not( P xor ( S and ( D or P ))) E7 not(( S xor P ) and ( P xor D )) C8 S and ( D or P ) E8 S xor (( S xor P ) and ( D xor S )) C9 not( S xor ( P or D )) E9 not( D xor ( S xor ( P and ( not( D and S ))))) CA D xor ( P and ( S xor D )) EA D or ( P and S ) CB not( S xor ( P or ( D and S ))) EB D or ( not( P xor S )) CC S EC S or ( D and P ) CD S or ( not( D or P )) ED S or ( not( D xor P )) CE S or ( D and ( notP )) EE D or S CF S or ( notP ) EF S or ( D or ( notP )) D0 P and ( S or ( notD )) F0 P D1 not( P xor ( S or ( D xor P ))) F1 P or ( not( D or S )) D2 P xor ( D and ( notS )) F2 P or ( D and ( notS )) D3 not( S xor ( P and ( D or S ))) F3 P or ( notS ) D4 S xor (( S xor P ) and ( P xor D )) F4 P or ( S and ( notD )) D5 not( D and ( not( P and S ))) F5 P or ( notD ) D6 P xor ( S xor ( D or ( P and S ))) F6 P or ( D xor S ) Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 11 Code Value Written to Bits at Destination Code Value Written to Bits at Destination D7 not( D and ( P xor S )) F7 P or ( not( D and S )) D8 P xor ( D and ( S xor P )) F8 P or ( D and S ) D9 not( S xor ( D or ( P and S ))) F9 P or ( not( D xor S )) DA D xor ( P and ( not( S and D ))) FA D or P DB not(( S xor P ) and ( D xor S )) FB D or ( P or ( notS )) DC S or ( P and ( notD )) FC P or S DD S or ( notD ) FD P or ( S or ( notD )) DE S or ( D xor P ) FE D or ( P or S ) DF S or ( not( D and P )) FF writes all 1’s Notes: S = Source Data P = Pattern Data D = Data Already Existing at the Destination 1.2.1.4 Per-Pixel Write-Masking Operations The BLT engine is able to perform per-pixel write-masking with various data sources used as pixel masks to constrain which pixels at the destination are to be written to by the BLT engine. As shown in the figure below, either monochrome source or monochrome pattern data may be used as pixel masks. Color pattern data cannot be used. Another available pixel mask is derived by comparing a particular color range per color channel to either the color already specified for a given pixel at the destination or source. 12 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 Block Diagram and Data Paths of the BLT Engine The command packets can specify the monochrome source or the monochrome pattern data as a pixel mask. When this feature is used, the bits that carry a value of 0 cause the bytes of the corresponding pixel at the destination to not be written to by the BLT engine, thereby preserving whatever data was originally carried within those bytes. This feature can be used in writing characters to the display, while also preserving the pre-existing backgrounds behind those characters. When both operands are in the transparent mode, the logical AND of the 2 operands are used for the write enables per pixel. The 3-bit field, destination transparency mode, within the command packets can select per-pixel write- masking with a mask based on the results of color comparisons. The monochrome source background and foreground are range compared with either the bytes for the pixels at the destination or the source operand. This operation is described in the BLT command packet and register descriptions. 1.2.1.5 When the Source and Destination Locations Overlap It is possible to have BLT operations in which the locations of the source and destination data overlap. This frequently occurs in BLT operations where a user is shifting the position of a graphical item on the display by only a few pixels. In these situations, the BLT engine must be programmed so that destination data is not written into destination locations that overlap with source locations before the source data at those locations has been read. Otherwise, the source data will become corrupted. The XY commands determine whether there is an overlap and perform the accesses in the proper direction to avoid data corruption. Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 13 The following figure shows how the source data can be corrupted when a rectangular block is copied from a source location to an overlapping destination location. The BLT engine typically reads from the source location and writes to the destination location starting with the left-most pixel in the top-most line of both, as shown in step (a). As shown in step (b), corruption of the source data has already started with the copying of the top-most line in step (a) — part of the source that originally contained lighter-colored pixels has now been overwritten with darker-colored pixels. More source data corruption occurs as steps (b) through (d) are performed. At step (e), another line of the source data is read, but the two right-most pixels of this line are in the region where the source and destination locations overlap, and where the source has already been overwritten as a result of the copying of the top-most line in step (a). Starting in step (f), darker-colored pixels can be seen in the destination where lighter-colored pixels should be. This errant effect occurs repeatedly throughout the remaining steps in this BLT operation. As more lines are copied from the source location to the destination location, it becomes clear that the end result is not what was originally intended. 14 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 Source Corruption in BLT with Overlapping Source and Destination Locations The BLT engine can alter the order in which source data is read and destination data is written when necessary to avoid source data corruption problems when the source and destination locations overlap. The command packets provide the ability to change the point at which the BLT engine begins reading and Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 15 writing data from the upper left-hand corner (the usual starting point) to one of the other three corners. The BLT engine may be set to read data from the source and write it to the destination starting at any of the four corners of the panel. The XY command packets perform the necessary comparisons and start at the proper corner of each operand which avoids data corruption. 16 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 Correctly Performed BLT with Overlapping Source and Destination Locations The following figure illustrates how this feature of the BLT engine can be used to perform the same BLT operation as was illustrated in the figure above, while avoiding the corruption of source data. As shown in the figure below, the BLT engine reads the source data and writes the data to the destination starting with Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 17 the right-most pixel of the bottom-most line. By doing this, no pixel existing where the source and destination locations overlap will ever be written to before it is read from by the BLT engine. By the time the BLT operation has reached step (e) where two pixels existing where the source and destination locations overlap are about to be over written, the source data for those two pixels has already been read. Suggested Starting Points for Possible Source and Destination Overlap Situations The figure above shows the recommended lines and pixels to be used as starting points in each of 8 possible ways in which the source and destination locations may overlap. In general, the starting point should be within the area in which the source and destination overlap. 18 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 1.2.2 Basic Graphics Data Considerations 1.2.2.1 Contiguous vs. Discontinuous Graphics Data Graphics data stored in memory, particularly in the frame buffer of a graphics system, has organizational characteristics that often distinguish it from other varieties of data. The main distinctive feature is the tendency for graphics data to be organized in a discontinuous block of graphics data made up of multiple sub-blocks of bytes, instead of a single contiguous block of bytes. Representation of On-Screen Single 6-Pixel Line in the Frame Buffer The figure above shows an example of contiguous graphics data — a horizontal line made up of six adjacent pixels within a single scan line on a display with a resolution of 640x480. Presuming that the graphics system driving this display has been set to 8 bits per pixel and that the frame buffer’s starting address of 0h corresponds to the upper left-most pixel of this display, then the six pixels that make this horizontal line starting at coordinates (256, 256) occupies the six bytes starting at frame buffer address 28100h, and ending at address 28105h. In this case, there is only one scan line’s worth of graphics data in this single horizontal line, so the block of graphics data for all six of these pixels exists as a single, contiguous block comprised of only these six bytes. The starting address and the number of bytes are the only pieces of information that a BLT engine would require to read this block of data. The simplicity of the above example of a single horizontal line contrasts sharply to the example of discontinuous graphics data depicted in the figure below. The simple six-pixel line of the figure above is now accompanied by three more six-pixel lines placed on subsequent scan lines, resulting in the 6x4 block of pixels shown. Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 19 Representation of On-Screen 6x4 Array of Pixels in the Frame Buffer Since there are other pixels on each of the scan lines on which this 6x4 block exists that are not part of this 6x4 block, what appears to be a single 6x4 block of pixels on the display must be represented by a discontinuous block of graphics data made up of 4 separate sub-blocks of six bytes apiece in the frame buffer at addresses 28100h, 28380h, 28600h, and 28880h. This situation makes the task of reading what appears to be a simple 6x4 block of pixels more complex. However, there are two characteristics of this 6x4 block of pixels that help simplify the task of specifying the locations of all 24 bytes of this discontinuous block of graphics data: all four of the sub-blocks are of the same length, and the four sub- blocks are separated from each other at equal intervals. The BLT engine is designed to make use of these characteristics of graphics data to simplify the programming required to handle discontinuous blocks of graphics data. For such a situation, the BLT engine requires only four pieces of information: the starting address of the first sub-block, the length of a sub-block, the offset (in bytes), pitch, of the starting address of each subsequent sub-block, and the quantity of sub-blocks. 1.2.2.2 Source Data The source data may exist in the frame buffer or elsewhere in the graphics aperture where the BLT engine may read it directly, or it may be provided to the BLT engine by the host CPU through the command packets. The block of source graphics data may be either contiguous or discontinuous, and may be either in color (with a color depth that matches that to which the BLT engine has been set) or monochrome. The source select bit in the command packets specifies whether the source data exists in the frame buffer or is provided through the command packets. Monochrome source data is always specified as being supplied through an immediate command packet. 20 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 If the color source data resides within the frame buffer or elsewhere in the graphics aperture, then the Source Address Register, specified in the command packets is used to specify the address of the source. In cases where the host CPU provides the source data, it does so by writing the source data to ring buffer directly after the BLT command that requires the data or uses an IMMEDIATE_INDIRECT_BLT command packet which has a size and pointer to the operand in Graphics aperture. The block of bytes sent by the host CPU through the command packets must be quadword-aligned and the source data contained within the block of bytes must also be aligned. To accommodate discontinuous source data, the source and destination pitch registers can be used to specify the offset in bytes from the beginning of one scan line’s worth source data to the next. Otherwise, if the source data is contiguous, then an offset equal to the length of a scan line’s worth of source data should be specified. 1.2.2.3 Monochrome Source Data The opcode of the command packet specifies whether the source data is color or monochrome. Since monochrome graphics data only uses one bit per pixel, each byte of monochrome source data typically carries data for 8 pixels which hinders the use of byte-oriented parameters when specifying the location and size of valid source data. Some additional parameters must be specified to ensure the proper reading and use of monochrome source data by the BLT engine. The BLT engine also provides additional options for the manipulation of monochrome source data versus color source data. The various bit-wise logical operations and per-pixel write-masking operations were designed to work with color data. In order to use monochrome data, the BLT engine converts it into color through a process called color expansion, which takes place as a BLT operation is performed. In color expansion the single bits of monochrome source data are converted into one, two, or four bytes (depending on the color depth) of color data that are set to carry value corresponding to either the foreground or background color that have been specified for use in this conversion process. If a given bit of monochrome source data carries a value of 1, then the byte(s) of color data resulting from the conversion process will be set to carry the value of the foreground color. If a given bit of monochrome source data carries a value of 0, then the resulting byte(s) will be set to the value of the background color. The foreground and background colors used in the color expansion of monochrome source data can be set in the source expansion foreground color register and the source expansion background color register. The BLT Engine requires that the bit alignment of each scan line’s worth of monochrome source data be specified. Each scan line’s worth of monochrome source data is word aligned but can actually start on any bit boundary of the first byte. Monochrome text is special cased and it is bit or byte packed, where in bit packed there are no invalid pixels (bits) between scan lines. There is a 3 bit field which indicates the starting pixel position within the first byte for each scan line, Mono Source Start. The BLT engine also provides various clipping options for use with specific BLT commands (BLT_TEXT) with a monochrome source. Clipping is supported through: Clip rectangle Y addresses or coordinates and X coordinates along with scan line starting and ending addresses (with Y addresses) along with X starting and ending coordinates. The maximum immediate source size is 128 bytes. 1.2.2.4 Pattern Data The color pattern data must exist within the frame buffer or Graphics aperture where the BLT engine may read it directly or it can be sent through the command stream. The pattern data must be located in linear memory. Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 21 Monochrome pattern data is supplied by the command packet when it is to be used. As shown in figure below, the block of pattern graphics data always represents a block of 8x8 pixels. The bits or bytes of a block of pattern data may be organized in the frame buffer memory in only one of three ways, depending upon its color depth which may be 8, 16, or 32 bits per pixel (whichever matches the color depth to which the BLT engine has been set), or monochrome. The maximum color pattern size is 256 bytes. Pattern Data -- Always an 8x8 Array of Pixels The Pattern Address Register is used to specify the address of the color pattern data at which the block of pattern data begins. The three least significant bits of the address written to this register are ignored, because the address must be in terms of quadwords. This is because the pattern must always be located on an address boundary equal to its size. Monochrome patterns take up 8 bytes, or a single quadword of space, and are loaded through the command packet that uses it. Similarly, color patterns with color depths of 8, 16, and 32 bits per pixel must start on 64-byte, 128-byte and 256-byte boundaries, respectively. The next 3 figures show how monochrome, 8bpp, 16bpp, and 32bpp pattern data , respectively, is organized in memory. 8bpp Pattern Data -- Occupies 64 Bytes (8 quadwords) 22 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 16bpp Pattern Data -- Occupies 128 Bytes (16 quadwords) 32bpp Pattern Data -- Occupies 256 Bytes (32 quadwords) The opcode of the command packet specifies whether the pattern data is color or monochrome. The various bit-wise logical operations and per-pixel write-masking operations were designed to work with color data. In order to use monochrome pattern data, the BLT engine is designed to convert it into color through a process called “color expansion” which takes place as a BLT operation is performed. In color expansion, the single bits of monochrome pattern data are converted into one, two, or four bytes (depending on the color depth) of color data that are set to carry values corresponding to either the foreground or background color that have been specified for use in this process. The foreground color is used for pixels corresponding to a bit of monochrome pattern data that carry the value of 1, while the background color is used where the corresponding bit of monochrome pattern data carries the value of 0. The foreground and background colors used in the color expansion of monochrome pattern data can be set in the Pattern Expansion Foreground Color Register and Pattern Expansion Background Color Register. 1.2.2.5 Destination Data There are actually two different types of “destination data”: the graphics data already residing at the location that is designated as the destination, and the data that is to be written into that very same location as a result of a BLT operation. The location designated as the destination must be within the frame buffer or Graphics aperture where the BLT engine can read from it and write to it directly. The blocks of destination data to be read from and written to the destination may be either contiguous or discontinuous. All data written to the destination will have the color depth to which the BLT engine has been set. It is presumed that any data already existing Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 23 at the destination which will be read by the BLT engine will also be of this same color depth — the BLT engine neither reads nor writes monochrome destination data. The Destination Address Register is used to specify the address of the destination. To accommodate discontinuous destination data, the Source and Destination Pitch Registers can be used to specify the offset in bytes from the beginning of one scan line’s worth of destination data to the next. Otherwise, if the destination data is contiguous, then an offset equal to the length of a scan line’s worth of destination data should be specified. 1.2.3 BLT Programming Examples 1.2.3.1 Pattern Fill — A Very Simple BLT In this example, a rectangular area on the screen is to be filled with a color pattern stored as pattern data in off-screen memory. The screen has a resolution of 1024x768 and the graphics system has been set to a color depth of 8 bits per pixel. On-Screen Destination for Example Pattern Fill BLT As shown in the figure above, the rectangular area to be filled has its upper left-hand corner at coordinates (128, 128) and its lower right-hand corner at coordinates (191, 191). These coordinates define a rectangle covering 64 scan lines, each scan line’s worth of which is 64 pixels in length — in other words, an array of 64x64 pixels. Presuming that the pixel at coordinates (0, 0) corresponds to the byte at 24 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 address 00h in the frame buffer memory, the pixel at (128, 128) corresponds to the byte at address 20080h. Pattern Data for Example Pattern Fill BLT As shown in figure above, the pattern data occupies 64 bytes starting at address 100000h. As always, the pattern data represents an 8x8 array of pixels. The BLT command packet is used to select the features to be used in this BLT operation, and must be programmed carefully. The vertical alignment field should be set to 0 to select the top-most horizontal row of the pattern as the starting row used in drawing the pattern starting with the top-most scan line covered by the destination. The pattern data is in color with a color depth of 8 bits per pixel, so the dynamic color enable should be asserted with the dynamic color depth field should be set to 0. Since this BLT operation does not use per-pixel write-masking (destination transparency mode), this field should be set to 0. Finally, the raster operation field should be programmed with the 8-bit value of F0h to select the bit-wise logical operation in which a simple copy of the pattern data to the destination takes place. Selecting this bit-wise operation in which no source data is used as an input causes the BLT engine to automatically forego either reading source data from the frame buffer. The Destination Pitch Register must be programmed with number of bytes in the interval from the start of one scan line’s worth of destination data to the next. Since the color depth is 8 bits per pixel and the horizontal resolution of the display is 1024, the value to be programmed into these bits is 400h, which is equal to the decimal value of 1024. Bits [31:3] of the Pattern Address Register must be programmed with the address of the pattern data. Similarly, bits [31:0] of the Destination Address Register must be programmed with the byte address at the destination that will be written to first. In this case, the address is 20080h, which corresponds to the byte representing the pixel at coordinates (128, 128). This BLT operation does not use the values in the Source Address Register or the Source Expansion Background or Foreground Color Registers. The Destination Width and Height Registers (or the Destination X and Y Coordinates) must be programmed with values that describe to the BLT engine the 64x64 pixel size of the destination location. The height should be set to carry the value of 40h, indicating that the destination location covers 64 scan lines. The width should be set to carry the value of 40h, indicating that each scan line’s worth of destination data occupies 64 bytes. All of this information is written to the ring buffer using the PAT_BLT (or XY_PAT_BLT) command packet. Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 25 Results of Example Pattern Fill BLT The figure above shows the end result of performing this BLT operation. The 8x8 pattern has been repeatedly copied (“tiled”) into the entire 64x64 area at the destination. 1.2.3.2 Drawing Characters Using a Font Stored in System Memory In this example BLT operation, a lowercase letter “f” is to be drawn in black on a display with a gray background. The resolution of the display is 1024x768, and the graphics system has been set to a color depth of 8 bits per pixel. 26 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 On-Screen Destination for Example Character Drawing BLT The figure above shows the display on which this letter “f” is to be drawn. As shown in this figure, the entire display has been filled with a gray color. The letter “f” is to be drawn into an 8x8 region on the display with the upper left-hand corner at the coordinates (128, 128). Source Data in System Memory for Example Character Drawing BLT The figure above shows both the 8x8 pattern making up the letter “f” and how it is represented somewhere in the host’s system memory — the actual address in system memory is not important. The letter “f” is represented in system memory by a block of monochrome graphics data that occupies 8 bytes. Each byte carries the 8 bits needed to represent the 8 pixels in each scan line’s worth of this graphics data. This type of pattern is often used to store character fonts in system memory. During this BLT operation, the host CPU will read this representation of the letter “f” from system memory, and write it to the BLT engine by performing memory writes to the ring buffer as an immediate monochrome BLT operand following the BLT_TEXT command. The BLT engine will receive this data through the command stream and use it as the source data for this BLT operation. The BLT engine will be set to the same color depth as the graphics system — 8 bits per pixel, in this case. Since the source data in this BLT operation is monochrome, color expansion must be used to convert it to an 8 bpp color depth. To ensure that the gray background behind this letter “f” is preserved, per-pixel write masking will be performed, using the monochrome source data as the pixel mask. Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 27 The BLT Setup and Text_immediate command packets are used to select the features to be used in this BLT operation. Only the fields required by these two command packets must be programmed carefully. The BLT engine ignores all other registers and fields. The source select field in the Text_immediate command must be set to 1, to indicate that the source data is provided by the host CPU through the command packet. Finally, the raster operation field should be programmed with the 8-bit value CCh to select the bit-wise logical operation that simply copies the source data to the destination. Selecting this bit-wise operation in which no pattern data is used as an input, causes the BLT engine to automatically forego reading pattern data from the frame buffer. The Setup Pattern/Source Expansion Foreground Color Register to specify the color with which the letter “f” will be drawn. There is no Source address. All scan lines of the glyph are bit packed and the clipping is controlled by the ClipRect registers from the SETUP_BLT command and the Destination Y1, Y2, X1, and X2 registers in the TEXT_BLT command. Only the pixels that are within (inclusive comparisons) the clip rectangle are written to the destination surface. The Destination Pitch Register must be programmed with a value equal to the number of bytes in the interval between the first bytes of each adjacent scan line’s worth of destination data. Since the color depth is 8 bits per pixel and the horizontal resolution of the display is 1024 pixels, the value to be programmed into these bits is 400h, which is equal to the decimal value of 1024. Since the source data used in this BLT operation is monochrome, the BLT engine will not use a byte-oriented pitch value for the source data. Since the source data is monochrome, color expansion is required to convert it to color with a color depth of 8 bits per pixel. Since the Setup Pattern/Source Expansion Foreground Color Register is selected to specify the foreground color of black to be used in drawing the letter “f”, this register must be programmed with the value for that color. With the graphics system set for a color depth of 8 bits per pixel, the actual colors are specified in the RAMDAC palette, and the 8 bits stored in the frame buffer for each pixel actually specify the index used to select a color from that palette. This example assumes that the color specified at index 00h in the palette is black, and therefore bits [7:0] of this register should be set to 00h to select black as the foreground color. The BLT engine ignores bits [31:8] of this register because the selected color depth is 8 bits per pixel. Even though the color expansion being performed on the source data normally requires that both the foreground and background colors be specified, the value used to specify the background color is not important in this example. Per-pixel write-masking is being performed with the monochrome source data as the pixel mask, which means that none of the pixels in the source data that will be converted to the background color will ever be written to the destination. Since these pixels will never be seen, the value programmed into the Pattern/Source Expansion Background Color Register to specify a background color is not important. The Destination Width and Height Registers are not used. The Y1, Y2, X1, and X2 are used to describe to the BLT engine the 8x8 pixel size of the destination location. The Destination Y1 and Y2 address (or coordinate) registers must be programmed with the starting and ending scan line address (or Y coordinates) of the destination data. This address is specified as an offset from the start of the frame buffer of the scan line at the destination that will be written to first. The destination X1 and X2 registers must be programmed with the starting and ending pixel offsets from the beginning of the scan line. This BLT operation does not use the values in the Pattern Address Register, the Source Expansion Background Color Register, or the Source Expansion Foreground Color Register. 28 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 Results of Example Character Drawing BLT The preceding shows the end result of performing this BLT operation. Only the pixels that form part of the actual letter “f” have been drawn into the 8x8 destination location on the display, leaving the other pixels within the destination with their original gray color. 1.3 BLT Instruction Overview This chapter defines the instructions used to control the 2D (BLT) rendering function. The instructions detailed in this chapter are used across devices. However, slight changes may be present in some instructions (i.e., for features added or removed), or some instructions may be removed entirely. Refer to the Device Dependencies chapter for summary information regarding device-specific behaviors/interfaces/features. The XY instructions offload the drivers by providing X and Y coordinates and taking care of the access directions for overlapping BLTs without fields specified by the driver. Color pixel sizes supported are 8, 16, and 32 bits per pixel (bpp). All pixels are naturally aligned. 1.4 BLT Engine State Most of the BLT instructions are state-free, which means that all states required to execute the command is within the instruction. If clipping is not used, then there is no shared state for many of the BLT instructions. This allows the BLT Engine to be shared by many drivers with minimal synchronization between the drivers. Instructions which share state are: All instructions that are X,Y commands and use the Clipping Rectangle by asserting the Clip Enable field All XY_Setup Commands (XY_SETUP_BLT and XY_SETUP_MONO_PATTERN_SL_BLT, XY_SETUP_CLIP_BLT) load the shared state for the following commands: XY_PIXEL_BLT (Negative Stride (=Pitch) Not Allowed) Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 29 XY_SCANLINES_BLT XY_TEXT_BLT (Negative Stride (=Pitch) Not Allowed) XY_TEXT_IMMEDIATE_BLT (Negative Stride (=Pitch) Not Allowed) State registers that are saved & restored in the Logical Context: BR1+ Setup Control (Solid Pattern Select, Clipping Enable, Mono Source Transparency Mode, Mono Pattern Transparency Mode, Color Depth[1:0], Raster Operation[7:0], & Destination Pitch[15:0]) + 32bpp Channel Mask[1:0], Mono / Color Pattern BR05 Setup Background Color BR06 Setup Foreground Color BR07 Setup Pattern Base Address BR09 Setup Destination Base Address BR20 DW0 for a Monochrome Pattern BR21 DW1 for a Monochrome Pattern BR24 ClipRectY1’X1 BR25 ClipRectY2’X2 1.5 Cacheable Memory Support The BLT Engine can be used to transfer data between cacheable (“system”) memory and uncached (“main”, or “UC”) graphics memory using the BLT instructions. The GTT must be properly programmed to map memory pages as cacheable or UC. Only linear-mapped (not tiled) surfaces can be mapped as cacheable. Transfers between cacheable sources and cacheable destinations are not supported. Patterns and monochrome sources can not be located in cacheable memory. Cacheable write operands do not snoop the processor’s cache nor update memory until evicted from the render cache. Cacheable read or write operands are not snooped (nor invalidated) from either internal cache by external (processor, hublink,…) accesses. 1.6 Device Cache Coherency: Render & Texture Caches Software must initiate cache flushes to enforce coherency between the render and texture caches, i.e., both the render and texture caches must be flushed before a BLT destination surface can be reused as a texture source. Color sources and destinations use the render cache, while patterns and monochrome sources use the texture cache. 1.7 BLT Engine Instructions The Instruction Target field is used as an opcode by the BLT Engine state machine to qualify the control bits that are relevant for executing the instruction. The descriptions for each DWord and bit field are contained in the BLT Engine Instruction Field Definition section. Each DWord field is described as a register, but none of these registers can be written of read through a memory mapped location – they are internal state only. 1.7.1 BLT Programming Restrictions Overlapping Source/Destination BLTs: The following condition must be avoided when programming the Blt engine: Linear surfaces with a cache line in scan line Y for the source stream overlapping with a cache line in scan line Y-1 for the dest stream (=> non-aligned surface pitches). The cache coherency 30 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 rules combined with the Blitter data consumption rules result in UNDEFINED operation. (Note that this restriction will likely follow forward to future products due to architectural complexities.) There are two suggested software workarounds: In order to perform coherent overlapping Blts, (a) the Source and Destination Base Address registers must hold the same value (without alignment restriction), and (b) the Source and Destination Pitch registers (BR11,BR13) must both be a multiple of 64 bytes. If (a) isn’t possible, do overlapping source copy BLTs as two blits, using a separate intermediate surface. All reserved fields must be programmed to 0s. When using monosource or text data (bit/byte/word aligned): do not program pixel widths greater than 32,745 pixels. The other way to do this is driver should always program a dummy 3D NON-PIPELINE state following the BLT commands. Immediate Commands: There must be at least 1 command after any immediate blitter commands before head == tail. This can be a simple MI_NOOP. 1.8 Fill/Move Instructions These instructions use linear addresses with width and height. BLT clipping is not supported. 1.8.1 COLOR_BLT (Fill) COLOR_BLT Length Bias: 2 COLOR_BLT is the simplest BLT operation. It performs a color fill to the destination (with a possible ROP). The only operand is the destination operand which is written dependent on the raster operation. The solid pattern color is stored in the pattern background register. This instruction is optimized to run at the maximum memory write bandwidth. The typical Raster operation code = F0 which performs a copy of the pattern background register to the destination. DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 28:22 Instruction Target(Opcode) Default Value: 40h Format: Opcode 21:20 32bpp Byte Mask This field is only used for 32bpp. Value Name Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 31 COLOR_BLT 1xb Write Alpha Channel x1b Write RGB Channel 19:5 Reserved Format: MBZ 5:0 DWord Length Default Value: 03h 1 31:26 Reserved Format: MBZ BR13 25:24 Color Depth Value Name 00b 8 Bit Color 01b 16 Bit Color(565) 10b 16 Bit Color(1555) 11b 32 Bit Color 23:16 Raster Operation 15:0 Destination Pitch (Signed) Destination pitch in bytes (Same as before). 2 31:16 Destination Height (in scan lines) 15:0 Destination Byte Width (in bytes) BR14 3 31:0 Destination Address Address of the first byte to be written. BR09 4 31:0 Solid Pattern Color 8 bit = [7:0], 16 bit = [15:0], 32 bit = [31:0] BR16 1.8.2 SRC_COPY_BLT (Move) SRC_COPY_BLT Length Bias: 2 This BLT instruction performs a color source copy where the only operands involved is a color source and destination of the same bit width. The source and destination operands may overlap. The command must indicate the horizontal and vertical directions: either forward or backwards to avoid data corruption. The X direction (horizontal) field applies to both the destination and source operands. The source and destination pitches (stride) are signed. DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 28:22 Instruction Target(Opcode) 32 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 SRC_COPY_BLT Default Value: 43h Format: Opcode 21:20 32bpp Byte Mask This field is only used for 32bpp. Value Name 1xb Write Alpha Channel x1b Write RGB Channel 19:5 Reserved Format: MBZ 5:0 DWord Length Default Value: 04h 1 31 Reserved Format: MBZ BR13 30 X Direction (1 = written from right to left (decrementing = backwards); 0 = incrementing) 29:26 Reserved Format: MBZ 25:24 Color Depth Value Name 00b 8 Bit Color 01b 16 Bit Color(565) 10b 16 Bit Color(1555) 11b 32 Bit Color 23:16 Raster Operation 15:0 Destination Pitch (signed) Destination pitch in bytes (Same as before). 2 31:16 Destination Height (in scan lines) 15:0 Destination Byte Width (in bytes) BR14 3 31:0 Destination Address Address of the first byte to be written. BR09 4 31:16 Reserved Format: MBZ BR11 15:0 Source Pitch (double word aligned and signed) 5 31:0 Source Address Address of the first byte to be read. BR12 1.9 2D (X,Y) BLT Instructions Most BLT instructions (prefixed with “XY_”) use 2D X,Y coordinate specifications vs. lower-level linear addresses. These instructions also support simple 2D clipping against a clip rectangle. Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 33 The top and left Clipping coordinates are inclusive. The bottom and right coordinates are exclusive. The BLT Engine performs a trivial reject for all CLIP BLT instructions before performing any accesses. Negative destination and source coordinates are supported. In the case of negative source coordinates, the destination X1 and Y1 are modified by the absolute value of the negative source coordinate before the destination clip checking and final drawing coordinates are calculated. The absolute value of the source negative coordinate is added to the corresponding destination coordinate. The BLT engine clipping also checks for (DX2 [ or = DX1) or (DY2 [ or = DY1) after this calculation and if true, then the BLT is totally rejected. DX1, DY1, CX1, and CY1 are inclusive, while DX2, DY2, CX2, and CY2 are exclusive. Destination pixel address = (Destination Base Address + (Destination Y coordinate * Destination pitch) + (Destination X coordinate * bytes per pixel)). Source pixel address = (Source Base Address + (Source Y coordinate * Source pitch) + (Source X coordinate * bytes per pixel)). Since there is 1 set of Clip Rectangle registers, the Interrupt Ring BLT commands either MUST NEVER enable clipping with these command and never use the XY_Pixel_BLT, XY_Scanline_BLT, nor XY_Text_BLT commands or it must use context switching. The Interrupt rings can also use the non- clipped, linear address commands specified before this section. The base addresses plus the X and Y coordinates determine if there is an overlap between the source and destination operands. If the base addresses of the source and destination are the same and the Source X1 is less than Destination X1, then the BLT Engine performs the accesses in the X-backwards 34 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 access pattern. There is no need to look for an actual overlap. If the base addresses are the same and Source Y1 is less than Destination Y1, then the scan line accesses are performed backwards. Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 35 1.9.1 XY_SETUP_BLT XY_SETUP_BLT Length Bias: 2 This setup instruction supplies common setup information including clipping coordinates used by the XY commands: XY_PIXEL_BLT, XY_SCANLINE_BLT, XY_TEXT_BLT, and XY_TEXT_BLT_IMMEDIATE. These are the only instructions that require that state be saved between instructions other than the Clipping parameters. There are 5 dedicated registers to contain the state for the 3 setup BLT instructions (XY_SETUP_BLT, XY_SETUP_MONO_PATTERN_SL_BLT, and XY_SETUP_CLIP_BLT. All other BLTs use a temporary version of these. The 5 double word registers are: DW1 (Setup Control), DW6 (Setup Foreground color), DW5 (Setup Background color), DW7 (Setup Pattern address), and DW4 (Setup Destination Base Address). DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 28:22 Instruction Target(Opcode) Default Value: 01h Format: Opcode 21:20 32 bpp Byte Mask Value Name 1xb Write Alpha Channel x1b Write RGB Channel 19:12 Reserved Format: MBZ 11 Tiling Enable Value Name Description 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (Tile-X or Tile-Y) 10:8 Reserved Format: MBZ 7:0 DWord Length Default Value: 06h 1 31 Reserved Format: MBZ BR01 30 Clipping Enabled Value Name 0b Disabled 1b Enabled 29 Mono Source Transparency Mode Value Name 0b Use Background 1b Transparency Enabled 28:26 Reserved 36 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 XY_SETUP_BLT Format: MBZ 25:24 Color Depth Value Name 00b 8 Bit Color 01b 16 Bit Color(565) 10b 16 Bit Color(1555) 11b 32 Bit Color 23:16 Raster Operation 15:0 Destination Pitch in DWords 2's complement (Negative Pitch Not allowed for Pixel nor Text) For Tiled surfaces (bit_11 enabled) this pitch is of 512Byte granularity for Tile-X, 128B granularity for Tile-Y and can be upto 128Kbytes (or 32KDwords). 2 31:16 ClipRect Y1 Coordinate (Top) (30:16 = 15 bit positive number) BR24 15:0 ClipRect X1 Coordinate (Left) (14:00 = 15 bit positive number) 3 31:16 ClipRect Y2 Coordinate (Bottom) (30:16 = 15 bit positive number) BR25 15:0 ClipRect X2 Coordinate (Right) (14:00 = 15 bit positive number) 4 31:0 Setup Destination Base Address Base address of the destination surface: X=0, Y=0. When Tiling is enabled (Bit_11 enabled), this BR09 address is limited to 4Kbytes. 5 31:0 Setup Background Color 8 bit = [7:0], 16 bit = [15:0], 32 bit = [31:0] All BR05 6 31:0 Setup Foreground Color 8 bit = [7:0], 16 bit = [15:0], 32 bit = [31:0] (SLB and TB only) BR06 7 31:0 Setup Pattern Base Address for Color Pattern (26:06 are implemented) (SLB only) (Note no NPO2 change here). The pattern data must be located BR07 in linear memory. Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 37 1.9.2 XY_SETUP_MONO_PATTERN_SL_BLT XY_SETUP_MONO_PATTERN_SL_BLT Length Bias: 2 This setup instruction supplies common setup information including clipping coordinates used exclusively with the following instruction: XY_SCANLINE_BLT (SLB) - 1 scan line of monochrome pattern and destination are the only operands allowed. DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 28:22 Instruction Target(Opcode) Default Value: 11h Format: Opcode 21:20 32 bpp Byte Mask Value Name 1xb Write Alpha Channel x1b Write RGB Channel 19:12 Reserved Format: MBZ 11 Tiling Enable Value Name 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (Tile-X or Tile-Y 10:8 Reserved Format: MBZ 7:0 DWord Length Default Value: 07h 1 31 Solid Pattern Select (SLB and Pixel only) BR01 Value Name 0 No Solid Pattern 1 Solid Pattern 30 Clipping Enabled Value Name 0b Disabled 1b Enabled 29 Reserved Format: MBZ 28 Mono Pattern Transparency Mode Value Name 0b Use Background 1b Transparency Enabled 27:26 Reserved Format: MBZ 25:24 Color Depth Value Name 38 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 XY_SETUP_MONO_PATTERN_SL_BLT 00b 8 Bit Color 01b 16 Bit Color(565) 10b 16 Bit Color(1555) 11b 32 Bit Color 23:16 Raster Operation 15:0 Destination Pitch in DWords 2's complement (Negative Pitch Not allowed for Pixel nor Text) For Tiled surfaces (bit_11 enabled) this pitch is of 512Byte granularity for Tile-X, 128B granularity for Tile-Y and can be upto 128Kbytes (or 32KDwords). 2 31:16 ClipRect Y1 Coordinate (Top) (30:16 = 15 bit positive number) BR24 15:0 ClipRect X1 Coordinate (Left) (14:00 = 15 bit positive number) 3 31:16 ClipRect Y2 Coordinate (Bottom) (30:16 = 15 bit positive number) BR25 15:0 ClipRect X2 Coordinate (Right) (14:00 = 15 bit positive number) 4 31:0 Setup Destination Base Address Base address of the destination surface: X=0, Y=0. When Tiling is enabled (Bit_11 enabled), this BR09 address is limited to 4Kbytes. 5 31:0 Setup Background Color 8 bit = [7:0], 16 bit = [15:0], 32 bit = [31:0] All BR05 6 31:0 Setup Foreground Color 8 bit = [7:0], 16 bit = [15:0], 32 bit = [31:0] (SLB and TB only) BR06 7 31:0 DW0 (least significant) for a Monochrome Pattern BR20 8 31:0 DW1 (most significant) for a Monochrome Pattern BR21 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 39 1.9.3 XY_SETUP_CLIP_ BLT XY_SETUP_CLIP_BLT Length Bias: 2 This command is used to only change the clip coordinate registers. These are the same clipping registers as the Setup clipping registers above. DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 28:22 Instruction Target(Opcode) Default Value: 03h Format: Opcode 21:12 Reserved Format: MBZ 11 Tiling Enable Value Name 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (Tile-X or Tile-Y 10:8 Reserved Format: MBZ 7:0 DWord Length Default Value: 01h 1 31:16 ClipRect Y1 Coordinate (Top) (30:16 = 15 bit positive number) BR24 15:0 ClipRect X1 Coordinate (Left) (14:00 = 15 bit positive number) 2 31:16 ClipRect Y2 Coordinate (Bottom) (30:16 = 15 bit positive number) BR25 15:0 ClipRect X2 Coordinate (Right) (14:00 = 15 bit positive number) 40 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 1.9.4 XY_PIXEL_BLT XY_PIXEL_BLT Length Bias: 2 The Destination X coordinate and Destination Y coordinate is compared with the ClipRect registers. If it is within all 4 comparisons, then the pixel supplied in the XY_SETUP_BLT instruction is written with the raster operation to (Destination Y Address + (Destination Y coordinate * Destination pitch) + (Destination X coordinate * bytes per pixel)). ROP field must specify pattern or fill with 0’s or 1’s. There is no source operand. Negative Stride (= Pitch) specified in the Setup command is Not Allowed DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 28:22 Instruction Target(Opcode) Default Value: 24h Format: Opcode 21:12 Reserved Format: MBZ 11 Tiling Enable Value Name Description 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (Tile-X or Tile-Y) 10:8 Reserved Format: MBZ 7:0 DWord Length Default Value: 00h 1 31:16 Destination Y1 Coordinate (Top) 16 bit signed number. BR22 15:0 Destination X1 Coordinate (Left) 16 bit signed number. Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 41 1.9.5 XY_SCANLINES_BLT XY_SCANLINES_BLT Length Bias: 2 All scan lines and pixels that fall within the ClipRect Y and X coordinates are written. Only pixels within the ClipRectX coordinates and the Destination X coordinates are written using the raster operation. The Pattern Seeds correspond to Destination X = 0 (horizontal) and Y = 0 (vertical). The alignment is relative to the destination coordinates. The pixel of the pattern used / scan line is the (destination X coordinate + horizontal seed) modulo 8. The scan line of the pattern used is the (destination Y coordinate + vertical seed) modulo 8. Solid pattern should use the XY_SETUP_MONO_PATTERN_SL_BLT instruction. ROP field must specify pattern or fill with 0's or 1's. There is no source operand. DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 28:22 Instruction Target(Opcode) Default Value: 25h Format: Opcode 21:15 Reserved Format: MBZ 14:12 Pattern Horizontal Seed Pixel of the scan line to start on corresponding to DST X=0. 11 Tiling Enable Value Name Description 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (Tile-X or Tile-Y) 10:8 Pattern Vertical Seed Scan line of the 8x8 pattern to start on corresponding to DST Y=0. 7:0 DWord Length Default Value: 01h 1 31:16 Destination Y1 Coordinate (Top) 16 bit signed number. BR22 15:0 Destination X1 Coordinate (Left) 16 bit signed number. 2 31:16 Destination Y2 Coordinate (Bottom) 16 bit signed number. BR23 15:0 Destination X2 Coordinate (Right) 16 bit signed number. 42 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 1.9.6 XY_TEXT_BLT XY_TEXT_BLT Length Bias: 2 All source scan lines and pixels that fall within the ClipRect Y and X coordinates are written. The source address corresponds to Destination X1 and Y1 coordinate. Text is either bit or byte packed. Bit packed means that the next scan line starts 1 pixel after the end of the current scan line with no bit padding. Byte packed means that the next scan line starts on the first bit of the next byte boundary after the last bit of the current line. Source expansion color registers are always in the SETUP_BLT. Negative Stride (= Pitch) is NOT ALLOWED. DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 28:22 Instruction Target(Opcode) Default Value: 26h Format: Opcode 21:17 Reserved Format: MBZ 16 Bit / Byte Packed Byte packed is for the NT driver. Value Name 0 Bit 1 Byte 15:12 Reserved Format: MBZ 11 Tiling Enable Value Name Description 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (Tile-X or Tile-Y) 10:8 Reserved Format: MBZ 7:0 DWord Length Default Value: 02h 1 31:16 Destination Y1 Coordinate (Top) 16 bit signed number. BR22 15:0 Destination X1 Coordinate (Left) 16 bit signed number. Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 43 XY_TEXT_BLT 2 31:16 Destination Y2 Coordinate (Bottom) 16 bit signed number. BR23 15:0 Destination X2 Coordinate (Right) 16 bit signed number. 3 31:0 Source Address (address of the first byte on scan line corresponding to Dst X1,Y1). (Note no NPO2 change here) BR12 1.9.7 XY_TEXT_IMMEDIATE_BLT XY_TEXT_IMMEDIATE_BLT Project: Length Bias: 2 This instruction allows the Driver to send data through the instruction stream that eliminates the read latency of reading a source from memory. If an operand is in system cacheable memory and either small or only accessed once, it can be copied directly to the instruction stream versus to graphics accessible memory. The IMMEDIATE_BLT data MUST transfer an even number of doublewords. The BLT engine will hang if it does not get an even number of doublewords. All source scan lines and pixels that fall within the ClipRect X and Y coordinates are written. The source data corresponds to Destination X1 and Y1 coordinate. Source expansion color registers are always in the SETUP_BLT. NEGATIVE STRIDE (= PITCH) IS NOT ALLOWED. DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 28:22 Instruction Target(Opcode) Default Value: 31h Format: Opcode 21:17 Reserved Format: MBZ 16 Bit / Byte Packed Byte packed is for the NT driver. Value Name 0 Bit 1 Byte 44 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 XY_TEXT_IMMEDIATE_BLT 15:12 Reserved Format: MBZ 11 Tiling Enable Value Name Description 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (Tile-X or Tile-Y) 10:8 Reserved Format: MBZ 7:0 DWord Length 01 + DWL = (Number of Immediate double words)h 1 31:16 Destination Y1 Coordinate (Top) 16 bit signed number. BR22 15:0 Destination X1 Coordinate (Left) 16 bit signed number. 2 31:16 Destination Y2 Coordinate (Bottom) 16 bit signed number. BR23 15:0 Destination X2 Coordinate (Right) 16 bit signed number. 3 31:0 Immediate Data DW 0 4 31:0 Immediate Data DW 1 5..n 31:0 Immediate Data DWs 2 through DWORD_LENGTH (DWL-1) 1.9.8 XY_COLOR_BLT XY_COLOR_BLT Length Bias: 2 COLOR_BLT is the simplest BLT operation. It performs a color fill to the destination (with a possible ROP). The only operand is the destination operand which is written dependent on the raster operation. The solid pattern color is stored in the pattern background register. This instruction is optimized to run at the maximum memory write bandwidth. The typical (and fastest) Raster operation code = F0 which performs a copy of the pattern background register to the destination. DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 28:22 Instruction Target(Opcode) Default Value: 50h Format: Opcode 21:20 32bpp Byte Mask Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 45 XY_COLOR_BLT This field is only used for 32bpp. Value Name 1xb Write Alpha Channel x1b Write RGB Channel 19:12 Reserved Format: MBZ 11 Tiling Enable Value Name Description 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (Tile-X or Tile-Y) 10:8 Reserved Format: MBZ 7:0 DWord Length Default Value: 04h 1 31 Reserved Format: MBZ BR13 30 Clipping Enabled Value Name 0b Disabled 1b Enabled 29:26 Reserved Format: MBZ 25:24 Color Depth Value Name 00b 8 Bit Color 01b 16 Bit Color(565) 10b 16 Bit Color(1555) 11b 32 Bit Color 23:16 Raster Operation 15:0 Destination Pitch in DWords 2's complement For Tiled surfaces (bit_11 enabled) this pitch is of 512Byte granularity for Tile-X, 128B granularity for Tile-Y and can be upto 128Kbytes (or 32KDwords). 2 31:16 Destination Y1 Coordinate (Top) 16 bit signed number. BR22 15:0 Destination X1 Coordinate (Left) 16 bit signed number. 3 31:16 Destination Y2 Coordinate (Bottom) 16 bit signed number. BR23 15:0 Destination X2 Coordinate (Right) 16 bit signed number. 4 31:0 Setup Destination Base Address Base address of the destination surface: X=0, Y=0. When Tiling is enabled (Bit_11 enabled), this BR09 address is limited to 4Kbytes. 5 31:0 Solid Pattern Color 8 bit = [7:0], 16 bit = [15:0], 32 bit = [31:0] BR16 46 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 1.9.9 XY_PAT_BLT XY_PAT_BLT Length Bias: 2 PAT_BLT is used when there is no source and the color pattern is not trivial (is not a solid color only). If clipping is enabled, all scan lines and pixels that fall within the ClipRect Y and X coordinates are written. Only pixels within the ClipRectX coordinates and the Destination X coordinates are written using the raster operation. The Pattern Seeds correspond to Destination X = 0 (horizontal) and Y = 0 (vertical). The alignment is relative to the destination coordinates. The pixel of the pattern used / scan line is the (destination X coordinate + horizontal seed) modulo 8. The scan line of the pattern used is the (destination Y coordinate + vertical seed) modulo 8. DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 28:22 Instruction Target(Opcode) Default Value: 51h Format: Opcode 21:20 32bpp Byte Mask This field is only used for 32bpp. Value Name 00b [Default] 1xb Write Alpha Channel x1b Write RGB Channel 19:15 Reserved Format: MBZ 14:12 Pattern Horizontal Seed Pixel of the scan line to start on corresponding to DST X=0. 11 Tiling Enable Value Name Description 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (Tile-X or Tile-Y) 10:8 Pattern Vertical Seed Scan line of the 8x8 pattern to start on corresponding to DST Y=0. 7:0 DWord Length Default Value: 04h 1 31 Reserved Format: MBZ BR13 30 Clipping Enabled Value Name 0b Disabled 1b Enabled 29:26 Reserved Format: MBZ Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 47 XY_PAT_BLT 25:24 Color Depth Value Name 00b 8 Bit Color 01b 16 Bit Color(565) 10b 16 Bit Color(1555) 11b 32 Bit Color 23:16 Raster Operation 15:0 Destination Pitch in DWords 2's complement (Negative Pitch Not allowed for Pixel nor Text) For Tiled surfaces (bit_11 enabled) this pitch is of 512Byte granularity for Tile-X, 128B granularity for Tile-Y and can be upto 128Kbytes (or 32KDwords). 2 31:16 Destination Y1 Coordinate (Top) 16 bit signed number. BR22 15:0 Destination X1 Coordinate (Left) 16 bit signed number. 3 31:16 Destination Y2 Coordinate (Bottom) 16 bit signed number. BR23 15:0 Destination X2 Coordinate (Right) 16 bit signed number. 4 31:0 Destination Base Address Base address of the destination surface: X=0, Y=0. When Tiling is enabled (Bit_11 enabled), this BR09 address is limited to 4Kbytes. 5 31:0 Pattern Base Address (28:06 are implemented) (Note no NPO2 change here) . The pattern data must be located in linear BR15 memory. 1.9.10 XY_PAT_CHROMA_BLT XY_PAT_CHROMA_BLT Length Bias: 2 PAT_BLT is used when there is no source and the color pattern is not trivial (is not a solid color only). All scan lines and pixels that fall within the ClipRect Y and X coordinates are written. Only pixels within the ClipRectX coordinates and the Destination X coordinates are written using the raster operation. The Pattern Seeds correspond to Destination X = 0 (horizontal) and Y = 0 (vertical). The alignment is relative to the destination coordinates. The pixel of the pattern used / scan line is the (destination X coordinate + horizontal seed) modulo 8. The scan line of the pattern used is the (destination Y coordinate + vertical seed) modulo 8. DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 48 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 XY_PAT_CHROMA_BLT 28:22 Instruction Target(Opcode) Default Value: 76h Format: Opcode 21:20 32bpp Byte Mask This field is only used for 32bpp. Value Name 00b [Default] 1xb Write Alpha Channel x1b Write RGB Channel 19:17 Transparency Range Mode (chroma-key) – Dst Chroma-key modes ONLY (SRC ILLEGAL) 16:15 Reserved Format: MBZ 14:12 Pattern Horizontal Seed Pixel of the scan line to start on corresponding to DST X=0. 11 Tiling Enable Value Name Description 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (Tile-X or Tile-Y) 10:8 Pattern Vertical Seed Scan line of the 8x8 pattern to start on corresponding to DST Y=0. 7:0 DWord Length Default Value: 06h 1 31 Reserved Format: MBZ BR13 30 Clipping Enabled Value Name 0b Disabled 1b Enabled 29:26 Reserved Format: MBZ 25:24 Color Depth Value Name 00b 8 Bit Color 01b 16 Bit Color(565) 10b 16 Bit Color(1555) 11b 32 Bit Color 23:16 Raster Operation 15:0 Destination Pitch in DWords 2's complement (Negative Pitch Not allowed for Pixel nor Text) For Tiled surfaces (bit_11 enabled) this pitch is of 512Byte granularity for Tile-X, 128B granularity for Tile-Y and can be upto 128Kbytes (or 32KDwords). 2 31:16 Destination Y1 Coordinate (Top) 16 bit signed number. BR22 15:0 Destination X1 Coordinate (Left) 16 bit signed number. 3 31:16 Destination Y2 Coordinate (Bottom) Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 49 XY_PAT_CHROMA_BLT 16 bit signed number. BR23 15:0 Destination X2 Coordinate (Right) 16 bit signed number. 4 31:0 Destination Base Address Base address of the destination surface: X=0, Y=0. When Tiling is enabled (Bit 11 enabled), this BR09 address is limited to 4Kbytes. 5 31:0 Pattern Base Address (26:06 are used, other bits are ignored) (Note no NPO2 change here). The pattern data must be BR15 located in linear memory. 6 31:0 Transparency Color Low (Chroma-key Low = Pixel Greater or Equal) BR18 7 31:0 Transparency Color High (Chroma-key High = Pixel Less or Equal) BR19 1.9.11 XY_PAT_BLT_IMMEDIATE XY_PAT_BLT_IMMEDIATE Length Bias: 2 PAT_BLT_IMMEDIATE is used when there is no source and the color pattern is not trivial (is not a solid color only) and the pattern is pulled through the command stream. The immediate data sizes are 64 bytes (16 DWs), 128 bytes (32 DWs), or 256 (64DWs) for 8, 16, and 32 bpp color patterns. DWL indicates the total number of Dwords of immediate data. All scan lines and pixels that fall within the ClipRect Y and X coordinates are written. Only pixels within the ClipRectX coordinates and the Destination X coordinates are written using the raster operation. The Pattern Seeds correspond to Destination X = 0 (horizontal) and Y = 0 (vertical). The alignment is relative to the destination coordinates. The pixel of the pattern used / scan line is the (destination X coordinate + horizontal seed) modulo 8. The scan line of the pattern used is the (destination Y coordinate + vertical seed) modulo 8. DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 28:22 Instruction Target(Opcode) Default Value: 72h Format: Opcode 21:20 32bpp Byte Mask This field is only used for 32bpp. Value Name 00b [Default] 50 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 XY_PAT_BLT_IMMEDIATE 1xb Write Alpha Channel x1b Write RGB Channel 19:15 Reserved Format: MBZ 14:12 Pattern Horizontal Seed Pixel of the scan line to start on corresponding to DST X=0. 11 Tiling Enable Value Name Description 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (Tile-X or Tile-Y) 10:8 Pattern Vertical Seed Scan line of the 8x8 pattern to start on corresponding to DST Y=0. 7:0 DWord Length 03 + DWL = (Number of Immediate double)h 1 31 Reserved Format: MBZ BR13 30 Clipping Enabled Value Name 0b Disabled 1b Enabled 29:26 Reserved Format: MBZ 25:24 Color Depth Value Name 00b 8 Bit Color 01b 16 Bit Color(565) 10b 16 Bit Color(1555) 11b 32 Bit Color 23:16 Raster Operation 15:0 Destination Pitch in DWords 2's complement (Negative Pitch Not allowed for Pixel nor Text) For Tiled surfaces (bit_11 enabled) this pitch is of 512Byte granularity for Tile-X, 128B granularity for Tile-Y and can be upto 128Kbytes (or 32KDwords). 2 31:16 Destination Y1 Coordinate (Top) 16 bit signed number. BR22 15:0 Destination X1 Coordinate (Left) 16 bit signed number. 3 31:16 Destination Y2 Coordinate (Bottom) 16 bit signed number. BR23 15:0 Destination X2 Coordinate (Right) 16 bit signed number. 4 31:0 Destination Base Address Base address of the destination surface: X=0, Y=0. When Tiling is enabled (Bit_11 enabled), this BR09 address is limited to 4Kbytes. 5 31:0 Immediate Data 0 6 31:0 Immediate Data 1 7..n 31:0 Immediate Data DWs 2 through DWORD_LENGTH (DWL-1): Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 51 1.9.12 XY_PAT_CHROMA_BLT_IMMEDIATE XY_PAT_CHROMA_BLT_IMMEDIATE Length Bias: 2 PAT_BLT_IMMEDIATE is used when there is no source and the color pattern is not trivial (is not a solid color only) and the pattern is pulled through the command stream. The immediate data sizes are 64 bytes (16 DWs), 128 bytes (32 DWs), or 256 (64DWs) for 8, 16, and 32 bpp color patterns. DWL indicates the total number of Dwords of immediate data. All scan lines and pixels that fall within the ClipRect Y and X coordinates are written. Only pixels within the ClipRectX coordinates and the Destination X coordinates are written using the raster operation. The Pattern Seeds correspond to Destination X = 0 (horizontal) and Y = 0 (vertical). The alignment is relative to the destination coordinates. The pixel of the pattern used / scan line is the (destination X coordinate + horizontal seed) modulo 8. The scan line of the pattern used is the (destination Y coordinate + vertical seed) modulo 8. DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 28:22 Instruction Target(Opcode) Default Value: 77h Format: Opcode 21:20 32bpp Byte Mask This field is only used for 32bpp. Value Name 00b [Default] 1xb Write Alpha Channel x1b Write RGB Channel 19:17 Transparency Range Mode (chroma-key) – Dst Chroma-key modes ONLY (SRC ILLEGAL) 16:15 Reserved Format: MBZ 14:12 Pattern Horizontal Seed Pixel of the scan line to start on corresponding to DST X=0. 11 Tiling Enable Value Name Description 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (Tile-X or Tile-Y) 10:8 Pattern Vertical Seed Scan line of the 8x8 pattern to start on corresponding to DST Y=0. 7:0 DWord Length 05 + DWL = (Number of Immediate double)h 1 31 Reserved Format: MBZ 52 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 XY_PAT_CHROMA_BLT_IMMEDIATE BR13 30 Clipping Enabled Value Name 0b Disabled 1b Enabled 29:26 Reserved Format: MBZ 25:24 Color Depth Value Name 00b 8 Bit Color 01b 16 Bit Color(565) 10b 16 Bit Color(1555) 11b 32 Bit Color 23:16 Raster Operation 15:0 Destination Pitch in DWords 2's complement For Tiled surfaces (bit_11 enabled) this pitch is of 512Byte granularity for Tile-X, 128B granularity for Tile-Y and can be upto 128Kbytes (or 32KDwords). 2 31:16 Destination Y1 Coordinate (Top) 16 bit signed number. BR22 15:0 Destination X1 Coordinate (Left) 16 bit signed number. 3 31:16 Destination Y2 Coordinate (Bottom) 16 bit signed number. BR23 15:0 Destination X2 Coordinate (Right) 16 bit signed number. 4 31:0 Destination Base Address Base address of the destination surface: X=0, Y=0. When Tiling is enabled (Bit_11 enabled), this BR09 address is limited to 4Kbytes. 5 31:0 Transparency Color Low (Chroma-key Low = Pixel Greater or Equal) BR18 6 31:0 Transparency Color High (Chroma-key High = Pixel Less or Equal) BR19 7 31:0 Immediate Data 0 8 31:0 Immediate Data 1 9..n 31:0 Immediate Data DWs 2 through DWORD_LENGTH (DWL-1): Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 53 1.9.13 XY_MONO_PAT_BLT XY_MONO_PAT_BLT Length Bias: 2 MONO_PAT_BLT is used when we have no source and the monochrome pattern is not trivial (is not a solid color only). The monochrome pattern is loaded from the instruction stream. All scan lines and pixels that fall within the ClipRect Y and X coordinates are written. Only pixels within the ClipRectX coordinates and the Destination X coordinates are written using the raster operation. The Pattern Seeds correspond to Destination X = 0 (horizontal) and Y = 0 (vertical). The alignment is relative to the destination coordinates. The pixel of the pattern used / scan line is the (destination X coordinate + horizontal seed) modulo 8. The scan line of the pattern used is the (destination Y coordinate + vertical seed) modulo 8. The monochrome pattern transparency mode indicates whether to use the pattern background color or de-assert the write enables when the bit in the pattern is 0. When the pattern bit is 1, then the pattern foreground color is used in the ROP operation. DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 28:22 Instruction Target(Opcode) Default Value: 52h Format: Opcode 21:20 32bpp Byte Mask This field is only used for 32bpp. Value Name 00b [Default] 1xb Write Alpha Channel x1b Write RGB Channel 19:15 Reserved Format: MBZ 14:12 Pattern Horizontal Seed Pixel of the scan line to start on corresponding to DST X=0. 11 Tiling Enable Value Name Description 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (Tile-X or Tile-Y) 10:8 Pattern Vertical Seed Scan line of the 8x8 pattern to start on corresponding to DST Y=0. 7:0 DWord Length Value Name 07h 54 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 XY_MONO_PAT_BLT 1 31 Reserved Format: MBZ BR13 30 Clipping Enabled Value Name 0b Disabled 1b Enabled 29 Reserved Format: MBZ 28 Mono Pattern Transparency Mode Value Name 0 Use Background 1 Transparency Enabled 27:26 Reserved Format: MBZ 25:24 Color Depth Value Name 00b 8 Bit Color 01b 16 Bit Color(565) 10b 16 Bit Color(1555) 11b 32 Bit Color 23:16 Raster Operation 15:0 Destination Pitch in DWords 2's complement For Tiled surfaces (bit_11 enabled) this pitch is of 512Byte granularity for Tile-X, 128B granularity for Tile-Y and can be upto 128Kbytes (or 32KDwords). 2 31:16 Destination Y1 Coordinate (Top) 16 bit signed number. BR22 15:0 Destination X1 Coordinate (Left) 16 bit signed number. 3 31:16 Destination Y2 Coordinate (Bottom) 16 bit signed number. BR23 15:0 Destination X2 Coordinate (Right) 16 bit signed number. 4 31:0 Destination Base Address Base address of the destination surface: X=0, Y=0. When Tiling is enabled (Bit 11 enabled), this BR09 address is limited to 4Kbytes. 5 31:0 Pattern Background Color 8 bit = [7:0], 16 bit = [15:0], 32 bit = [31:0] BR16 6 31:0 Pattern Foreground Color 8 bit = [7:0], 16 bit = [15:0], 32 bit = [31:0] BR17 7 31:0 Pattern Data 0 BR20 8 31:0 Pattern Data 1 BR21 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 55 1.9.13.1 XY_MONO_PAT_FIXED_BLT XY_MONO_PAT_FIXED_BLT Length Bias: 2 MONO_PAT_FIXED_BLT is used when we have no source and the monochrome pattern is not trivial (is not a solid color only). The monochrome pattern is one of 10 fixed patterns described below. The pattern seeds can still be used with the fixed patterns, creating even more fixed patterns. This eliminates 2 doublewords compared to the XY_MONO_PAT_BLT command packet. All scan lines and pixels that fall within the ClipRect Y and X coordinates are written. Only pixels within the ClipRectX coordinates and the Destination X coordinates are written using the raster operation. The Pattern Seeds correspond to Destination X = 0 (horizontal) and Y = 0 (vertical). The alignment is relative to the destination coordinates. The pixel of the pattern used / scan line is the (destination X coordinate + horizontal seed) modulo 8. The scan line of the pattern used is the (destination Y coordinate + vertical seed) modulo 8. The monochrome pattern transparency mode indicates whether to use the pattern background color or de-assert the write enables when the bit in the pattern is 0. When the pattern bit is 1, then the pattern foreground color is used in the ROP operation. DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 28:22 Instruction Target(Opcode) Default Value: 59h Format: Opcode 21:20 32bpp Byte Mask This field is only used for 32bpp. Value Name 00b [Default] 1xb Write Alpha Channel x1b Write RGB Channel 19 Reserved Format: MBZ 18:15 Fixed Pattern Value Name 0000b HS_HORIZONTAL 0001b HS_VERTICAL 0010b HS_FDIAGONAL 0011b HS_BDIAGONAL 0100b HS_CROSS 0101b HS_DIAGCROSS 0110b Reserved 0111b Reserved 56 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 XY_MONO_PAT_FIXED_BLT 1000b Screen Door 1001b SD Wide 1010b Walking Bit (one) 1011b Walking Zero 1100b Reserved 1101b Reserved 1110b Reserved 1111b Reserved 14:12 Pattern Horizontal Seed Pixel of the scan line to start on corresponding to DST X=0. 11 Tiling Enable Value Name Description 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (Tile-X or Tile-Y) 10:8 Pattern Vertical Seed Scan line of the 8x8 pattern to start on corresponding to DST Y=0. 7:0 DWord Length Value Name 05h 1 31 Reserved Format: MBZ BR13 30 Clipping Enabled Value Name 0b Disabled 1b Enabled 29 Reserved Format: MBZ 28 Mono Pattern Transparency Mode Value Name 0 Use Background 1 Transparency Enabled 27:26 Reserved Format: MBZ 25:24 Color Depth Value Name 00b 8 Bit Color 01b 16 Bit Color(565) 10b 16 Bit Color(1555) 11b 32 Bit Color 23:16 Raster Operation 15:0 Destination Pitch in DWords 2's complement For Tiled surfaces (bit_11 enabled) this pitch is of 512Byte granularity for Tile-X, 128B granularity for Tile-Y and can be upto 128Kbytes (or 32KDwords). 2 31:16 Destination Y1 Coordinate (Top) 16 bit signed number. BR22 15:0 Destination X1 Coordinate (Left) 16 bit signed number. Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 57 XY_MONO_PAT_FIXED_BLT 3 31:16 Destination Y2 Coordinate (Bottom) 16 bit signed number. BR23 15:0 Destination X2 Coordinate (Right) 16 bit signed number. 4 31:0 Destination Base Address Base address of the destination surface: X=0, Y=0. When Tiling is enabled (Bit_11 enabled), this BR09 address is limited to 4Kbytes. 5 31:0 Pattern Background Color 8 bit = [7:0], 16 bit = [15:0], 32 bit = [31:0] BR16 6 31:0 Pattern Foreground Color 8 bit = [7:0], 16 bit = [15:0], 32 bit = [31:0] BR17 1.9.13.2 Monochrome Pattern Memory Format The monochrome pattern is made of 8 bytes that correspond to the 8 pixels per scan line and 8 scan lines. Byte 0 corresponds to scan line 0, byte 1 corresponds to scan line 1,…, and byte 7 corresponds to scan line 7. The bits within each byte are transposed. Pixel 0 is bit 7, pixel 1 is bit 6,…, pixel 7 is bit 0. The diagram below illustrates the byte and bit relationship to the pixels of the pattern. 1.9.13.3 HS_HORIZONTAL 0 Bit 7 0 0,0 7,0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 58 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1.9.13.4 HS_VERTICAL 1 Bit 7 0 0,0 7,0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 1.9.13.5 HS_FDIAGONAL 2 Bit 7 0 0,0 7,0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 1.9.13.6 HS_BDIAGONAL 3 Bit 7 0 0,0 7,0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 59 1.9.13.7 HS_CROSS 4 Bit 7 0 0,0 7,0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 1 1 1 1 1 1 1 1 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 1.9.13.8 HS_DIAGCROSS 5 Bit 7 0 0,0 7,0 1 0 0 0 0 0 0 1 0 1 0 0 0 0 1 0 0 0 1 0 0 1 0 0 0 0 0 1 1 0 0 0 0 0 0 1 1 0 0 0 0 0 1 0 0 1 0 0 0 1 0 0 0 0 1 0 1 0 0 0 0 0 0 1 1.9.13.9 Screen Door 8 Bit 7 0 0,0 7,0 0 1 0 1 0 1 0 1 1 0 1 0 1 0 1 0 0 1 0 1 0 1 0 1 1 0 1 0 1 0 1 0 0 1 0 1 0 1 0 1 1 0 1 0 1 0 1 0 0 1 0 1 0 1 0 1 1 0 1 0 1 0 1 0 1.9.13.10 SD Wide 9 Bit 7 0 0,0 7,0 1 1 0 0 1 1 0 0 60 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 0 0 1 1 0 0 1 1 1 1 0 0 1 1 0 0 0 0 1 1 0 0 1 1 1 1 0 0 1 1 0 0 0 0 1 1 0 0 1 1 1 1 0 0 1 1 0 0 0 0 1 1 0 0 1 1 1.9.13.11 Walking Bit (One) A Bit 7 0 0,0 7,0 1 0 0 0 1 0 0 0 0 1 0 0 0 1 0 0 0 0 1 0 0 0 1 0 0 0 0 1 0 0 0 1 1 0 0 0 1 0 0 0 0 1 0 0 0 1 0 0 0 0 1 0 0 0 1 0 0 0 0 1 0 0 0 1 1.9.13.12 Walking Zero B Bit 7 0 0,0 7,0 0 1 1 1 0 1 1 1 1 0 1 1 1 0 1 1 1 1 0 1 1 1 0 1 1 1 1 0 1 1 1 0 0 1 1 1 0 1 1 1 1 0 1 1 1 0 1 1 1 1 0 1 1 1 0 1 1 1 1 0 1 1 1 0 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 61 1.9.14 XY_SRC_COPY_BLT XY_SRC_COPY_BLT Length Bias: 2 This BLT instruction performs a color source copy where the only operands involved is a color source and destination of the same bit width. The source and destination operands may overlap, which means that the X and Y directions can be either forward or backwards. The BLT Engine takes care of all situations. The base addresses plus the X and Y coordinates determine if there is an overlap between the source and destination operands. If the base addresses of the source and destination are the same and the Source X1 is less than Destination X1, then the BLT Engine performs the accesses in the X-backwards access pattern. There is no need to look for an actual overlap. If the base addresses are the same and Source Y1 is less than Destination Y1, then the scan line accesses start at Destination Y2 with the corresponding source scan line and the strides are subtracted for every scan line access. The ROP value chosen must involve source and no pattern data in the ROP operation. DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 28:22 Instruction Target(Opcode) Default Value: 53h Format: Opcode 21:20 32bpp Byte Mask This field is only used for 32bpp. Value Name 00b [Default] 1xb Write Alpha Channel x1b Write RGB Channel 19:16 Reserved Format: MBZ 15 Src Tiling Enable Value Name Description 0b Tiling Disabled (Linear) 1b Tiling Enabled (Tile-X or Tile-Y) 14:12 Reserved Format: MBZ 11 Dest Tiling Enable Value Name Description 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (Tile-X or Tile-Y) 10:8 Reserved Format: MBZ 62 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 XY_SRC_COPY_BLT 7:0 DWord Length Value Name 06h 1 31 Reserved Format: MBZ BR13 30 Clipping Enabled Value Name 0b Disabled 1b Enabled 29:26 Reserved Format: MBZ 25:24 Color Depth Value Name 00b 8 Bit Color 01b 16 Bit Color(565) 10b 16 Bit Color(1555) 11b 32 Bit Color 23:16 Raster Operation 15:0 Destination Pitch in DWords 2's complement For Tiled surfaces (bit_11 enabled) this pitch is of 512Byte granularity for Tile-X, 128B granularity for Tile-Y and can be upto 128Kbytes (or 32KDwords). 2 31:16 Destination Y1 Coordinate (Top) 16 bit signed number. BR22 15:0 Destination X1 Coordinate (Left) 16 bit signed number. 3 31:16 Destination Y2 Coordinate (Bottom) 16 bit signed number. BR23 15:0 Destination X2 Coordinate (Right) 16 bit signed number. 4 31:0 Destination Base Address Base address of the destination surface: X=0, Y=0. When Dest Tiling is enabled (Bit_11 enabled), BR09 this address is limited to 4Kbytes. 5 31:16 Source Y1 Coordinate (Top) 16 bit signed number. BR26 15:0 Source X1 Coordinate (Left) 16 bit signed number. 6 31:16 Reserved Format: MBZ BR11 15:0 Source Pitch (double word aligned) and in DWords 2's complement. For Tiled Src (bit 15 enabled) this pitch is of 512Byte granularity for Tile-X, 128B granularity for Tile-Yand can be upto 128Kbytes (or 32KDwords). 7 31:0 Source Base Address Base address of the destination surface: X=0, Y=0. When Src Tiling is enabled (Bit_15 enabled), BR12 this address is limited to 4Kbytes. Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 63 1.9.15 XY_SRC_COPY_CHROMA_BLT XY_SRC_COPY_CHROMA_BLT Length Bias: 2 This BLT instruction performs a color source copy with chroma-keying where the only operands involved is a color source and destination of the same bit width. The source and destination operands may overlap, which means that the X and Y directions can be either forward or backwards. The BLT Engine takes care of all situations. The base addresses plus the X and Y coordinates determine if there is an overlap between the source and destination operands. If the base addresses of the source and destination are the same and the Source X1 is less than Destination X1, then the BLT Engine performs the accesses in the X-backwards access pattern. There is no need to look for an actual overlap. If the base addresses are the same and Source Y1 is less than Destination Y1, then the scan line accesses start at Destination Y2 with the corresponding source scan line and the strides are subtracted for every scan line access. The ROP value chosen must involve source and no pattern data in the ROP operation. DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 28:22 Instruction Target(Opcode) Default Value: 73h Format: Opcode 21:20 32bpp Byte Mask This field is only used for 32bpp. Value Name 00b [Default] 1xb Write Alpha Channel x1b Write RGB Channel 19:17 Transparency Range Mode (chroma-key) 16 Reserved Format: MBZ 15 Src Tiling Enable Value Name Description 0b Tiling Disabled (Linear) 1b Tiling Enabled (Tile-X or Tile-Y) 14:12 Reserved Format: MBZ 11 Dest Tiling Enable Value Name Description 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (Tile-X or Tile-Y) 10:8 Reserved 64 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 XY_SRC_COPY_CHROMA_BLT Format: MBZ 7:0 DWord Length Value Name 08h 1 31 Reserved Format: MBZ BR13 30 Clipping Enabled Value Name 0b Disabled 1b Enabled 29:26 Reserved Format: MBZ 25:24 Color Depth Value Name 00b 8 Bit Color 01b 16 Bit Color(565) 10b 16 Bit Color(1555) 11b 32 Bit Color 23:16 Raster Operation 15:0 Destination Pitch in DWords 2's complement For Tiled surfaces (bit_11 enabled) this pitch is of 512Byte granularity for Tile-X, 128B granularity for Tile-Y and can be upto 128Kbytes (or 32KDwords). 2 31:16 Destination Y1 Coordinate (Top) 16 bit signed number. BR22 15:0 Destination X1 Coordinate (Left) 16 bit signed number. 3 31:16 Destination Y2 Coordinate (Bottom) 16 bit signed number. BR23 15:0 Destination X2 Coordinate (Right) 16 bit signed number. 4 31:0 Destination Base Address Base address of the destination surface: X=0, Y=0. When Tiling is enabled (Bit_11 enabled), this BR09 address is limited to 4Kbytes. 5 31:16 Source Y1 Coordinate (Top) 16 bit signed number. BR26 15:0 Source X1 Coordinate (Left) 16 bit signed number. 6 31:16 Reserved Format: MBZ BR11 15:0 Source Pitch (double word aligned) and in DWords 2's complement. For Tiled Src (bit 15 enabled) this pitch is of 512Byte granularity for Tile-X, 128B granularity for Tile-Yand can be upto 128Kbytes (or 32KDwords). 7 31:0 Source Base Address Base address of the destination surface: X=0, Y=0. When Tiling is enabled (Bit_15 enabled), this BR12 address is limited to 4Kbytes. 8 31:0 Transparency Color Low (Chroma-key Low = Pixel Greater or Equal) BR18 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 65 XY_SRC_COPY_CHROMA_BLT 9 31:0 Transparency Color High (Chroma-key High = Pixel Less or Equal) BR19 1.9.16 XY_MONO_SRC_COPY_BLT XY_MONO_SRC_COPY_BLT Length Bias: 2 This BLT instruction performs a monochrome source copy where the only operands involved is a monochrome source and destination. The source and destination operands cannot overlap therefore the X and Y directions are always forward. All non-text monochrome sources are word aligned. At the end of a scan line of monochrome source, all bits until the next word boundary are ignored. The monochrome source data bit position field [2:0] indicates the bit position within the first byte of the scan line that should be used as the first source pixel which corresponds to the destination X1 coordinate. The monochrome source transparency mode indicates whether to use the source background color or de-assert the write enables when the bit in the source is 0. When the source bit is 1, then the source foreground color is used in the ROP operation. The ROP value chosen must involve source and no pattern data in the ROP operation. Negative Stride (= Pitch) is NOT ALLOWED. DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 28:22 Instruction Target(Opcode) Default Value: 54h Format: Opcode 21:20 32bpp Byte Mask This field is only used for 32bpp. Value Name 00b [Default] 1xb Write Alpha Channel x1b Write RGB Channel 19:17 Monochrome source data bit position of the first pixel within a byte per scan line. 16:12 Reserved Format: MBZ 11 Tiling Enable Value Name Description 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (Tile-X or Tile-Y) 66 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 XY_MONO_SRC_COPY_BLT 10:8 Reserved Format: MBZ 7:0 DWord Length Value Name 06h 1 31 Reserved Format: MBZ BR13 30 Clipping Enabled Value Name 0b Disabled 1b Enabled 29 Mono Source Transparency Mode Value Name 0 Use Background 1 Transparency Enabled 28:26 Reserved Format: MBZ 25:24 Color Depth Value Name 00b 8 Bit Color 01b 16 Bit Color(565) 10b 16 Bit Color(1555) 11b 32 Bit Color 23:16 Raster Operation 15:0 Destination Pitch in DWords 2's complement For Tiled surfaces (bit_11 enabled) this pitch is of 512Byte granularity for Tile-X, 128B granularity for Tile-Y and can be upto 128Kbytes (or 32KDwords). 2 31:16 Destination Y1 Coordinate (Top) 16 bit signed number. BR22 15:0 Destination X1 Coordinate (Left) 16 bit signed number. 3 31:16 Destination Y2 Coordinate (Bottom) 16 bit signed number. BR23 15:0 Destination X2 Coordinate (Right) 16 bit signed number. 4 31:0 Destination Base Address Base address of the destination surface: X=0, Y=0. When Tiling is enabled (Bit_11 enabled), this BR09 address is limited to 4Kbytes. 5 31:0 Source Address (address corresponding to DST X1,Y1) (Note no NPO2 change here). BR12 6 31:0 Source Background Color 8 bit = [7:0], 16 bit = [15:0], 32 bit = [31:0] BR18 7 31:0 Source Foreground Color 8 bit = [7:0], 16 bit = [15:0], 32 bit = [31:0] BR19 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 67 1.9.17 XY_MONO_SRC_COPY_ IMMEDIATE_BLT XY_MONO_SRC_COPY_IMMEDIATE_BLT Length Bias: 2 This instruction allows the Driver to send monochrome data through the instruction stream, eliminating the read latency of the source during command execution. The IMMEDIATE_BLT data MUST transfer an even number of doublewords and the exact number of quadwords. DWL indicates the total number of Dwords of immediate data. All non-text monochrome sources are word aligned. At the end of a scan line of monochrome source, all bits until the next word boundary are ignored. The Monochrome source data bit position field [2:0] indicates the bit position within the first byte of the scan line that should be used as the first source pixel which corresponds to the destination X1 coordinate. The monochrome source transparency mode indicates whether to use the source background color or de-assert the write enables when the bit in the source is 0. When the source bit is 1, then the source foreground color is used in the ROP operation. The ROP value chosen must involve source and no pattern data in the ROP operation. The monochrome source data supplied corresponds to the Destination X1 and Y1 coordinates. Negative Stride (= Pitch) is NOT ALLOWED. DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 28:22 Instruction Target(Opcode) Default Value: 71h Format: Opcode 21:20 32bpp Byte Mask This field is only used for 32bpp. Value Name 00b [Default] 1xb Write Alpha Channel x1b Write RGB Channel 19:17 Monochrome source data bit position of the first pixel within a byte per scan line. 16:12 Reserved Format: MBZ 11 Dest Tiling Enable Value Name Description 68 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 XY_MONO_SRC_COPY_IMMEDIATE_BLT 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (Tile-X or Tile-Y) 11 Src Tiling Enable Value Name Description 0b Tiling Disabled (Linear) 1b Tiling Enabled (Tile-X or Tile-Y) 10:8 Reserved Format: MBZ 7:0 DWord Length 05 + DWL = (Number of Immediate double words)h 1 31 Reserved Format: MBZ BR13 30 Clipping Enabled Value Name 0b Disabled 1b Enabled 29 Mono Source Transparency Mode Value Name 0b Transparency Enabled 1b Use Background 28:26 Reserved Format: MBZ 25:24 Color Depth Value Name 00b 8 Bit Color 01b 16 Bit Color(565) 10b 16 Bit Color(1555) 11b 32 Bit Color 23:16 Raster Operation 15:0 Destination Pitch in DWords 2's complement For Tiled surfaces (bit_11 enabled) this pitch is of 512Byte granularity for Tile-X, 128B granularity for Tile-Y and can be upto 128Kbytes (or 32KDwords). 2 31:16 Destination Y1 Coordinate (Top) 16 bit signed number. BR22 15:0 Destination X1 Coordinate (Left) 16 bit signed number. 3 31:16 Destination Y2 Coordinate (Bottom) 16 bit signed number. BR23 15:0 Destination X2 Coordinate (Right) 16 bit signed number. 4 31:0 Destination Base Address Base address of the destination surface: X=0, Y=0. When Tiling is enabled (Bit_11 enabled), this BR09 address is limited to 4Kbytes. 5 31:0 Source Background Color 8 bit = [7:0], 16 bit = [15:0], 32 bit = [31:0] BR18 6 31:0 Source Foreground Color 8 bit = [7:0], 16 bit = [15:0], 32 bit = [31:0] Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 69 XY_MONO_SRC_COPY_IMMEDIATE_BLT BR19 7 31:0 Immediate Data 0 8 31:0 Immediate Data 1 9..n 31:0 Immediate Data DWs 2 through DWORD_LENGTH (DWL-1) 1.9.18 XY_FULL_BLT XY_FULL_BLT Length Bias: 2 The full BLT is the most comprehensive BLT instruction. It provides the ability to specify all 3 operands: destination, source, and pattern. The source and pattern operands are the same bit width as the destination operand. The source and destination operands may overlap, which means that the X and Y directions can be either forward or backwards. The BLT Engine takes care of all situations. The base addresses plus the X and Y coordinates determine if there is an overlap between the source and destination operands. If the base addresses of the source and destination are the same and the Source X1 is less than Destination X1, then the BLT Engine performs the accesses in the X-backwards access pattern. There is no need to look for an actual overlap. If the base addresses are the same and Source Y1 is less than Destination Y1, then the scan line accesses start at Destination Y2 with the corresponding source scan line and the strides are subtracted for every scan line access. All scan lines and pixels that fall within the ClipRect Y and X coordinates are written. Only pixels within the ClipRectX coordinates and the Destination X coordinates are written using the raster operation. The Pattern Seeds correspond to Destination X = 0 (horizontal) and Y = 0 (vertical). The alignment is relative to the destination coordinates. The pixel of the pattern used / scan line is the (destination X coordinate + horizontal seed) modulo 8. The scan line of the pattern used is the (destination Y coordinate + vertical seed) modulo 8. DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 28:22 Instruction Target(Opcode) Default Value: 55h Format: Opcode 21:20 32bpp Byte Mask This field is only used for 32bpp. Value Name 00b [Default] 1xb Write Alpha Channel x1b Write RGB Channel 19:16 Reserved 70 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 XY_FULL_BLT Format: MBZ 15 Src Tiling Enable Value Name Description 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (Tile-X or Tile-Y) 14:12 Pattern Horizontal Seed Pixel of the scan line to start on corresponding to DST X=0. 11 Dest Tiling Enable Value Name Description 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (-X or Tile-Y) 10:8 Pattern Vertical Seed Starting scan line of the 8x8 pattern corresponding to DST Y=0. 7:0 DWord Length Default Value: 07h 1 31 Reserved Format: MBZ BR13 30 Clipping Enabled Value Name 0b Disabled 1b Enabled 29:26 Reserved Format: MBZ 25:24 Color Depth Value Name 00b 8 Bit Color 01b 16 Bit Color(565) 10b 16 Bit Color(1555) 11b 32 Bit Color 23:16 Raster Operation 15:0 Destination Pitch in DWords 2's complement For Tiled surfaces (bit_11 enabled) this pitch is of 512Byte granularity for Tile-X, 128B granularity for Tile-Y and can be upto 128Kbytes (or 32KDwords). 2 31:16 Destination Y1 Coordinate (Top) 16 bit signed number. BR22 15:0 Destination X1 Coordinate (Left) 16 bit signed number. 3 31:16 Destination Y2 Coordinate (Bottom) 16 bit signed number. BR23 15:0 Destination X2 Coordinate (Right) 16 bit signed number. 4 31:0 Destination Base Address Base address of the destination surface: X=0, Y=0. When Tiling is enabled (Bit_11 enabled), this BR09 address is limited to 4Kbytes. 5 31:16 Reserved Format: MBZ BR11 Should be programmed all 0's for 48bit addressing. Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 71 XY_FULL_BLT 15:0 Source Pitch (double word aligned and signed) and in DWords 2's complement. For Tiled Src (bit 15 enabled) this pitch is of 512Byte granularity for Tile-X, 128B granularity for Tile-Y and can be upto 128Kbytes (or 32KDwords). 6 31:16 Source Y1 Coordinate (Top) 16 bit signed number. BR26 15:0 Source X1 Coordinate (Left) 16 bit signed number. 7 31:0 Source Address Base address of the destination surface: X=0, Y=0. When Tiling is enabled (Bit_15 enabled), this BR12 address is limited to 4Kbytes. 8 31:0 Pattern Base (28:06 are implemented ) (Note no NPO2 change here). The pattern data must be located in linear BR15 memory. 1.9.19 XY_FULL_IMMEDIATE_PATTERN_BLT XY_FULL_IMMEDIATE_PATTERN_BLT Length Bias: 2 The full BLT is the most comprehensive BLT instruction. It provides the ability to specify all 3 operands: destination, source, and pattern. The source and immediate pattern operands are the same bit width as the destination operand. The immediate data sizes are 64 bytes (16 DWs), 128 bytes (32 DWs), or 256 (64 DWs) for 8, 16, and 32 bpp color patterns. DWL indicates the total number of Dwords of immediate data. The source and destination operands may overlap, which means that the X and Y directions can be either forward or backwards. The BLT Engine takes care of all situations. The base addresses plus the X and Y coordinates determine if there is an overlap between the source and destination operands. If the base addresses of the source and destination are the same and the Source X1 is less than Destination X1, then the BLT Engine performs the accesses in the X-backwards access pattern. There is no need to look for an actual overlap. If the base addresses are the same and Source Y1 is less than Destination Y1, then the scan line accesses start at Destination Y2 with the corresponding source scan line and the strides are subtracted for every scan line access. All scan lines and pixels that fall within the ClipRect Y and X coordinates are written. Only pixels within the ClipRectX coordinates and the Destination X coordinates are written using the raster operation. The Pattern Seeds correspond to Destination X = 0 (horizontal) and Y = 0 (vertical). The alignment is relative to the destination coordinates. The pixel of the pattern used / scan line is the (destination X coordinate + horizontal seed) modulo 8. The scan line of the pattern used is the (destination Y coordinate + vertical seed) modulo 8. DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 72 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 XY_FULL_IMMEDIATE_PATTERN_BLT 28:22 Instruction Target(Opcode) Default Value: 74h Format: Opcode 21:20 32bpp Byte Mask This field is only used for 32bpp. Value Name 00b [Default] 1xb Write Alpha Channel x1b Write RGB Channel 19:16 Reserved Format: MBZ 15 Src Tiling Enable Value Name Description 0b Tiling Disabled (Linear) 1b Tiling Enabled (Tile-X or Tile-Y) 14:12 Pattern Horizontal Seed (pixel of the scan line to start on corresponding to DST X=0) 11 Dest Tiling Enable Value Name Description 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (Tile-X or Tile-Y) 10:8 Reserved Format: MBZ 7:0 DWord Length 06 + DWL = (Number of Immediate double words)h 1 31 Reserved Format: MBZ BR13 30 Clipping Enabled Value Name 0b Disabled 1b Enabled 29:26 Reserved Format: MBZ 25:24 Color Depth Value Name 00b 8 Bit Color 01b 16 Bit Color(565) 10b 16 Bit Color(1555) 11b 32 Bit Color 23:16 Raster Operation 15:0 Destination Pitch in DWords 2's complement For Tiled surfaces (bit_11 enabled) this pitch is of 512Byte granularity for Tile-X, 128B granularity for Tile-Y and can be upto 128Kbytes (or 32KDwords). 2 31:16 Destination Y1 Coordinate (Top) 16 bit signed number. BR22 15:0 Destination X1 Coordinate (Left) 16 bit signed number. Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 73 XY_FULL_IMMEDIATE_PATTERN_BLT 3 31:16 Destination Y2 Coordinate (Bottom) 16 bit signed number. BR23 15:0 Destination X2 Coordinate (Right) 16 bit signed number. 4 31:0 Destination Base Address Base address of the destination surface: X=0, Y=0. When Src Tiling is enabled (Bit_15 enabled), this BR09 address is limited to 4Kbytes. 5 31:16 Reserved Format: MBZ BR11 Should be programmed all 0's for 48bit addressing. 15:0 Source Pitch (double word aligned and signed) and in DWords 2's complement. For Tiled Src (bit 11 enabled) this pitch is of 512Byte granularity for Tile-X, 128B granularity for Tile-Y and can be upto 128Kbytes (or 32KDwords). 6 31:16 Source Y1 Coordinate (Top) 16 bit signed number. BR26 15:0 Source X1 Coordinate (Left) 16 bit signed number. 7 31:0 Source Address Base address of the destination surface: X=0, Y=0. When Tiling is enabled (Bit 15 enabled), this BR12 address is limited to 4Kbytes. 8 31:0 Immediate Data 0 9 31:0 Immediate Data 1 10..n 31:0 Immediate Data DWs 2 through DWORD_LENGTH (DWL-1) 1.9.20 XY_FULL_MONO_SRC_BLT XY_FULL_MONO_SRC_BLT Length Bias: 2 The full BLT is the most comprehensive BLT instruction. It provides the ability to specify all 3 operands: destination, source, and pattern. The source operand is monochrome and the pattern operand is the same bit width as the destination. The monochrome source transparency mode indicates whether to use the source background color or de-assert the write enables when the bit in the source is 0. When the source bit is 1, then the source foreground color is used in the ROP operation. All non-text and non-immediate monochrome sources are word aligned. At the end of a scan line the monochrome source, the remaining bits until the next word boundary are ignored. The Monochrome source data bit position field [2:0] indicates which bit position within the first byte should be used as the first source pixel which corresponds to the Destination X1 coordinate. 74 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 XY_FULL_MONO_SRC_BLT All scan lines and pixels that fall within the ClipRect Y and X coordinates are written. Only pixels within the ClipRectX coordinates and the Destination X coordinates are written using the raster operation. The Pattern Seeds correspond to Destination X = 0 (horizontal) and Y = 0 (vertical). The alignment is relative to the destination coordinates. The pixel of the pattern used / scan line is the (destination X coordinate + horizontal seed) modulo 8. The scan line of the pattern used is the (destination Y coordinate + vertical seed) modulo 8. Negative Stride (= Pitch) is NOT ALLOWED DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 28:22 Instruction Target(Opcode) Default Value: 56h Format: Opcode 21:20 32bpp Byte Mask This field is only used for 32bpp. Value Name 00b [Default] 1xb Write Alpha Channel x1b Write RGB Channel 19:17 Monochrome source data bit position of the first pixel within a byte per scan line. 16:15 Reserved Format: MBZ 14:12 Pattern Horizontal Seed (pixel of the scan line to start on corresponding to DST X=0) 11 Tiling Enable Value Name Description 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (Tile-X or Tile-Y) 10:8 Pattern Vertical Seed Starting scan line of the 8x8 pattern corresponding to DST Y = 0. 7:0 DWord Length Value Name 07h 1 31 Reserved Format: MBZ BR13 30 Clipping Enabled Value Name 0b Disabled 1b Enabled 29 Mono Source Transparency Mode Value Name Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 75 XY_FULL_MONO_SRC_BLT 0 Use Background 1 Transparency Enabled 28:26 Reserved Format: MBZ 25:24 Color Depth Value Name 00b 8 Bit Color 01b 16 Bit Color(565) 10b 16 Bit Color(1555) 11b 32 Bit Color 23:16 Raster Operation 15:0 Destination Pitch in DWords 2's complement For Tiled surfaces (bit_11 enabled) this pitch is of 512Byte granularity for Tile-X, 128B granularity for Tile-Y and can be upto 128Kbytes (or 32KDwords). 2 31:16 Destination Y1 Coordinate (Top) 16 bit signed number. BR22 15:0 Destination X1 Coordinate (Left) 16 bit signed number. 3 31:16 Destination Y2 Coordinate (Bottom) 16 bit signed number. BR23 15:0 Destination X2 Coordinate (Right) 16 bit signed number. 4 31:0 Destination Base Address Base address of the destination surface: X=0, Y=0. When Tiling is enabled (Bit_11 enabled), this BR09 address is limited to 4Kbytes. 5 31:0 Mono Source Address (address corresponds to DST X1, Y1) (Note no NPO2 change here). BR12 6 31:0 Source Background Color 8 bit = [7:0], 16 bit = [15:0], 32 bit = [31:0] BR18 7 31:0 Source Foreground Color 8 bit = [7:0], 16 bit = [15:0], 32 bit = [31:0] BR19 8 31:0 Pattern Base Address (28:06 are implemented ) (Note no NPO2 change here). The pattern data must be located in linear BR15 memory. 76 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 1.9.21 XY_FULL_MONO_SRC_IMMEDIATE_PATTERN_BLT XY_FULL_MONO_SRC_IMMEDIATE_PATTERN_BLT Length Bias: 2 The full BLT is the most comprehensive BLT instruction. It provides the ability to specify all 3 operands: destination, source, and pattern. The source operand is a monochrome and the immediate pattern operand is the same bit width as the destination. The immediate data sizes are 64 bytes (16 DWs), 128 bytes (32 DWs), or 256 (64DWs) for 8, 16, and 32 bpp color patterns. The monochrome source transparency mode indicates whether to use the source background color or de-assert the write enables when the bit in the source is 0. When the source bit is 1, then the source foreground color is used in the ROP operation. All non-text monochrome sources are word aligned. At the end of a scan line the monochrome source, the remaining bits until the next word boundary are ignored. The Monochrome source data bit position field [2:0] indicates which bit position within the first byte should be used as the first source pixel which corresponds to the destination X1 coordinate. All scan lines and pixels that fall within the ClipRect Y and X coordinates are written. Only pixels within the ClipRectX coordinates and the Destination X coordinates are written using the raster operation. The Pattern Seeds correspond to Destination X = 0 (horizontal) and Y = 0 (vertical). The alignment is relative to the destination coordinates. The pixel of the pattern used / scan line is the (destination X coordinate + horizontal seed) modulo 8. The scan line of the pattern used is the (destination Y coordinate + vertical seed) modulo 8. Negative Stride (= Pitch) is NOT ALLOWED. DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 28:22 Instruction Target(Opcode) Default Value: 75h Format: Opcode 21:20 32bpp Byte Mask This field is only used for 32bpp. Value Name 00b [Default] 1xb Write Alpha Channel x1b Write RGB Channel Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 77 XY_FULL_MONO_SRC_IMMEDIATE_PATTERN_BLT 19:17 Monochrome source data bit position of the first pixel within a byte per scan line. 16:15 Reserved Format: MBZ 14:12 Pattern Horizontal Seed (pixel of the scan line to start on corresponding to DST X=0) 11 Tiling Enable Value Name Description 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (Tile-X or Tile-Y) 10:8 Reserved Format: MBZ 7:0 DWord Length 06 + DWL = (Number of Immediate double words)h 1 31 Reserved Format: MBZ BR13 30 Clipping Enabled Value Name 0b Disabled 1b Enabled 29 Mono Source Transparency Mode Value Name 0 Use Background 1 Transparency Enabled 28:26 Reserved Format: MBZ 25:24 Color Depth Value Name 00b 8 Bit Color 01b 16 Bit Color(565) 10b 16 Bit Color(1555) 11b 32 Bit Color 23:16 Raster Operation 15:0 Destination Pitch in DWords 2's complement For Tiled surfaces (bit_11 enabled) this pitch is of 512Byte granularity for Tile-X, 128B granularity for Tile-Y and can be upto 128Kbytes (or 32KDwords). 2 31:16 Destination Y1 Coordinate (Top) 16 bit signed number. BR22 15:0 Destination X1 Coordinate (Left) 16 bit signed number. 3 31:16 Destination Y2 Coordinate (Bottom) 16 bit signed number. BR23 15:0 Destination X2 Coordinate (Right) 16 bit signed number. 4 31:0 Destination Base Address Base address of the destination surface: X=0, Y=0. When Tiling is enabled (Bit_11 enabled), this BR09 address is limited to 4Kbytes. 5 31:0 Mono Source Address (address corresponds to DST X1, Y1) (Note no NPO2 change here). 78 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 XY_FULL_MONO_SRC_IMMEDIATE_PATTERN_BLT BR12 6 31:0 Source Background Color 8 bit = [7:0], 16 bit = [15:0], 32 bit = [31:0] BR18 7 31:0 Source Foreground Color 8 bit = [7:0], 16 bit = [15:0], 32 bit = [31:0] BR19 8 31:0 Immediate Data DW 0 9 31:0 Immediate Data DW 1 10..n 31:0 Immediate Data DWs 2 through DWORD_LENGTH (DWL-1) 1.9.22 XY_FULL_MONO_PATTERN_BLT XY_FULL_MONO_PATTERN_BLT Length Bias: 2 The full BLT is the most comprehensive BLT instruction. It provides the ability to specify all 3 operands: destination, source, and pattern. The pattern operand is monochrome and the source operand is the same bit width as the destination operand. The source and destination operands may overlap, which means that the X and Y directions can be either forward or backwards. The BLT Engine takes care of all situations. The base addresses plus the X and Y coordinates determine if there is an overlap between the source and destination operands. If the base addresses of the source and destination are the same and the Source X1 is less than Destination X1, then the BLT Engine performs the accesses in the X-backwards access pattern. There is no need to look for an actual overlap. If the base addresses are the same and Source Y1 is less than Destination Y1, then the scan line accesses start at Destination Y2 with the corresponding source scan line and the strides are subtracted for every scan line access. The monochrome pattern transparency mode indicates whether to use the pattern background color or de-assert the write enables when the bit in the source is 0. When the source bit is 1, then the pattern foreground color is used in the ROP operation. All scan lines and pixels that fall within the ClipRect Y and X coordinates are written. Only pixels within the ClipRectX coordinates and the Destination X coordinates are written using the raster operation. The Pattern Seeds correspond to Destination X = 0 (horizontal) and Y = 0 (vertical). The alignment is relative to the destination coordinates. The pixel of the pattern used / scan line is the (destination X coordinate + horizontal seed) modulo 8. The scan line of the pattern used is the (destination Y coordinate + vertical seed) modulo 8. Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 79 XY_FULL_MONO_PATTERN_BLT Setting both Solid Pattern Select =1 and Mono Pattern Transparency = 1 is mutually exclusive. The device implementation results in NO PIXELs DRAWN. DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 28:22 Instruction Target(Opcode) Default Value: 57h Format: Opcode 21:20 32bpp Byte Mask This field is only used for 32bpp. Value Name 00b [Default] 1xb Write Alpha Channel x1b Write RGB Channel 19:16 Reserved 15 Src Tiling Enable Value Name Description 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (Tile-X or Tile-Y) 14:12 Pattern Horizontal Seed (pixel of the scan line to start on corresponding to DST X=0) 11 Dest Tiling Enable Value Name Description 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (Tile-X or Tile-Y) 10:8 Pattern Vectical Seed Starting scan line of the 8x8 pattern corresponding to DST Y=0. 7:0 DWord Length Value Name 0Ah 1 31 Solid Pattern Select Value Name BR13 0 No Solid Pattern 1 Solid Pattern 30 Clipping Enabled Value Name 0b Disabled 1b Enabled 29 Reserved Format: MBZ 28:27 Mono Source Transparency Mode Value Name 0 Use Background 1 Transparency Enabled 26 Reserved Format: MBZ 80 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 XY_FULL_MONO_PATTERN_BLT 25:24 Color Depth Value Name 00b 8 Bit Color 01b 16 Bit Color(565) 10b 16 Bit Color(1555) 11b 32 Bit Color 23:16 Raster Operation 15:0 Destination Pitch in DWords 2's complement For Tiled surfaces (bit_11 enabled) this pitch is of 512Byte granularity for Tile-X, 128B granularity for Tile-Y and can be upto 128Kbytes (or 32KDwords). 2 31:16 Destination Y1 Coordinate (Top) 16 bit signed number. BR22 15:0 Destination X1 Coordinate (Left) 16 bit signed number. 3 31:16 Destination Y2 Coordinate (Bottom) 16 bit signed number. BR23 15:0 Destination X2 Coordinate (Right) 16 bit signed number. 4 31:0 Destination Base Address Base address of the destination surface: X=0, Y=0. When Tiling is enabled (Bit_11 enabled), this BR09 address is limited to 4Kbytes. 5 31:16 Reserved Format: MBZ BR11 15:0 Source Pitch (double word aligned and signed) and in DWords 2's complement. For Tiled Src (bit 15 enabled) this pitch is of 512Byte granularity for Tile-X, 128B granularity for Tile-Y and can be upto 128Kbytes (or 32KDwords). 6 31:16 Source Y1 Coordinate (Top) 16 bit signed number. BR26 15:0 Source X1 Coordinate (Left) 16 bit signed number. 7 31:0 Source Base Address (base address of the source surface: X=0, Y=0). When Src Tiling is enabled (Bit 15 enabled), this BR12 address is limited to 4Kbytes. 8 31:0 Pattern Background Color 8 bit = [7:0], 16 bit = [15:0], 32 bit = [31:0] BR16 9 31:0 Pattern Foreground Color 8 bit = [7:0], 16 bit = [15:0], 32 bit = [31:0] BR17 10 31:0 Pattern Data 0 (least significant DW) BR20 11 31:0 Pattern Data 1 (most significant DW) BR21 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 81 1.9.23 XY_FULL_MONO_PATTERN_MONO_SRC_BLT XY_FULL_MONO_PATTERN_MONO_SRC_BLT Length Bias: 2 The full BLT provides the ability to specify all 3 operands: destination, source, and pattern. The pattern and source operands are monochrome. The monochrome source transparency mode indicates whether to use the source background color or de-assert the write enables when the bit in the source is 0. When the source bit is 1, then the source foreground color is used in the ROP operation. All non-text monochrome sources are word aligned. At the end of a scan line the monochrome source, the remaining bits until the next word boundary are ignored. The Monochrome source data bit position field [2:0] indicates which bit position within the first byte should be used as the first source pixel which corresponds to the destination X1 coordinate. The monochrome pattern transparency mode indicates whether to use the pattern background color or de-assert the write enables when the bit in the pattern is 0. When the source bit is 1, then the pattern foreground color is used in the ROP operation. The monochrome source transparency mode works identical to the pattern transparency mode. All scan lines and pixels that fall within the ClipRect Y and X coordinates are written. Only pixels within the ClipRectX coordinates and the Destination X coordinates are written using the raster operation. The Pattern Seeds correspond to Destination X = 0 (horizontal) and Y = 0 (vertical). The alignment is relative to the destination coordinates. The pixel of the pattern used / scan line is the (destination X coordinate + horizontal seed) modulo 8. The scan line of the pattern used is the (destination Y coordinate + vertical seed) modulo 8. Setting both Solid Pattern Select =1 and Mono Pattern Transparency = 1 is mutually exclusive. The device implementation results in NO PIXELs DRAWN. Negative Stride (= Pitch) is NOT ALLOWED. DWord Bit Description 0 31:29 Client Default Value: 02h 2D Processor BR00 Format: Opcode 28:22 Instruction Target(Opcode) Default Value: 58h 82 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 XY_FULL_MONO_PATTERN_MONO_SRC_BLT Format: Opcode 21:20 32bpp Byte Mask This field is only used for 32bpp. Value Name 00b [Default] 1xb Write Alpha Channel x1b Write RGB Channel 19:17 Monochrome source data bit position of the first pixel within a byte per scan line. 16:15 Reserved Format: MBZ 14:12 Pattern Horizontal Seed (pixel of the scan line to start on corresponding to DST X=0) 11 Tiling Enable Value Name Description 0b Tiling Disabled (Linear Blit) 1b Tiling Enabled (Tile-X or Tile-Y) 10:8 Pattern Vertical Seed Starting scan line of the 8x8 pattern corresponding to DST Y = 0. 7:0 DWord Length Value Name 0Ah 1 31 Solid Pattern Select Value Name BR13 0 No Solid Pattern 1 Solid Pattern 30 Clipping Enabled Value Name 0b Disabled 1b Enabled 29 Mono Source Transparency Mode Value Name 0 Use Background 1 Transparency Enabled 28 Mono Pattern Transparency Mode Value Name 0 Use Background 1 Transparency Enabled 27:26 Reserved Format: MBZ 25:24 Color Depth Value Name 00b 8 Bit Color 01b 16 Bit Color(565) 10b 16 Bit Color(1555) 11b 32 Bit Color 23:16 Raster Operation 15:0 Destination Pitch in DWords Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 83 XY_FULL_MONO_PATTERN_MONO_SRC_BLT 2's complement For Tiled surfaces (bit_11 enabled) this pitch is of 512Byte granularity for Tile-X, 128B granularity for Tile-Y and can be upto 128Kbytes (or 32KDwords). 2 31:16 Destination Y1 Coordinate (Top) 16 bit signed number. BR22 15:0 Destination X1 Coordinate (Left) 16 bit signed number. 3 31:16 Destination Y2 Coordinate (Bottom) 16 bit signed number. BR23 15:0 Destination X2 Coordinate (Right) 16 bit signed number. 4 31:0 Destination Base Address Base address of the destination surface: X=0, Y=0. When Tiling is enabled (Bit_11 enabled), this BR09 address is limited to 4Kbytes. 5 31:0 Mono Source Address (address corresponds to DST X1, Y1) (Note no NPO2 change here). BR12 6 31:0 Source Background Color 8 bit = [7:0], 16 bit = [15:0], 32 bit = [31:0] BR18 7 31:0 Source Foreground Color 8 bit = [7:0], 16 bit = [15:0], 32 bit = [31:0] BR19 8 31:0 Pattern Background Color 8 bit = [7:0], 16 bit = [15:0], 32 bit = [31:0] BR16 9 31:0 Pattern Foreground Color 8 bit = [7:0], 16 bit = [15:0], 32 bit = [31:0] BR17 10 31:0 Pattern Data 0 (least significant DW) BR20 11 31:0 Pattern Data 1 (most significant DW) BR21 1.10 BLT Engine Instruction Field Definitions This section describes the BLT Engine instruction fields. These descriptions are in the format of register descriptions. These registers are internal and are not readable. Some of these registers are state that is saved and restored for supporting separate software threads. 84 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 1.10.1 BR00—BLT Opcode & Control BR00 - BLT Opcode and Control Register Space: MMIO: 0/2/0 Default Value: 0x00000000 DWord Bit Description 0 31 BLT Engine Busy This bit indicates whether the BLT Engine is busy (1) or idle (0). This bit is replicated in the SETUP BLT Opcode and Control register. Value Name 0 Idle [Default] 1 Busy 30 Setup Instruction Instruction Default Value: 0 The current instruction performs clipping (1). 29 Setup Monochrome Pattern This bit is decoded from the Setup instruction opcode to identify whether a color (0) or monochrome (1) pattern is used with the SCANLINE_BLT instruction. Value Name 0 Color [Default] 1 Monochrome 28:22 Instruction Target (Opcode) Default Value: 0000000b This is the contents of the Instruction Target field from the last BLT instruction. This field is used by the BLT Engine state machine to identify the BLT instruction it is to perform. The opcode specifies whether the source and pattern operands are color or monochrome. 21:20 32bpp Byte Mask This field is only used for 32bpp. Value Name 00b [Default] 1xb Write Alpha Channel x1b Write RGB Channel 19:17 Monochrome Source Start Default Value: 000b This field indicates the starting monochrome pixel bit position within a byte per scan line of the source operand. The monochrome source is word aligned which means that at the end of the scan line all bits should be discarded until the next word boundary. 16 Bit/Byte Packed Byte packed is for the NT driver. Value Name 0b Bit [Default] 1b Byte 15 Src Tiling Enable Value Name Project Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 85 BR00 - BLT Opcode and Control 0b Tiling Disabled (Linear) [Default] 1b Tiling enabled: Tile-X or Tile-Y 14:12 Horizontal Pattern Seed Default Value: 0b This field indicates the pattern pixel position which corresponds to X = 0. 11 Dest Tiling Enable When set to '1', this means that Blitter is executing in Tiled mode. If '0' it means that Blitter is in Linear mode. Blitter supports both Tile-X and Tile-Y modes. On reset, this bit will be '0'. This definition applies to only X,Y Blits. Value Name Project 0b Tiling Disabled (Linear blit) [Default] 1b Tiling enabled: Tile-X or Tile-Y 10:8 Transparency Range Mode These bits control whether or not the byte(s) at the destination corresponding to a given pixel will be conditionally written, and what those conditions are. This feature can make it possible to perform various masking functions in order to selectively write or preserve graphics data already at the destination. Value Name Description xx0b [Default] No color transparency mode enabled. This causes normal operation with regard to writing data to the destination. 001b [Source color transparency] The Transparency Color Low: (Pixel Greater or Equal) (source background register) and the Transparency Color High: (Pixel Less or Equal) (source foreground register) are compared to the source pixels. The range comparisons are done on each component (R,G,B) and then logically ANDed. If the source pixel components are not within the range defined by the Transparency Color registers, then the byte(s) at the destination corresponding to the current pixel are written with the result of the bit-wise operation. 011b [Source and Alpha color transparency] The Transparency Color Low: (Pixel Greater or Equal) (source background register) and the Transparency Color High: (Pixel Less or Equal) (source foreground register) are compared to the source pixels. The range comparisons are done on each component (A,R,G,B) and then logically ANDed. If the source pixel components are not within the range defined by the Transparency Color registers, then the byte(s) at the destination corresponding to the current pixel are written with the result of the bit-wise operation." 101b [Destination and Alpha color transparency] The Transparency Color Low: (Pixel Greater or Equal) (source background register) and the Transparency Color High: (Pixel Less or Equal) (source foreground register) are compared to the destination pixels. The range comparisons are done on each component (A,R,G,B) and then logically ANDed. If the destination pixels are within the range, then the byte(s) at the destination corresponding to the current pixel are written with the result of the bit-wise operation. 111b [Destination color transparency] The Transparency Color Low: (Pixel Greater or Equal) (source background register) and the Transparency Color High: (Pixel Less or Equal) (source foreground register) are compared to the destination pixels. The range comparisons are done on each component (R,G,B) and then logically ANDed. If the destination pixels are within the range, then the byte(s) at the destination corresponding to the current pixel are written with the result of the bit-wise operation. 7:5 Pattern Vertical Seed Default Value: 000b 86 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 BR00 - BLT Opcode and Control This field specifies the pattern scan line which corresponds to Y=0. 4 Destination Read Modify Write Default Value: 0b This bit is decoded from the last instruction's opcode field and Destination Transparency Mode to identify whether a Destination read is needed. 3 Color Source Default Value: 0b This bit is decoded from the last instructions opcode field to identify whether a color (1) source is used. 2 Monochrome Source Default Value: 0b This bit is decoded from the last instructions opcode field to identify whether a monochrome (1) source is used. 1 Color Pattern Default Value: 0b This bit is decoded from the last instructions opcode field to identify whether a color (1) pattern is used. 0 Monochrome Pattern Default Value: 0b This bit is decoded from the last instructions opcode field to identify whether a monochrome (1) pattern is used. 1.10.2 BR01—Setup BLT Raster OP, Control, and Destination Offset BR01 - Setup BLT Raster OP, Control, and Destination Offset Register Space: MMIO: 0/2/0 Default Value: 0x00000000 DWord Bit Description 0 31 Solid Pattern Select This bit applies only when the pattern data is monochrome. This bit determines whether or not the BLT Engine actually performs read operations from the frame buffer in order to load the pattern data. Use of this feature to prevent these read operations can increase BLT Engine performance, if use of the pattern data is indeed not necessary. The BLT Engine is configured to accept either monochrome or color pattern data via the opcode field. Value Name Description 0b [Default] This causes normal operation with regard to the use of the pattern data. The BLT Engine proceeds with the process of reading the pattern data, and the pattern data is used as the pattern operand for all bit-wise operations. 1b The BLT Engine forgoes the process of reading the pattern data, the presumption is made that all of the bits of the pattern data are set to 0, and the pattern operand for all bit-wise operations is forced to the background color specified in the Color Expansion Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 87 BR01 - Setup BLT Raster OP, Control, and Destination Offset Background Color Register. 30 Clipping Enabled Value Name 0b [Default] 1b 29 Monochrome Source Transparency Mode This bit applies only when the source data is in monochrome. This bit determines whether or not the byte(s) at the destination corresponding to the pixel to which a given bit of the source data also corresponds will actually be written if that source data bit has the value of 0. This feature can make it possible to use the source as a transparency mask. The BLT Engine is configured to accepted either monochrome or color source data via the opcode field. Value Name Description 0b [Default] This causes normal operation with regard to the use of the source data. Wherever a bit in the source data has the value of 0, the color specified in the background color register is used as the source operand in the bit-wise operation for the pixel corresponding to the source data bit, and the bytes at the destination corresponding to that pixel are written with the result. 1b Wherever a bit in the source data has the value of 0, the byte(s) at the destination corresponding to the pixel to which the source data bit also corresponds are simply not written, and the data at those byte(s) at the destination are allowed to remain unchanged. 28 Monochrome Pattern Transparency Mode This bit applies only when the pattern data is monochrome. This bit determines whether or not the byte(s) at the destination corresponding to the pixel to which a given bit of the pattern data also corresponds will actually be written if that pattern data bit has the value of 1. This feature can make it possible to use the pattern as a transparency mask. The BLT Engine is configured to accepted either monochrome or color pattern data via the opcode field. Value Name Description 0b [Default] This causes normal operation with regard to the use of the pattern data. Wherever a bit in the pattern data has the value of 0, the color specified in the background color register is used as the pattern operand in the bit-wise operation for the pixel corresponding to the pattern data bit, and the bytes at the destination corresponding to that pixel are written with the result. 1b Wherever a bit in the pattern data has the value of 0, the byte(s) at the destination corresponding to the pixel to which the pattern data bit also corresponds are simply not written, and the data at those byte(s) at the destination are allowed to remain unchanged. 27:26 32bpp Byte Mask This bit applies only when the pattern data is monochrome. This bit determines whether or not the byte(s) at the destination corresponding to the pixel to which a given bit of the pattern data also corresponds will actually be written if that pattern data bit has the value of 1. This feature can make it possible to use the pattern as a transparency mask. The BLT Engine is configured to accepted either monochrome or color pattern data via the opcode field. Value Name 00b [Default] 1xb Write Alpha Channel x1b Write RGB Channel 25:24 Color Depth Value Name 00b 8 Bit Color Depth [Default] 88 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 BR01 - Setup BLT Raster OP, Control, and Destination Offset 01b 16 Bit Color Depth 10b 16 Bit Color Depth 11b 32 Bit Color Depth 23:16 Raster Operation Select These 8 bits are used to select which one of 256 possible raster operations is to be performed by the BLT Engine. The opcode field must indicate a monochrome source if ROP = F0. 15:0 Destination Pitch (Offset) For non-XY Blits, the signed 16bit field allows for specifying upto + 32Kbytes signed pitches in bytes (same as before). For X, Y Blits with tiled-X surfaces, the pitch for Destination will be 512Byte aligned and should be programmable upto + 128Kbytes. For X, Y Blits with tiled-Y surfaces, the pitch for Destination will be 128Byte aligned and should be programmable upto + 128Kbytes. In this case, this 16bit signed pitch field is used to specify upto + 32KDWords. For X, Y blits with nontiled surfaces (linear surfaces), this 16bit field can be programmed to byte specification of upto + 32Kbytes (same as before). These 16 bits store the signed memory address offset value by which the destination address originally specified in the Destination Address Register is incremented or decremented as each scan line's worth of destination data is written into the frame buffer by the BLT Engine, so that the destination address will point to the next memory address to which the next scan line's worth of destination data is to be written. If the intended destination of a BLT operation is within on-screen frame buffer memory, this offset is normally set so that each subsequent scan line's worth of destination data lines up vertically with the destination data in the scan line, above. However, if the intended destination of a BLT operation is within off-screen memory, this offset can be set so that each subsequent scan line's worth of destination data is stored at a location immediately after the location where the destination data for the last scan line ended, in order to create a single contiguous block of bytes of destination data at the destination. 1.10.3 BR05—Setup Expansion Background Color BR05 - Setup Expansion Background Color Register Space: MMIO: 0/2/0 Default Value: 0x00000000 DWord Bit Description 0 31:0 Setup Expansion Background Color Bits These bits provide the one, two, or four bytes worth of color data that select the background color to be used in the color expansion of monochrome pattern or source data for either the SCANLINE_BLT or TEXT_BLT instructions. BR05 is also used as the solid pattern for the PIXEL_BLT instruction. Whether one, two, or three bytes worth of color data is needed depends upon the color depth to which the BLT Engine has been set. For a color depth of 32bpp, 16bpp and 8bpp, bits [31:0], [15:0] and [7:0], respectively, are used. Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 89 1.10.4 BR06—Setup Expansion Foreground Color BR06 - Setup Expansion Foreground Color Register Space: MMIO: 0/2/0 Default Value: 0x00000000 DWord Bit Description 0 31:0 Setup Expansion Foreground Color Bits These bits provide the one, two, or four bytes worth of color data that select the foreground color to be used in the color expansion of monochrome pattern or source data for either the SCANLINE_BLT or TEXT_BLT instructions. Whether one, two, or three bytes worth of color data is needed depends upon the color depth to which the BLT Engine has been set. For a color depth of 32bpp, 16bpp and 8bpp, bits [31:0], [15:0] and [7:0], respectively, are used. 1.10.5 BR07— Setup Blit Color Pattern Address BR07 - Setup Blit Color Pattern Address Register Space: MMIO: 0/2/0 Default Value: 0x00000000 DWord Bit Description 0 31:29 Reserved Format: MBZ 28:6 Setup Blit Color Pattern Address These 26 bits specify the starting address of the (8X8) pixel color pattern from the SETUP_BLT instruction. This register works identically to the Pattern Address register (BR15), but this version is only used with the SCANLINE_BLT instruction execution (the actual programming for this, is done in XY_SETUP_BLT command). The pattern data must be located in linear memory. The pattern data must be located on a pattern-size boundary. The pattern is always of 8x8 pixels, and therefore, its size is dependent upon its pixel depth. The pixel depth may be 8, 16, or 32 bits per pixel if the pattern is in color (the pixel depth of a color pattern must match the pixel depth to which the graphics system has been set). Monochrome patterns require 8 bytes and is supplied through the instruction. Color patterns of 8, 16, and 32 bits per pixel color depth must start on 64-byte, 128-byte and 256-byte boundaries, respectively. 5:0 Reserved Format: MBZ 90 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 1.10.6 BR09—Destination Address BR09 - Destination Address Register Space: MMIO: 0/2/0 Default Value: 0x00000000 DWord Bit Description 0 31:0 Destination Address Bits When tiling is enabled for XY-blits, this base address should be limited to 4KB. Otherwise for XY blits, there is no restriction and it is same as before. These specify the starting pixel address of the destination data. This register is also the working destination address register and changes as the BLT Engine performs the accesses. Used as the scan line address (Destination Y Address and Destination Y1 Address) for BLT instructions: PIXEL_BLT, SCANLINE_BLT, and TEXT_BLT. In this case the address points to the first pixel in a scan line and is compared with the ClipRect Y1 and Y2 address registers to determine whether the scan line should be written or not. The Destination Y1 address is the top scan line to be written for text. Note that for non-XY blits (COLOR_BLT, SRC_COPY_BLT), this address points to the first byte to be written. Note: Some instructions affect only one scan line (requiring only one coordinate); other instructions affect multiple scan lines and need both coordinates. 1.10.7 BR11—BLT Source Pitch (Offset) BR11 - BLT Source Pitch (Offset) Register Space: MMIO: 0/2/0 Default Value: 0x00000000 DWord Bit Description 0 15:0 Source Pitch (Offset) For non-XY Blits with color source operand (SRC_COPY_BLT), the signed 16bit field allows for specifying upto + 32Kbytes signed pitch in bytes (same as before). For X, Y Blits with tiled-X surfaces, the pitch for Color Source will be 512Byte aligned and should be programmable upto + 128Kbytes. For X, Y Blits with tiled-Y surfaces, the pitch for Color Source will be 128Byte aligned and should be programmable upto + 128Kbytes. In this case, this 16bit signed pitch field is used to specify upto + 32KDWords. For X, Y blits with nontiled color source surfaces (linear surfaces), this 16bit field can be programmed to byte specification of upto + 32Kbytes (same as before). When the color source data is located within the frame buffer or AGP aperture, these signed 16 bits store the memory address offset (pitch) value by which the source address originally specified in the Source Address Register is incremented or decremented as each scan line's worth of source data is read from the frame buffer by the BLT Engine, so that the source address will point to the next memory address from which the next scan line's worth of source data is to be read. Note that if the intended source of a BLT operation is within on-screen frame buffer memory, this offset is normally set to accommodate the fact that each subsequent scan line's worth of source data lines up vertically with the source data in the scan line, above. However, if the intended source of a BLT operation is within off- screen memory, this offset can be set to accommodate a situation in which the source data exists as a single contiguous block of bytes where in each subsequent scan line's worth of source data is stored at a location immediately after the location where the source data for the last scan line ended. Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 91 1.10.8 BR12—Source Address BR12 - Source Address Register Space: MMIO: 0/2/0 Default Value: 0x00000000 DWord Bit Description 0 31:0 Source Address Bits When tiling is enabled for XY-blits with Color source surfaces, this base address should be limited to 4KB. Otherwise for XY blits, there is no restriction and it is same as before, including for monosource and text blits. Note that for non-XY blit with Color Source (SRC_COPY_BLT), this address points to the first byte to be read. These specify the starting pixel address of the color source data. The lower 3 bits are used to indicate the position of the first valid byte within the first Quadword of the source data. 1.10.9 BR13—BLT Raster OP, Control, and Destination Pitch BR13 - BLT Raster OP, Control, and Destination Pitch Register Space: MMIO: 0/2/0 Default Value: 0x00000000 DWord Bit Description 0 31 Solid Pattern Select This bit applies only when the pattern data is monochrome. This bit determines whether or not the BLT Engine actually performs read operations from the frame buffer in order to load the pattern data. Use of this feature to prevent these read operations can increase BLT Engine performance, if use of the pattern data is indeed not necessary. The BLT Engine is configured to accept either monochrome or color pattern data via the opcode field. Value Name Description 0 [Default] This causes normal operation with regard to the use of the pattern data. The BLT Engine proceeds with the process of reading the pattern data, and the pattern data is used as the pattern operand for all bit-wise operations. 1 The BLT Engine forgoes the process of reading the pattern data, the presumption is made that all of the bits of the pattern data are set to 0, and the pattern operand for all bit-wise operations is forced to the background color specified in the Color Expansion Background Color Register. 30 Clipping Enabled Default Value: 0 29 Monochrome Source Transparency Mode This bit applies only when the source data is in monochrome. This bit determines whether or not the byte(s) at the destination corresponding to the pixel to which a given bit of the source data also corresponds will actually be written if that source data bit has the value of 0. This feature can make it possible to use the source as a transparency mask. The BLT Engine is configured to accepted either monochrome or color source data via the opcode field. Value Name Description 0 [Default] This causes normal operation with regard to the use of the source data. Wherever a bit in the source data has the value of 0, the color specified in the background color register is used as the source operand in the bit-wise operation for the pixel 92 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 BR13 - BLT Raster OP, Control, and Destination Pitch corresponding to the source data bit, and the bytes at the destination corresponding to that pixel are written with the result. 1 Where a bit in the source data has the value of 0, the byte(s) at the destination corresponding to the pixel to which the source data bit also corresponds are simply not written, and the data at those byte(s) at the destination are allowed to remain unchanged. 28 Monochrome Pattern Transparency Mode This bit applies only when the pattern data is monochrome. This bit determines whether or not the byte(s) at the destination corresponding to the pixel to which a given bit of the pattern data also corresponds will actually be written if that pattern data bit has the value of 1. This feature can make it possible to use the pattern as a transparency mask. The BLT Engine is configured to accepted either monochrome or color pattern data via the opcode in the Opcode and Control register. Value Name Description 0 [Default] This causes normal operation with regard to the use of the pattern data. Where a bit in the pattern data has the value of 0, the color specified in the background color register is used as the pattern operand in the bit-wise operation for the pixel corresponding to the pattern data bit, and the bytes at the destination corresponding to that pixel are written with the result. 1 Wherever a bit in the pattern data has the value of 0, the byte(s) at the destination corresponding to the pixel to which the pattern data bit also corresponds are simply not written, and the data at those byte(s) at the destination are allowed to remain unchanged. 27:26 32bpp Byte Mask This field is only used for 32bpp. Value Name 00b [Default] 1xb Write Alpha Channel x1b Write RGB Channel 25:24 Color Depth Value Name 00b 8 Bit Color Depth [Default] 01b 16 Bit Color Depth 10b 24 Bit Color Depth 11b Reserved 23:16 Raster Operation Select Default Value: 00000000b These 8 bits are used to select which one of 256 possible raster operations is to be performed by the BLT Engine. The opcode must indicate a monochrome source operand if ROP = F0. 15:0 Destination Pitch(Offset) These 16 bits store the signed memory address offset value by which the destination address originally specified in the Destination Address Register is incremented or decremented as each scan line's worth of destination data is written into the frame buffer by the BLT Engine, so that the destination address will point to the next memory address to which the next scan line's worth of destination data is to be written. If the intended destination of a BLT operation is within on-screen frame buffer memory, this offset is normally set so that each subsequent scan line's worth of destination data lines up vertically with the destination data in the scan line, above. However, if the intended destination of a BLT operation is within off-screen memory, this offset can be set so that each subsequent scan line's worth of destination data is stored at a location immediately after the location where the destination data for the last scan line ended, in order to create Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 93 BR13 - BLT Raster OP, Control, and Destination Pitch a single contiguous block of bytes of destination data at the destination. 1.10.10 BR14—Destination Width & Height BR14 - Destination Width and Height Register Space: MMIO: 0/2/0 Default Value: 0x00000000 BR14 contains the values for the height and width of the data to be BLT. If these values are not correct, such that the BLT Engine is either expecting data it does not receive or receives data it did not expect, the system can hang. DWord Bit Description 0 31:29 Reserved 28:16 Destination Height These 13 bits specify the height of the destination data in terms of the number of scan lines. This is a working register. 15:13 Reserved 12:0 Destination Byte Width These 13 bits specify the width of the destination data in terms of the number of bytes per scan line. The number of pixels per scan line into which this value translates depends upon the color depth to which the graphics system has been set. 1.10.11 BR15—Color Pattern Address BR15 - Color Pattern Address Register Space: MMIO: 0/2/0 Default Value: 0x00000000 DWord Bit Description 0 31:29 Reserved Format: MBZ 28:6 Color Pattern Address There is no change to the Color Pattern address specification due to Non-Power-of-2 change. It remains the same as before. The pattern data must be located in linear memory. These 26 bits specify the starting address of the (8X8) pixel color pattern. The pattern data must be located on a pattern-size boundary. The pattern is always of 8x8 pixels, and therefore, its size is dependent upon its pixel depth. The pixel depth may be 8, 16, or 32 bits per pixel if the pattern is in color (the pixel depth of a color pattern must match the pixel depth to which the graphics system has been set). Monochrome patterns require 8 bytes and are applied through the instruction. Color patterns of 8, 16, and 32 bits per pixel color depth must start on 64-byte, 128-byte and 256-byte boundaries, respectively. 5:0 Reserved Format: MBZ 94 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 1.10.12 BR16—Pattern Expansion Background & Solid Pattern Color BR16 - Pattern Expansion Background and Solid Pattern Color Register Space: MMIO: 0/2/0 Default Value: 0x00000000 DWord Bit Description 0 31:0 Pattern Expansion Background Color Bits These bits provide the one, two, or four bytes worth of color data that select the background color to be used in the color expansion of monochrome pattern data during BLT operations. Whether one, two, or four bytes worth of color data is needed depends upon the color depth to which the BLT Engine has been set. For a color depth of 32bpp, 16bpp and 8bpp, bits [31:0], [15:0] and [7:0], respectively, are used. 1.10.13 BR17—Pattern Expansion Foreground Color BR17 - Pattern Expansion Foreground Color Register Space: MMIO: 0/2/0 Default Value: 0x00000000 DWord Bit Description 0 31:0 Pattern Expansion Background Color Bits These bits provide the one, two, or four bytes worth of color data that select the foreground color to be used in the color expansion of monochrome pattern data during BLT operations. Whether one, two, or four bytes worth of color data is needed depends upon the color depth to which the BLT Engine has been set. For a color depth of 32bpp, 16bpp and 8bpp, bits [31:0], [15:0] and [7:0], respectively, are used. 1.10.14 BR18—Source Expansion Background, and Destination Color BR18 - Source Expansion Background and Destination Color Register Space: MMIO: 0/2/0 Default Value: 0x00000000 DWord Bit Description 0 31:0 Source Expansion Background Color Bits These bits provide the one, two, or four bytes worth of color data that select the background color to be used in the color expansion of monochrome source data during BLT operations. This register is also used to support destination transparency mode and Solid color fill. Whether one, two, three, or four bytes worth of color data is needed depends upon the color depth to which the BLT Engine has been set. For a color depth of 32bpp, 16bpp and 8bpp, bits [31:0], [15:0] and [7:0], respectively, are used. Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 95 1.10.15 BR19—Source Expansion Foreground Color BR19 - Source Expansion Foreground Color Register Space: MMIO: 0/2/0 Default Value: 0x00000000 DWord Bit Description 0 31:0 Pattern/Source Expansion Foreground Color Bits These bits provide the one, two, or four bytes worth of color data that select the foreground color to be used in the color expansion of monochrome source data during BLT operations. Whether one, two, or four bytes worth of color data is needed depends upon the color depth to which the BLT Engine has been set. For a color depth of 32bpp, 16bpp and 8bpp, bits [31:0], [15:0] and [7:0], respectively, are used. 96 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 2. Blitter (Blt) Engine Command Streamer The blitter pipeline has its own command streamer and operates completely independently of the other command streamers. This command streamer supports a separate set of registers starting at offset 20000h. 2.1 Registers for Blitter Engine 2.1.1 Introduction Each register is at the same offset from 020000h as its primary counterpart is offset from 02000h. 2.1.2 GAB PWR CTX STORAGE REGISTERS 2.1.2.1 GAB_CTL_REG – GAB unit Control Register GAB_CTL_REG - GAB unit Control Register Source: BlitterCS Default Value: 0x000000BF Access: R/W Size (in bits): 32 Address: 24000h DefaultValue=FF0000BFh Trusted Type = 1 DWord Bit Description 0 31:9 Reserved 8 Continue after Page Fault If set to 1: upon receiving a page fault when requesting an address translation, GAB will set address bit 39 to 1 and continue. If set to 0: GAB will hang on a page fault. Default = b0. 7:6 PPGTT BCS TLB LRA MIN Default Value: 10b TLB Depth Partitioning Register In PP GTT Mode. 5:4 GAB write request priority signal value used in GAC arbitration Default Value: 11b 3:2 GAB read only request priority signal value used in GAC arbitration Default Value: 11b 1:0 GAB read request priority signal value used in GAC arbitration Default Value: 11b Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 97 2.1.3 GFX TLB In Use Virtual Address Registers. 2.1.3.1 BCSTLB_VA — BCS TLB Virtual Page Address Registers BCSTLB_VA - BCS TLB Virtual Page Address Registers Register Space: MMIO: 0/2/0 Source: BlitterCS Default Value: 0x00000000 Access: RO Size (in bits): 32 Trusted Type: 1 Address: 24800h-248FCh This register is directly mapped to the current Virtual Addresses in the BCS TLB. DWord Bit Description 0 31:12 ADDRESS Format: GraphicsAddress[31:12] PAGE VIRTUAL ADDRESS. 11:0 RESERVED Format: MBZ 98 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 2.1.3.2 BLBTLB_VA — Virtual page Address Registers BLBTLB_VA - BLBTLB_VA Virtual page Address Registers Register Space: MMIO: 0/2/0 Source: BlitterCS Default Value: 0x00000000 Access: RO Size (in bits): 32 Trusted Type: 1 Address: 24900h-249FCh This register is directly mapped to the current Virtual Addresses in the BLB TLB. DWord Bit Description 0 31:12 ADDRESS Format: GraphicsAddress[31:12] PAGE VIRTUAL ADDRESS 11:0 RESERVED Format: MBZ 2.1.3.3 CTXTLB_VA — Virtual page Address Registers CTXTLB_VA - CTXTLB_VA Virtual page Address Registers Register Space: MMIO: 0/2/0 Source: BlitterCS Default Value: 0x00000000 Access: RO Size (in bits): 32 Trusted Type: 1 Address: 24A00h-24AFCh This register is directly mapped to the current Virtual Addresses in the CTX TLB. DWord Bit Description 0 31:12 ADDRESS Format: GraphicsAddress[31:12] PAGE VIRTUAL ADDRESS 11:0 RESERVED Format: MBZ Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 99 2.1.3.4 PDTLB_VA — Virtual page Address Registers PDTLB_VA - PDTLB_VA Virtual page Address Registers Register Space: MMIO: 0/2/0 Source: BlitterCS Default Value: 0x00000000 Access: RO Size (in bits): 32 Trusted Type: 1 Address: 24B00h-24BFCh This register is directly mapped to the current Virtual Addresses in the PD TLB. DWord Bit Description 0 31:12 ADDRESS Format: GraphicsAddress[31:12] PAGE VIRTUAL ADDRESS 11:0 RESERVED Format: MBZ 2.1.3.5 BCSTLB_VLD — Valid Bit Vector for BCS TLB BCSTLB_VLD - Valid Bit Vector for BCS TLB Register Space: MMIO: 0/2/0 Source: BlitterCS Default Value: 0x00000000 Access: RO Size (in bits): 32 Trusted Type: 1 Address: 24780h-24783h This register contains the valid bits for entries 0-31 of BCS TLB. DWord Bit Description 0 31:4 Reserved 3:0 Valid bits per entry 100 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 2.1.3.6 BLBTLB_VLD — Valid Bit Vector for BLB TLB BLBTLB_VLD - Valid Bit Vector for BLB TLB Register Space: MMIO: 0/2/0 Source: BlitterCS Default Value: 0x00000000 Access: RO Size (in bits): 32 Trusted Type: 1 Address: 24784h-24787h This register contains the valid bits for entries 0-31 of BLB TLB. DWord Bit Description 0 31:8 Reserved 7:0 Valid bits per entry 2.1.3.7 CTXTLB_VLD — Valid Bit Vector for CTX TLB CTX_TLB_VLD - Valid Bit Vector for CTX TLB Register Space: MMIO: 0/2/0 Source: BlitterCS Default Value: 0x00000000 Access: RO Size (in bits): 32 Trusted Type: 1 Address: 24788h-2478Bh This register contains the valid bits for entries 0-31 of CTX TLB. DWord Bit Description 0 31:1 Reserved 0 Valid bits per entry Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 101 2.1.3.8 PDTLB_VLD — Valid Bit Vector for PD TLB PDTLB_VLD - Valid Bit Vector for PD TLB Register Space: MMIO: 0/2/0 Source: BlitterCS Default Value: 0x00000000 Access: RO Size (in bits): 32 Trusted Type: 1 Address: 2478Ch-2478Fh This register contains the valid bits for entries 0-31 of PD TLB. DWord Bit Description 0 31:8 Reserved 7:0 Valid bits per entry 2.1.4 GFX Pending TLB cycles information registers. The following registers contain information about cycles that did not complete their TLB translation. Information is organized as 64 entries, where each entry has a valid and ready bit, collapsed into separate registers. 2.1.4.1 BCS_TLBPEND_VLD0 - BCS Valid Bit Vector for TLBPEND registers BCS_TLBPEND_VLD0 - BCS Valid Bit Vector for TLBPEND registers Register Space: MMIO: 0/2/0 Source: BlitterCS Default Value: 0x00000000 Access: RO Size (in bits): 32 Trusted Type: 1 Address: 24700h-24703h This register contains the valid bits for entries 0-31 of TLBPEND structure(Cycles pending TLB translation). DWord Bit Description 0 31:0 Valid bits per entry 102 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 2.1.4.2 BCS_TLBPEND_RDY0 - BCS Ready Bit Vector for TLBPEND registers BCS_TLBPEND_RDY0 - BCS Ready Bit Vector for TLBPEND Registers Register Space: MMIO: 0/2/0 Source: BlitterCS Default Value: 0x00000000 Access: RO Size (in bits): 32 Trusted Type: 1 Address: 24708h-2470Bh This register contains the ready bits for entries 0-31 of TLBPEND structure (Cycles pending TLB translation). DWord Bit Description 0 31:0 Ready bits per entry 2.1.4.3 TLBPEND_SEC0 — Section 0 of TLBPEND entry TLBPEND_SEC0 - Section 0 of TLBPEND Entry Register Space: MMIO: 0/2/0 Source: RenderCS Default Value: 0x00000000 Access: R/W Size (in bits): 32 Trusted Type: 1 Address: 04400h-044FCh This register is directly mapped to the TLBPEND Array in the Graphic Arbiter. DWord Bit Description 0 31 vtstatus This bit will be used in conjunction with the ready bit to determine the stage of the translation. See table below. 30:28 GTT bits Bits 3:1 of the GTT entry used to translate the Virtual Address. 000 if translation is pending. 27:0 Current address The value of this field depends on the stage of the TLB translation for this entry: VA – bits 27:20 = 00, bits 19:0 = Bits 31:12 of the Virtual Address of the cycle. Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 103 2.1.4.4 BCS_TLBPEND_SEC1 — BCS Section 1 of TLBPEND entry BCS_TLBPEND_SEC1 - BCS Section 1 of TLBPEND entry Register Space: MMIO: 0/2/0 Source: BlitterCS Default Value: 0x00000000 Access: RO Size (in bits): 32 Trusted Type: 1 Address: 24500h-245FCh This register is directly mapped to the current Virtual Addresses in the MTTLB (Texture and constant cache TLB) DWord Bit Description 0 31 vtstatus This bit will be used in conjunction with the ready bit to determine the stage of the translation. See table in section 0 register. 30:28 Reserved 27:24 PAT entry Location of Physical Address in Physical Address Table. 23:22 Reserved 21:20 Surface format Value Name 0xb Linear 10b Tile X 11b Tile Y 19:14 Cache line offset in page 13:10 Cacheability Control Bits 9 ZLR bit indicates a zero length read 8:2 TAG 1:0 SRC ID 00/01=BCS; 10/11= BLB 104 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 2.1.5 GAB Error Reporting Register GAB Error Reporting Register Register Space: MMIO: 0/2/0 Source: BlitterCS Default Value: 0x00000000 Access: RO Size (in bits): 32 Trusted Type: 1 Address: 24094h This register is directly mapped for the Error Reporting Register DWord Bit Description 0 31:8 Reserved 7 HWSP GGTT fetch yields an invalid entry 6 VTD fetch yields an invalid entry 5 PD VTD HPA fetch yields an invalid entry 4 PD fetch yields an invalid entry 3 PD fetch for entry marked as invalid by BCS 2 GTT fetch yields an invalid entry Page Fault occurred in one of the GTT translations. 1 CTXTLB VTD fetch yields an invalid entry 0 CTXTLB fetch yields an invalid entry Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 105 2.1.6 Virtual Memory Control 2.1.6.1 BCS_HWS_PGA — BCS Hardware Status Page Address Register BCS_HWS_PGA - BCS Hardware Status Page Address Register Register Space: MMIO: 0/2/0 Source: BlitterCS Default Value: 0x00000000 Access: R/W Size (in bits): 32 Trusted Type: 1 Address: 04280h This register is used to program the 4 KB-aligned System Memory address of the Hardware Status Page used to report hardware status into (typically cacheable) System Memory. Programming Notes Project If this register is written, a workload must subsequently be dispatched to the Blitter command streamer. DWord Bit Description 0 11:1 Reserved Format: MBZ The following table defines the layout of the Hardware Status Page: DWord Offset Description 3:0 Reserved. Must not be used. 4 Head Pointer Storage: The contents of the Ring Buffer Head Pointer register (register DWord 1) are written to this location either as result of an MI_REPORT_HEAD instruction or as the result of an “automatic report” (see RINGBUF registers). 0Fh:05h Reserved. Must not be used. 3FFh:010h These locations can be used for general purpose via the MI_STORE_DATA_INDEX or MI_STORE_DATA_IMM instructions. 106 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 2.1.6.2 BCS_PP_DCLV – PPGTT Directory Cacheline Valid Register BCS_PP_DCLV - BCS PPGTT Directory Cacheline Valid Register Register Space: MMIO: 0/2/0 Project: All Source: BlitterCS Default Value: 0x00000000, 0x00000000 Access: R/W Size (in bits): 64 Address: 22220h Default Value = 0h This register controls update of the on-chip PPGTT Directory Cache during a context restore. Bits that are set will trigger the load of the corresponding 16 directory entry group. This register is restored with context (prior to restoring the on-chip directory cache itself). This register is also restored when switching to a context whose LRCA matches the current CCID if the Force PD Restore bit is set in the context descriptor. The context image of this register must be updated and maintained by SW; SW should not normally need to read this register. This register can also effectively be used to limit the size of a processes’ virtual address space. Any access by a process that requires a PD entry in a set that is not enabled in this register will cause a fatal error, and no fetch of the PD entry will be attempted. DWord Bit Description 0 63:32 Reserved Format: MBZ 31:0 PPGTT Directory Cache Restore Format: Enable[32] [1..32] 16 entries If set, the [1st..32nd] 16 entries of the directory cache are considered valid and will be brought in on context restore. If clear, these entries are considered invalid and fetch of these entries will not be attempted. Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 107 2.1.7 Mode and Misc Ctrl Registers 2.1.7.1 BCS_CXT_SIZE—BCS Context Sizes BCS_CXT_SIZE - BCS Context Sizes Register Space: MMIO: 0/2/0 Source: BlitterCS Default Value: 0x00000400 Access: Read/32 bit Write Only Size (in bits): 32 Address: 221A8h DWord Bit Description 0 31:13 Reserved Project: All Format: MBZ 12:8 BCS Context Size Project: All Format: U5 Value Name Project 4h [Default] 7:5 Reserved Project: All Format: MBZ 2.1.7.2 BCS_MI_MODE — Mode Register for Software Interface BCS_MI_MODE - BCS Mode Register for Software Interface Register Space: MMIO: 0/2/0 Source: BlitterCS Default Value: 0x00000000 Access: R/W Size (in bits): 32 Address: 2209Ch-2209Fh The MI_MODE register contains information that controls software interface aspects of the command parser. DWord Bit Description 0 31:16 Masks A 1 in a bit in this field allows the modification of the corresponding bit in Bits 15:0 108 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 BCS_MI_MODE - BCS Mode Register for Software Interface 15 Suspend Flush Project: All Mask: MMIO(0x209c)#31 Value Name Description 0h No Delay HW will not delay flush, this bit will get cleared by MI_SUSPEND_FLUSH as well 1h Delay Flush Suspend flush is active 14:12 Reserved Read/Write 11 Invalidate UHPTR enable If bit set H/W clears the valid bit of BCS_UHPTR (4134h, bit 0) when current active head pointer is equal to UHPTR. 10 Reserved Format: MBZ 9 Ring Idle (Read Only Status Bit) Writes to this bit are not allowed. Value Name 0 Parser not Idle 1 Parser Idle 8 Stop Ring Software must set this bit to force the Ring and Command Parser to Idle. Software must read a 1 in Ring Idle bit after setting this bit to ensure that the hardware is idle. Software must clear this bit for Ring to resume normal operation. Value Name 0 Normal Operation 1 Parser is turned off 7:2 Reserved Read/Write 0 Reserved Read/Write Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 109 2.1.7.3 BLT_MODE – Blitter Mode Register BLT_MODE - Blitter Mode Register Register Space: MMIO: 0/2/0 Source: BlitterCS Default Value: 0x00000000 Access: R/W Size (in bits): 32 Trusted Type: 1 Address: 2229Ch This register contains a control bit for the new 2-level PPGTT functions. This register is not saved/restored with context. DWord Bit Description 0 31:16 Mask Bits Format: Mask[15:0] Must be set to modify corresponding bit in Bits 15:0. (All implemented bits) 14 Reserved Format: MBZ 13:10 Reserved Project: All Format: MBZ 9 Per-Process GTT Enable Project: All Format: Enable Per-Process GTT BS Mode Enable Value Name Description Project 0h PPGTT Disable When clear, the Global GTT will be used to translate memory access All [Default] from designated commands and for commands that select the PPGTT as their translation space. 1h PPGTT Enable When set, the PPGTT will be used to translate memory access from All designated commands and for commands that select the PPGTT as their translation space. 7:5 Reserved Format: MBZ 0 Reserved Format: MBZ 110 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 2.1.7.4 BCS_INSTPM—BCS Instruction Parser Mode Register The BCS_INSTPM register is used to control the operation of the BCS Instruction Parser. Certain classes of instructions can be disabled (ignored) – often useful for detecting performance bottlenecks. Also, “Synchronizing Flush” operations can be initiated – useful for ensuring the completion (vs. only parsing) of rendering instructions. Programming Notes:  All Reserved bits are implemented. BCS_INSTPM - BCS Instruction Parser Mode Register Register Space: MMIO: 0/2/0 Source: BlitterCS Default Value: 0x00000000 Access: R/W Size (in bits): 32 Trusted Type: 1 Address: 220C0h Desc DWord Bit Description 0 31:16 Mask Bits Format: Mask[15:0] Must be set to modify corresponding bit in Bits 15:0. (All implemented bits) 15:11 Reserved Project: All Format: MBZ 10 Reserved Format: MBZ 9 TLB Invalidate Format: U1 If set, this bit allows the command stream engine to invalidate the blitter TLBs. This bit is valid only with the Sync flush enable Note: GFX soft resets do not invalidate TLBs, it is up to GFX driver to explicitly invalidate TLBs post reset. 8:7 Reserved Project: All Format: MBZ 6 Memory Sync Enable Format: U1 This set, this bit allows the blitter decode engine to write out the data from the local caches to memory.This bit is not persistent. S/W must define this bit each time a sync flush is requested Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 111 BCS_INSTPM - BCS Instruction Parser Mode Register 5 Sync Flush Enable Format: U1 Format: Enable Cleared by HW This field is used to request a Sync Flush operation. The device will automatically clear this bit before completing the operation. See Sync Flush (Programming Environment). 4:0 Reserved Project: All Format: MBZ 2.1.8 BCS_EXCC — BCS Execute Condition Code Register BCS_EXCC - BCS Execute Condition Code Register Register Space: MMIO: 0/2/0 Source: BlitterCS Default Value: 0x00000000 Access: R/W,RO Size (in bits): 32 Trusted Type: 1 Address: 22028h This register contains user defined and hardware generated conditions that are used by MI_WAIT_FOR_EVENT commands. An MI_WAIT_FOR_EVENT instruction excludes the executing ring from arbitration if the selected event evaluates to a 1, while instruction is discarded if the condition evaluates to a 0. Once excluded, a ring is enabled into arbitration when the selected condition evaluates to a 0. This register also contains control for the invalidation of indirect state pointers on context restore. DWord Bit Description 0 31:16 Mask Bits Format: Mask[15:0] These bits serves as a write enable for bits 15:0. If this register is written with any of these bits clear the corresponding bit in the field 15:0 will not be modified. Reading these bits always returns 0s. 15 Reserved Format: MBZ 14:12 Reserved Format: MBZ 112 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 BCS_EXCC - BCS Execute Condition Code Register 11:5 Reserved Format: MBZ 4:0 User Defined Condition Codes Format: U5 The software may signal a Stream Semaphore by setting the Mask bit and Signal Bit together to match the bit field specified in a WAIT_FOR_EVENT (Semaphore). 2.1.8.1 BRSYNC – Blitter/Render Semaphore Sync Register BRSYNC - Blitter/Render Semaphore Sync Register Register Space: MMIO: 0/2/0 Source: BlitterCS Default Value: 0x00000000 Access: R/W Size (in bits): 32 Trusted Type: 1 Address: 22040h This register is written by CS, read by BCS. DWord Bit Description 0 31:0 Semaphore Data Semaphore data for synchronization between blitter engine and render engine. Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 113 2.1.8.2 BVSYNC – Blitter/Video Semaphore Sync Register BVSYNC - Blitter/Video Semaphore Sync Register Register Space: MMIO: 0/2/0 Source: BlitterCS Default Value: 0x00000000 Access: R/W Size (in bits): 32 Trusted Type: 1 Address: 22044h This register is written by VCS, read by BCS. DWord Bit Description 0 31:0 Semaphore Data Semaphore data for synchronization between blitter engine and video codec engine. 2.1.8.3 GAB_MODE — Mode Register for GAB GAB_MODE - Mode Register for GAB Register Space: MMIO: 0/2/0 Source: BlitterCS Default Value: 0x00000000 Access: R/W Size (in bits): 32 Address: 220A0h-220A3h The GAB_MODE register contains information that controls configurations in the GAB. DWord Bit Description 0 31:16 Masks Format: Mask[15:0] A 1 in a bit in this field allows the modification of the corresponding bit in Bits 15:0. 15:0 Reserved Read/Write 114 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 2.1.9 BCS_RINGBUF—Ring Buffer Registers RING_BUFFER_TAIL - Ring Buffer Tail Register Space: MMIO: 0/2/0 Default Value: 0x00000000 Access: R/W Address: 02030h Name: RCS Ring Buffer Tail ShortName: RCS_RING_BUFFER_TAIL Address: 12030h Name: VCS Ring Buffer Tail ShortName: VCS_RING_BUFFER_TAIL Address: 22030h Name: BCS Ring Buffer Tail ShortName: BCS_RING_BUFFER_TAIL These registers are used to define and operate the “ring buffer” mechanism which can be used to pass instructions to the command interface. The buffer itself is located in a linear memory region. The ring buffer is defined by a 4 Dword register set that includes starting address, length, head offset, tail offset, and control information. Refer to the Programming Interface chapter for a detailed description of the parameters specified in this ring buffer register set, restrictions on the placement of ring buffer memory, arbitration rules, and in how the ring buffer can be used to pass instructions. Ring Buffer Tail Offsets must be properly programmed before ring is enabled. A Ring Buffer can be enabled when empty. DWord Bit Description 0 31:21 Reserved Format: MBZ 20:3 Tail Offset Format: GraphicsAddress[20:3] This field is written by software to specify where the valid instructions placed in the ring buffer end. The value written points to the QWord past the last valid QWord of instructions. In other words, it can be defined as the next QWord that software will write instructions into. Software must write subsequent instructions to QWords following the Tail Offset, possibly wrapping around to the top of the buffer (i.e., software can’t skip around within the buffer). Note that all DWords prior to the location indicated by the Tail Offset must contain valid instruction data – which may require instruction padding by software. See Head Offset for more information. 2:0 Reserved Format: MBZ Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 115 RING_BUFFER_HEAD - Ring Buffer Head Register Space: MMIO: 0/2/0 Default Value: 0x00000000 Access: R/W Address: 02034h Name: RCS Ring Buffer Head ShortName: RCS_RING_BUFFER_HEAD Address: 12034h Name: VCS Ring Buffer Head ShortName: VCS_RING_BUFFER_HEAD Address: 22034h Name: BCS Ring Buffer Head ShortName: BCS_RING_BUFFER_HEAD This register is used to define and operate the ring buffer mechanism which can be used to pass instructions to the command interface. The buffer itself is located in a physical memory region. The ring buffer is defined by a 4 Dword register set that includes starting address, length, head offset, tail offset, and control information. Refer to the Programming Interface chapter for a detailed description of the parameters specified in this ring buffer register set, restrictions on the placement of ring buffer memory, arbitration rules, and in how the ring buffer can be used to pass instructions. Ring Buffer Head Offsets must be properly programmed before ring is enabled. A Ring Buffer can be enabled when empty. DWord Bit Description 0 31:21 Wrap Count Format: U11 count of ring buffer wraps This field is incremented by 1 whenever the Head Offset wraps from the end of the buffer back to the start (i.e., whenever it wraps back to 0). Appending this field to the Head Offset field effectively creates a virtual 4GB Head “Pointer” which can be used as a tag associated with instructions placed in a ring buffer. The Wrap Count itself will wrap to 0 upon overflow. 20:2 Head Offset Format: GraphicsAddress[20:2] DWord Offset This field indicates the offset of the next instruction DWord to be parsed. Software will initialize this field to select the first DWord to be parsed once the RB is enabled. (Writing the Head Offset while the RB is enabled is UNDEFINED). Subsequently, the device will increment this offset as it executes instructions – until it reaches the QWord specified by the Tail Offset. At this point the ring buffer is considered “empty”. Programming Notes A RB can be enabled empty or containing some number of valid instructions. 1 Reserved Format: MBZ 116 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 RING_BUFFER_HEAD - Ring Buffer Head 0 Wait for Condition Indicator Source: RenderCS This is a read only value used to indicate whether or not the command streamer is currently waiting for a conditional code to be cleared from 0x2028 0 Reserved Source: BlitterCS, VideoCS, VideoCS2, VideoEnhancementCS Format: MBZ RING_BUFFER_START - Ring Buffer Start Register Space: MMIO: 0/2/0 Default Value: 0x00000000 Access: R/W Address: 02038h Name: RCS Ring Buffer Start ShortName: RCS_RING_BUFFER_START Address: 12038h Name: VCS Ring Buffer Start ShortName: VCS_RING_BUFFER_START Address: 22038h Name: BCS Ring Buffer Start ShortName: BCS_RING_BUFFER_START These registers are used to define and operate the “ring buffer” mechanism which can be used to pass instructions to the command interface. The buffer itself is located in a physical memory region. The ring buffer is defined by a 4 Dword register set that includes starting address, length, head offset, tail offset, and control information. Refer to the Programming Interface chapter for a detailed description of the parameters specified in this ring buffer register set, restrictions on the placement of ring buffer memory, arbitration rules, and in how the ring buffer can be used to pass instructions. DWord Bit Description 0 31:12 Starting Address Format: GraphicsAddress[31:12]RingBuffer This field specifies Bits 31:12 of the 4KB-aligned starting Graphics Address of the ring buffer. Address bits 31 down to 29 must be zero. All ring buffer pages must map to Main Memory (uncached) pages. Ring Buffer addresses are always translated through the global GTT. 11:0 Reserved Format: MBZ Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 117 RING_BUFFER_CTL - Ring Buffer Control Register Space: MMIO: 0/2/0 Default Value: 0x00000000 Access: R/W Address: 0203Ch Name: RCS Ring Buffer Control ShortName: RCS_RING_BUFFER_CTL Address: 1203Ch Name: VCS Ring Buffer Control ShortName: VCS_RING_BUFFER_CTL Address: 2203Ch Name: BCS Ring Buffer Control ShortName: BCS_RING_BUFFER_CTL These registers are used to define and operate the ring buffer mechanism which can be used to pass instructions to the command interface. The buffer itself is located in a physical memory region. The ring buffer is defined by a 4 Dword register set that includes starting address, length, head offset, tail offset, and control information. Refer to the Programming Interface chapter for a detailed description of the parameters specified in this ring buffer register set, restrictions on the placement of ring buffer memory, arbitration rules, and in how the ring buffer can be used to pass instructions. Ring Buffer Head and Tail Offsets must be properly programmed before it is enabled. A Ring Buffer can be enabled when empty. DWord Bit Description 0 31:21 Reserved Format: MBZ 20:12 Buffer Length Format: U9-1 in 4 KB pages – 1 This field is written by SW to specify the length of the ring buffer in 4 KB Pages.Range = [0 = 1 page = 4 KB, 1FFh = 512 pages = 2 MB] Value Name Description 0 1 page = 4 KB 1FFh 512 pages = 2 MB 11 RBWait Indicates that this ring has executed a WAIT_FOR_EVENT instruction and is currently waiting. Software can write a “1” to clear this bit, write of “0” has no effect. When the RB is waiting for an event and this bit is cleared, the wait will be terminated and the RB will be returned to arbitration. 10 Semaphore Wait Description Project Indicates that this ring has executed a MI_SEMAPHORE_MBOX instruction with register compare and is currently waiting. 9 Reserved Format: MBZ 8 Reserved Source: RenderCS, BlitterCS 118 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 RING_BUFFER_CTL - Ring Buffer Control Format: MBZ 8 Disable Register Accesses Source: VideoCS, VideoCS2, VideoEnhancementCS Value Name Description 0 R/W Ring is allowed to access (read or write) MMIO space. 1 Read Only Ring is not allowed to write MMIO space. Ring is allowed to read registers. 7:3 Reserved Format: MBZ 2:1 Automatic Report Head Pointer Source: BlitterCS, VideoCS, VideoCS2, VideoEnhancementCS Description Project This field is written by software to control the automatic “reporting” (write) of this ring buffer’s “Head Pointer” register (register DWord 1) to the corresponding location within the Hardware Status Page. Automatic reporting can either be disabled or enabled at 4KB, 64KB or 128KB boundaries within the ring buffer. The head pointer will be reported to the head pointer location in the Per-Process Hardware Status Page when it passes each 4KB page boundary. When the above-mentioned bit is set, reporting will behave just as on the prior devices (as documented above), and option 2 is not legal. Value Name Description 0 MI_AUTOREPORT_OFF Automatic reporting disabled 1 MI_AUTOREPORT_64KB Report every 16 pages (64KB) 2 MI_AUTOREPORT_4KB Report every page (4KB)This mode must not be enabled in Ring Buffer mode of scheduling to minimize the auto reports. 3 MI_AUTOREPORT_128KB Report every 32 pages (128KB) 2:1 Reserved Source: RenderCS Format: MBZ 0 Ring Buffer Enable Format: Enable This field is used to enable or disable this ring buffer. It can be enabled or disabled regardless of whether there are valid instructions pending. If disabled and the ring head equals ring tail, all state currently loaded in hardware is considered invalid. Programming Notes Project SW should follow the below programming notes while enabling render engine's ring buffer for the first time, this would be coming out of boot, standby, hibernate or reset.  SW should set the Force Wakeup bit to prevent GT from entering C6.  SW should dispatch workload (dummy) to initialize render engine with default state such that any context switches that occur subsequently (Power Save) will save and restore coherent device state. Indirect pointers used in 3D states should point to valid graphics surface existing in memory. PP_DCLV followed by PP_DIR_BASE register should be programmed as part of initialization workload if PPGTT is enabled in GFX_MODE register. Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 119 RING_BUFFER_CTL - Ring Buffer Control  Once the render engine is programmed with valid state and the configuration, Force Wakeup bit should be reset to enable C6 entry. 120 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 2.1.9.1 BCS_UHPTR — BCS Pending Head Pointer Register UHPTR - Pending Head Pointer Register Register Space: MMIO: 0/2/0 Default Value: 0x00000000 Access: R/W Address: 02134h Name: RCS Pending Head Pointer Register ShortName: RCS_UHPTR Address: 12134h Name: VCS Pending Head Pointer Register ShortName: VCS_UHPTR Address: 22134h Name: BCS Pending Head Pointer Register ShortName: BCS_UHPTR Programming Notes Once SW uses UHPTR to preempt the existing workload, should explicitly program MI_SET_CONTEXT to save the preempted context status before submitting the new workload. In case SW doesn’t want to save the state of the preempted context, it should at the minimum program RS_PREEMPT_STATUS to 0x0 so that the register status doesn’t interfere with the new workloads. DWord Bit Description 0 31:3 Head Pointer Address Format: GraphicsAddress[31:3] This register represents the GFX address offset where execution should continue in the ring buffer following execution of an MI_ARB_CHECK command. 2:1 Reserved Format: MBZ 0 Head Pointer Valid This bit is set by the software to request a pre-emption. It is reset by hardware when an MI_ARB_CHECK command is parsed by the command streamer. The hardware uses the head pointer programmed in this register at the time the reset is generated. Value Name Description 0 InValid No valid updated head pointer register, resume execution at the current location in the ring buffer 1 Valid Indicates that there is an updated head pointer programmed in this register Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 121 2.1.9.2 BCS_CTR_THRSH – BCS Watchdog Counter Threshold BCS_CTR_THRSH - BCS Watchdog Counter Threshold Register Space: MMIO: 0/2/0 Project: All Source: BlitterCS Default Value: 0x00150000 Access: R/W Size (in bits): 32 Address: 2217Ch DWord Bit Description 0 31:0 Counter logic Threshold Default Value: 00150000h Format: U32 This field specifies the threshold that the hardware checks against for the value of the blitter clock counter before generating an interrupt. The counter in hardware generates an interrupt when the threshold is reached, rolls over and starts counting again. The interrupt generated is the "Media Hang Notify" interrupt since this watchdog timer is intended primarily to remedy VLD hangs on the main pipeline. 2.1.10 Interrupt Control Registers The Interrupt Control Registers described below all share the same bit definition. The bit definition is as follows: Bit Definition for Interrupt Control Registers Bit Description 31:30 Reserved. MBZ: These bits may be assigned to interrupts on future products/steppings. 29 Page Fault: This bit is set whenever there is a pending page or directory fault in blitter command streamer. 28:27 Reserved. MBZ 26 MI_FLUSH_DW Notify Interrupt: The Pipe Control packet (Fences) specified in 3D pipeline document may optionally generate an Interrupt. The Store QW associated with a fence is completed ahead of the interrupt. 25 Blitter Command Parser Master Error: When this status bit is set, it indicates that the hardware has detected an error. It is set by the device upon an error condition and cleared by a CPU write of a one to the appropriate bit contained in the Error ID register followed by a write of a one to this bit in the IIR. Further information on the source of the error comes from the “Error Status Register” which along with the “Error Mask Register” determine which error conditions will cause the error status bit to be set and the interrupt to occur. 122 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 Bit Description Page Table Error: Indicates a page table error. Instruction Parser Error: The Blitter Instruction Parser encounters an error while parsing an instruction. 24 Sync Status: This bit is set when the Instruction Parser completes a flush with the sync enable bit active in the INSTPM register. The event will happen after all the blitter engines are flushed. The HW Status DWord write resulting from this event will cause the CPU’s view of graphics memory to be coherent as well (flush and invalidate the blitter cache). It is the driver’s responsibility to clear this bit before the next sync flush with HWSP write enabled. 23 Reserved. MBZ 22 Blitter Command Parser User Interrupt: This status bit is set when an MI_USER_INTERRUPT instruction is executed on the Render Command Parser. Note that instruction execution is not halted and proceeds normally. A mechanism such as an MI_STORE_DATA instruction is required to associate a particular meaning to a user interrupt. 21:0 Reserved. MBZ 2.1.10.1 BCS_HWSTAM - BCS Hardware Status Mask Register BCS_HWSTAM - BCS Hardware Status Mask Register Register Space: MMIO: 0/2/0 Project: All Source: BlitterCS Default Value: 0xFFFFFFFF Access: R/W Size (in bits): 32 Trusted Type: 1 Address: 22098h Access: RO for Reserved Control bits The HWSTAM register has the same format as the Interrupt Control Registers. The bits in this register are “mask” bits that prevent the corresponding bits in the Interrupt Status Register from generating a “Hardware Status Write” (PCI write cycle). Any unmasked interrupt bit (HWSTAM bit set to 0) will allow the Interrupt Status Register to be written to the ISR location (within the memory page specified by the Hardware Status Page Address Register) when that Interrupt Status Register bit changes state. Programming Notes To write the interrupt to the HWSP, the corresponding IMR bit must also be clear (enabled). At most 1 bit can be unmasked at any given time. DWord Bit Description 0 31:0 Hardware Status Mask Register Default Value: FFFFFFFFh Project: All Format: Array of Masks refer to Table 5-1 in Interrupt Control Register section for bit definitions Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 123 2.1.10.2 IMR—BCS Interrupt Mask Register BCS_IMR - BCS Interrupt Mask Register Register Space: MMIO: 0/2/0 Project: All Source: BlitterCS Default Value: 0xFFFFFFFF Access: R/W Size (in bits): 32 Address: 220A8h The IMR register is used by software to control which Interrupt Status Register bits are “masked” or “unmasked”. “Unmasked” bits will be reported in the IIR, possibly triggering a CPU interrupt, and will persist in the IIR until cleared by software. “Masked” bits will not be reported in the IIR and therefore cannot generate CPU interrupts. DWord Bit Description 0 31:0 Interrupt Mask Bits Project: All Format: Array of interrupt mask bits Refer to Table 5-1 in Interrupt Control Register section for bit definitions This field contains a bit mask which selects which interrupt bits (from the ISR) are reported in the IIR. Value Name Description Project FFFF FFFFh [Default] 0h Not Masked Will be reported in the IIR All 1h Masked Will not be reported in the IIR All 2.1.10.3 Hardware-Detected Error Bit Definitions (for EIR, EMR, ESR) This section defines the Hardware-Detected Error bit definitions and ordering that is common to the EIR, EMR and ESR registers. The EMR selects which error conditions (bits) in the ESR are reported in the EIR. Any bit set in the EIR will cause the Master Error bit in the ISR to be set. EIR bits will remain set until the appropriate bit(s) in the EIR is cleared by writing the appropriate EIR bits with ‘1’ (except for the unrecoverable bits described below). The following table describes the Hardware-Detected Error bits: BCS Hardware-Detected Error Bit Definitions Source: BlitterCS Default Value: 0x00000000 DWord Bit Description 0 15:3 Reserved Format: MBZ 2 Reserved Format: MBZ 124 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 BCS Hardware-Detected Error Bit Definitions 1 Reserved Format: MBZ 0 Instruction Error This bit is set when the Renderer Instruction Parser detects an error while parsing an instruction. Instruction errors include:  Client ID value (Bits 31:29 of the Header) is not supported (only MI, 2D and 3D are supported).  Defeatured MI Instruction Opcodes: Value Name Description 1 Instruction Error detected Programming Notes This error indications cannot be cleared except by reset (i.e., it is a fatal error). 2.1.10.3.1 EIR — BCS Error Identity Register BCS_EIR - BCS Error Identity Register Register Space: MMIO: 0/2/0 Project: All Source: BlitterCS Default Value: 0x00000000 Access: R/WC Size (in bits): 32 Address: 220B0h The EIR register contains the persistent values of Hardware-Detected Error Condition bits. Any bit set in this register will cause the Master Error bit in the ISR to be set. The EIR register is also used by software to clear detected errors (by writing a ‘1’ to the appropriate bit(s) except for the unrecoverable bits described).). DWord Bit Description 0 31:16 Reserved Project: All Format: MBZ 15:0 Error Identity Bits Project: All Format: Array of Error condition bits See Table 1 5. Hardware-Detected Error Bits This register contains the persistent values of ESR error status bits that are unmasked via the EMR register. The logical OR of all (defined) bits in this register is reported in the Master Error bit of the Interrupt Status Register. In order to clear an error condition, software must first clear the error by writing a ‘1’ to the appropriate bit(s) in this field. If required, software should then proceed to clear the Master Error bit of the IIR. Value Name Description Project Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 125 BCS_EIR - BCS Error Identity Register 0h [Default] 1h Error occurred Error occurred All Programming Notes Writing a ‘1’ to a set bit will cause that error condition to be cleared. However, the Instruction Error bit (Bit 0) cannot be cleared except by reset (i.e., it is a fatal error). 2.1.10.3.2 EMR—BCS Error Mask Register BCS_EMR - BCS Error Mask Register Register Space: MMIO: 0/2/0 Project: All Source: BlitterCS Default Value: 0x0000FFFF Access: R/W Size (in bits): 32 Address: 220B4h The EMR register is used by software to control which Error Status Register bits are “masked” or “unmasked”. “Unmasked” bits will be reported in the EIR, thus setting the Master Error ISR bit and possibly triggering a CPU interrupt, and will persist in the EIR until cleared by software. “Masked” bits will not be reported in the EIR and therefore cannot generate Master Error conditions or CPU interrupts. DWord Bit Description 0 31:16 Reserved Project: All Format: MBZ 15:0 Error Mask Bits Project: All Format: Array of error condition mask bits See Table 1 5. Hardware-Detected Error Bits This register contains a bit mask that selects which error condition bits (from the ESR) are reported in the EIR. Value Name Description Project FFFF FFFFh [Default] 0h Not Masked Will be reported in the EIR All 1h Masked Will not be reported in the EIR All 126 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 2.1.10.3.3 ESR—Error Status Register BCS_ESR - BCS Error Status Register Register Space: MMIO: 0/2/0 Project: All Source: BlitterCS Default Value: 0x00000000 Access: RO Size (in bits): 32 Address: 220B8h The ESR register contains the current values of all Hardware-Detected Error condition bits (these are all by definition “persistent”). The EMR register selects which of these error conditions are reported in the persistent EIR (i.e., set bits must be cleared by software) and thereby causing a Master Error interrupt condition to be reported in the ISR. DWord Bit Description 0 31:16 Reserved Project: All Format: MBZ 15:0 Error Status Bits Project: All Format: Array of error condition bits See Table 1 5. Hardware-Detected Error Bits This register contains the non-persistent values of all hardware-detected error condition bits. Value Name Description Project 0h [Default] 1h Error Condition Detected Error Condition detected All 2.1.11 Logical Context Support 2.1.11.1 BB_ADDR — Batch Buffer Head Pointer Register BB_ADDR - Batch Buffer Head Pointer Register Register Space: MMIO: 0/2/0 Default Value: 0x00000000 Access: RO Size (in bits): 32 Address: 02140h Name: RCS Batch Buffer Head Pointer Register ShortName: RCS_BB_ADDR Address: 12140h Name: VCS Batch Buffer Head Pointer Register ShortName: VCS_BB_ADDR Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 127 BB_ADDR - Batch Buffer Head Pointer Register Address: 1A140h Name: VECS Batch Buffer Head Pointer Register ShortName: VECS_BB_ADDR Address: 22140h Name: BCS Batch Buffer Head Pointer Register ShortName: BCS_BB_ADDR This register contains the current DWord Graphics Memory Address of the last-initiated batch buffer. Programming Notes Programming Restriction: This register should NEVER be programmed by driver. This is for HW internal use only. DWord Bit Description 0 31:3 Batch Buffer Head Pointer Source: BlitterCS, VideoCS, VideoCS2, VideoEnhancementCS Format: GraphicsAddress[31:3] This field specifies the DWord-aligned Graphics Memory Address where the last initiated Batch Buffer is currently fetching commands. If no batch buffer is currently active, the Valid bit will be 0 and this field will be meaningless. 31:2 Batch Buffer Head Pointer Source: RenderCS Format: GraphicsAddress[31:2] This field specifies the DWord-aligned Graphics Memory Address where the last initiated Batch Buffer is currently fetching commands. If no batch buffer is currently active, the Valid bit will be 0 and this field will be meaningless. 2 Reserved Source: BlitterCS, VideoCS, VideoCS2, VideoEnhancementCS Format: MBZ 1 Reserved Format: MBZ 0 Valid Format: U1 Value Name Description 0h Invalid [Default] Batch buffer Invalid 1h Valid Batch buffer Valid 128 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 2.1.11.2 BCS_SYNC_FLIP_STATUS – Wait for event and Display flip flags Register BCS_SYNC_FLIP_STATUS - BCS Wait for event and Display flip flags Register Register Space: MMIO: 0/2/0 Source: BlitterCS Default Value: 0x00000000 Access: R/W Size (in bits): 32 Address: 222D0h This register is the saved value of what wait for events are still valid. This register is part of context save and restore for RC6 feature. DWord Bit Description 0 31 Reserved Project: All Format: MBZ 30 Display Plane A Asyncronous Display Flip Pending Project: All Format: Enable This field enables a wait for the duration of a Display Plane A “Flip Pending” condition. If a flip request is pending, the parser will wait until the flip operation has completed (i.e., the new front buffer address has now been loaded into the active front buffer registers). See Display Flip Pending Condition (in the Device Programming Interface chapter of MI Functions. 29 Display Plane A Syncronous Flip Display Pending Project: All Format: Enable This field enables a wait for the duration of a Display Plane A “Flip Pending” condition. If a flip request is pending, the parser will wait until the flip operation has completed (i.e., the new front buffer address has now been loaded into the active front buffer registers). See Display Flip Pending Condition (in the Device Programming Interface chapter of MI Functions. 28 Display Sprite A Syncronous Flip Display Pending Project: All Format: Enable This field enables a wait for the duration of a Display Sprite A “Flip Pending” condition. If a flip request is pending, the parser will wait until the flip operation has completed (i.e., the new front buffer address has now been loaded into the active front buffer registers). See Display Flip Pending Condition in the Device Programming Interface chapter of MI Functions. 27 Reserved Project: All Format: MBZ 26 Display Plane B Asyncronous Display Flip Pending Project: All Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 129 BCS_SYNC_FLIP_STATUS - BCS Wait for event and Display flip flags Register Format: Enable This field enables a wait for the duration of a Display Plane B “Flip Pending” condition. If a flip request is pending, the parser will wait until the flip operation has completed (i.e., the new front buffer address has now been loaded into the active front buffer registers). See Display Flip Pending Condition (in the Device Programming Interface chapter of MI Functions. 25 Display Plane B Syncronous Flip Display Pending Project: All Format: Enable This field enables a wait for the duration of a Display Plane B “Flip Pending” condition. If a flip request is pending, the parser will wait until the flip operation has completed (i.e., the new front buffer address has now been loaded into the active front buffer registers). See Display Flip Pending Condition (in the Device Programming Interface chapter of MI Functions. 24 Display Sprite B Syncronous Flip Display Pending Project: All Format: Enable This field enables a wait for the duration of a Display Sprite B “Flip Pending” condition. If a flip request is pending, the parser will wait until the flip operation has completed (i.e., the new front buffer address has now been loaded into the active front buffer registers). See Display Flip Pending Condition in the Device Programming Interface chapter of MI Functions. 23 Reserved Project: All Format: MBZ 22 Display Plane A Asyncronous Flip Pending Wait Enable Project: All Format: Enable This field enables a wait for the duration of a Display Plane A “Flip Pending” condition. If a flip request is pending, the parser will wait until the flip operation has completed (i.e., the new front buffer address has now been loaded into the active front buffer registers). See Display Flip Pending Condition (in the Device Programming Interface chapter of MI Functions. 21 Display Plane A Syncronous Flip Pending Wait Enable Project: All Format: Enable This field enables a wait for the duration of a Display Plane A “Flip Pending” condition. If a flip request is pending, the parser will wait until the flip operation has completed (i.e., the new front buffer address has now been loaded into the active front buffer registers). See Display Flip Pending Condition (in the Device Programming Interface chapter of MI Functions. 20 Display Sprite A Syncronous Flip Pending Wait Enable Project: All Format: Enable This field enables a wait for the duration of a Display Sprite A “Flip Pending” condition. If a flip request is pending, the parser will wait until the flip operation has completed (i.e., the new front buffer address has now been loaded into the active front buffer registers). See Display Flip Pending Condition in the Device Programming Interface chapter of MI Functions. 130 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 BCS_SYNC_FLIP_STATUS - BCS Wait for event and Display flip flags Register 19:15 Reserved Project: All Format: MBZ 14 Display Plane B Asyncronous Flip Pending Wait Enable Project: All Format: Enable This field enables a wait for the duration of a Display Plane B “Flip Pending” condition. If a flip request is pending, the parser will wait until the flip operation has completed (i.e., the new front buffer address has now been loaded into the active front buffer registers). See Display Flip Pending Condition (in the Device Programming Interface chapter of MI Functions. 13 Display Plane B Syncronous Flip Pending Wait Enable Project: All Format: Enable This field enables a wait for the duration of a Display Plane B “Flip Pending” condition. If a flip request is pending, the parser will wait until the flip operation has completed (i.e., the new front buffer address has now been loaded into the active front buffer registers). See Display Flip Pending Condition (in the Device Programming Interface chapter of MI Functions. 12 Display Sprite B Syncronous Flip Pending Wait Enable Project: All Format: Enable This field enables a wait for the duration of a Display Sprite B “Flip Pending” condition. If a flip request is pending, the parser will wait until the flip operation has completed (i.e., the new front buffer address has now been loaded into the active front buffer registers). See Display Flip Pending Condition in the Device Programming Interface chapter of MI Functions. 11 Display Plane C Asynchronous Display Flip Pending Project: All Format: Enable This field enables a wait for the duration of a Display Plane C “Flip Pending” condition. If a flip request is pending, the parser will wait until the flip operation has completed (i.e., the new front buffer address has now been loaded into the active front buffer registers). See Display Flip Pending Condition (in the Device Programming Interface chapter of MI Functions. 10 Display Plane C Synchronous Display Flip Pending Project: All Format: Enable This field enables a wait for the duration of a Display Plane C “Flip Pending” condition. If a flip request is pending, the parser will wait until the flip operation has completed (i.e., the new front buffer address has now been loaded into the active front buffer registers). See Display Flip Pending Condition (in the Device Programming Interface chapter of MI Functions. 9 Display Sprite C Syncronous Flip Display Pending Project: All Format: Enable This field enables a wait for the duration of a Display Sprite C “Flip Pending” condition. If a flip request Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 131 BCS_SYNC_FLIP_STATUS - BCS Wait for event and Display flip flags Register is pending, the parser will wait until the flip operation has completed (i.e., the new front buffer address has now been loaded into the active front buffer registers). See Display Flip Pending Condition in the Device Programming Interface chapter of MI Functions. 8 Display Plane C Asyncronous Flip Pending Wait Enable Project: All Format: Enable This field enables a wait for the duration of a Display Plane C “Flip Pending” condition. If a flip request is pending, the parser will wait until the flip operation has completed (i.e., the new front buffer address has now been loaded into the active front buffer registers). See Display Flip Pending Condition (in the Device Programming Interface chapter of MI Functions. 7 Display Plane C Syncronous Flip Pending Wait Enable Project: All Format: Enable This field enables a wait for the duration of a Display Plane C “Flip Pending” condition. If a flip request is pending, the parser will wait until the flip operation has completed (i.e., the new front buffer address has now been loaded into the active front buffer registers). See Display Flip Pending Condition (in the Device Programming Interface chapter of MI Functions. 6 Display Sprite C Syncronous Flip Pending Wait Enable Project: All Format: Enable This field enables a wait for the duration of a Display Sprite C “Flip Pending” condition. If a flip request is pending, the parser will wait until the flip operation has completed (i.e., the new front buffer address has now been loaded into the active front buffer registers). See Display Flip Pending Condition in the Device Programming Interface chapter of MI Functions.. 5 Reserved Project: All Format: MBZ 4:0 Condition Code Wait Select Project: All This field enables a wait for the duration that the corresponding condition code is active. These enable select one of 15 condition codes in the EXCC register, that cause the parser to wait until that condition- code in the EXCC is cleared. Value Name Description Project 0h Not Enabled Condition Code Wait not enabled All 1h-5h Enabled Condition Code select enabled; selects one of 5 codes, 0 – 4 All 6h-15h Reserved All Programming Notes Note that not all condition codes are implemented. The parser operation is UNDEFINED if an unimplemented condition code is selected by this field. The description of the EXCC register (Memory Interface Registers) lists the codes that are implemented. 132 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 2.1.12 Software Control Bit Definitions Registers in the range 22XX are not protected from the load register immediate instruction if the command is executed in the non-secure batch buffer. 2.1.12.1 BCS_TILE—Software Tile Register BCS_SWCTRL Register Space: MMIO: 0/2/0 Source: BlitterCS Default Value: 0x00000000 Access: R/W Size (in bits): 32 Trusted Type: 1 Address: 22200h DWord Bit Description 0 31:16 Masks Format: U16 A “1” in a bit in this field allows the modification of the corresponding bit in bits 15:0. 15:2 Reserved Format: MBZ 1 Tile Y Destination Format: U1 Programming this bit makes the HW treat all destination surfaces as Tile Y. This bit over-rides the setting of the destination format in the packet provided to the blitter command streamer. SW is required to flush the HW before changing the polarity of this bit. This bit is part of the context save/restore. 0 Tile Y Source Format: U1 Programming this bit makes the HW treat all source surfaces as Tile Y. This bit over-rides the setting of the source format in the packet provided to the blitter command streamer. SW is required to flush the HW before changing the polarity of this bit. This bit is part of the context save/restore. Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 133 2.1.12.2 TIMESTAMP — BCS Reported Timestamp Count BCS_TIMESTAMP - BCS Reported Timestamp Count Register Space: MMIO: 0/2/0 Project: All Source: BlitterCS Default Value: 0x00000000, 0x00000000 Access: RO. This register is not set by the context restore. Size (in bits): 64 Address: 22358h This register provides an elapsed real-time value that can be used as a timestamp.This register is not reset by a graphics reset. It will maintain its value unless a full chipset reset is performed. Note: This timestamp register reflects the value of the PCU TSC. The PCU TSC counts 10ns increments; this timestamp reflects bits 38:3 of the TSC (i.e. 80ns granularity, rolling over every 1.5 hours). DWord Bit Description 0 63:36 Reserved Project: All Format: MBZ 35:0 Timestamp Value Project: All Format: U36 This register toggles every 80 ns. The upper 28 bits are zero. 2.2 Memory Interface Commands for Blitter Engine 2.2.1 Introduction This chapter describes the formats of the “Memory Interface” commands, including brief descriptions of their use. The functions performed by these commands are discussed fully in the Memory Interface Functions Device Programming Environment chapter. This chapter describes MI Commands for the blitter graphics processing engine. The term “for Blitter Engine” in the title has been added to differentiate this chapter from a similar one describing the MI commands for the Media Decode Engine and the Rendering Engine. The commands detailed in this chapter are used across products within the subsystem. However, slight changes may be present in some commands (i.e., for features added or removed), or some commands may be removed entirely. Refer to the Preface chapter for product specific summary. 134 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 2.2.2 MI_ARB_CHECK The instruction format is: MI_ARB_CHECK Source: BlitterCS Length Bias: 1 The MI_ARB_CHECK is used to check for a change in arbitration. If executed as part of a Ring Buffer the command checks the UHPTR valid bit and if set the head of the ring will jump to the value of the head pointer programmed in the UHPTR. Programming Notes This instruction cannot be placed in a batch buffer. DWord Bit Description 0 31:29 Command Type Default Value: 0h MI_INSTRUCTION Format: OpCode 28:23 MI Command Opcode Default Value: 05h MI_ARB_CHECK Format: OpCode 22:0 Reserved Format: MBZ 2.2.3 I_BATCH_BUFFER_END MI_BATCH_BUFFER_END Source: BlitterCS Length Bias: 1 The MI_BATCH_BUFFER_END command is used to terminate the execution of commands stored in a batch buffer initiated using a MI_BATCH_BUFFER_START command. DWord Bit Description 0 31:29 Command Type Default Value: 0h MI_COMMAND 28:23 MI Command Opcode Default Value: 0Ah MI_ BATCH_BUFFER_END 22:0 Reserved Project: All Format: MBZ Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 135 2.2.4 MI_BATCH_BUFFER_START MI_BATCH_BUFFER_START Source: BlitterCS Length Bias: 2 The MI_BATCH_BUFFER_START command is used to initiate the execution of commands stored in a batch buffer. For restrictions on the location of batch buffers, see Batch Buffers in the Device Programming Interface chapter of MI Functions.The batch buffer can be specified as secure or non-secure, determining the operations considered valid when initiated from within the buffer and any attached (chained) batch buffers. See Batch Buffer Protection in the Device Programming Interface chapter of MI Functions. Programming Notes  Batch buffers referenced with physical addresses must not extend beyond the end of the starting physical page (can’t span physical pages). However, a batch buffer initiated using a physical address can chain to another buffer in another physical page.  A batch buffer initiated with this command must end either with a MI_BATCH_BUFFER_END command or by chaining to another batch buffer with an MI_BATCH_BUFFER_START command. DWord Bit Description 0 31:29 Command Type Default Value: 0h MI_COMMAND Format: OpCode 28:23 MI Command Opcode Default Value: 31h MI_BATCH_BUFFER_START Format: OpCode 22 Reserved Format: MBZ 21:9 Reserved Project: All Format: MBZ 8 Address Space Indicator Format: MI_BufferSecurityType Certain operations (e.g., MI_STORE_DATA_IMM commands to privileged memory) are prohibited within non-secure buffers. See Batch Buffer Protection in the Device Programming Interface chapter of MI Functions. The command streamer will not allow a batch buffer in PPGTT to call a batch buffer in GGTT space by retaining the PPGTT value. It is illegal for the driver to program the value of this field to a different value than the current batch buffer executing this command. Value Name Description Project 0h GGTT This batch buffer is secure and will be accessed via the GGTT. All Programming Notes This field must be ‘0’ unless the Per-Process GTT Enable is ‘1’ 7:0 DWord Length Default Value: 0h Excludes DWord (0,1) Format: =n Total - Bias 136 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 MI_BATCH_BUFFER_START 1 31:2 Batch Buffer Start Address Project: All Format: GraphicsAddress[31:2]BatchBuffer This field specifies Bits 31:2 of the starting address of the batch buffer. 1:0 Reserved Project: All Format: MBZ 2.2.5 MI_FLUSH_DW MI_FLUSH_DW Source: BlitterCS Length Bias: 2 The MI_FLUSH_DW command is used to perform an internal “flush” operation. The parser pauses on an internal flush until all drawing engines have completed any pending operations. In addition, this command can also be used to: Flush any dirty data to memory. Invalidate the TLB cache inside the hardware Usage note: After this command is completed with a Store DWord enabled, CPU access to graphics memory will be coherent (assuming the Render Cache flush is not inhibited). DWord Bit Description 0 31:29 Command Type Default Value: 0h MI_COMMAND 28:23 MI Command Opcode Default Value: 26h MI_FLUSH_DW 22 Reserved Project: All Format: U1 21 Store Data Index Format: U1 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 hardware status page. If this bit is set, this command will index into the per-process hardware status page if executed from within a non-secure batch buffer and if the Per-Process Virtual Address Space is set. Else the Global HW status page is used. 20:19 Reserved Project: All Format: MBZ 18 TLB Invalidate Format: U1 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 137 MI_FLUSH_DW Description Project If ENABLED, all TLBs will be invalidated once the flush operation is complete. This bit is only valid when the Post-Sync Operation field is a value of 1h or 3h. If GFX_MODE (0x229c) bit 13, this command will cause a config write to MMIO register space with the address 0x4f100. 17 Synchronize GFDT surface Format: U1 If enabled, at the end of the current flush the last level cache is cleared of all the cachelines which have been marked with the special GFDT flags. Store DW must be enabled 16 Reserved Project: All Format: MBZ 15:14 Post-Sync Operation BitFieldDesc Value Name Description 0h No write occurs as a result of this instruction. This can be used to implement a “trap” operation, etc. 1h Write the QWord containing Immediate Data Low, High DWs to the Destination Address 2h Reserved 3h Write the TIMESTAMP register to the Destination Address with a granularity of 80ns. The upper 28 bits of the TIMESTAMP register are tied to ‘0’. Programming Notes If executed in a non-secure batch buffer, the address given is in a PPGTT address space. If in a secure ring or batch, the address given is in GGTT space. 13:9 Reserved Project: All Format: MBZ 8 Notify Enable Format: U1 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:6 Reserved Project: All Format: MBZ 5:0 DWord Length Project: All Format: =n Total Length - 2 138 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 MI_FLUSH_DW Value Name Project 2h Excludes DWord (0,1) = 1 for DWord, 2 for QWord [Default] 1 31:3 Address Format: GraphicsAddress[31:3]U28 This field specifies Bits 31:3 of the Address where the DWord or QWord will be stored. Note that the address can only be QWord aligned, irrespective of data size. 2 Destination Address Type Project: All 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 the selected in Operation. 1:0 Reserved Project: All Format: MBZ 2..3 31:0 Immediate Data Format: U64 This field specifies the DWord value to be written to the targeted location. DW2 is the lower DW if QW is desired. Only valid when 15:14 in header is set to 1h To avoid hitting a known hardware bug, drivers cannot send a QW write when bit 5 of the address is ‘1’ Value Name [0,FFFFFFFFh] Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 139 2.2.6 MI_LOAD_REGISTER_IMM MI_LOAD_REGISTER_IMM Source: BlitterCS Length Bias: 2 The MI_LOAD_REGISTER_IMM command requests a write of up to a DWord constant supplied in the command to the specified Register Offset (i.e., offset into Memory-Mapped Register Range). The register is loaded before the next command is executed. DWord Bit Description 0 31:29 Command Type Default Value: 0h MI_COMMAND 28:23 MI Command Opcode Default Value: 22h MI_ 22:12 Reserved Project: All Format: MBZ 11:8 Byte Write Disables Format: Enable[4] Bit 8 corresponds to Data DWord [7:0] Range: Must specify a valid register write operation If [11:8] is '1111b', then the register write will not occur. If [11:8] is '0000b', then the register DW will be updated. Any other value, the behavior will be specifically specified by the register or the behavior is undefined. 7:0 DWord Length Default Value: 1h Excludes DWord (0,1) Format: =n Total Length - 2 1 31:2 Register Offset Format: U30 Format: MmioAddress[31:2] This field specifies bits [31:2] of the offset into the Memory Mapped Register Range (i.e., this field specifies a DWord offset). 1:0 Reserved Project: All Format: MBZ 2 31:0 Data DWord Mask: Bytes Write Disables Format: U32 This field specifies the DWord value to be written to the targeted location. 140 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 2.2.7 MI_NOOP MI_NOOP Source: BlitterCS Length Bias: 1 The MI_NOOP command basically performs a “no operation” in the command stream and is typically used to pad the command stream (e.g., in order to pad out a batch buffer to a QWord boundary). However, there is one minor (optional) function this command can perform – a 22-bit value can be loaded into the MI NOPID register. This provides a general-purpose command stream tagging ("breadcrumb") mechanism (e.g., to provide sequencing information for a subsequent breakpoint interrupt). DWord Bit Description 0 31:29 Command Type Default Value: 0h MI_COMMAND 28:23 MI Command Opcode Default Value: 0h MI_NOOP 22 Identification Number Register Write Enable Project: All Format: Enable This field enables the value in the Identification Number field to be written into the MI NOPID register. If disabled, that register is unmodified – making this command an effective “no operation” function. Value Name Description Project 0h Disable Do not write the NOP_ID register. All 1h Enable Write the NOP_ID register. All 21:0 Identification Number Project: All Format: U22 This field contains a 22-bit number which can be written to the MI NOPID register. Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 141 2.2.8 MI_REPORT_HEAD MI_REPORT_HEAD Source: BlitterCS Length Bias: 1 The MI_REPORT_HEAD command causes the Head Pointer value of the active ring buffer to be written to a cacheable (snooped) system memory location. Programming Notes This command must not be executed from a Batch Buffer (Refer to the description of the HWS_PGA register). DWord Bit Description 0 31:29 Command Type Default Value: 0h MI_COMMAND 28:23 MI Command Opcode Default Value: 07h MI_REPORT_HEAD 22:0 Reserved Project: All Format: MBZ 2.2.9 MI_SEMAPHORE_MBOX MI_SEMAPHORE_MBOX Source: BlitterCS Length Bias: 2 This command is provided as alternative to MI_SEMAPHORE to provide mailbox-type semaphores where there is no update of the semaphore by the checking process (the consumer). Single-bit compare-and- update semantics are also provided. In either case, atomic access of semaphores need not be guaranteed by hardware as with the previous command. This command should eventually supersede the previous command. Synchronization between contexts (especially between contexts running on 2 different engines) is provided by the MI_SEMAPHORE_MBOX command. Note that contexts attempting to synchronize in this fashion must be able to access a common memory location. This means the contexts must share the same virtual address space (have the same page directory), must have a common physical page mapped into both of their respective address spaces or the semaphore commands must be executing from a secure batch buffer or directly from a ring with the Use Global GTT bit set such that they are “privileged” and will use the (always shared) global GTT. MI_SEMAPHORE with the Update Semaphore bit set (and the Compare Semaphore bit clear) implements the Signal command, while the Wait command is indicated by Compare Semaphore being set. Note that Wait can cause a context switch. Signal increments unconditionally. If execution is stalled due to this command, the engine signals IDLE to Power Management. DWord Bit Description 142 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 MI_SEMAPHORE_MBOX 0 31:29 Command Type Default Value: 0h MI_COMMAND 28:23 MI Command Opcode Default Value: 16h MI_SEMAPHORE_MBOX 22 Use Global GTT Project: All Format: U1 If set, this command will use the global GTT to translate the Semaphore Address and this command must be executing from a privileged (secure) batch buffer. If clear, the PPGTT will be used to translate the Semaphore Address.This bit will be ignored (and treated as if clear) if this command is executed from a non-privileged batch buffer. It is allowed for this bit to be clear when executing this command from a privileged (secure) batch buffer or directly from a ring buffer. Programming Notes This field is only valid when Compare Register Field is reset. 21 Update Semaphore Project: All Format: U1 If set, the value from the Semaphore Data Dword is written to memory. If Compare Semaphore is also set, the semaphore is not updated if the semaphore comparison fails.If clear, the data at Semaphore Address is not changed. Programming Notes This field should be always clear when Compare Register Field is set. 20 Compare Semaphore Project: All Format: U1 If set, the value from the Semaphore Data Dword is compared to the value from the Semaphore Address in memory when Compare Register is clear. If set, the value from the Semaphore Data Dword is compared to the value from MMIO Register selected by Register Select field when Compare Register is set. If the value at Semaphore Address/MMIO Register is greater than the Semaphore Data Dword, execution is continued from the current command buffer. If clear, no comparison takes place. Update Semaphoremust be set in this case. 19 Reserved Project: All Format: MBZ 18 Compare Register Format: Compare Type If set, data in MMIO register will be used for compare. If clear, data in memory will be used for compare. Programming Notes Compare Register field should be always set. 17:16 Register Select Format: Register Select If compare register is set in bit[18], this field indicates which register will be used. Value Name 0 CS register (BRSYNC) 2 VCS regiser (BVSYNC) Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 143 MI_SEMAPHORE_MBOX 3 Reserved 15:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 0h Excludes DWord (0,1) Format: =n Total Length - 2 1 31:0 Semaphore Data Dword Project: All Format: U32 Data dword to compare/update memory. The Data dword is supplied by software to control execution of the command buffer. If the compare is enabled and the data at Semaphore Address is greater than this dword, the execution of the command buffer continues. 2 31:2 PointerBitFieldName/MMIO Register Address Project: All Format: GraphicsVirtualAddress[31:2]Semaphore if Compare Register bit[18] is cleared, this field if the Graphics Memory Address of the 32 bit value for the semaphore.If Compare Register bit[18] is set, this field is the MMIO address of the register for the semaphore. 1:0 Reserved Project: All Format: MBZ 2.2.10 MI_STORE_REGISTER_MEM MI_STORE_REGISTER_MEM Project: All Source: BlitterCS Length Bias: 2 The MI_STORE_REGISTER_MEM command requests a register read from a specified memory mapped register location in the device and store of that DWord to memory. The register address is specified along with the command to perform the read. Programming Notes The command temporarily halts command execution.The memory address for the write is snooped on the host bus. This command will cause undefined data to be written to memory if given register addresses for the PGTBL_CTL_0 or FENCE registers DWord Bit Description 0 31:29 Command Type 144 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 MI_STORE_REGISTER_MEM Default Value: 0h MI_COMMAND Format: OpCode 28:23 MI Command Opcode Default Value: 24h MI_STORE_REGISTER_MEM Format: OpCode 22 Use Global GTT Project: All This bit must be ‘1’ if the Per Process GTT Enable bit is clear Value Name Description Project 0h Per Process All Graphics Address 1h Global Graphics This command will use the global GTT to translate the Address and All Address this command must be executing from a privileged (secure) batch buffer. Programming Notes Project This will not be ignored when in a PPGTT batch buffer. 21:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 1h Excludes DWord (0,1) Format: =n Total Length - 2 1 31:23 Reserved Format: MBZ 22:2 Register Address Project: All Format: MMIOAddress[22:2]MMIO_Register This field specifies Bits 22:2 of the Register offset the DWord will be read from. As the register address must be DWord-aligned, Bits 1:0 of that address MBZ. Programming Notes  Storing a VGA register is not permitted and will store an UNDEFINED value.  The values of PGTBL_CTL0 or any of the FENCE registers cannot be stored to memory; UNDEFINED values will be written to memory if the addresses of these registers are specified. 1:0 Reserved Project: All Format: MBZ 2 31:2 Memory Address Format: GraphicsAddress[31:2]MMIO_Register This field specifies the address of the memory location where the register value specified in the DWord above will be written. The address specifies the DWord location of the data. 1:0 Reserved Project: All Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 145 MI_STORE_REGISTER_MEM Format: MBZ 2.2.11 MI_STORE_DATA_IMM MI_STORE_DATA_IMM Project: All Source: BlitterCS Length Bias: 2 The MI_STORE_DATA_IMM command requests a write of the QWord constant supplied in the packet to the specified Memory Address. As the write targets a System Memory Address, the write operation is coherent with the CPU cache (i.e., the processor cache is snooped). Programming Notes This command can be used for general software synchronization through variables in cacheable memory (i.e., where software does not need to poll un-cached memory or device registers). However, the cacheable nature of the transaction is determined by the setting of the “mapping type” in the GTT entry. This command simply initiates the write operation with command execution proceeding normally. Although the write operation is guaranteed to complete “eventually”, there is no mechanism to synchronize command execution with the completion (or even initiation) of these operations. All writes to memory generated using this command are expected to finish in order. DWord Bit Description 0 31:29 Command Type Default Value: 0h MI_COMMAND 28:23 MI Command Opcode Default Value: 20h MI_STORE_DATA_IMM 22 Use Global GTT Project: All This bit must be ‘1’ if the Per Process GTT Enable bit is clear. Value Name Description Project 0h Per Process All Graphics Address 1h Global Graphics This command will use the global GTT to translate the Address and All Address this command must be executing from a privileged (secure) batch buffer. Programming Notes Project This will not be ignored when in a PPGTT batch buffer. 21 Reserved Format: MBZ 20:10 Reserved Project: All Format: MBZ 9:0 DWord Length Default Value: 2h Excludes DWord (0,1) = 2 for DWord, 3 for QWord 146 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 MI_STORE_DATA_IMM Format: =n Total Length - 2 1 31:0 Reserved Project: All Format: MBZ 2 31:2 Address Project: All Format: GraphicsAddress[31:2]U32(2) This field specifies Bits 31:2 of the Address where the DWord will be stored. As the store address must be DWord-aligned, Bits 1:0 of that address MBZ. This address must be 8B aligned for a store “QW” command. 1:0 Reserved Project: All Format: MBZ 3 31:0 Data DWord 0 Project: All Format: U32 This field specifies the DWord value to be written to the targeted location.For a QWord write this DWord is the lower DWord of the QWord to be reported (DW 0). 4 31:0 Data DWord 1 Project: All Format: U32 This field specifies the upper DWord value to be written to the targeted QWord location (DW 1). 2.2.12 MI_STORE_DATA_INDEX MI_STORE_DATA_INDEX Source: BlitterCS Length Bias: 2 The MI_STORE_DATA_INDEX command requests a write of the data constant supplied in the packet to the specified offset from the System Address defined by the Hardware Status Page Address Register. As the write targets a System Address, the write operation is coherent with the CPU cache (i.e., the processor cache is snooped). Programming Notes Use of this command with an invalid or uninitialized value in the Hardware Status Page Address Register is UNDEFINED. This command can be used for general software synchronization through variables in cacheable memory (i.e., where software does not need to poll uncached memory or device registers). This command simply initiates the write operation with command execution proceeding normally. Although the write operation is guaranteed to complete “eventually”, there is no mechanism to synchronize command execution with the completion (or even initiation) of these operations. DWord Bit Description 0 31:29 Command Type Default Value: 0h MI_COMMAND Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 147 MI_STORE_DATA_INDEX 28:23 MI Command Opcode Default Value: 21h MI_STORE_DATA_INDEX 22 Reserved Project: All Format: MBZ 21 Reserved Format: MBZ 20:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 1h Excludes DWord (0,1 ) = 1 for DWord, 2 for QWord Format: =n Total Length - 2 1 31:12 Reserved Project: All Format: MBZ 11:2 Offset Project: All Format: U10 zero-based DWord offset into the HW status page. Format: HardwareStatusPageOffset[11:2]U32 This field specifies the offset (into the hardware status page) to which the data will be written. Note that the first few DWords of this status page are reserved for special-purpose data storage – targeting these reserved locations via this command is UNDEFINED.This address must be 8B aligned for a store “QW” command. Value Name [16, 1023] 1:0 Reserved Project: All Format: MBZ 2 31:0 Data DWord 0 Project: All Format: U32 This field specifies the DWord value to be written to the targeted location.For a QWord write this DWord is the lower DWord of the QWord to be reported (DW 0). 3 31:0 Data DWord 1 Project: All Format: U32 This field specifies the upper DWord value to be written to the targeted QWord location (DW 1). 148 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 2.2.13 MI_SUSPEND_FLUSH MI_SUSPEND_FLUSH Project: All Source: BlitterCS Length Bias: 1 Description Project Blocks MMIO sync flush or any flushes related to VT-d while enabled. DWord Bit Description 0 31:29 Command Type Default Value: 0h MI_COMMAND 28:23 MI Command Opcode Default Value: 0Bh MI_SUSPEND_FLUSH 22:1 Reserved Project: All Format: MBZ 0 Suspend Flush Project: All Format: Enable Description Project This field suspends flush due and IOTLB invalidation. 2.2.14 MI_UPDATE_GTT MI_UPDATE_GTT Source: BlitterCS Length Bias: 2 The MI_UPDATE_GTT command is used to update GTT page table entries in a coherent manner and at a predictable place in the command flow. An MI_FLUSH should be placed before this command, because work associated with preceding commands that are still in the pipeline may be referencing GTT entries that will be changed by its execution. The flush will also invalidate TLBs and read caches that may become invalid as a result of the changed GTT entries. MI_FLUSH is not required if it can be guaranteed that the pipeline is free of any work that relies on changing GTT entries (such as MI_UPDATE_GTT contained in a paging DMA buffer that is doing only update/mapping activities and no rendering). This is a privileged command. DWord Bit Description 0 31:29 Command Type Default Value: 0h MI_COMMAND Format: OpCode 28:23 MI Command Opcode Default Value: 23h MI_UPDATE_GTT Format: OpCode 22 Use Global GTT Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 149 MI_UPDATE_GTT Project: All Reserved: Must be 1h. Updating Per Process Graphics Address is not supported Value Name Description Project 0h Per Process Graphics Address All 1h Global Graphics Address All 21:6 Reserved Project: All Format: MBZ 5:0 DWord Length Default Value: 0h Excludes DWord (0,1) Format: =n Total Length - 2 1 31:12 Entry Address Project: All Format: GraphicsAddress[31:12] This field simply holds the DW offset of the first table entry to be modified. Note that one or more of the upper bits may need to be 0, i.e., for a 2G aperture, bit 31 MBZ. 11:0 Reserved Project: All Format: MBZ 2..n 31:0 Entry Data Project: All Format: Table Entry This Dword becomes the new page table entry. See PPGTT/Global GTT Table Entries (PTEs) in Memory Interface Registers. 2.2.15 MI_USER_INTERRUPT MI_USER_INTERRUPT Source: BlitterCS Length Bias: 1 The MI_USER_INTERRUPT command is used to generate a User Interrupt condition. The parser will continue parsing after processing this command. See User Interrupt. DWord Bit Description 0 31:29 Command Type Default Value: 0h MI_COMMAND 28:23 MI Command Opcode Default Value: 02h MI_USER_INTERRUPT 22:0 Reserved Project: All Format: MBZ 150 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 2.2.16 MI_WAIT_FOR_EVENT MI_WAIT_FOR_EVENT Source: BlitterCS Length Bias: 1 The MI_WAIT_FOR_EVENT command is used to pause command stream processing until a specific event occurs or while a specific condition exists. Only one event/condition can be specified -- specifying multiple events is UNDEFINED.The effect of the wait operation depends on the source of the command. If executed from a batch buffer, the parser will halt (and suspend command arbitration) until the event/condition occurs. If executed from a ring buffer, further processing of that ring will be suspended, although command arbitration (from other rings) will continue. Note that if a specified condition does not exist (the condition code is inactive) at the time the parser executes this command, the parser proceeds, treating this command as a no-operation.If execution of this command from a primary ring buffer causes a wait to occur, the active ring buffer will effectively give up the remainder of its time slice (required in order to enable arbitration from other primary ring buffers). Programming Notes Project Driver must ensure blitter command stream is not waiting for an event with the following code:  MI_LOAD_REGISTER_IMM with 0x22050[31:0] = 0x00010001  WAIT_FOR_EVENT  MI_LOAD_REGISTER_IMM with 0x22050[31:0] = 0x00010000 RC6 entry must be disabled during a MI_WAIT_FOR_EVENT command with a Flip Pending Wait Enable bit set if this command is in a batch buffer. If RC6 entry is required with a MI_WAIT_FOR_EVENT command with a Flip Pending Wait Enable bit set then it needs to be executed in the ring. DWord Bit Description 0 31:29 Command Type Default Value: 0h MI_COMMAND 28:23 MI Command Opcode Default Value: 03h MI_WAIT_FOR_EVENT 22 Reserved Project: All Format: MBZ 21 Reserved Format: MBZ 20 Display Sprite C Flip Pending Wait Enable Project: All Format: Enable This field enables a wait for the duration of a Display Sprite C “Flip Pending” condition. If a flip request is pending, the parser will wait until the flip operation has completed (i.e., the new front buffer address has now been loaded into the active front buffer registers). 19:16 Condition Code Wait Select Project: All Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 151 MI_WAIT_FOR_EVENT This field enables a wait for the duration that the corresponding condition code is active. These enable select one of 15 condition codes in the EXCC register, that cause the parser to wait until that condition-code in the EXCC is cleared. Value Name Description Project 0h Not Enabled Condition Code Wait not enabled All 1h-5h Enabled Condition Code select enabled; selects one of 5 codes, 0 – 4 All 6h-15h Reserved All Programming Notes Note that not all condition codes are implemented. The parser operation is UNDEFINED if an unimplemented condition code is selected by this field. The description of the EXCC register (Memory Interface Registers) lists the codes that are implemented. 15 Display Plane C Flip Pending Wait Enable Project: All Format: Enable This field enables a wait for the duration of a Display Plane C “Flip Pending” condition. If a flip request is pending, the parser will wait until the flip operation has completed (i.e., the new front buffer address has now been loaded into the active front buffer registers). 14 Reserved Format: MBZ 13:12 Reserved Project: All Format: MBZ 11 Reserved Format: MBZ 10 Display Sprite B Flip Pending Wait Enable Project: All Format: Enable This field enables a wait for the duration of a Display Sprite B “Flip Pending” condition. If a flip request is pending, the parser will wait until the flip operation has completed (i.e., the new front buffer address has now been loaded into the active front buffer registers). 9 Display Plane B Flip Pending Wait Enable Project: All Format: Enable This field enables a wait for the duration of a Display Plane B “Flip Pending” condition. If a flip request is pending, the parser will wait until the flip operation has completed (i.e., the new front buffer address has now been loaded into the active front buffer registers). 8 Reserved Format: MBZ 7:4 Reserved Project: All Format: MBZ 152 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 MI_WAIT_FOR_EVENT 3 Reserved Format: MBZ 2 Display Sprite A Flip Pending Wait Enable Project: All Format: Enable This field enables a wait for the duration of a Display Sprite A “Flip Pending” condition. If a flip request is pending, the parser will wait until the flip operation has completed (i.e., the new front buffer address has now been loaded into the active front buffer registers). 1 Display Plane A Flip Pending Wait Enable Project: All Format: Enable This field enables a wait for the duration of a Display Plane A “Flip Pending” condition. If a flip request is pending, the parser will wait until the flip operation has completed (i.e., the new front buffer address has now been loaded into the active front buffer registers). 0 Reserved Format: MBZ 2.2.17 MI_LOAD_REGISTER_MEM MI_LOAD_REGISTER_MEM Source: BlitterCS Length Bias: 2 The MI_LOAD_REGISTER_MEM command requests from a memory location and stores that DWord to a register. Programming Notes The following addresses should NOT be used for LRIs  0x8800 - 0x88FF  >= 0xC0000 Limited LRI cycles to the Display Engine 0x40000-0xBFFFF) are allowed, but must be spaced to allow only one pending at a time. This can be done by issuing an SRM to the same address immediately after each LRI. DWord Bit Description 0 31:29 Command Type Default Value: 0h MI_COMMAND Format: OpCode 28:23 MI Command Opcode Default Value: 29h MI_LOAD_REGISTER_MEM Format: OpCode Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 153 MI_LOAD_REGISTER_MEM 22 Use Global GTT Project: All This bit must be ‘1’ if the Per-Process GTT Enable bit is clear. Value Name Description Project 0h Per Process All Graphics Address 1h Global Graphics This command will use the global GTT to translate the Address and All Address this command must be executing from a privileged (secure) batch buffer. 21 Async Mode Enable Project: All If this bit is set then the command stream will not wait for completion of this command before executing the next command. 20:8 Reserved Project: All Format: MBZ 7:0 DWord Length Default Value: 1h Excludes DWord (0,1) Format: =n Total Length - 2 1 31:26 Reserved Format: MBZ 22:2 Register Address Project: All Format: MMIOAddress[22:2]MMIO_Register This field specifies Bits 25:2 of the Register offset the DWord will be written to. As the register address must be DWord-aligned, Bits 1:0 of that address MBZ. 1:0 Reserved Format: MBZ 2 31:2 Memory Address Project: All Format: GraphicsAddress[31:2]MMIO_Register This field specifies the address of the memory location where the register value specified in the DWord above will read from. The address specifies the DWord location of the data. 1:0 Reserved Project: All Format: MBZ 154 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 2.2.18 MI_DISPLAY_FLIP MI_DISPLAY_FLIP Source: BlitterCS Length Bias: 2 The MI_DISPLAY_FLIP command is used to request a specific display plane to switch (flip) to display a new buffer. The buffer is specified with a starting address and pitch. The tiled attribute of the buffer start address is programmed as part of the packet. The operation this command performs is also known as a “display flip request” operation – in that the flip operation itself will occur at some point in the future. This command specifies when the flip operation is to occur: either synchronously with vertical retrace to avoid tearing artifacts Programming Notes Project This command simply requests a display flip operation -- command execution then continues normally. There is no guarantee that the flip (even if asynchronous) will occur prior to subsequent commands being executed. (Note that completion of the MI_FLUSH_DW command does not guarantee that outstanding flip operations have completed). The MI_WAIT_FOR_EVENT command must be used to provide this synchronization to avoid back to back MI_DISPLAY_FLIP commands to the same display plane – by pausing command execution until a pending flip has actually completed. This synchronization can also be performed by use of the Display Flip Pending hardware status. See Display Flip Synchronization in the Device Programming Interface chapter of MI Functions. After a display flip operation is requested, software is responsible for initiating any required synchronization with subsequent buffer clear or blitter operations. For multi-buffering (e.g., double buffering) operations, this will typically require updating SURFACE_STATE or the binding table to change the blitter (back) buffer. In addition, prior to any subsequent clear or blitter operations, software must typically ensure that the new blitter buffer is not actively being displayed. Again, the MI_WAIT_FOR_EVENT command or Display Flip Pending hardware status can be used to provide this synchronization. See Display Flip Synchronization in the Device Programming Interface chapter of MI Functions. The display buffer command uses the X and Y offset for the tiled buffers from the Display Interface registers. Software is allowed to change the offset via the MMIO interface irrespective of the flip commands enqueued in the command stream. For tiled buffers, the display subsystem uses the X and Y offset in generation of the final request to memory. The offset is always updated on the next vblank for both Synchronous and Asynch Flips. It is not necessary to have a flip enqueued to update the X and Y offset The display buffer command uses the linear dword offset for the linear buffers from the Display Interface registers. Software is allowed to change the offset via the MMIO interface irrespective of the flip commands enqueued in the command stream. For linear buffers, the display subsystem uses the dword offset in generation of the final request to memory.  For synchronous flips the offset is updated on the next vblank. It is not necessary to have a sync flip enqueued to update the dword offset.  Linear memory does not support asynchronous flips DWord 3 (Left Eye Display Buffer Base Address) must not be set with synchronous flips or asynchronous flips. The full packet must be contained within the same cache line. There must be at least one valid command following this packet. Events must be unmasked in the Display Engine Render Response Mask Register (DE RRMR 0x44050) prior to waiting for them with a MI_WAIT_FOR_EVENT command, or in the case of flips or scanlines, prior to starting the flip or loading the scanline. Unmasked events will wake command streamer as they occur, so for improved power savings it is recommended to only unmask events that are required. Programming the DE RRMR register can be done through MMIO or a LOAD_REGISTER_IMMEDIATE command. Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 155 DWord Bit Description 0 31:29 Command Type Default Value: 0h MI_COMMAND Format: OpCode 28:23 MI Command Opcode Default Value: 14h MI_DISPLAY_FLIP Format: OpCode 22 Async Flip Indicator Project: All Format: Enable This bit should always be set if DW2 [1:0] == ‘01’ (async flip). This field is required due to HW limitations. This bit is used by the blitter pipe while DW2 is used by the display hardware. 21:19 Display (Plane) Select Project: All Format: U3 This field selects which display plane is to perform the flip operation. Value Name Project 0h Display Plane A All 1h Display Plane B All 2h Display Sprite A All 3h Display Sprite B All 4h Display Plane C 5h Display Sprite C 18:8 Reserved Project: Format: MBZ 7:0 DWord Length Default Value: 0h Excludes DWord (0,1) Format: =n Total Length - 2 For Synchronous Flips and Asynchronous Flips, this field must be programmed to 1h for a total length of 3. 1 31 Reserved Project: Format: MBZ 30:16 Reserved Project: All Format: MBZ 15:6 Display Buffer Pitch Default Value: 0h DefaultVaueDesc Project: All Format: U10 For Synchronous Flips only, this field specifies the 64-byte aligned pitch of the new display buffer. For Asynchronous Flips, this parameter is programmed so that all the flips in a flip chain should maintain the same pitch as programmed with the last synchronous or direct thru mmio 5:1 Reserved 156 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 MI_DISPLAY_FLIP Project: All Format: MBZ 0 Tile Parameter Format: Enable For Asynchronous Flips, this parameter cannot be changed. All the flips in a flip chain should maintain the same tile parameter as programmed with the last synchronous flip or direct thru mmio. Value Name Description 0h Linear [Default] For Syncronous Flips Only 1h Tiled X Programming Notes Performing a synchronous or asynchronous flip will drop any previous synchronous flip that has not yet completed. 2 31:12 Display Buffer Base Address Project: All Format: GraphicsAddress[31:12] This field specifies Bits 31:12 of the Graphics Address of the new display buffer. Programming Notes The Display buffer must reside completely in Main Memory This address is always translated via the global (rather than per-process) GTT 11:3 Reserved Project: All Format: MBZ 1:0 Flip Type This field specifies whether the flip operation should be performed asynchronously to vertical retrace. Value Name Description Project 00b Synchronous flip [Default] 00b Sync Flip [Default] The flip will occur during the vertical blanking interval – thus All avoiding any tearing artifacts. 01b Async Flip The flip will occur “as soon as possible” – and may exhibit All tearing artifacts 1b Reserved All Doc Ref #: IHD-OS-V1 Pt 4 – 05 12 5/31/2012 157 Revision History Revision Number Description Revision Date 1.0 First 2012 OpenSource edition May 2012 §§ 158 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 4 – 05 12