Intel® OpenSource HD Graphics
Programmer’s Reference Manual (PRM)
Volume 2 Part 2: Media and General Purpose
Pipeline
(Ivy Bridge)


                              ®
For the 2012 Intel Core™ Processor Family


May 2012
Revision 1.0


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




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

Under the following conditions:

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

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

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

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

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

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

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

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


Copyright © 2012, Intel Corporation. All rights reserved.




2                                              5/29/2012                 Doc Ref #: IHD-OS-V2 Pt 2 – 05 12
Contents
1.       Media and General Purpose Pipeline .................................................................................................. 4
     1.1 Introduction .......................................................................................................................................... 4
       1.1.1 Terminologies ................................................................................................................................. 4
       1.1.2 Hardware Feature Map in Products ............................................................................................... 5
     1.2 Media Pipeline Overview...................................................................................................................... 6
       1.2.1 GPGPU Media Pipe Differences .................................................................................................... 7
     1.3 Programming Media Pipeline ............................................................................................................... 8
       1.3.1 Command Sequence ...................................................................................................................... 8
       1.3.2 Interrupt Latency ........................................................................................................................... 10
       1.3.3 Programming the GPGPU Pipeline .............................................................................................. 10
       1.3.4 GPGPU Indirect Thread Dispatch ................................................................................................ 11
       1.3.5 GPGPU Context Switch ................................................................................................................ 12
       1.3.6 Media GPGPU Payload Limitations.............................................................................................. 13
       1.3.7 Synchronization of the Media/GPGPU Pipeline ........................................................................... 14
     1.4 Video Front End Unit .......................................................................................................................... 14
       1.4.1 Interfaces ...................................................................................................................................... 15
       1.4.2 Mode of Operations ...................................................................................................................... 16
       1.4.3 Parameterized Media Walker ....................................................................................................... 24
     1.5 Thread Spawner Unit ......................................................................................................................... 32
       1.5.1 Basic Functions ............................................................................................................................ 33
       1.5.2 Interfaces ...................................................................................................................................... 39
     1.6 Media State Model ............................................................................................................................. 39
     1.7 Media Messages ................................................................................................................................ 40
       1.7.1 Thread Payload Messages ........................................................................................................... 40
       1.7.2 Thread Spawn Message ............................................................................................................... 47
     1.8 Media State and Primitive Commands............................................................................................... 50
       1.8.1 MEDIA_VFE_STATE Command .................................................................................................. 50
       1.8.2 MEDIA_CURBE_LOAD ................................................................................................................ 55
       1.8.3 MEDIA_INTERFACE_DESCRIPTOR_LOAD Command ............................................................ 57
       1.8.4 INTERFACE_DESCRIPTOR_DATA ............................................................................................ 58
       1.8.5 MEDIA_STATE_FLUSH command .............................................................................................. 61
       1.8.6 MEDIA_OBJECT Command ........................................................................................................ 64
       1.8.7 MEDIA_OBJECT_PRT Command ............................................................................................... 67
       1.8.8 MEDIA_OBJECT_WALKER Command ....................................................................................... 69
       1.8.9 GPGPU_OBJECT ........................................................................................................................ 75
       1.8.10 GPGPU_WALKER Command .................................................................................................... 77




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                                        5/31/2012                                                                          3
1. Media and General Purpose Pipeline
1.1       Introduction
This section covers the programming details for the media (general purpose) fixed function pipeline. The
media pipeline is positioned in parallel with the 3D fixed function pipeline. It provides media
functionalities and has media specific fixed function capability. However, the fixed functions are designed
to have the general capability of controlling the shared functions and resources, feeding generic threads
to the Execution Units to be executed, and interacting with these generic threads during run time. The
media pipeline can be used for non-media applications, and therefore, can also be referred to as the
general purpose pipeline. For the rest of this chapter, we refer to this fixed function pipeline as the
media pipeline, keeping in mind its general purpose capability.
Concurrency of the media pipeline and the 3D pipeline is not supported. In other words, only one pipeline
can be activated at a given time. Switching between the two pipelines within a single context is supported
using the MI_PIPELINE_SELECT command.
Following are some media application examples that can be mapped onto the media pipeline. All these
applications are functional; however, the level of performance that can be achieved depends on the
hardware configuration and is beyond the scope of this document.

      MPEG-2 decode acceleration with HWMC (e.g. DXVA HWMC interface)
      MPEG-2 decode acceleration with IS/IDCT and forward (e.g. DXVA IDCT interface)
      MPEG-2 decode acceleration with VLD and forward (e.g. DXVA VLD interface)
      AVC decode acceleration with HWMC and forward including Loop Filter
      AVC decode acceleration with IT and forward including Loop Filter (with hardware IT)
      VC1 decode acceleration with HWMC and forward including Loop Filter
      VC1 decode acceleration with IT and forward including Loop Filter (with hardware IT and overlap
       filter)
      Advanced deinterlace filter (motion detected or motion compensated deinterlace filter)
      Video encode acceleration (with various level of hardware assistant)


1.1.1       Terminologies
AVC                               Advanced Video Coding. An international video coding standard jointly
                                  developed by MPEG and ITU. It is also known as H.264 (ITU), or MPEG-4 Part
                                  10 (MPEG).
Child Thread                      A thread corresponding to a leaf-node or a branch-node in a thread generation
                                  hierarchy. All thread originated from kernels running on the execution units are
                                  child threads.
EOB                               End of Block. It is a 1-bit flag in the non-zero DCT coefficient data structure
                                  indicating the end of an 8x8 block in a DCT coefficient data buffer.
IDCT                              Inverse Discrete Cosine Transform. It is the stage in the video decoding pipe
                                  between IQ and MC.
ILDB                              In-loop Deblocking Filter – the deblocking filter operation in the decoding loop. It
                                  is a stage after MC in the video decoding pipe.
IQ                                Inverse Quantization. It is a stage in the video decoding pipe between IS and
                                  IDCT.



Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                   5/31/2012                                                            4
IS                                  Inverse Scan. It is a stage in the video decoding pipe between VLD and IQ. In
                                    this stage, a sequence of none-zero DCT coefficients are converted into a block
                                    (e.g. an 8x8 block) of coefficients. VFE unit has fixed functions to support IS.
IT                                  Inverse Integer Transform. It is the stage in AVC or VC1 video decoding pipe
                                    between IQ and MC.
MPEG                                Motion Picture Expert Group. MPEG is the international standard body
                                    JTC1/SC29/WG11 under ISO/IEC that has defined audio and video
                                    compression standards such as MPEG-1, MPEG-2, and MPEG-4, etc.
MC                                  Motion Compensation. It is part of the video decoding pipe.
MVFS                                Motion Vector Field Selection – a four-bit field selecting reference fields for the
                                    motion vectors of the current macroblock.
PRT                                 A persistent root thread in general stays in the system for a long period of time.
                                    It is normally a parent thread. Only one PRT is allowed in the system.
                                    Hardware is responsible of re-dispatching the incomplete PRT at context
                                    restore, and a PRT can continue operations from that previously left-over state.
Parent Thread                       A thread corresponding to a root-node or a branch-node in thread generation
                                    hierarchy. A parent thread may be a root thread or a child thread depending on
                                    its position in the thread generation hierarchy.
Root Thread                         A thread corresponding to a root-node in a thread generation hierarchy. In the
                                    general-purpose pipeline, all threads originated from VFE unit are root threads.
Synchronized Root Thread            A root thread that is dispatched by TS upon a ‘dispatch root thread’ message.
TS                                  Thread Spawner. It is the second (and the last) fixed function in the general-
                                    purpose pipeline.
Unsynchronized Root Thread          A root thread that is automatically dispatched by TS.
VFE                                 Video Front End. It is the first fixed function in the general-purpose pipeline.
VLD                                 Variable Length Decode. It is the first stage of the video decoding pipe that
                                    consists mainly of bit-wide operations. The architecture supports hardware
                                    MPEG-2 VLD acceleration in the VFE fixed function stage.


1.1.2        Hardware Feature Map in Products
The following table lists the hardware features in the media pipe.

Video Front End Features in Device Hardware

               Features

            Generic Mode
                                       Y

            Root Threads
                                       Y

         Parent/Child Threads
                                       Y

SRT (Synchronized Root Threads)
                                       Y

     PRT (Persistent Root Thread)
                                       Y

 Interface Descriptor Remapping
                                       N
     IS Mode (HW Inverse Scan)
                                       N
     VLD Mode (HW MPEG2 VLD)
                                       N




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

          AVC MC Mode
                                     N
     AVC IT Mode (HW AVC IT)
                                     N

  AVC ILDB Filter (in Data Port)
                                     N
          VC1 MC Mode
                                     N
     VC1 IT Mode (HW VC1 IT)
                                     N
      Stalling HW Scoreboard
                                     Y

  Non-stalling HW Scoreboard
                                     Y

           HW Walker
                                     Y

            HW Timer
                                     Y

       Pipelined State Flush
                                     Y

            HW Barrier
                                     Y



1.2       Media Pipeline Overview
The media (general purpose) pipeline consists of two fixed function units: Video Front End (VFE) unit and
Thread Spawner (TS) unit. VFE unit interfaces with the Command Streamer (CS), writes thread payload
data into the Unified Return Buffer (URB), and prepares threads to be dispatched through TS unit. VFE
unit also contains a hardware Variable Length Decode (VLD) engine for MPEG-2 video decode. TS unit is
the only unit of the media pipeline that interfaces to the Thread Dispatcher (TD) unit for new thread
generation. It is responsible for spawning root threads (short for the root-node parent threads) originated
from VFE unit and for spawning child threads (can be either a leaf-node child thread or a branch-node
parent thread) originated from the Execution Units (EU) by a parent thread (can be a root-node or a
branch-node parent thread).
The fixed functions, VFE and TS, in the media pipeline, in most cases, share the same basic building
blocks as the fixed functions in the 3D pipeline. However, there are some unique features in media fixed
functions as highlighted by the followings.

     VFE manages URB and only has write access to URB; TS does not interface to URB.
     When URB Constant Buffer is enabled, VFE forwards TS the URB Handler for the URB Constant
      Buffer received from CS.
     TS interfaces to TD; VFE does not.
     TS can have a message directed to it like other shared functions (and thus TS has a shared function
      ID), and it does not snoop the Output Bus as some other fixed functions in the 3D pipeline do.
     A root thread generated by the media pipeline can only have up to one URB return handle.
     If a root thread has a URB return handle, VFE creates the URB handle for the payload to initiating
      the root thread and also passes it alone to the root thread as the return handle. The root thread then
      uses the same URB handle for child thread generation.



Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                 5/31/2012                                                6
    If URB Constant Buffer is enabled and an interface descriptor indicates that it is also used for the
     kernel, TS requests TD to load constant data directly to the thread’s register space. For root thread,
     constant data are loaded after R0 and before the data from the other URB handle. For child thread,
     as the R0 header is provided by the parent thread, Thread Spawner splits the URB handles from the
     parent thread into two and inserts the constant data after the R0 header.
    A root thread must terminate with a message to TS. A child thread should also terminate with a
     message to TS.
    High streaming performance of indirect media object load is achieved by utilizing the large vertex
     cache available in the Vertex Fetch unit (of the 3D pipeline).

Top level block diagram of the Media Pipeline




1.2.1     GPGPU Media Pipe Differences
You can access the GPGPU pipe with the GPGPU_OBJECT and GPGPU_WALKER commands. A
thread group id is associated with every dispatch, which is used to allocate and track barriers and Shared
Local Memory. The GPGPU pipe has access to all the shared functions. The GPGPU pipe does not use
the Scoreboard and should not dispatch child threads.
You can access the Media pipe with the various MEDIA_OBJECT* commands. Barriers and Shared Local
Memory are not allocated for them. All shared functions are available. The Scoreboard is available to
control dispatch depending on the completion of neighboring blocks.




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                5/31/2012                                                7
1.3       Programming Media Pipeline

1.3.1      Command Sequence
Media pipeline uses a simple programming model. Unlike the 3D pipeline, it does not support pipelined
state changes. Any state change requires an MI_FLUSH or PIPE_CONTROL command. When
programming the media pipeline, it should be cautious to not use the pipelining capability of the
commands described in the Graphics Processing Engine chapter.
To emphasize the non-pipeline nature of the media pipeline programming model, the programmer should
note that if any one command is issued in the “Primitive Command” step, none of the state commands
described in the previous steps cannot be issued without preceding with a MI_FLUSH or
PIPE_CONTROL command.
With the addition of MEDIA_STATE_FLUSH command, pipelined state changes are allowed on the
media pipeline. The MEDIA_STATE_FLUSH serves as a fence for state change by flushing the VFE/TS
front ends but not waiting for threads to retire.
The basic steps in programming the media pipeline are listed below. Some of the steps are optional;
however, the order must be followed strictly. Some usage restrictions are highlighted for illustration
purpose. For details, refer to the respective chapters for these commands.

1.3.1.1      Command Sequence
For, the media pipeline is further simplified with fixed functions like MPEG2 VLD and AVC/VC1 IT
removed. The addition includes (1) CURBE command is now unique to the media pipeline and (2) the
interface descriptors are delivered directly as a media state command instead of being loaded through
indirect state.
The programming model is listed as the following.

     Step1: MI_FLUSH/PIPE_CONTROL
                o   This step is mandatory.
                o   Multiple such commands in step 1 are allowed, but not recommended for performance
                    reason.

     Step2: State command PIPELINE_ SELECT
                o   This step is optional. This command can be omitted if it is known that within the same
                    context media pipeline was selected before Step 1.
                o   Multiple such commands in step 2 are allowed, but not recommended for performance
                    reason.

     Step3: State commands configuring pipeline states
                o   STATE_BASE_ADDRESS
                           This command is mandatory for this step (i.e. at least one).
                           Multiple such commands in this step are allowed. The last one overwrites
                            previous ones.
                           This command must precede any other state commands below.
                           Particularly, the fields Indirect Object Base Address and Indirect Object
                            Access Upper Bound are used to control indirect Media object load in VF.




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                5/31/2012                                                   8
                           The fields Dynamics Base Address and Dynamics Base Access Upper
                            Bound are used to control indirect Curbe and Interface Descriptor object load
                            in VF.
                           Note: This command may be inserted before (and after) any commands listed
                            in the previous steps (Step 1 to 3). For example, this command may be placed
                            in the ring buffer while the others are put in a batch buffer.
               o   STATE_SIP
                           This command is optional for this step. It is only required when SIP is used by
                            the kernels.
               o   MEDIA_VFE_STATE
                           This command is mandatory for this step (i.e. at least one).
                           This command cause destruction of all outstanding URB handles in the
                            system. A new set of URB handles will be generated based on state
                            parameters, no. of URB and URB length, programmed in VFE FF state.
                           Multiple such commands in this step are allowed. The last one overwrites
                            previous ones.
               o   MEDIA_CURBE_LOAD
                           This command is optional.
                           Multiple such commands in this step are allowed. The last one overwrites
                            previous ones.
               o   MEDIA_INTERFACE_DESCRIPTOR_LOAD
                           This command is mandatory for this step (i.e. at least one).
                           Multiple such commands in this step are allowed. The last one overwrites
                            previous ones.

    Step4: Primitive commands
               o   MEDIA_OBJECT
                           This step is optional, but it doesn’t make practical sense not issuing media
                            primitive commands after being through previous steps to set up the media
                            pipeline.
                           Multiple such commands in step 4 can be issued to continue processing
                            media primitives.

With the addition of MEDIA_STATE_FLUSH command, pipelined state changes are allowed on the
media pipeline. In order to support context switch for barrier groups, watermark and barrier dependencies
are added to the MEDIA_STATE_FLUSH command. The usage of barrier group may have strict
restriction that all threads belonging to a barrier group must all be present in order to avoid deadlock
during context switch. Here are the example programming sequences to allow context switch. Note that
the use of MEDIA_OBJECT_PRT and MI_ARB_ON_OFF are optional.

    MEDIA_VFE_STATE
    MEDIA_INTERFACE_DESCRIPTOR_LOAD
    MEDIA_CURBE_LOAD (optional)
    MEDIA_GATEWAY_STATE (for example for barrier group 1)




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                5/31/2012                                                 9
    MEDIA_OBJECT_PRT (with VFE_STATE_FLUSH set and PRT NEEDED set.)
    MEDIA_STATE_FLUSH (with watermark set for group 1)
    MI_ARB_ON_OFF (OFF)// Arbitration must be turned off while sending objects for group 1
    Several MEDIA_OBJECT command (for barrier group 1)
    MI_ARB_ON_OFF (ON)// Arbitration is allowed
    MEDIA_STATE_FLUSH (optional, only if barrier dependency is needed)
    MEDIA_INTERFACE_DESCRIPTOR_LOAD (optional)
    MEDIA_CURBE_LOAD (optional)
    MEDIA_GATEWAY_STATE (for example for barrier group 2)
    MEDIA_STATE_FLUSH (with watermark set for group 1)
    MI_ARB_ON_OFF (OFF)// Arbitration must be turned off while sending objects for group 2
    Several MEDIA_OBJECT command (for barrier group 2)
    MI_ARB_ON_OFF (ON)// Arbitration is allowed
    …
    MI_FLUSH

Commands for the GPGPU pipe (GPGPU_OBJECT and GPGPU_WALKER) should be separated from
commands for the Media pipe (MEDIA_OBJECT*) by an MI_FLUSH.


1.3.2       Interrupt Latency
Command Streamer is capable of context switching between primitive commands.
For all independent threads, it is not much a problem. The interrupt latency is dictated by the longest
command that is likely to have the largest number of threads. For VLD mode, such a command may be
corresponding to a largest slice in a high definition video frame. This is application dependent, there are
not much host software can do. For Generic mode, programmer should consider to constrain the compute
workload size of each thread.
In modes with child threads, a root thread may persist in the system for long period of time – staying until
its child threads are all created and terminated. Therefore, the corresponding primitive command may
also last for long time. The Software designer should partition the workload to restrict the duration of each
root thread. For example, this may be achieved by partitioning a video frame and assigning separate
primitive commands for different data partitions.
In modes with synchronized root threads, a synchronized root thread is dependent on a previous root or
child thread. This means context switch is not allowed between the primitive command for the
synchronized root thread and the one for the depending thread. So no command queue arbitration should
be allowed between them. Software designer should also restrict the duration of such non-interruptible
primitive command segments.


1.3.3       Programming the GPGPU Pipeline
       1.   In MEDIA_VFE_STATE choose whether to set DW2.6 Bypass Gateway Control. Usually this
            will be set, allowing the gateway to be used without OpenGateway/CloseGateway.
       2.   Set up interface descriptor with # of threads in barrier. The barrier id is not specified here
            because can Gen7 automatically assigns barriers to thread groups when they are free. The
            amount of CURBE data to deliver per thread dispatch is set in the interface descriptor.




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                 5/31/2012                                                  10
       3.    Set up CURBE with thread ids and common data for all thread dispatches in the thread group.
       4.    Set up a GPGPU_WALKER command or a set of GPGPU_OBJECT commands with the
             thread group ids to dispatch the threads. The CURBE data is sent in sections for each thread
             dispatch in the thread group; a new thread group starts sending the CURBE data from the
             beginning of the buffer.
Note: Gen7 can either have the barriers and SLM automatically managed by hardware or specified by
software. Mixing software managed and hardware managed in the same set of threads is allowed, but
may cause stalls if there is an allocation conflict.
Note: When using GPGPU_OBJECT, finish dispatching a thread group before starting a different one.
The kernel should handle the barriers as follows:
The BarrierMsg message contains the barrier id and a way to reprogram the barrier count. The barrier
count reprogram is not normally used for GPGPU workloads. When all threads in the group have reached
the barrier, the gateway returns a notification bit 0.
The kernel must wait for the barrier to finish with a WAIT N0.


1.3.4        GPGPU Indirect Thread Dispatch
Indirect thread dispatch allows one thread group to control the group size of a following thread group.
This is the sequence of commands in the ring buffer:
GPGPU_OBJECT/WALKER     // Either a set of objects or a walker to dispatch a thread group which will write the
                        next groups properties to memory
MI_FLUSH                // Make sure the thread group has finished executing
MEDIA_CURBE_LOAD        // Load the thread ids for new group
                        // Load the indirect MMIO GPGPU registers from the mem written by the previous
MI_LOAD_REGISTER_MEMORY group
GPGPU_WALKER (indirect) // A walker with the indirect bit set.

The first thread group writes this data to memory:
        1) The thread ids delivered in the CURBE - written where the following MEDIA_CURBE_LOAD
        will read them.
        2) The GPGPU_WALKER parameters are written to memory where the
        MI_LOAD_REGISTER_MEMORY will read them.
            a. GPGPU_DISPATCHDIMX - the X dimension of the number of thread groups to dispatch in
            dword 4.
            b. GPGPU_DISPATCHDIMY - the Y dimension of the number of thread groups to dispatch in
            dword 6.
            c. GPGPU_DISPATCHDIMZ - the Z dimension of the number of thread groups to dispatch in
            dword 8.
See vol1c Memory Interface and Command Stream for the MMIO register addresses and formats.
 The indirect registers are not supposed to be set to 0, but sometimes the kernel computing the value
wants no work done and sets them to 0. This does not work correctly, so a work-around in the command
stream is needed:
GPGPU_WALKER // The thread group which writes the indirect values to memory locations
MI_CONDITIONAL_BATCH_BUFFER_END DIMX 0 // End batch buffer if X dim in memory = 0
MI_CONDITIONAL_BATCH_BUFFER_END DIMY 0 // End batch buffer if Y dim in memory = 0



Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                 5/31/2012                                                 11
MI_CONDITIONAL_BATCH_BUFFER_END DIMZ 0 // End batch buffer if Z dim in memory = 0
MI_LOAD_REGISTER_MEM GPGPU_DISPATCHDIMX DIMX // Normal load of register from memory
MI_LOAD_REGISTER_MEM GPGPU_DISPATCHDIMY DIMY
MI_LOAD_REGISTER_MEM GPGPU_DISPATCHDIMZ DIMZ
GPGPU_WALKER // The thread groups which depend on the indirect dimensions


1.3.5     GPGPU Context Switch
The GPGPU pipeline supports interruption of GPGPU workloads on thread group boundaries. This is
needed for GPGPU workloads that are so large that there is a risk of the display becoming n on-
responsive if the work cannot be interrupted for other jobs.
A workload is interrupted with the MI_ARB_CHECK command with the UHPTR register. The
MI_ARB_CHECK command is placed throughout the command buffer. The driver updates the UHPTR
register when a new context is needed; MI_ARB_CHECK checks for this and reprograms the head and
tail pointers to the new batch of commands. The driver waits for the pre-emption to occur without going
into RS2.
The GPGPU needs to modify this to allow a GPGPU_WALKER command to be interrupted. This is done
by following each GPGPU_WALKER command with a MEDIA_STATE_FLUSH. This causes the CS to
stop fetching commands until either the command completes or until the UHPTR valid bit is set.
GPGPU workloads can be dispatched with either GPGPU_OBJECT commands or GPGPU_WALKER
commands. In the case of GPGPU_OJBECT, the MEDIA_STATE_FLUSH/ MI_ARB_CHECK pair must
be placed in the batch buffer at thread group boundaries, since preemption cannot occur with a thread
group partially dispatched. GPGPU_WALKER commands can dispatch multiple thread groups, in this
case the MEDIA_STATE_FLUSH/ MI_ARB_CHECK follows each GPGPU_WALKER and the hardware
takes care of noticing the UHPTR update and stopping at the next thread group boundary.
The commands in the batch buffer will look something like this:
     Command Ring                                            Comments
MI_SET_CONTEXT        Go to GPGPU context
MI_BATCH_BUFFER_START If new context, set address to top of batch. Otherwise, address needs to be set to the
                      command preempted (given in the HWSP).


    Command Batch                                         Comments
GPGPU_OBJECT
GPGPU_OBJECT
...               (more threads forming a complete thread group)
MEDIA_STATE_FLUSH Check for preemption at thread group boundary. “Preemption” defined by the UHPTR valid
                  bit set.
MI_ARB_CHECK      Move the head only if UHPTR valid bit is set.
…
GPGPU_WALKER
MEDIA_STATE_FLUSH Check for preemption at thread group boundary internal to GPGPU_WALKER command.
                  “Preemption” defined by the UHPTR valid bit set.
MI_ARB_CHECK      Move the head only if UHPTR valid bit is set.




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                 5/31/2012                                                12
The context saved will consist of the state commands for VFE and a modified GPGPU_WALKER
command with a new starting thread group id. On context restore, the commands are executed to start
the GPGPU_WALKER where it left off before continuing with the rest of the command buffer.
An example software model for starting a preemption goes like this:
1.   The UHPTR is reprogrammed to point to the current tail of the ring buffer.
2.   Insert new commands:
      a. LRI to UHPTR to clear valid.
      b. Store Register to mem the preempted batch offset.
      c. Store Register to mem the preempted ring offset.
      d. Pipe_control notification.
      e. An MI_SET_CONTEXT to the new context is put into the ring.
3.   Insert commands for new context. i.e. batch buffers.
4.   Update Tail Pointer.
Note: 2-3 items above could happen during execution of a thread group so the HW may see the tail
pointer updated before preemption starts.
Note: The driver needs to turn off RC6 during items 1 and 4.


1.3.6      Media GPGPU Payload Limitations
There are 3 types of payload that the media/GPGPU instructions can have, but not all of them are
allowed. The following table lists the legal combinations:
          WorkLoad                            Commands                              Data Stored
GPGPU                           GPGPU_WALKER                             CURBE
                                GPGPU_WALKER                             INDIRECT
                                GPGPU_OBJECT                             CURBE
Media(Legacy)                   Media_Object                             CURBE
                                Media_Object                             INDIRECT
                                Media_Object                             INLINE
                                Media_Object                             CURBE+INLINE
                                Media_Object                             CURBE+INDIRECT
                                Media_Object                             INLINE+INDIRECT
                                Media_Object                             CURBE+ INLINE+INDIRECT
                                Media_Object_Walker                      CURBE
                                Media_Object_Walker                      INLINE
                                Media_Object_Walker                      CURBE+INLINE
Media using Barrier/SLM         Media_Object_GRPID                       CURBE
                                Media_Object_GRPID                       INDIRECT
                                Media_Object_GRPID                       INLINE
                                Media_Object_Walker (with group id)      CURBE
                                Media_Object_Walker (with group id)      INLINE




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                  5/31/2012                                          13
1.3.7      Synchronization of the Media/GPGPU Pipeline
The Media/GPGPU Pipeline is synchronized in the same way as the 3D pipeline using the
PIPE_CONTROL command.
See the Bspec section on 3d pipe synchronization: vol2a 3D Pipeline - Overview [SNB+] > 3D Pipeline >
Synchronization of the 3D Pipeline.


1.4      Video Front End Unit
The Video Front End unit is the first fixed function unit in the media pipeline. It processes
MEDIA_OBJECT commands to generate root threads by preparing the control (including interface
descriptor pointers) and payload (data pushed into the GRF) for the root threads.
VFE supports three modes of operation: Generic mode, Inverse Scan mode and VLD mode.

     Generic mode: In the Generic mode, VFE serves as a conduit for general-purpose kernels fully
      configured by the host software. There is no application specific hardware enabled in this mode.
     IS (Inverse Scan) mode: The IS mode is a special mode for video decoding when off-host IDCT
      acceleration is supported by kernels running on execution units.
     VLD mode: It is a special mode for video decoding when MPEG-2 off-host VLD acceleration is
      supported by hardware.
     AVC-IT (AVC Inverse Integer Transform) mode: The AVC-IT mode is a special mode for AVC
      video decoding when off-host IDCT acceleration is supported by VFE hardware and MC and Loop
      Filter are supported by kernels running on execution units.
     AVC-MC (AVC Motion Compensation) mode: The AVC-MC mode is a special mode for AVC video
      decoding with host-based IDCT and MC and Loop Filter are supported by kernels running on
      execution units.
      VC1-IT (VC1 Inverse Integer Transform) mode: The VC1-IT mode is a special mode for VC1
      video decoding when off-host IDCT acceleration is supported by VFE hardware and MC and Loop
      Filter are supported by kernels running on execution units.

The following figure illustrates the three modes of operation. The details can be found in the rest of the
sections.




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                 5/31/2012                                                  14
VFE Functional Blocks and Modes of Operations




MEDIA_STATE_POINTERS command configures VFE in one of the three modes using. Mode switching
requires media pipeline state change.


1.4.1     Interfaces
VFE unit acquires its states from Sate Variable Manager, accesses URB handles from the Global URB
Manager, receives state and primitive commands from CS unit, writes thread payloads to URB, and
sends new thread to TS unit. It does not directly interface to Thread Dispatcher. When VFE is ready for a
thread, it sends the interface descriptor pointer for the thread to TS.

1.4.1.1      Interface to Command Streamer
VFE interfaces to CS to acquire the control data, inline data and indirect data of MEDIA_OBJECT
commands. The interface supports the throughput of a given mode of operation of VFE. For example, in
VLD mode and IS mode, VFE consumes one dword at a time, one dword to the variable length decoder
or one dword to the inverse-scan operator. In Generic mode, VFE is capable of a much higher throughput
to push indirect data (as thread payload data) into URB. As throughput for indirect data is much higher
than that of inline data, when large amount of user data need to be passed through VFE unit, if
applicable, it is encouraged to use indirect object load.

1.4.1.2      Interface to Thread Spawner
VFE also transmits scratch memory base address received from State Variable Manager to TS, and
passes on the Constant URB handle received from CS.
VFE receives URB handle dereference signal from TS.




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12               5/31/2012                                              15
1.4.1.3       Interface to State Variable Manager
State Variable Manager is responsible of fetching media state structure from memory. VFE only acquires
its state variable upon the first primitive command. Therefore, host software is allowed to change media
states before issuing primitive commands. As media pipeline does not support pipelined state change, a
pipeline flush is required before any state change to make sure that there are no outstanding primitive
commands in the pipeline.

1.4.1.4       Interface to Global URB Manager
VFE is responsible for managing URB handles for all root threads. Upon state change, VFE allocates
URB handles through the Global URB Manager. VFE manages the URB handles in a circular buffer. URB
handle referencing is in a strict order (taking from the head of the circular buffer), even though the handle
dereferencing may occur out of order.
When starting a root thread, VFE reference one and only one URB handle, forwarding it to TS. TS then
forwards this handle to TD for thread dispatching.
The URB handle for a root thread is used in two ways: (1) serving as buffer space for VFE to assemble
thread payload, and (2) serving as the return URB buffer for the root thread to assemble child threads and
their payload.
TS sends an indication to VFE when it is safe to dereference the URB handle, and VFE dereferences it.
After a URB handle has been dereferenced, VFE can assign it to a new thread.

1.4.1.5       Interface to URB
VFE sends the assembled root thread payload to URB via a wide data bus. In Generic mode, the data
comes from the command as inline or indirect data objects. In IS mode, the inline data is directly
assembled as URB register wide payloads, and the indirect data are assembled through the Inverse Scan
logic. In VLD mode, the data is decoded from the indirect object (i.e. bitstream data).


1.4.2      Mode of Operations

1.4.2.1       Generic Mode
In the Generic mode, VFE serves as a conduit for general-purpose kernels fully configured by the host
software. As there is no special fixed function logic used, the Generic mode can also be viewed as a
‘pass-through’ mode. In this mode, VFE generates a new thread for each MEDIA_OBJECT command.
The payload contained in the MEDIA_OBJECT command (inline and/or indirect) is streamed into URB.
The interface descriptor pointer is computed by VFE based on the interface descriptor offset value and
the interface descriptor base pointer stored in the VFE state. VFE then forwards the interface descriptor
pointer and the URB handle to TS to generate a new root thread. Many media processing applications
can be supported using the Generic mode: MPEG-2 HWMC, frame rate conversion, advanced
deinterface filter, to name a few.

1.4.2.2       Interface Descriptor Selection
After populating the URB with the data, VFE notifies TS to initiate the thread. TS needs an interface
descriptor pointer to fetch the information for thread initiation. A list of interface descriptors is arranged by
the host software as a descriptor array in memory, as shown in the media state model in the Media State
Model Figure.




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                   5/31/2012                                                  16
VFE obtains the interface descriptor base pointer from the VFE state structure. The offset into the list of
interface descriptors comes from MEDIA_OBJECT command. Each interface descriptor has a fixed size.
VFE uses a multiple of the fixed size and the offset to add to the base pointer, and creates the final
interface descriptor pointer to be sent to TS.
TS fetches the interface descriptor through the Instruction State Cache (ISC) using the interface
descriptor pointer. TS then initializes the thread through the Thread Dispatcher. The interface descriptor
pointer is given to TS by VFE for a root thread and by a thread for a child thread. The R0 header is
formed by TS for a root thread and is stored in URB by the parent thread for a child thread.

1.4.2.3      Scratch Space Allocation
TS handles the allocation of scratch space. Since TS does not have a normal state interface, VFE
receives the scratch space configuration with the VFE state, then forwards the configuration to TS with
the interface descriptor pointer.

1.4.2.4      GPGPU Mode
The general purpose (GPGPU) mode allows the Gen7 architecture to be used by general purpose
parallel APIs such as . This is similar to the Generic mode with additional support for automatic
generation of threads, Shared Local Memory and Barriers.

1.4.2.4.1       Automatic Thread Generation
A single GPGPU job may require thousands or even millions of GPU_OBJECT commands. Rather than
create them separately, it would be better to generate them algorithmically. To do this a
GPGPU_WALKER command is created.
Rather than modifying the Media Walker, a simple Thread Group Walker is created instead:




The X/Y/Z counters for the thread group will have an initial and maximum value. The thread group id sent
with each dispatch consists of these 3 numbers. These counters are 32-bits since the spec does not give
a limit to the size of the thread id.
The 3 thread counters count the number of dispatches in a single thread group – up to 32 dispatches for
SIMD32 or 64 dispatches for SIMD16/8. There are 3 of them in order to select the execution masks
correctly – see section Execution Masks on execution masks. Each one is 6-bits in order to allow full
flexibility of any dimension going to 64 while the rest do not increment.




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                5/31/2012                                                   17
A thread is generated each time one of the thread counters increment. When all the counters reach their
maximum values, the thread group is done and the thread group counter can increment and start a new
thread group. When the thread group X counter reaches its maximum it is reset to 0, and the Y counter is
incremented.
The compiler determines how many SIMD channels are needed per thread group, and then decides how
these will be split among EU threads. The number of threads is programmed in the thread counter, and
the SIMD mode (SIMD8/SIMD16/SIMD32) is specified in the GPGPU_WALKER command.

1.4.2.4.2        Thread Payload
The payload to each thread dispatched is:
       1.   A thread group id which identifies the group the set of threads belong to. This is in the form of
            a set of 3, 32-bit X/Y/Z values.
       2.   The set of X/Y/Z that form the thread id for each channel. If Z is not used then only X/Y are
            needed.
       3.   The execution mask which indicates which channels are active.
Thread ids form a 2D or 3D surface which has to be mapped into SIMD32, SIMD16 or SIMD8 dispatches.
Rather than have the hardware force a particular mapping of thread ids to channels, the mapping will be
supplied by the compiler. The VFE will receive a simple count of the number of threads per thread group
which will be used to count the number of dispatches. The thread ids for all threads in a thread group are
put in a constant buffer with the MEDIA_CURBE_LOAD command. A single set of thread ids can be used
repeatedly for all thread groups, since the thread ids are the same for each thread group id output by the
GPGPU_WALKER.
The data required is up to the compiler, but here is an example set of payloads for a 2 Z x 2Y x 12 X and
a SIMD16 dispatch. This thread group requires 3 dispatches:




In this case the thread counter width would be programmed with a maximum value of 3 (since all the
execution masks are all F, it doesn’t matter how the thread counters are programmed as long as they
count to 3 before finishing the thread group).
The first dispatch would tell the TS (who would tell the TD) that the payload starts at the beginning of the
constant buffer and has a length of 3. The next dispatch would have a payload starting at
constant_buffer_start + 3. The final dispatch payload starts at constant_buffer_start + 6. If there are more
thread groups in the command they would get exactly the same payload – the only difference is the
thread group id (as well as a different barrier and shared local memory space).




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                 5/31/2012                                                 18
1.4.2.4.3       Execution Masks
The number of channels required by the GPGPU job may not evenly fit into the number of SIMD
channels. That can leave some channels idle. The execution mask is used to tell the hardware which
channels are to be used.
A thread group is modeled as a 3D solid with each channel acting as one X/Y/Z point in the solid. This
can take the form of a line with 1024 channels with X from 0 to 1023 and constant Y/Z, a square with X=0
to 32 and Y=0 to 32, or a cube with X=0 to 9, Y=0 to 9, Z=0 to 9. Software needs to determine how these
shapes are mapped onto the 32 SIMD32 channels per dispatch (or 16 SIM16, etc). The mapping per
thread is assumed to be a 2D square of channels such as 8x4, 16x2, 32x1. Below is a diagram of a 22x6
thread group that is mapped onto a set of 8x4 SIMD32 channels:




Note that the dispatches to the top and left have execution masks of all-F, while all the right edge
dispatches have the same execution mask; likewise all the bottom edge dispatches have the same
execution mask. The bottom right is the logical-AND of the right and bottom edge dispatches.
A 32-bit right and bottom mask is sent with the GPGPU_WALKER command, and the thread width, height
and depth counters are used to determine when they are used (width, height and depth are used instead
of X/Y/Z, since it is not required that width = X – width and height are the two variables that are changing
in a single SIMD dispatch even if they are Y and Z).
For each dispatch the width counter is incremented until it reaches the maximum – the dispatch with
width=max will use the right execution mask. The height counter is then incremented and process
repeated. If at any time the height counter = max then the execution mask is the bottom execution mask.
When the height and width counters are both max then the dispatch will be the AND of the right and
bottom and the depth counter will increment.
The same 2Z x 2Y x 12X thread group described above dispatched as SIMD32 with each dispatch
delivering a 16X x 2Y shape would require 2 dispatches with empty bits in the right execution mask and
all F in the bottom.




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                5/31/2012                                               19
The width and height counter would have a maximum of 1, and the depth counter would have a maximum
of 2. The two dispatches would use the AND of the two masks, but since the bottom mask is F it would be
the same as just the right mask.
The execution masks can also be used when the software wants to pack the channels rather than lay
them out in a regular pattern:




In this case the width counter can have a maximum of 2, and the height and depth counters with a
maximum of 1. The first dispatch will use the bottom mask only (all-F) and the second will use the right
AND bottom mask to remove the channels that are not used.

1.4.2.4.4       Payload Storage
The MEDIA_CURBE_LOAD constant data is stored in the URB by CS and read out by TDL when the
dispatch occurs. The inline payload with the execution counts is sent to VFE from CS. The execution
counts are stored internal to VFE.




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                5/31/2012                                                 20
Only 32 threads are allowed for SIMD32 to match the 1024 thread limit, requiring 32 execution count
bytes, or 8 DW payload. SIMD16 and SIMD8 allow the full 64 thread per half-slice, and so require as
much as 16 DWords.
The X/Y/Z payload size per dispatch is specified in the command, but a maximum size is 3 16-bit
numbers per 1024 SIMD channels, or 6 kbytes.

1.4.2.4.5       URB Management
The VFE manages the URB in GPGPU and generic/media modes. The first 32 URB entries are reserved
for the interface descriptor, and CURBE data is placed after the IDs. URB handles are needed for indirect
data and parent/child communication; when the VFE starts up it creates up to 64 handles by partitioning
the remaining URB space into evenly spaced addresses and saving the resulting handles in a FIFO. The
handles can then be treated just like ones created by the URBM – send to TD on dispatch and recovered
on the handle return bus.




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12               5/31/2012                                              21
MEDIA_VFE_STATE specifies the amount of CURBE space, the URB handle size and the number of
URB handles. The driver must ensure that ((URB_handle_size * URB_num_handle) – CURBE – 32) <=
URB_allocation_in_L3.

1.4.2.4.6       AVC-Style Dependency Example
For AVD decoding, dependencies for a given macroblock may be set based on the availability of neighbor
macroblocks, namely A, B, C, D and left-bottom neighbors (left-bottom only if MbAff = 1), as well as the
current macroblock’s address, MbAff flag and FieldMbFlag. For a macroblock in a progressive frame
picture or a field picture, one macroblock may depend on up to four neighbors, A, B, C and D as shown in
AVC Style Dependency Example. For a macroblock in a MbAff pair, it may depend on up to three, five or
eight neighbors as shown in AVC Style Dependency Example and AVC Style Dependency Example,
based on the current macroblock’s address and FieldMbFlag.
The neighbor’s availability depends on the corresponding IntraPredAvailFlagA|B|C|D|E flags for the
macroblock (or the macroblock pair). Hardware assumes that the flags are set correctly in the
MEDIA_OBJECT_EX command as shown in Macroblock indices for field picture destination. For
simplicity, the left neighbor pair (A0 and A1) availability for a MbAff macroblock can be determined as a
group by IntraPredAvailFlagA | IntraPredAvailFlagE. For the second macroblock in a ‘frame’ MbAff
pair, it depends on the first macroblock in the pair and it is always available.

Neighbor addresses of a macroblock in a progressive frame picture (MbAff = 0) or a field picture
with up to 4 dependencies




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                5/31/2012                                                  22
Neighbor addresses of the first macroblock in a MbAff frame picture (MbAff = 1) with up to 8
dependencies




Neighbor addresses of the second macroblock in a MbAff frame picture (MbAff = 1) with up to 8
dependencies




Neighbor Availability
MbAff FieldMbFlag VertOrigin[0] A B C D LB         Comments
0     0/1         0/1                      Progressive or Field picture
                                   
1     0           0
                                      1st Frame MbAff macroblock




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                 5/31/2012                                     23
MbAff FieldMbFlag VertOrigin[0] A B C D LB        Comments
1     0           1               na 0 na
                                          2 Frame MbAff macroblock
                                             nd



1         1              0
                                             1st Field MbAff macroblock

1         1              1
                                             2nd Field MbAff macroblock


1.4.2.5          VC1-Style Dependency Example
For VC1, only one dependency may be set depending on the availability of the upper neighbor
macroblock.

Macroblock sequence order in a VC-1 picture with WidthInMblk = 5 and HeightInMblk = 6

        0 1 2 3 4

    0 1 2 3 4
0

    5 6 7 8 9
1

    10 11 12 13 14
2

    15 16 17 18 19
3

    20 21 22 23 24
4

    25 26 27 28 29
5



1.4.3         Parameterized Media Walker
The Parameterized Media Walker is a hardware thread generation mechanism that creates threads
associated with units in a generalized 2-dimensional space, for example, blocks in a 2D image. With a
small number of unit step vectors, the walker can implement a large number of walking patterns as
described hereafter. This command may provide functions that are normally handled by the host
software, thus, may be used to simplify the host software and GPU interface.
The walker described herein is doubly nested, where essentially a “local” walker can perform a variety of
2-dimensional walking patterns and a “global” walker can perform similar 2-dimensional walking patterns
upon many local walkers. The local walker has 3 levels (outer, middle, and inner) while the global walker
has 2 levels (outer and inner). Thus, the algorithm has 5-nested loops that modify local state based on
user-defined unit step vectors.
The Walker’s programmability is derived from:

        The walker traverses a unit-normalized surface. Some example unit sizes:
                     o       1x1: Walking pixels
                     o       4x4: Walking sub-blocks
                     o       16x16: Walking macro-blocks
                     o       32x16: Walking macro-block-pairs

        The use of unit step vectors to describe the motion at each of level of nesting



Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                       5/31/2012                                       24
    Starting locations for the local and global walkers
    Block sizes of the local and global walker
    And a small number of special mode controls for the inner-most loop which are aimed at efficiently
     dividing an image into two balanced workloads for dual-slice designs.

1.4.3.1      Walker Parameter Description
The global and local loops are both described by the same four parameters:

    Resolution,
    Starting location,
    Outer unit vector,
    Inner unit vector

The local inner loop has some special modes that will be described later. A table of the user inputs and
some example values are given below:




It should be emphasized that the value of what a “unit” represents is implicitly defined by the user. In
other words, the walker traverses a “unit normalized space” that is not inherently bound to pixel walking. If
the smallest unit of work the user wants to walk is a 4x3 block of pixels, you can program the inner loop to
step (4,3) or (1,1):

    In the first case (4,3) the user is walking in units of pixels
    In the second case (1,1) the user is walking in units of 4x3 blocks of pixels.

It should be noted that hardware doesn’t contain enough bits for pixel walking for pixel resolution like
1920x1088. The intended usage of the walker is for block walking whereas the block size is not relevant
to the walker parameters.

1.4.3.2      Basic Parameters for the Local Loop
The local inner and outer loop xy-pair parameters alone can describe a large variety of primitive walking
patterns. Below are 9 primitive walking patterns generated by varying only the inner and outer unit step
vectors of the local loop:




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                   5/31/2012                                               25
    The top row shows the outer unit vector pointing down (+Y) and the inner unit vector pointing right
     (+X). Rows and columns can easily be skipped by increasing the unit step vectors above one.
    The middle row the outer unit vector pointing right (+X) and the inner unit vector pointing down (+Y).
     Again, rows and columns are skipped by increasing the unit step vectors beyond one.
    The last row shows the capability to walk angles not perpendicular to the edge. The 1 st shows a 45º
     walking pattern by setting the inner unit vector to (-1,1). The 2nd shows a checkerboard pattern by
     skipping every other outer loop and retaining the inner unit vector of (-1,1). The 3rd shows a 26.5º
     walking pattern by setting the inner unit vector to (-2,1).

The block resolution, shown as [8,8], and the starting location, currently [0,0], can be varied and the
above patterns can be stretched and rotated many ways. The diagram below shows an example of where
the start position and unit step vectors can be set to achieve a full rotation of the same pattern:




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                5/31/2012                                                 26
1.4.3.3      Dual Mode of Local Loop
The local Inner Loop Special mode selects are included to aid in the distribution of work, specifically with
two slices in mind. Essentially, the local inner loop can be bisected and each half-walk can be directed
inward towards the center of the image (dual). The local inner loop need not be bisected, and can either
move away from the outer loop (repel) or move towards it (attract) when an even split is not desired:




In Dual mode, the sequence will alternate between two half-walks such that every-other output would go
to the same slice. This effect will produce a more balanced workload to two slices as shown in the
example below where the color of the block represents which slice it was dispatched to. This is the
walker’s approach to fine-grained parallelism.




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                 5/31/2012                                                27
1.4.3.4      MbAff-Like Special Case in Local Loop
The local loop has an additional middle loop that is used to achieve some specific walking patterns, with
MBAFF mode especially in mind. A pattern to handle MBAFF AVC content is to walk the top macroblocks
of all macroblock pairs (MB-pairs) on a wavefront followed by the respective bottom macroblocks. The
pattern is shown below.




The outer loop unit step vector would be [1, 0] and the inner loop unit step vector would be [-2, 2]. A third
loop is necessary to repeat the inner loop, only shifted down a unit before restarting. Thus, a middle loop
with a unit step vector of [0,1] would achieve this MBAFF pattern. Additionally, the number of “extra steps”
taken by the middle loop would be 1 in this case.
The addition of a middle loop also creates more overall flexibility, which seems necessary due to the
integer-based unit step vector solution proposed (Manhattan distance issues etc.).




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                5/31/2012                                                28
1.4.3.5       Global Loop
The same set of general parameters is used to describe the global loop as well. Thus, a global loop that
is walking a raster-scan pattern can be combined with a local loop that is walking a 26.5º pattern (or vice-
versa). As shown in the example below, if the local block size [8,8] is not an even multiple of the global
resolution [20,20], the slack is still processed by dynamically changing the local block resolution.




The global loop will always resolve to be the upper-left corner of the local loop, shown above black
circles. Note that local loop can still start in any corner of the local block, but the local (0,0) will always be
the location where global loop begins the local loop, hence the upper-left corner.
The user can specify where the staring location of the global loop as with the local loop. If the user were
to set the global starting location to (16,16) in the previous example, after inverting the global outer and
global inner unit step vectors the same pattern would be achieved in the reverse order. Note that the
slack would still be handled along the right and bottom edge of the global image in that case. The user
could have also started at (12,12) in which case the slack would be handled on the left and top faces.

1.4.3.6       Walker Algorithm Description
The walker algorithm has been tested and optimized in software. A high-level pseudo-code description is
given below:
 Walker(){ //C-Style Pseudo-Code of Walker Algorithm



Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                   5/31/2012                                                    29
     Load_Inputs_And_Initialize();
     While (Global_Outer_Loop_In_Bounds()){
       Global_Inner_Loop_Intialization();
       While (Global_Inner_Loop_In_Bounds()){
         Local_Block_Boundary_Adjustment();
         Local_Outer_Loop_Initialization();
         While (Local_Outer_Loop_In_Bounds()){
            Local_Middle_Loop_Initialization();
            While (Local_Middle_Steps_Remaining()){
              Local_Inner_Loop_Initialization();
              While (Local_Inner_Loop_Is_Shrinking()){
                    Execute();
                  Calculate_Next_Local_Inner_X_Y();
              } //End Local Inner Loop
              Calculate_Next_Local_Middle_X_Y();
            } //End Local Middle Loop
            Calculate_Next_Local_Outer_X_Y();
            Calculate_Next_Local_Inverse_Outer_X_Y();
         } //End Local Outer Loop
         Calculate_Next_Global_Inner_X_Y();
       } //End Global Inner Loop
       Calculate_Next_Global_Outer_X_Y();
     } //End Global Outer Loop
 } //End Walker
The pseudo-code has the following characteristics:

    There are 5 levels of iteration
    The highest 2 levels are called “global” and the lowest 3 levels are called “local”
                o     The global loop is split into an outer and an inner loop.
                o     The local loop is split into an outer, a middle, and an inner loop.
                o     A bounding box for the global and local resolution is defined by the user.
                o     The starting location within each bounding box is also specified by the user.

    Each of the 5 loops has its own persistent
                o     Current position (x,y)
                o     Unit step vector (x,y)

    The final output (x,y) is a summation of the global x,y and the local x,y.




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                   5/31/2012                                         30
     The next (x,y) for given level can be calculated while the next lower level is still executing.
      Additionally, the result can be used to check to see if the current level will execute again once
      control is returned.

The flow of the global outer and inner loops is:
         1.   Check a bound condition
         2.   Initialize the next level loop
         3.   Execute the next level loop
         4.   When the next level loop fails its condition, calculate the next position for the current loop
              level and repeat.

Walker algorithm flowchart for the Global Loop




Take note of the grey box “Local Block Boundary Adjustment”. This logic is necessary to adjust the local
block size when the distance between the current global position to the edge of the image is less than the
local resolution. Additionally, the local starting positions might be modified here as well if the defined
starting position is larger than the new local block size.
The flow of the 3 local loops does not vary much from the 2 global loops. The differences are:

      In addition to a boundary check, the local middle loop also ensures the number of middle steps is
       less than or equal to the user defined “number of extra steps”.
      The local inner loop only checks to see if the prior distance between the x,y starting and ending
       points are greater than their current distance. If this is true, it implies that the two inner loops are
       converging towards each other.
      When the middle loop check fails, both the starting points (local outer) and ending points (local
       inner) are updated.




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                   5/31/2012                                                     31
Walker algorithm flowchart for the Local Loop




1.5     Thread Spawner Unit
The Thread Spawner (TS) unit is responsible for making thread requests (root and child) to the Thread
Dispatcher, managing scratch memory, maintaining outstanding root thread counts, and monitoring the
termination of threads.




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12              5/31/2012                                                32
Thread Spawner block diagram




1.5.1       Basic Functions

1.5.1.1         Root Threads Lifecycle
Thread requests sourced from VFE are called root threads, since these threads may be creating
subsequent (child) threads. A root thread may a macroblock thread created by VFE as in VLD mode, or
may be a general-purpose thread assembled by VFE according to full description provided by host
software in Generic mode.
Thread requests are stored in the Root Thread Queue. TS keeps everything needed to get the root
threads ready for dispatch and then tracks dispatched threads until their retirement.
TS arbitrates between root thread and child thread. The root thread request queue is in the arbitration
only if the number of outstanding threads does not exceed the maximum root thread state variable.
Otherwise, the root thread request queue is stalled until some other root threads retire/terminate.
Once a root thread is selected to be dispatched, its lifecycle can be described by the following steps:
       1.   TS forwards the interface descriptor pointer to the L1 interface descriptor cache (a small fully
            associated cache containing up to 4 interface descriptors). The interface descriptor is either
            found in the cache or a corresponding request is forwarded to the L2 cache. Interface
            descriptors return back to TS in requesting order.

                Once TS receives the interface descriptor, it checks whether maximum concurrent root
                 thread number has reached to determine whether to make a thread dispatch request or to



Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                 5/31/2012                                                33
                 stall the request until some other root threads retire. If the thread requests the use of
                 scratch memory, it also generates a pointer into the scratch space.
       2.   TS then builds the transparent header and the R0 header.
       3.   Finally, TS makes a thread request to the Thread Dispatcher.
       4.   TS keeps track of dispatched thread, and monitors messages from the thread (resource
            dereference and/or thread termination). When it receives a root thread termination message, it
            can recover the scratch space and thread slot allocated to it. The URB handle may also be
            dereferenced for a terminated root thread for future reuse. It should be noted that URB handle
            dereference may occur before a root thread terminates. See detailed description in the Media
            Message section.

                It is the root thread’s responsibility (software) to guarantee that all its children have retired
                 before the root thread can retire.

1.5.1.2         URB Handles
VFE is in charge of allocating URB handles for root threads. One URB handle is assigned to each root
thread. The handle is used for the payload into the root thread.
If Children Present is not set (root-without-child case), TS signals VFE to dereference the URB handle
immediately after it receives acknowledgement from TD that the thread is dispatched.
If Children Present is set (root-with-child case), the URB handle is forwarded to the root thread and
serves as the return URB handle for the root thread. TS does not signal deference at the time of dispatch.
TS signals URB handle deference only when it receives a resource dereference message from the
thread.
Children Present is a command variable in the _OBJECT command.

1.5.1.3         Root to Child Responsibilities
Any thread created by another thread running in an EU is called a child thread. Child threads can create
additional threads, all under the tree of a root which was requested via the VFE path.
A root thread is responsible of managing pre-allocated resources such as URB space and scratch space
for its direct and indirect child threads. For example, a root thread may split its URB space into sections. It
can use one section for delivering payload to one child thread as well as forwarding the section to the
child thread to be used as return URB space. The child thread may further subdivide the URB section into
subsections and use these subsections for its own child threads. Such process may be iterated. Similarly,
a root thread may split its scratch memory space into sections and give one scratch section for one child
thread.
TS unit only enforces limitation on number of outstanding root threads. It is the root threads’ responsibility
to limit the number of child threads in their respected trees to balance performance and avoid deadlock.

1.5.1.4         Multiple Simultaneous Roots
Multiple root threads are allowed concurrently running in execution units. As there is only one scratch
space state variable shared for all root threads, all concurrent root thread requiring scratch space share
the same scratch memory size. Multiple Simultaneous Roots depicts two examples of thread-thread
relationship. The left graph shows one single tree structure. This tree starts with a single root thread that
generates many child threads. Some child threads may create subsequent child threads. The right graph
shows a case with multiple disconnected trees. It has multiple root threads, showing sibling roots of
disconnected trees. Some roots may have child threads (branches and leafs) and some may not.



Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                   5/31/2012                                                   34
There is another case (as shown in Multiple Simultaneous Roots) where multiple trees may be
connected. If a root is a synchronized root thread, it may be dependent on a preceding sibling root thread
or on a child thread.

Examples of thread relationship




A example of thread relationship with root sibling dependency




1.5.1.5      Synchronized Root Threads
A synchronized root thread (SRT) originates from a MEDIA_OBJECT command with Thread
Synchronization field set. Synchronized root threads share the same root thread request queue with the
non-synchronized roots. A SRT is not automatically dispatched. Instead, it stays in the root thread request
queue until a spawn-root message is at the head of the child thread request queue. Conversely, a spawn-
root message in the child thread request queue will block the child thread request queue until the head of
root thread request queue is a SRT. When they are both at the head of queues, they are taken out from
the queue at the same time.
A spawn-root message may be issued by a root thread or a child thread. There is no restriction. However,
the number of spawn-root messages and the number of SRT must be identical between state changes.
Otherwise, there can be a deadlock. Furthermore, as both requests are blocking, synchronized root
threads must be used carefully to avoid deadlock.
When Scoreboard Control is enabled, the dispatch of a SRT originated from a MEDIA_OBJECT_EX
command is still managed by the same way in addition to the hardware scoreboard control.

1.5.1.6      Deadlock Prevention
Root threads must control deadlock within their own child set. Each root is given a set of preallocated
URB space; to prevent deadlock it must make sure that all the URB space is not allocated to intermediate
children who must create more children before they can exit.



Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                5/31/2012                                              35
There are limits to the number of concurrent threads. The upper bound is determined by the number of
execution units and the number of threads per EU. The actual upper bound on number of concurrent
threads may be smaller if the GRF requirement is large. Deadlock may occur if a root or intermediate
parent cannot exit until it has started its children but there is no space (for example, available thread slot
in execution units) for its children to start.
To prevent deadlock, the maximum number of root threads is provided in VFE state. The Thread
Spawner keeps track of how many roots have been spawned and prevents new roots if the maximum has
been reached. When child threads are present, it is software’s responsibility to constrain child thread
generation, particularly the generation of child threads that may also spawn more child threads.
Child thread dispatch queue in TS is another resource that needs to be considered in preventing
deadlock. The child thread dispatch queue in TS is used for (1) message to spawn a child thread, (2)
message to spawn a synchronized root thread, and (3) thread termination message. If this queue is full, it
will prevent any thread to terminate, causing deadlock.
For example, if an application only has one root thread (max # of root threads is programmed to be one).
This root thread spawns child threads. In order to avoid deadlock, the maximum number of outstanding
child thread that this root thread can spawn is the sum of the maximum available thread slots plus the
depth of the child thread dispatch queue minus one.
        Max_Outstanding_Child_Threads = (Thread Slot Number – 1) + (TS Child Queue Depth – 1)
Adding other root threads (synchronized and/or non-synchronized) to the above example, the situation is
more complicated. A conservative measure may have to use to prevent deadlock. For example, the root
thread spawning child threads may have to exclude the max number of root threads as in the following
equation to compute the maximum number of outstanding child threads to be dispatched.
        Max_Outstanding_Child_Threads = (Thread Slot Number – 1) + (TS Child Queue Depth – 1) –
        (Max Root Threads-1)

1.5.1.7      Child Thread Lifecycle
When a (parent) thread creates a child thread, the parent thread behaves like a fixed function. It provides
all necessary information to start the child thread, by assembling the payload in URB (including R0
header) and then sending a spawn thread message to TS with following data:

    An interface descriptor pointer for the child thread.
    A pointer for URB data

The interface descriptor for a child may be different from the parent – how the parent determines the child
interface descriptor is up to the parent, but it must be one from the interface descriptor array on the same
interface descriptor base address.
The URB pointer is not the same as a URB handle. It does not have an URB handle number and does
not appear in any handle table. This is acceptable because the URB space is never reclaimed by TS after
a child is dispatched, but rather when the parent releases its original handles and/or retires.
The child request is stored in the child thread queue. The depth of the queue is limited to 8, overrun is
prevented by the message bus arbiter which controls the message bus. The arbiter knows the depth of
the queue and will only allow 8 requests to be outstanding until the TS signals an entry has been
removed.
As mentioned previously, child threads have higher priority over root threads. Once TS selects a child
thread to dispatch, it follows these steps:




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                  5/31/2012                                                 36
       1.    TS forwards the interface descriptor pointer to the L1 interface descriptor cache (a small fully
             associated cache containing up to 4 interface descriptors). The interface descriptor is either
             found in the cache or a corresponding request is forwarded to the L2 cache. Interface
             descriptors return back to TS in requesting order.
       2.    TS then builds the transparent header but not the R0 header.
       3.    Finally, TS makes a thread request to the Thread Dispatcher.
       4.    Once the dispatch is done, TS can forget the child – unlike roots, no bookkeeping is done that
             has to be updated when the child retires.
If more data needs to be transferred between a parent thread and its child thread than that can fit in a
single URB payload, extra data must be communicated via shared memory through data port.

1.5.1.8       Arbitration between Root and Child Threads
When both root thread queue and child thread queue are both non-empty, TS serves the child thread
queue. In other words, child threads have higher priority over root threads. The only condition that the
child thread queue is stalled by the root thread queue is that the head of child thread queue is a root-
synchronization message and the head of root thread queue is not a synchronized root thread.

1.5.1.9       Persistent Root Thread
A persistent root thread in general stays in the system for a long period of time. It is normally a parent
thread, and only one PRT is allowed in the system at a time. The PRT can be restarted later, even if it
had completed normally the last time it was executed. Therefore, the PRT must always save enough
context (via data port messages to a predefined surface) to allow it to restart from where it left off
(including determining that it has nothing left to do). However, since only one PRT can execute at a time,
once the next PRT starts, the previous one will never be restarted, thus the context save surface can be
reused from one PRT to the next.
A PRT may check the Thread Restart Enable bit in the R0 header to find out whether it is a fresh start or
resumed from a previous interrupt and then can continue operations from that previously saved context.
PRT can be interleaved with other root (such as parent root thread, or synchronized root thread) and child
threads. A parent root thread is not necessarily a PRT, and doesn’t have to be as long as it can be
finished in deterministic time that is shorter than required for fine-grain context switch interrupt.
Use of PRT must follow the following rules:

    There can only be one PRT in the media pipeline at a given time. That means, there shall not be any
     other media primitive commands (MEDIA_OBJECT or MEDIA_OBJECT_EX) between it and the
     previous MI_FLUSH command. In other words, when multiple such PRTs are used in a sequence of
     media primitive commands, MI_FLUSH must be inserted.

1.5.1.10      GPGPU Functions
In GPGPU mode, the Thread Spawner allocate and track the barriers and shared local memory per
thread group.

1.5.1.10.1        Thread Group Tracking
The TSG needs to keep track of the threads outstanding in a group to know when the thread group
barrier and Shared Local Memory can be reclaimed. This can be done by keeping a counter per active
thread group (up to 16 per half-slice) which increments when a new thread is sent out and decremented




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                  5/31/2012                                                37
when the thread retires. The assigned barrier ID (with half-slice bit) is unique per thread group and much
smaller than the thread group id and so will be used to keep track of the thread group instead.
Since TSL sends the thread retirement via the Message Channel rather thant the thread retirement bus,
the barrier ID used to identify the thread group can be sent at the same time. A CAM will then match the
ID with the counter to decrement.
There is a potential corner case of a thread group without barriers being partly dispatched, then retiring
before the rest of the thread group is sent. This should be OK, since the lack of barriers means that there
is no dependencies between threads.

1.5.1.10.2      Shared Local Memory Allocation
The Shared Local Memory is a 64k block per half-slice in the L3 that must be shared between all thread
groups on that half-slice. A new memory manager simular to the Scratch Space memory manager is used
to allocate this space.
We are only dispatching threads from a single Interface Descriptor at a time. If a new Interface Descriptor
is requested the pipe is drained and all shared memory recovered before starting to allocate new shared
memory. This means that only a single size of shared memory needs to be supported at once.
For simplicity, only power-of-2 sizes from 4k to 64k are allowed. The thread request will specify how much
is needed. The first thread of a Thread Group is marked as requiring a new shared local memory – if not
the old Shared Local Memory offset is sent with the dispatch.
A simple set of 16-bits is used to allocate 4k shared memory, with fewer bits used for larger sizes. A
priority encoder finds the first unused bit and the offset remembered as being associated with a particular
barrier id. The barrier id is then used to track the thread group.
When the Thread Group Tracking indicates that a thread group is completely retired, that section of
shared local memory can be reclaimed.

1.5.1.10.3      Software Managed Shared Local Memory
Software can optionally manage shared local memory. In this case, each thread command or thread
group command will have the shared memory offset included – each command in a thread group must
have the same offset, of couse. If the offset requested is still being used then the command is stalled until
the thread group using that offset is done.
Hardware will track the usage of this section of shared memory as before, recording the offset as being
used and recording it as being available after the thread group is done.

1.5.1.10.4      Automatic Barrier Management
Since we have an automatic shared memory allocation it makes sense to make barrier management
automatic too.
Instead of the barrier id in the Interface Descriptor, there is now a thread count per thread group. If a new
thread group id comes in without a barrier allocated (checked with a CAM match across> 16 barriers), the
TSG picks an unused barrier and sends this count in a message to GWunit. It then needs to wait for an
accept message back from GW before sending the dispatch to ensure that a barrier message doesn’t
arrive at the GW before the barrier is programmed. The barrier id picked is sent with every dispatch from
this thread group.
When the thread group tracker determines that a thread group has finished, the barrier becomes
available to new thread groups.




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                 5/31/2012                                                38
1.5.1.10.5       Local Memory / Scratch Space
The Local Memory (not to be confused with Shared Local Memory, which is shared by all thread in a
thread group) is allocated per thread dispatched to the EU.
The existing Scratch Space manager is used to provide between 1k and 12k bytes memory per thread. A
small change to the kernel can be used to provide more scratch space – the pointer that TSG provides is
simply:
Scratch Space Pointer = Scratch Space Base Pointer + FFTID * Per Thread Scratch Space
To increase the amount of scratch space per thread, each kernel needs to do this operation on its
Scratch Space Pointer:
New Scratch Space Pointer = Old Scratch Space Pointer + FFTID * (New Per Thread Scratch Space
– Old Per Thread Scratch Space)
The old Scratch Space Pointer and FFTID are available in the R0 header. The driver needs to allocate
enough memory for the total number of threads in the system * the new per thread scratch space.

1.5.1.10.6       Dispatch Payload
The payload for a general purpose thread will have to include the execution mask with a bit per 32-
channel. SIMD16 and SIMD8 use the LSB bits of the execution mask. The 5-bit number transferred from
VFE will be expanded to produce the 32-bit mask. This will use the Dmask currently used by the pixel
shader dispatch in the transparent header.


1.5.2        Interfaces

1.5.2.1       Interface to VFE
TS receives an interface descriptor pointer and a URB handle from VFE. It uses the interface descriptor
pointer to fetch the interface descriptor. TS uses the information in the interface descriptor along with the
URB handle to fill out the transparent header in the message to TD for all threads. For root thread, TS
also generate the R0 header.
TS transmits URB handle dereference signal to VFE. As described previously, the derefernce signal may
be at dispatch time or at later time depending on Children Present. No matter which case, there is one
and only one URB handle dereference for a thread.

1.5.2.2       Interface to Thread Dispatcher
TS creates the transparent header, assembles the URB handles and calls TD to dispatch a new thread.
For an unsynchronized root thread, there is one URB handle managed by VFE and optionally one
Constant URB handle managed by CS. For a synchronized root thread, there is one URB handle
managed by VFE, a URB handle created by the synchronizing thread (the one that sends the ‘spawn root
thread’ message, and optionally one Constant URB handle managed by CS. For a child thread, there is
one URB handle managed by the parent thread plus an optional Constant URB handle.


1.6       Media State Model
The media state model is based on in-line state load mechanism. VFE state, URB configuration and
Interface Descriptors are loaded to VFE hardware through state commands.




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                 5/31/2012                                                 39
All Interface Descriptors have the same size and are organized as a contiguous array in memory. They
can be selected by Interface Descriptor Index for a given kernel. This allows different kinds of kernels to
coexist in the system.

        Pipeline         Opcode        Sub                      Command
                                      Opcode

        (Media)
          Bits              Bits        Bits
         [28:27]          [26:24]     [23:16]

          2h               0h          00h      MEDIA_VFE_STATE
          2h               0h          01h      MEDIA_CURBE_LOAD
          2h               0h          02h      MEDIA_INTERFACE_DESCRIPTOR_LOAD



1.7      Media Messages
All message formats are given in terms of dwords (32 bits) using the following conventions.
Dispatch Messages: Rp.d
SEND Instruction Messages: Mp.d


1.7.1     Thread Payload Messages
The root thread’s register contents differ from that of child threads, as shown in Thread Payload
Messages. The register contents for a synchronized root thread (also referred to as ‘spawned root
thread’) and an unsynchronized one are also different. Whether the URB Constant data field is present or
not is determined by the interface descriptor of a given thread. This applies to both root and child threads.
When URB Constant data field is present for a synchronized root thread, URB constant data field is
before the data field received from the spawning thread, which is also before the URB payload data.

Thread payload message formats for root and child threads




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                 5/31/2012                                                   40
1.7.1.1     Generic Mode Root Thread
The following table shows the R0 register contents for a Generic mode root thread, which is generated by
TS. The remaining payloads are application dependent.

R0 Header of a Generic Mode Root Thread
DWord                   Bit                                             Description
 R0.7                  31:0
                       31:0
 R0.6                                        Reserved

                       31:10
 R0.5                                        Scratch Space Pointer. Specifies the 1k-byte aligned pointer to
                                             the scratch space. This field is only valid when Scratch Space is
                                             enabled.
                                             Format = GeneralStateOffset[31:10]

                        9:8
                                              Reserved: MBZ.
                        9:0
                                             FFTID. This ID is assigned by TS and is a unique identifier for the
                                             thread in comparison to other concurrent root threads. It is used to
                                             free up resources used by the thread upon thread completion.
                                             Format = U8. Bits 9:8 are Reserved, MBZ.
                       31:5
 R0.4                                        Binding Table Pointer: Specifies the 32-byte aligned pointer to
                                             the Binding Table. It is specified as an offset from the Surface
                                             State Base Address.
                                             Format = SurfaceStateOffset[31:5]
                        4:0                 Reserved : MBZ
                       31:5
 R0.3                                        Sampler State Pointer. Specifies the 32-byte aligned pointer to
                                             the sampler state table.
                                             Format = GeneralStateOffset[31:5]

                         4                  Reserved : MBZ
                        3:0
                                             Per Thread Scratch Space. Specifies the amount of scratch
                                             space, in 16-byte quantities, allowed to be used by this thread.
                                             The value specifies the power that two will be raised to, to
                                             determine the amount of scratch space.
                                             Format = U4
                                             Range = [0,11] indicating [1k bytes, 2M bytes] in powers of two
 R0.2                  31:28                Reserved : MBZ
                       27:24
                                             BarrierID. This field indicates which one from the 16 Barriers this
                                             kernel is associated.
                                             Format: U4
                       23:16
                                             Barrier.Offset. This is the offset for the Barrier to indicate the
                                             offset from the requester's RegBase (which may be 0 if Bypass
                                             Gateway Control is set to 1) for the broadcast barrier message.
                                             Barrier.Offset + RegBase must be in the valid GRF range.
                                             Otherwise, hardware behavior is undefined.
                                             It is in unit of 256-bit GRF register.



Doc Ref #: IHD-OS-V2 Pt 2 – 05 12              5/31/2012                                                          41
DWord                       Bit                                                     Description
                                                        The most significant bit of this field must be zero.
                                                        Format = U8
                                                        Range = [0,127]
                            15:9                        Reserved : MBZ
 8:4
        Interface Descriptor Offset. This field
        specifies the offset from the interface
        descriptor base pointer to the interface
        descriptor which will be applied to this
        object. It is specified in units of interface
        descriptors.
        Format = U5

                            3:0
                                                        Scoreboard Color (only with MEDIA_OBJECT_EX): This field
                                                        specifies which dependency color the current thread belongs to. It
                                                        affects the dependency scoreboard control.
                                                        Format = U4
 R0.2                      31:10                        Reserved: MBZ
                            9:4
                                                        Interface Descriptor Offset. This field specifies the offset from
                                                        the interface descriptor base pointer to the interface descriptor
                                                        which will be applied to this object. It is specified in units of
                                                        interface descriptors.
                                                        Format = U5
                            3:0
                                                        Scoreboard Color (only with MEDIA_OBJECT_EX): This field
                                                        specifies which dependency color the current thread belongs to. It
                                                        affects the dependency scoreboard control.
                                                        Format = U4

 R0.1                      31:28
                                                        Scoreboard Mask 4-7 (only with MEDIA_OBJECT_EX): Each bit
                                                        indicates the corresponding dependency scoreboard is dependent
                                                        on. This field is AND’d with the corresponding Scoreboard Mask
                                                        field in the VFE_STATE_EX.
                                                        Bit n (for n = 4…7): Scoreboard n is dependent, where bit 28
                                                        maps to n = 4.
                                                        Format = TRUE/FALSE
                                                        Reserved : MBZ
                           27:26
                                                         Reserved : MBZ
                             25
                                                        Reserved. MBZ

                           24:16
                                                        Scoreboard Y
                                                        This field provides the Y term of the scoreboard value of the
                                                        current thread.
                                                        Format = U9
                                                        only with MEDIA_OBJECT_EX.




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                          5/31/2012                                                        42
DWord                    Bit                                                  Description
                                                   Reserved : MBZ
                       15:12
                                                   Reserved : MBZ

                        11:9
                                                   Reserved. MBZ

                         8:0
                                                   Scoreboard X
                                                   This field provides the X term of the scoreboard value of the
                                                   current thread.
                                                   Format = U9
                                                   only with MEDIA_OBJECT_EX.
                                                   Reserved : MBZ
 R0.0                  31:24
                                                   Scoreboard Mask: Each bit indicates the corresponding
                                                   dependency scoreboard is dependent on. This field is AND’d with
                                                   the corresponding Scoreboard Mask field in the
                                                   MEDIA_VFE_STATE.
                                                   Bit n (for n = 0…7): Scoreboard n is dependent, where bit 24
                                                   maps to n = 0.
                                                   Format = TRUE/FALSE
                       23:16                   Reserved : MBZ
                        15:0
                                                   URB Handle. This is the URB handle where indicating the URB
                                                   space for use by the root thread and its children.


1.7.1.2      Root Thread from MEDIA_OBJECT_PRT
The root thread payload message for an MEDIA_OBJECT_PRT command has a fixed format
independent of the VFE mode (e.g. Generic mode or AVC-IT mode). One example GRF register location
is given for the condition that CURBE is disabled.

Root thread payload layout for a MEDIA_OBJECT_PRT command
GRF Register Example                     Description
    R0         R0
                       R0 header

 R1 – R(m)     n/a
                       Constants from CURBE when CURBE is enabled
                       m is a non-negative value

   R(m+1)      R1
                       In-line Data block.

The R0 header field is as the following, which is the same as in other modes except the Thread Restart
Enable bit (bit 0 of R0.2).

R0 header of the thread payload of a MEDIA_OBJECT_PRT command
DWord Bit                                                  Description
 R0.7 31
     27:24
      23:0



Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                    5/31/2012                                                     43
DWord Bit                                                  Description
 R0.6 31:24
       23:0
 R0.5 31:10
              Scratch Space Pointer. Specifies the 1k-byte aligned pointer to the scratch space. This field is only
              valid when Scratch Space is enabled.
              Format = GeneralStateOffset[31:10]
        9:8 Reserved : MBZ
        7:0
             FFTID. This ID is assigned by TS and is a unique identifier for the thread in comparison to other
             concurrent root threads. It is used to free up resources used by the thread upon thread completion.

 R0.4 31:5
              Binding Table Pointer: Specifies the 32-byte aligned pointer to the Binding Table. It is specified as an
              offset from the Surface State Base Address.
              Format = SurfaceStateOffset[31:5]
       4:0 Reserved : MBZ
 R0.3 31:5
            Sampler State Pointer. Specifies the 32-byte aligned pointer to the sampler state table.
              Format = GeneralStateOffset[31:5]
         4 Reserved : MBZ
        3:0
            Per Thread Scratch Space. Specifies the amount of scratch space, in 16-byte quantities, allowed to
            be used by this thread. The value specifies the power that two will be raised to, to determine the
            amount of scratch space.
              Format = U4
              Range = [0,11] indicating [1k bytes, 2M bytes] in powers of two
 R0.2 31:4
              Interface Descriptor Pointer. Specifies the 16-byte aligned pointer to this thread’s interface
              descriptor. Can be used as a base from which to offset child thread’s interface descriptor pointers from.
              Format = GeneralStateOffset[31:4]

        3:1 Reserved : MBZ
         0
             Thread Restart Enable. If set, indicates that the persistent root thread (PRT) is being restarted, and
             context should be restored from the context save area before executing.
              Format = Enable
 R0.1 31:0 Reserved : MBZ
 R0.0 31:16 Reserved : MBZ
       15:0
             URB Handle. This is the URB handle where indicating the URB space for use by the root thread and
             its children.

The inline data block field is the same as in the MEDIA_OBJECT_EX command with zero-filled partial
GRF.

1.7.1.3       Root Thread from MEDIA_OBJECT_WALKER
The root thread payload message for an MEDIA_OBJECT_WALKER command, which must be in
Generic mode, has the same format as that of the generic mode root thread format.




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                     5/31/2012                                                       44
Root thread payload layout for a MEDIA_OBJECT_WALKER command
GRF Register Example                        Description
    R0         R0
                        R0 header

 R1 – R(m)       n/a
                        Constants from CURBE when CURBE is enabled
                        m is a non-negative value
   R(m+1)        R1
                        In-line Data block.

The R0 header field is identical to that of Generic Mode Root Thread.
The inline data block field is the same as in the MEDIA_OBJECT command with zero-filled partial GRF.
There is no indirect data block field.

1.7.1.4        Child Thread
The tread initiation for the child thread is determined by the data stored in the URB by the parent that
spawns it. No hardware-defined header is generated. However, software should follow the header field
definition similar to that for a root thread, when the same fields are used, to be consistent and to reduce
message header assemble overhead.
 The Parent Thread Count field should be the Thread Count field of the parent thread itself (e.g. copying
R0.6[23:0] to R0.7[23:0]. The Thread Count field should have a unique value for each child thread and
the unique value should not be dependent on the execution order. This is mostly important for the cases
when the child thread generation order may vary depending on the thread completion order. For example,
when generating child threads for macroblock-based processing, the Thread Count field for a child thread
should be deterministic for a macroblock position.
The following table shows the R0 register contents for a child thread, which is generated by its parent
thread. The remaining payloads are application dependent.
 DWord     Bit     Description
           31
   R0.7
         27:24
          23:0
         31:24
   R0.6
          23:0
R0.5-R0.0 31:0
                 Software defined



1.7.1.5        GPGPU Thread
The RO header of the Thread Dispatch Payload for the GPGPU thread:
DWord Bit                                                  Description
 R0.7 31:0
               Thread Group ID Z: This field identifies the Z component of the thread group. That this thread
               belongs to.
 R0.6   31:0
               Thread Group ID Y: This field identifies the Y component of the thread group that this thread belongs
               to.
 R0.5 31:10
               Scratch Space Pointer. Specifies the 1k-byte aligned pointer to the scratch space (used for the




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                    5/31/2012                                                    45
DWord Bit                                                      Description
                GPGPU local memory space).
                Format = GeneralStateOffset[31:10]
         9:8
                Reserved: MBZ.

         9:0
                FFTID. This ID is assigned by TS and is a unique identifier for the thread in comparison to other
                concurrent threads (of any thread group). It is used to free up resources used by the thread upon
                thread completion.
                Format = U8. Bits 9:8 are Reserved, MBZ.
 R0.4   31:5
                Binding Table Pointer. Specifies the 32-byte aligned pointer to the Binding Table. It is specified as
                an offset from the Surface State Base Address.
                Format = SurfaceStateOffset[31:5]
          4 Reserved
         3:0
             Range = [0,11] indicating [1K Bytes, 2M Bytes]
 R0.3   31:5
                Sampler State Pointer. Specifies the 32-byte aligned pointer to the sampler state table.
                Format = GeneralStateOffset[31:5]

          4 Reserved : MBZ
         3:0
             Per Thread Scratch Space. Specifies the amount of scratch space, in 16-byte quantities, allowed to
             be used by this thread. The value specifies the power that two will be raised to, to determine the
             amount of scratch space.
                Format = U4
                Range = [0,11] indicating [1k bytes, 12k bytes]
 R0.2    31
                Reserved: MBZ

         30
                Reserved: MBZ

         29
                Barrier Enable: This field indicates that a barrier has been allocated for this kernel
                Reserved: MBZ
         28
                SLM Enable: This field indicates that Shared Local Memory has been allocated for this kernel
                Reserved: MBZ
        27:24
                BarrierID: This field indicates the barrier that this kernel is associated with.
                Format: U4
        23:15
        23:16
                This key is a free running count of the number of dispatches.

                Reserved: MBZ
        14:10
         9:4
                Interface Descriptor Offset. This field specifies the offset from the interface descriptor base pointer
                to the interface descriptor which will be applied to this object. It is specified in units of interface
                descriptors.




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                       5/31/2012                                                       46
DWord Bit                                                   Description
                Format = U5
         3:0
                Reserved. MBZ

 R0.1   31:0
                Thread Group ID X: This field identifies the X component of the thread group that this thread belongs
                to.
        30:28 Reserved: MBZ
        27:24
               Shared Local Memory Index: Indicates the starting index for the shared local memory for the thread
               group. Each index points to the start of a 4k memory block, 16 possibilities cover the entire 64k
               shared memory per half-slice.
                Format = U4
        23:16
                Reserved: MBZ

        15:0
                URB Handle. This is the URB handle where indicating the URB space for use by the thread.

Cross-thread CURBE if present is in R1 and above, followed by the X/Y/Z thread id values for each
channel in the thread.


1.7.2      Thread Spawn Message
The thread spawn message is issued to the TS unit by a thread running on an EU. This message
contains only one 8-DW register. The thread spawn message may be used to

    Spawn a child thread
    Spawn a root thread (start dispatching a synchronized root thread)
    Dereference URB handle
    Indicate a thread termination, dereference other TS managed resource and may or may not
     dereference URB handle
    Release a PRT_Fence ()

In order to end a root thread, the end of thread message must be targeted at the thread spawner. In this
case, the root thread sends a message with a “dereference resource” in the Opcode field. The thread
spawner does not snoop the messages sideband to determine when a root thread has ended. Thread
Spawner does not track when a child thread terminates, to be consistent a child thread should also
terminate with a “dereference resource” message to the Thread Spawner. Software must set the
Requester Type (root or child thread) field correctly.
As TS dispatches one synchronized root thread upon receiving a ‘spawn root thread’ message (from a
synchronization thread). The synchronizing thread must send the number of ‘spawn root thread’ message
exactly the same as the subsequent ‘synchronized root thread’. No more, no less. Otherwise, hardware
behavior is undefined.
URB Handle Offset field in this message (in M0.4) has 10 bits, allowing addressing of a large URB space.
However, when a parent thread writes into the URB, it subjects to the maximum URB offset limitation of
the URB write message, which is only 6 bits (see Unified Return Buffer Chapter for details). In this case,
the parent thread may have to modify the URB Return Handle 0 field of the URB write message in order
to subdivide the large URB space that the thread manages.
Only a persistent root thread can use this message to dispatch a root thread if preemption exceptions are
possible. The root thread requested by this message is not guaranteed to dispatch, and the persistent



Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                     5/31/2012                                                    47
root thread must handle the case where it does not dispatch. When a context switch interrupt is
recognized by the persistent root thread, all other root threads that had been dispatched have completed
and no more will be dispatched. Child threads requested by this message are guaranteed to dispatch in
all cases, so long as the persistent root thread does not also dispatch synchronized root threads. A child
thread will not dispatch if it is behind a synchronized root thread that is not dispatched due to preemption
exception.
In a system running child threads, a parent thread is monitoring the status of the child threads by
communications through Message Gateway. When a child thread is about to terminate, it sends a
message to the parent through Message Gateway and then sends a second message of EOT (end of
thread) to TS.
There is a latency between sending a message to parent thread and the EOT to TS due to message bus
arbitration. The parent thread may acknowledge the GW message and issue a new child dispatch before
the EOT was processed; basically threads are issued faster than retired.
Because the messages for new child dispatch and EOT go to the same queue in TS, if the queue gets
full, EOTs will get blocked. In the case when all the EUs/Threads are full, this will create a system
deadlock: no EOTs can be acknowledged by TS (to free up EU resource) and no child threads can be
dispatched (to free up TS queue to receive EOT message).

1.7.2.1         Message Descriptor
The following table shows the lower 16 bits of the message descriptor (lower 20 bits for ) within the SEND
instruction for a thread spawn message.
Bit                                                        Description
19
       Header Present
       This bit must be set to zero for all Thread Spawner messages.
       :this bit is not part of the shared function specific message descriptor.

18:5
       Reserved: MBZ
       Bits 18:16 are not part of the shared function specific message descriptor.
 4
       Resource Select. This field specifies the resource associated with the action taken by the Opcode.
       If Opcode is “Spawn thread”, this field selects whether it is a child thread or a root thread.
       0: spawn a child thread
       1: spawn a root thread or (only) release a PRT_Fence
       If Opcode == “Dereference Resource”, this field indicates whether the URB handle is to be dereferenced. The
       URB handle can only be dereferenced once.
       0: The URB handle is dereferenced
       1: The URB handle is NOT dereferenced
3:2
       Reserved: MBZ

 1
       Requester Type. This field indicates whether the requesting thread is a root thread or a child thread. If it is a
       root thread, when Opcode is 0, FF managed resources will be dereferenced. If it is a child thread and Opcode is
       0, no resource will be dereferenced – basically no action is required by the TS.
       0: Root thread




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                        5/31/2012                                                   48
Bit                                                      Description
      1: Child thread
 0
      Opcode. Indicates the operation performed by the message. A root thread must terminate with a message to
      TS (Opcode == 0 and EOT == 1). A child thread should also terminate with such a message. A thread cannot
      terminate with an Opcode of “spawn thread”.
      0: dereference resource (also used for end of thread)
      1: spawn thread


1.7.2.2         Message Payload
DWord Bit                                                   Description
 M0.7 31:0
 M0.6 31:0
 M0.5 31:8 Ignored
       7:0
            FFTID. This ID is assigned by TS and is a unique identifier for the thread in comparison to other
            concurrent root threads. It is used to free up resources used by a root thread upon thread completion.
                This field is valid only if the Opcode is “dereference resource”, and is ignored by hardware otherwise.

 M0.4 31:16 Ignored
      15:10
             Dispatch URB Length. Indicates the number of 8-DW URB entries contained in the Dispatch URB
             Handle that will be dispatched. When spawning a child thread, the URB handle contains most of the
             child thread's payload including R0 header. When spawning a root thread, the URB handle contains
             the message passed from the requesting thread to the spawned "peer" root thread. The number of
             GRF registers that will be initialized at the start of the spawned child thread is the addition of this field
             and the number of URB constants if present. The number of GRF registers that will be initialized at the
             start of a spawned root thread is the addition of this field, the number of URB constants if present, and
             the URB handle received from VFE.
             This field is ignored if the Opcode is "dereference resource".
             Length of 0 can be used while spawning child threads to indicate that there is no payload beyond the
             required R0 header. Length of 0 while spawning a root thread indicates that there is no payload at all
             from the parent thread. A spawned root has R0 supplied by the Media_Object command indirect/inline
             data.
                Format = U6
                Range = [0,63] for child threads
         9:0
                URB Handle Offset. Specifies the 8-DW URB entry offset into the URB handle that determines where
                the associated dispatch payload will be retrieved from when the spawned child or root thread is
                dispatched.
                This field is ignored if the Opcode is “dereference resource”.
                Format = U10
                Range = [0,1023]

 M0.3 31:0 Ignored
 M0.2 31:28 Ignored
      27:24
             BarrierID. This field indicates which one from the 16 Barriers this kernel is associated.
                Format: U4
        23:16
                Ignored




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                       5/31/2012                                                       49
    DWord Bit                                                  Description
         15:10 Ignored
          9:4
                Interface Descriptor Offset. This field specifies the offset from the interface descriptor base pointer to
                the interface descriptor which will be applied to this object. It is specified in units of interface
                descriptors.
                   Format = U5
             3:0
                   Scoreboard Color (only with MEDIA_OBJECT_EX): This field specifies which dependency color the
                   current thread belongs to. It affects the dependency scoreboard control.
                   Format = U4

     M0.1 31:0 Ignored
     M0.0 31:28 Ignored
          27:24
                 Shared Local Memory Index: Indicates the starting index for the shared local memory for the thread
                 group. Each index points to the start of a 4k memory block, 16 possibilities cover the entire 64k shared
                 memory per half-slice.


                   Format = U4
           23:16 Reserved : MBZ
            15:0
                  Dispatch URB Handle
                   If Opcode (and Requester Type) is “spawn a child thread”: Specifies the URB handle for the child
                   thread.
                   If Opcode (and Requester Type) is “spawn a root thread”: Specifies the URB handle containing
                   message (e.g. requester’s gateway information) from the requesting thread to the spawned root thread.
                   If Opcode is “dereference resource”: This field is required on end of thread messages if the Children
                   Present bit is set, as the handle must be dereferenced, otherwise this field is ignored.



    1.8       Media State and Primitive Commands

    1.8.1      MEDIA_VFE_STATE Command

                                             MEDIA_VFE_STATE

    Length Bias:                                                                                               2
    An MI_FLUSH is required before MEDIA_VFE_STATE unless the only bits that are changed are scoreboard related:
    Scoreboard Enable, Scoreboard Type, Scoreboard Mask, Scoreboard * Delta. For these scoreboard related states, a
    MEDIA_STATE_FLUSH is sufficient.



      MEDIA_STATE_FLUSH (optional, only if barrier dependency is needed)

      MEDIA_INTERFACE_DESCRIPTOR_LOAD (optional)

    DWord Bit                                                 Description
    0    31:29 Command Type



    Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                     5/31/2012                                                     50
                                        MEDIA_VFE_STATE
           Default Value:                                         3h GFXPIPE
           Format:                                                OpCode
     28:27 Pipeline
           Default Value:                                                  2h Media
           Format:                                                         OpCode
     26:24 Media Command Opcode
           Default Value:                                                    0h
           Format:                                                           OpCode
     23:16 SubOpcode
           Default Value:                         0h MEDIA_VFE_STATE
           Format:                                OpCode
     15:0 DWord Length
          Format:                         =n Total Length - 2




             Value                    Name                                              Description
           06h        DWORD_COUNT_n [Default]                                Excludes DWord (0,1)
1    31:10 Scratch Space Base Pointer
           Format:                  GeneralStateOffset[31:10]
           Specifies the 1k-byte aligned address offset to scratch space for use by the kernel. This pointer is
           relative to the General State Base Address.

     9:8   Reserved
           Format:                                                          MBZ
     7:4   Reserved

           Format:                                                          MBZ
     3:0   Per Thread Scratch Space
           Format:                                                                     U4
           Specifies the amount of scratch space allowed to be used by each thread. The driver must allocate
           enough contiguous scratch space, pointed to by the Scratch Space Pointer, to ensure that the
           maximum threads in the device each get Per Thread Scratch Space size without exceeding the driver-
           allocated scratch space..
            Value Name                                        Description                               Project
           [0,11]          Indicating [1k bytes, 12k bytes] : 0->1k, 1->2k, 2->3k … 11->12k
2    31:16 Maximum Number of Threads
           Format:        U16-1 representing thread count




          Specifies the maximum number of simultaneous root threads allowed to be active. Used to avoid
          potential deadlock.
           Note that MSB will be zero due to the range limit below.
          Range: [0, n-1] where n = (# EUs) * (# threads/EU). See Graphics Processing Engine for listing of
          #EUs and #threads in each device.
     15:8 Number of URB Entries




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                    5/31/2012                                                    51
                                        MEDIA_VFE_STATE
           Format:                                                                      U8
           Specifies the number of URB entries that are used by the unit.
                  Value             Name                       Description                           Project
           [0,64]                               [0,64] Entries
     7     Reset Gateway Timer
           This field controls the reset of the timestamp counter maintained in Message Gateway.
             Value                                                  Name
           0h          Maintaining the existing timestamp state
           1h          Resetting relative timer and latching the global timestamp
     6     Bypass Gateway Control
           This field configures Gateway to use a simple message protocol.
            Value                                             Name
           0h       Maintaining OpenGateway/ForwardMsg/CloseGateway protocol (legacy mode)
           1h       Bypassing OpenGateway/CloseGateway protocol
     5     Reserved


     4:3   Gateway MMIO Access Control

           The Gateway allows messages from EUs to read and write MMIO registers. This field limits this feature
           for security reasons
                 Value                                         Name
           0h                No MMIO read/write allowed
           2h                MMIO read/write to any address
3    7:2   Reserved
           Format:                                                           MBZ
     1:0   Reserved

           Format:                                                           MBZ
4    31:16 URB Entry Allocation Size
           Format:                                                              U16


                                                     Description                                               Project
           Specifies the length of each URB entry used by the unit, in 256-bit register increments - 1.
           ROB address for URB starts after CURBE Allocated region.
            (URB Entry Allocation Size * Number of URB Entries) + CURBE Allocation Size + Interface
           Descriptor Entries) must be less than or equal to the number of entries in the URB as
           described in vol5c.5 Shared Functions Unified Return Buffer, under the section “URB Size”.
           Interface Descriptor Entires is 32


                                                     Programming Notes
          When Inline data is used with MEDIA_OBJECT or MEDIA_OBJECT_WALKER, then the URB entry
          allocation size must match the Inline data size.
           If Indirect data is being used with MEDIA_OBJECT then the allocation size does not matter, but the
          total Allocation Size * Number of URB Entries should be sufficient for the Indirect data.
           If both Inline and Indirect are being used, then the allocation size must match the Inline and the total
          space must be enough for both the Indirect and Inline.
     15:0 CURBE Allocation Size




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                    5/31/2012                                                        52
                                        MEDIA_VFE_STATE
           Format:                                                              U16


                                                      Description                                          Project
           Specifies the total length allocated for CURBE, in 256-bit register increments. ROB address for
           CURBE starts at address 32 . (URB Entry Allocation Size * Number of URB Entries) + CURBE
           Allocation Size + Interface Descriptor Entries) must be less than or equal to the number of
           entries in the URB as described in vol5c.5 Shared Functions Unified Return Buffer, under the
           section “URB Size”.
           Interface Descriptor Entires is 32
           There are additional restrictions on CURBE Allocation:




                           Value                              Name                             Project
           [0,480]
           [0,2016]
5    31    Scoreboard Enable
           This field enables and disables the hardware scoreboard in the Media Pipeline. If this field is cleared,
           hardware ignores the following scoreboard state fields.
                     Value                                             Name
           0h                        Scoreboard disabled
           1h                        Scoreboard enabled
     30    Scoreboard Type
           This field selects the type of scoreboard in use.
                 Value                                     Name                                        Project
           0h                Stalling Scoreboard
           1h                Non-Stalling Scoreboard
     29:8 Reserved
          Format:                                                            MBZ
     7:0   Scoreboard Mask
           Format:                                          Enable[8]
           Each bit indicates the corresponding dependency scoreboard is enabled. The scoreboard is based on
           the relative (X, Y) distance from the current threads’ (X, Y) position.
           Bit n (for n = 0…7): Score n is enabled.

6    31:28 Scoreboard 3 Delta Y
           Format:                                                                    S3
           Relative vertical distance of the dependent instance assigned to scoreboard 3, in the form of 2’s
           compliment.

     27:24 Scoreboard 3 Delta X
           Format:                                                                   S3
           Relative horizontal distance of the dependent instance assigned to scoreboard 3, in the form of 2’s
           compliment.

     23:20 Scoreboard 2 Delta Y
           Format:                                                                    S3
           Relative vertical distance of the dependent instance assigned to scoreboard 2, in the form of 2’s




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                    5/31/2012                                                        53
                                       MEDIA_VFE_STATE
           compliment.

     19:16 Scoreboard 2 Delta X
           Format:                                                                   S3
           Relative horizontal distance of the dependent instance assigned to scoreboard 2, in the form of 2’s
           compliment.

     15:12 Scoreboard 1 Delta Y
           Format:                                                                    S3
           Relative vertical distance of the dependent instance assigned to scoreboard 1, in the form of 2’s
           compliment.

     11:8 Scoreboard 1 Delta X
          Format:                                                                   S3
          Relative horizontal distance of the dependent instance assigned to scoreboard 1, in the form of 2’s
          compliment.

     7:4   Scoreboard 0 Delta Y
           Format:                                                                    S3
           Relative vertical distance of the dependent instance assigned to scoreboard 0, in the form of 2’s
           compliment.

     3:0   Scoreboard 0 Delta X
           Format:                                                                   S3
           Relative horizontal distance of the dependent instance assigned to scoreboard 0, in the form of 2’s
           compliment.

7    31:28 Scoreboard 7 Delta Y
           Format:                                                                    S3
           Relative vertical distance of the dependent instance assigned to scoreboard 7, in the form of 2’s
           compliment.

     27:24 Scoreboard 7 Delta X
           Format:                                                                   S3
           Relative horizontal distance of the dependent instance assigned to scoreboard 7, in the form of 2’s
           compliment.

     23:20 Scoreboard 6 Delta Y
           Format:                                                                    S3
           Relative vertical distance of the dependent instance assigned to scoreboard 6, in the form of 2’s
           compliment.

     19:16 Scoreboard 6 Delta X
           Format:                                                                   S3
           Relative horizontal distance of the dependent instance assigned to scoreboard 6, in the form of 2’s
           compliment.

     15:12 Scoreboard 5 Delta Y
           Format:                                                                     S3




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                   5/31/2012                                                    54
                                        MEDIA_VFE_STATE
            Relative vertical distance of the dependent instance assigned to scoreboard 5, in the form of 2’s
            compliment.

      11:8 Scoreboard 5 Delta X
           Format:                                                                   S3
           Relative horizontal distance of the dependent instance assigned to scoreboard 5, in the form of 2’s
           compliment.

      7:4   Scoreboard 4 Delta Y
            Format:                                                                    S3
            Relative vertical distance of the dependent instance assigned to scoreboard 4, in the form of 2’s
            compliment.

      3:0   Scoreboard 4 Delta X
            Format:                                                                   S3
            Relative horizontal distance of the dependent instance assigned to scoreboard 4, in the form of 2’s
            compliment.




1.8.2       MEDIA_CURBE_LOAD

                                      MEDIA_CURBE_LOAD

Length Bias:                                                                                               2
DWord Bit                                                 Description
0     31:29 Command Type
             Default Value:                                       3h GFXPIPE
             Format:                                              OpCode
      28:27  Pipeline
             Default Value:                                                2h Media
             Format:                                                       OpCode
      26:24 Media Command Opcode
            Default Value:                                                   0h
            Format:                                                          OpCode
      23:16 SubOpcode
            Default Value:                       1h Media_CURBE_LOAD
            Format:                              OpCode
      15:0 DWord Length
           Project:                       All
           Format:                        =n Total Length - 2




              Value                    Name                                             Description
            2h         DWORD_COUNT_n [Default]                               Excludes DWord (0,1)




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                    5/31/2012                                                    55
                                   MEDIA_CURBE_LOAD
1    31:0 Reserved
           Project:                                                      All
           Format:                                                       MBZ
2    31:17 Reserved
           Project:                                                      All
           Format:                                                       MBZ
     16:0 CURBE Total Data Length
           Project:                             All
           Format:                              U17 In Bytes




                                                      Description                                        Project
          This field provides the length in bytes of the CURBE data.
          This field must have the same alignment as the Curbe Object Data Start Address.As the
          CURBE data are sent directly to ROB, range is limited to CURBE Allocation Size.
          This field must be DWord (32-byte) aligned.
3    31:0 CURBE Data Start Address
          Project:        All
          Format:         DynamicStateOffset[31:0] CURBE


                                                  Description                                            Project
          Specifies the 32-byte (DWord) aligned address of the CURBE data. This pointer is relative to
          the Dynamics Base Address.


                                           Value                                              Name
          [0,FFFFFFFFh]


                                                Programming Notes                                     Project
          Driver must invalidate the vertex fetch cache thru the VF(address based) Cache Invalidation P
          Enable thru a PIPE_CONTROL command prior to reusing the same graphics memory space.




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                  5/31/2012                                                   56
1.8.3      MEDIA_INTERFACE_DESCRIPTOR_LOAD Command

                         MEDIA_INTERFACE_DESCRIPTOR_LOAD

Length Bias:                                                                                                 2
A Media_State_Flush should be used before this command to ensure that the temporary Interface Descriptor storage
is cleared.
DWord Bit                                             Description
0       31:29 Command Type
              Default Value:                                  3h GFXPIPE
              Format:                                         OpCode
        28:27 Pipeline
              Default Value:                                            2h Media
              Format:                                                   OpCode
       26:24 Media Command Opcode
             Default Value:                                                     0h
             Format:                                                            OpCode
       23:16 SubOpcode
             Default Value:            2h MEDIA_INTERFACE_DESCRIPTOR_LOAD
             Format:                   OpCode
       15:0 DWord Length
            Project:                         All
            Format:                          =n Total Length - 2




                 Value                    Name                                             Description
               2h         DWORD_COUNT_n [Default]                               Excludes DWord (0,1)
1      31:5 Reserved
            Project:                                                           All
            Format:                                                            MBZ
       4:0  Reserved
            Project:                                                           All
            Format:                                                            MBZ
2      31:17 Reserved
             Project:                                                          All
             Format:                                                           MBZ
       16:0 Interface Descriptor Total Length
             Project:                                  All
             Format:                                   U17 In bytes


               This field provides the length in bytes of the Interface Descriptor data. This field must have the same
               alignment as the Interface Descriptor Data Start Address.It must be DQWord (32-byte) aligned. As the
               Interface Descriptor data are sent directly to ROB, range is limited to CURBE Allocation Size.
                       Value                                         Name                                      Project
               [32,1024]            [1,32] interface descriptor entries
3      31:0 Interface Descriptor Data Start Address




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                       5/31/2012                                                        57
                         MEDIA_INTERFACE_DESCRIPTOR_LOAD
              Project:    All
              Format:     DynamicStateOffset[31:0]INTERFACE_DESCRIPTOR_DATA*32


                                                        Description                                               Project
              This bit specifies the 32-byte aligned address of the Interface Descriptor data. This pointer is
              relative to the Dynamics Base Address.


                                                  Value                                                 Name
              [0,FFFFFFFFh]


                                                    Programming Notes                                     Project
              Driver must invalidate the vertex fetch cache thru the VF(address based) Cache Invalidation
              Enable thru a
              PIPE_CONTROL command prior to reusing the same graphics memory space.




1.8.4        INTERFACE_DESCRIPTOR_DATA
Interface Descriptor Data payload as pointed to by the Interface Descriptor Data Start Address:

                               INTERFACE_DESCRIPTOR_DATA

Default       0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
Value:        0x00000000
DWord Bit                                                 Description
0      31:6 Kernel Start Pointer
            Project:            All
            Format:             InstructionBaseOffset[31:6]Kernel
            Specifies the 64-byte aligned address offset of the first instruction in the kernel. This pointer is relative
            to the Instruction Base Address.

       5:0    Reserved
              Project:                                                           All
              Format:                                                            MBZ
1      31:19 Reserved
             Project:                                                      All
             Format:                                                       MBZ
       18 Single Program Flow (SPF)
             Specifies whether the kernel program has a single program flow (SIMDnxm with m = 1) or multiple
             program flows (SIMDnxm with m > 1).
                      Value                                            Name
             0h                    Multiple Program Flow
             1h                    Single Program Flow
       17     Thread Priority
              Specifies the priority of the thread for dispatch.




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                         5/31/2012                                                         58
                            INTERFACE_DESCRIPTOR_DATA
                        Value                                                  Name
           0h                              Normal Priority
           1h                              High Priority
     16    Floating Point Mode
           Specifies the floating point mode used by the dispatched thread.
                    Value                                               Name
           0h                       Use IEEE-754 Rules
           1h                       Use alternate rules
     15:14 Reserved
           Format:                                                             MBZ
     13    Illegal Opcode Exception Enable
           Project:                                                All
           Format:                                                 Enable
           This bit gets loaded into EU CR0.1[12] (note the bit # difference). See Exceptions and ISA Execution
           Environment.

     12    Reserved
           Format:                                                             MBZ
     11    MaskStack Exception Enable
           Project:
           Format:                                              Enable
           This bit gets loaded into EU CR0.1[11]. See Exceptions and ISA Execution Environment.

     10:8 Reserved
          Format:                                                              MBZ
     7     Software Exception Enable
           Format:                                                 Enable
           This bit gets loaded into EU CR0.1[13] (note the bit # difference). See Exceptions and ISA Execution
           Environment.

     6:0   Reserved
           Format:                                                             MBZ
2    31:5 Sampler State Pointer
          Format:           DynamicStateOffset[31:5]SAMPLER_STATE
          Specifies the 32-byte aligned address offset of the sampler state table. This pointer is relative to the
          Dynamic State Base Address.
          This field is ignored for child threads.

     4:2   Sampler Count
           Format:                                                                            U3
           Specifies how many samplers (in multiples of 4) the kernel uses. Used only for prefetching the
           associated sampler state entries.
           This field is ignored for child threads.
           If this field is not zero, sampler state is prefetched for the first instance of a root thread upon the startup
           of the media pipeline.
                  Value                                                  Name
           [0,4]
           0h                 No samplers used




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                      5/31/2012                                                         59
                            INTERFACE_DESCRIPTOR_DATA
           1h              Between 1 and 4 samplers used
           2h              Between 5 and 8 samplers used
           3h              Between 9 and 12 samplers used
           4h              Between 13 and 16 samplers used
     1:0   Reserved
           Format:                                                          MBZ
3    31:16 Reserved
           Project:
           Format:                                                          MBZ
     15:5 Binding Table Pointer
           Project:
           Format:         SurfaceStateOffset[15:5]BINDING_TABLE_STATE*256
           Specifies the 32-byte aligned address of the binding table. This pointer is relative to the Surface State
           Base Address.
           This field is ignored for child threads.

     4:0   Binding Table Entry Count
           Format:                                                                         U5
           Specifies how many binding table entries the kernel uses. Used only for prefetching of the binding table
           entries and associated surface state.
           Note: The maximum number of prefetched binding table entries is limited to 31. For kernels using a
           large number of binding table entries, it may be wise to set this field to zero to avoid prefetching too
           many entries and thrashing the state cache.
           This field is ignored for child threads.
           If this field is not zero, binding table and surface state are prefetched for the first instance of a root
           thread upon the startup of the media pipeline.
                                      Value                                                Name
           [0,31]
4    31:16 Constant URB Entry Read Length
           Format:                                                            U16
           Specifies the amount of URB data read and passed in the thread payload for the Constant or Indirect
           URB entry, in 8-DW register increments.
            A value 0 means that no Constant or Indirect URB Entry will be loaded. The Constant URB Entry Read
           Offset field will then be ignored.
                                    Value                                           Name
           [0,63]
     15:0 Constant URB Entry Read Offset

           Format:                                                             U16
           Specifies the offset (in 8-DW units) at which Constant URB data is to be read from the URB before
           being included in the thread payload.
            Value Name                                        Description                                Project
           [0,2015]       indicating [0,2015] 256-bit register increments. ROB has 64KB of storage; 2048
                          entries. However, lowest 32 entries are reserved for VFE/TS to store interface
                          descriptor data. Hence, URB Entry Read Offset plus Read Length shall not
                          exceed 2016.
           [0, 479]
5    31:24 Reserved
           Project:
           Format:                                                          MBZ



Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                    5/31/2012                                                         60
                             INTERFACE_DESCRIPTOR_DATA
     31:24 Barrier Return GRF Offset
           Project:
           Format:                                                                         U8
           This field specifies the offset into the GRF that the barrier return byte will be written to.
                                    Value                                                  Name
           0,127
     23:22 Rounding Mode
           Project:
           Format:                                                                         U2


                 Value                 Name                                         Description
           00b            RTNE [Default]                         Round to Nearest Even
           01b            RU                                     Round toward +Infinity
           10b            RD                                     Round toward –Infinity
           11b            RTZ                                    Round toward Zero
     21    Barrier Enable

           Format:                                                Enable
           This field specifies whether the thread group requires a barrier. If not, it can be dispatched without
           allocating one.

     20:16 Shared Local Memory Size

           Format:                                                                     U5
           This field indicates how much shared local memory the thread group requires. The amount is specified
           in 4k blocks, but only powers of 2 are allowed: 0, 4k, 8k, 16k, 32k and 64k per half-slice.
               Value           Name                                     Description
           [0,16]                       Encodes 0k to 64k in powers of 2
     15:8 Reserved
          Project:
          Format:                                                               MBZ
     15:8 Barrier Return Byte
          Project:
          Format:                                                                      U8
          This field specifies the byte that will be returned by the gateway when the barrier is reached.

6    31:0 Reserved
          Project:
          Format:                                                               MBZ
7    31:0 Reserved
          Format:                                                               MBZ




1.8.5     MEDIA_STATE_FLUSH command
The MEDIA_STATE_FLUSH command is updated to specify all the resources required for the next thread
group via an interface descriptor – if the resources are not available the group cannot start.




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                      5/31/2012                                                    61
    Two MEDIA_STATE_FLUSH commands need to be used to ensure that the flush is complete.

                                       MEDIA_STATE_FLUSH

Length Bias:                                                                                            2
This command updates the Message Gateway state. In particular, it updates the state for a selected Interface
Descriptor.
 This command can be considered same as a MI_Flush except that only media parser will get flushed instead of the
entire 3D/media render pipeline. The command should be programmed prior to new Media state, curbe and/or
interface descriptor commands when switching to a new context or programming new state for the same context.
 With this command, pipelined state change is allowed for the media pipe.
 It should be cautious when using this command when child_present flag in the media state is enabled. This is
because that CURBE state as well as Interface Descriptor state are shared between root threads and child threads.
Changing these states while child threads are generated on the fly may cause unexpected behavior.
 Combining with MI_ARB_ON/OFF command, it is possible to support interruptability with the following command
sequence where interrupt may be allowed only when MI_ARB_ON_OFF is ON:
 MEDIA_STATE_FLUSH
 VFE_STATE // VFE will hold CS if watermark isn't met
 MI_ARB_OFF // There must be at least one VFE command before this one
 MEDIA_OBJECT …. MI_ARB_ON
DWord Bit                                                  Description
0       31:29 Command Type
               Default Value:                                      3h GFXPIPE
               Format:                                             OpCode
        28:27 Pipeline
               Default Value:                                              2h Media
               Format:                                                     OpCode
         26:24 Media Command Opcode
               Default Value:                                               0h
               Format:                                                      OpCode
         23:16 SubOpcode A
               Default Value:                   4h MEDIA_STATE_FLUSH
               Format:                          OpCode
         15:0 DWord Length
              Project:                     All
              Format:                      =n Total Length - 2




                 Value                   Name                                          Description
               0h        DWORD_COUNT_n [Default]                            Excludes DWord (0,1)
1        31:9 Reserved
              Project:                                                        All
              Format:                                                         MBZ
         8    Disable   Pre-emption
              Project:
              Format:                                                Enable
              This bit causes the video front-end to ignore pre-emption requests if set. If this bit is set then
              ARB_CHECK commands should not be used with it.
              A subsequent MEDIA_STATE_FLUSH command with this bit cleared will honor previous pre-emption




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                    5/31/2012                                                      62
                                      MEDIA_STATE_FLUSH
           requests.

     7     Reserved

           Format:                                                            MBZ
     6     Watermark Required
           Project:                                                                         All
           This is a single bit specifying if the MEDIA_STATE_FLUSH should stall further commands until there is
           enough room in a half-slice for the following thread group. The characteristics of the thread group are
           specified in the Interface Descriptor Offset.
            If set, the MEDIA_STATE_FLUSH stalls CS until there are enough threads in a half-slice, and enough
           SLM available in the same half-slice, and a free barrier if one is required. An Interface Descriptors can
           be updated after a Watermarked MEDIA_STATE_FLUSH only if it has not been used in the current
           context. Reusing an interface desciptor requires that this bit is clear to ensure the ID cache is reloaded.
            If clear, the MEDIA_STATE_FLUSH stalls CS until the TDL has dispatched the last thread, allowing
           the CURBE and Interface Descriptors to be updated by following commands.
                                         Programming Notes                                           Project


     5:0   Interface Descriptor Offset
           Format:                                                                         U5
           This field specifies the offset from the interface descriptor base pointer to the interface descriptor which
           describes what resources are required to meet the watermark.




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                     5/31/2012                                                       63
1.8.6       MEDIA_OBJECT Command
The MEDIA_OBJECT command is the basic media primitive command for the media pipeline. It supports
loading of inline data as well as indirect data. At least one form of payload (either inline, indirect or
CURBE) must be sent with the MEDIA_OBJECT.

                                            MEDIA_OBJECT

Length Bias:                                                                                                  2
DWord Bit                                                  Description
0     31:29 Command Type
             Default Value:                                         3h GFXPIPE
             Format:                                                OpCode
      28:27 Media Command Pipeline
             Default Value:                                                  2h Media
             Format:                                                         OpCode
      26:24 Media Command Opcode
            Default Value:                              1h MEDIA_OBJECT
            Format:                                     OpCode
      23:16 Media Command Sub-Opcode
            Default Value:                              0h MEDIA_OBJECT
            Format:                                     OpCode
      15:0 DWord Length
           Default Value:                           4h DWORD_COUNT_n
           Format:                                  =n Total Length - 2


            Excludes DWords 0,1

            Generic Mode: DWord Length = N+4, where N is in the range of [0,504]. The maximum is 504 DW
            (equivalent to 63 8-DW registers).
             When both inline and indirect data are fetched for this command, the total size in 8-DW registers must
            be less than 112
             (with both inline data length N and indirect data length rounded up to 8-DW aligned individually). The
            minimal inline data length is 0.

1     7:6   Reserved
            Format:                                                            MBZ
      5:0   Interface Descriptor Offset
            Format:                                                                         U5
            This field specifies the offset from the interface descriptor base pointer to the interface descriptor which
            will be applied to
             this object. It is specified in units of interface descriptors.

2     31    Children Present
            Format:                                                 Enable
            Indicates that the root thread may send spawn messages to spawn child threads and/or synchronized
            root threads.
             If Children Present is not set, TS signals VFE to dereference the URB handle immediately after it
            receives acknowledgement from TD that the thread is dispatched.
             If Children Present is set, the URB handle is forwarded to the root thread and serves as the return



Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                      5/31/2012                                                       64
                                           MEDIA_OBJECT
          URB handle for the root thread. TS does not signal deference at the time of dispatch. TS signals URB
          handle deference only when it receives a resource dereference message from the thread.
          In order avoid deadlock, such dereference must be issued once and only once for each URB handle.

     30:25 Reserved
           Format:                                                            MBZ
     24   Thread Synchronization
          This field when set indicates that the dispatch of the thread originated from this command is based on
          the “spawn root thread” message.
            Value                                                 Name
          0         No thread synchronization
          1         Thread dispatch is synchronized by the “spawn root thread” message
     23   Reserved
          Format:                                                             MBZ
     22   Reserved

          Format:                                                             MBZ
     21   Use Scoreboard
          This field specifies whether the thread associated with this command uses hardware scoreboard. Only
          when this field is set, the scoreboard control fields in the VFE Dword are valid. If this field is cleared,
          the thread associated with this command bypasses hardware scoreboard.
                    Value                                                Name
          0                         Not using scoreboard
          1                         Using scoreboard
     20   Reserved

          Format:                                                             MBZ
     19   Reserved

          Format:                                                             MBZ
     18:17 Half-Slice Destination Select

          This field selects the half slice that this thread must be sent to.
           Value             Name                                           Description
          10b       Half-Slice 1             Cannot be used in products without a Half-Slice 1.
          01b       Half-Slice 0
          00b       Either half-slice        Hardware will choose the slice based on load.


                                                       Programming Notes
          If "Either half-slice" is selected then the Slice Destination Select must also specify "Either slice".
     16:0 Indirect Data Length
          Format:                                   U17 In bytes


          This field provides the length in bytes of the indirect data. A value zero indicates that indirect data
          fetching is disabled – subsequently, the Indirect Data Start Address field is ignored.
           This field must have the same alignment as the Indirect Object Data Start Address.
           It must be DQWord (32-byte) aligned. As the indirect data are sent directly to URB, range is limited to




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                    5/31/2012                                                          65
                                           MEDIA_OBJECT
           496 DW. When both inline and indirect data are fetched for this command, the total size in 8-DW
           registers must be less than 112 (with both inline data length and indirect data length rounded up to 8-
           DW aligned).

3    31:0 Indirect Data Start Address
                                                       Description                                          Project
           This field specifies the Graphics Memory starting address of the data to be loaded into the
           kernel for processing. This pointer is relative to the Indirect Object Base Address.


           Hardware ignores this field if indirect data is not present.


           Alignment of this address depends on the mode of operation.
           This field specifies the DWord aligned address of the indirect data.


                                         Value                                               Name
           [0,512MB]


                                                  Programming Notes                                         Project
           Driver must invalidate the vertex fetch cache through the VF(address based) Cache
           Invalidation Enable through a PIPE_CONTROL command prior to reusing the same graphics
           memory space.
           Bits 31:29 MBZ
4    31:25 Reserved
           Format:                                                          MBZ
     24:16 Scoredboard Y
           Format:                                                                     U9
           This field provides the Y term of the scoreboard value of the current thread.

     15:9 Reserved
          Format:                                                           MBZ
     8:0   Scoreboard X
           Format:                                                                     U9
           This field provides the X term of the scoreboard value of the current thread.

5    31:20 Reserved
           Format:                                                         MBZ
     19:16 Scoreboard    Color
           Format:                                                                     U4
           This field specifies which dependency color the current thread belongs to. It affects the dependency
           scoreboard control.

     15:8 Reserved
          Format:                                                           MBZ
     7:0   Scoreboard Mask
           Format:                                         Boolean
           Each bit indicates the corresponding dependency scoreboard is dependent on. This field is AND’d with




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                    5/31/2012                                                       66
                                             MEDIA_OBJECT
               the corresponding Scoreboard Mask field in the MEDIA_VFE_STATE command.

               Bit n (for n = 0…7): Scoreboard n is dependent, where bit 0 maps to n = 0.

6..n   31:0 Inline Data
            Generic Mode: The format of this data is specified by software. Hardware does not interpret this data; it
            merely passes it to the kernel for processing. The total size for the inline data and indirect data must
            not exceed 112 registers.




1.8.7       MEDIA_OBJECT_PRT Command

                                         MEDIA_OBJECT_PRT

Length Bias:                                                                                               2
command is for generating Persistent Root Thread for the media pipeline. It only supports loading of inline data but
not indirect data.
 This command should be used for a root thread that might have to be present in the system for a period longer than
the certain minimal context-switch interrupt latency. It has to honor the context interrupt signal to terminate upon
request. It should also handle replay from theinterrupted point upon context restore (the same thread being
dispatched more than once). In contrary, if a thread is not a Persistent Root Thread, if dispatched, it must run to
completion.
 The command can be used in all VFE modes, except VLD mode.
For simplification, _PRT command has a fixed size of 16 DWORD
DWord Bit                                                     Description
0       31:29 Command Type
              Default Value:                                           3h GFXPIPE
              Format:                                                  OpCode
        28:27 Pipeline
              Default Value:                                                   2h Media
              Format:                                                          OpCode
       26:24 Media Command Opcode
             Default Value:                                                   1h
             Format:                                                          OpCode
       23:16 SubOpcode
             Default Value:                       2h MEDIA_OBJECT_PRT
             Format:                              OpCode
       15:0 DWord Length
            Project:                        All
            Format:                         =n Total Length - 2


               Note: Regardless of the mode, inline data must be present in this command. The command size must
               fit within 16 dwords.
                   Value                         Name                                      Description
               14h          DWORD_COUNT_n [Default]                             Excludes DWord (0,1)
1      31:6 Reserved




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                      5/31/2012                                                    67
                                          MEDIA_OBJECT_PRT
              Project:                                                               All
              Format:                                                                MBZ
        5:0   Interface Descriptor Offset
              Project:                                                                           All
              Format:                                                                            U5
              This field specifies the offset from the interface descriptor base pointer to the interface descriptor which
              will be applied to this object. It is specified in units of interface descriptors.

2       31    Children Present
              Project:                                                All
              Format:                                                 Enable
              Indicates that the root thread may send spawn messages to spawn child threads and/or synchronized
              root threads.
               If Children Present is not set, TS signals VFE to dereference the URB handle immediately after it
              receives acknowledgement from TD that the thread is dispatched.
               If Children Present is set, the URB handle is forwarded to the root thread and serves as the return
              URB handle for the root thread. TS does not signal deference at the time of dispatch. TS signals URB
              handle deference only when it receives a resource dereference message from the thread.
               In order avoid deadlock, such de-reference must be issued once and only once for each URB handle.

        30:24 Reserved
              Project:                                                            All
              Format:                                                             MBZ
        23    PRT_Fence Needed
              Project:                                                All
              Format:                                                 Enable
              This field specifies that a PRT_Fence is generated after dispatching the thread associated with this
              MEDIA_OBJECT_PRT. The PRT_Fence prevents additional threads following this persistent root
              thread until a thread spawn message is sent. The PRT_Fence is generated on first dispatch of the
              persistent root, as well as on re-dispatches of the persistent root after context restore.

        22    PRT_FenceType
              Project:                                                                           All
              This field specifies the type of fence the PRT thread uses. If this field is set to 0, the fence is set at the
              end of the root thread queue. It will block the dispatch of the next root thread, but allowed these root
              threads to be populated through VFE to the root thread queue in TS. If this field is set to 1, the fence is
              set at the entry of VFE, similar to the fence set by the MEDIA_STATE_FLUSH command. No more
              command can go into the media pipe until a thread spawn message is sent (by the PRT).
               This field is only valid when PRT_Fence Needed is set to 1. Otherwise, it is ignored by hardware.
                 Value                    Name                                Description                         Project
              0h           Root thread queue                  Root thread queue fence                         All
              1h           VFE state flush                    VFE state flush fence                           All
        21:0 Reserved
             Project:                                                             All
             Format:                                                              MBZ
3       31:0 Reserved
             Format:                                                              MBZ
4..15   31:0 Inline Data
             Project:                                                                 All
             Format:                                                                  U32




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                         5/31/2012                                                        68
1.8.8       MEDIA_OBJECT_WALKER Command
The MEDIA_OBJECT_WALKER command uses the hardware walker in VFE for generating threads
associated with a rectangular shaped object. It only supports loading of inline data or CURBE but not
indirect data. At least one form of payload must be sent. Control of scoreboards (up to 8) is implicit based
on the (X, Y) address of the generated thread and the scoreboard control state.
The command can be used only in Generic modes.
When Use Scoreboard field is set, the (X, Y) address and the Color field of the generated thread are
used in the hardware scoreboard and the thread dependencies are set by states from the
MEDIA_VFE_STATE command.
One or more threads may be generated by this command. This command doesn’t support indirect object
load. When inline data is present, it is repeated for all threads it generates. Unlike CURBE, which requires
pipeline flush for change, continued change of this kind of ‘global’ (in the sense of shared by multiple
threads from this command) data is supported when MEDIA_OBJECT_WALKER commands are issued
without a pipeline flush in between.

                                    MEDIA_OBJECT_WALKER

Length Bias:                                                                                                    2
DWord Bit                                                   Description
0     31:29 Command Type
             Default Value:                                          3h GFXPIPE
             Format:                                                 OpCode
      28:27  Pipeline
             Default Value:                                                   2h Media
             Format:                                                          OpCode
      26:24 Media Command Opcode
            Default Value:                                                       1h
            Format:                                                              OpCode
      23:16 SubOpcode
            Default Value:                   03h MEDIA_OBJECT_WALKER
            Format:                          OpCode
      15:0 DWord Length
           Default Value:                            Eh DWORD_COUNT_n
           Project:                                  All
           Format:                                   =n Total Length - 2


            Note: If this field is greater than 15, it indicates that inline data is present. If present, inline data is
            common for all threads generated from this command, If this field is 15, it indicates that inline data is
            not present. It should be noted that unlike other media object command, inline data is optional for this
            command.

1     7:6   Reserved
            Format:                                          Reserved
      5:0   Interface Descriptor Offset




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                      5/31/2012                                                           69
                                 MEDIA_OBJECT_WALKER
          Format:                                                                            U5
          This field specifies the offset from the interface descriptor base pointer to the interface descriptor which
          will be applied to this object. It is specified in units of interface descriptors.

2    31   Children Present
          Format:                                                 Enable
          Indicates that the root thread may send spawn messages to spawn child threads and/or synchronized
          root threads.
           If Children Present is not set, TS signals VFE to dereference the URB handle immediately after it
          receives acknowledgement from TD that the thread is dispatched.
           If Children Present is set, the URB handle is forwarded to the root thread and serves as the return
          URB handle for the root thread. TS does not signal deference at the time of dispatch. TS signals URB
          handle deference only when it receives a resource dereference message from the thread.
          In order avoid deadlock, such dereference must be issued once and only once for each URB handle.

     30:25 Reserved
           Format:                                                           MBZ
     24   Thread Synchronization
          This field when set indicates that the dispatch of the thread originated from this command is based on
          the “spawn root thread” message.
            Value                                                 Name
          0         No thread synchronization
          1         Thread dispatch is synchronized by the “spawn root thread” message
     23:22 Reserved

          Format:                                                            MBZ
     21   Use Scoreboard
          This field specifies whether the thread associated with this command uses hardware scoreboard. Only
          when this field is set, the scoreboard control fields in the VFE Dword are valid. If this field is cleared,
          the thread associated with this command bypasses hardware scoreboard.
                    Value                                                Name
          0                         Not using scoreboard
          1                         Using scoreboard
     20:17 Reserved
           Format:                                                           MBZ
     16:0 Indirect Data Length
          Format:                                  U17 in bytes


          This field provides the length in bytes of the indirect data. A value zero indicates that indirect data
          fetching is disabled – subsequently, the Indirect Data Start Address field is ignored.
           This field must have the same alignment as the Indirect Object Data Start Address.
           It must be DQWord (32-byte) aligned. As the indirect data are sent directly to URB, range is limited to
          496 DW. When both inline and indirect data are fetched for this command, the total size in 8-DW
          registers must be less than or equal to 63 (with both inline data length and indirect data length rounded
          up to 8-DW aligned).

3    31:0 Indirect Data Start Address
                                                   Description                                                Project
          This field specifies the Graphics Memory starting address of the data to be loaded into the




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                    5/31/2012                                                          70
                                MEDIA_OBJECT_WALKER
          kernel for processing. This pointer is relative to the Indirect Object Base Address.
           Hardware ignores this field if indirect data is not present.
           Alignment of this address depends on the mode of operation.
          It is the DWord aligned address of the indirect data.


                         Value                    Name                          Description
          [0 - 512MB]                                        (Bits 31:29 MBZ)
4    31:0 Reserved
          Format:                                                       MBZ
5    7:0 Scoreboard Mask
          Format:                                          Boolean
          Each bit indicates the corresponding dependency scoreboard is dependent on. This field is AND’d with
          the corresponding Scoreboard Mask field in the MEDIA_VFE_STATE. All threads generated by this
          walker command share the same dynamic mask.
          Bit n (for n = 0…7): Scoreboard n is dependent, where bit 0 maps to n = 0.

6    31   Dual Mode
          Project:
          Format:                                           Boolean


                                          Programming Notes                                            Project
          Dual mode should be used in products that have 2 half-slices.
     30   Repel

          Format:                                           Boolean


                                                 Programming Notes
          Repel should not be combined with either Dual Mode or Quad Mode.
     29   Reserved

          Format:                                                         MBZ
     28   Reserved
          Format:                                                         MBZ
     27:24 Color Count Minus One
           Format:                                                                      U4
           This field specifies the number of repeat of the inner most loop of the walker. Each repeated walk
           position is assigned with an incremental Color number. The Color number together with the X and Y
           position of the thread is used for dependency scoreboard control.
           Usage Example: This allows multiple sets of dependency threads to be dispatched.

     23:21 Reserved
           Format:                                                        MBZ
     20:16 Middle Loop Extra Steps
           Format:                                                                   U5
     15:14 Reserved
           Format:                                                        MBZ




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                  5/31/2012                                                     71
                                   MEDIA_OBJECT_WALKER
     13:12 Local Mid-Loop Unit Y
           Format:                                                          S1
     11:10 Reserved
           Format:                                                   MBZ
     9:8   Mid-Loop Unit X
           Format:                                                          S1
     7:0   Reserved
           Format:                                                   MBZ
7    31:26 Reserved
           Format:                                                   MBZ
     25:16 Global Loop Exec Count
           Format:                                                    U10
     15:10 Reserved
           Format:                                                   MBZ
     9:0   Local Loop Exec Count
           Format:                                                    U10
8    31:25 Reserved
           Format:                                                   MBZ
     24:16 Block  Resolution Y
           Format:                                                          U9
           Vertical resolution of the local loop.

     15:9 Reserved
          Format:                                                    MBZ
     8:0   Block Resolution X
           Format:                                                          U9
           Horizontal resolution of the local loop.

9    31:25 Reserved
           Format:                                                   MBZ
     24:16 Local Start Y
           Format:                                                          U9
           Starting vertical position of the local loop.

     15:9 Reserved
          Format:                                                    MBZ
     8:0   Local Start X
           Format:                                                          U9
           Starting horizontal position of the local loop.

10   31:25 Reserved
           Format:                                                   MBZ
     24:16 Local End Y

           Format:                                                          U9
           Ending vertical position of the local loop.




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                        5/31/2012               72
                                   MEDIA_OBJECT_WALKER
     15:9 Reserved
          Format:                                                          MBZ
     8:0   Local End X

           Format:                                                               U9
           Ending horizontal position of the local loop.

11   31:26 Reserved
           Format:                                                         MBZ
     25:16 Local Outer Loop Stride Y
           Format:                                                               S9
           Vertical stride of the local outer loop, in 2’s complement.

     15:10 Reserved
           Format:                                                         MBZ
     9:0   Local Outer Loop Stride X
           Format:                                                               S9
           Horizontal stride of the local outer loop, in 2’s complement.

12   31:26 Reserved
           Format:                                                         MBZ
     25:16 Local Inner Loop Unit Y
           Format:                                                               S9
           Vertical stride of the local inner loop, in 2’s complement.

     15:10 Reserved
           Format:                                                         MBZ
     9:0   Local Inner Loop Unit X
           Format:                                                               S9
           Horizontal stride of the local inner loop, in 2’s complement.

13   31:25 Reserved
           Format:                                                         MBZ
     24:16 Global Resolution Y
           Format:                                                               U9
           Vertical resolution of the global loop.

     15:9 Reserved
          Format:                                                          MBZ
     8:0   Global Resolution X
           Format:                                                               U9
           Horizontal resolution of the global loop.

14   31:26 Reserved
           Format:                                                         MBZ
     25:16 Global Start Y
           Format:                                                               S9




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                      5/31/2012                      73
                                     MEDIA_OBJECT_WALKER
              Starting vertical location of the global loop, in 2’s complement.

        15:10 Reserved
              Format:                                                             MBZ
        9:0   Global Start X
              Format:                                                                   S9
              Starting horizontal location of the global loop, in 2’s complement.

15      31:26 Reserved
              Format:                                                             MBZ
        25:16 Global Outer Loop Stride Y
              Format:                                                                   S9
              Vertical stride of the global outer loop, in 2’s complement.

        15:10 Reserved
              Format:                                                             MBZ
        9:0   Global Outer Loop Stride X
              Format:                                                                   S9
              Horizontal stride of the global outer loop, in 2’s complement.

16      31:26 Reserved
              Format:                                                             MBZ
        25:16 Global Inner Loop Unit Y
              Format:                                                                   S9
              Vertical stride of the global inner loop, in 2’s complement.

        15:10 Reserved
              Format:                                                             MBZ
        9:0   Global Inner Loop Unit X
              Format:                                                                   S9
              Horizontal stride of the global inner loop, in 2’s complement.

17..n   31:0 Inline Data




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                        5/31/2012                           74
1.8.9        GPGPU_OBJECT
This command is modified from the MEDIA_OBJECT command.

                                              GPGPU_OBJECT

Length Bias:                                                                                                     2
                                             Programming Notes
If the threads spawned by this command are required to observe memory writes performed by threads spawned
from a previous command, software must precede this command with a command that performs a memory flush
(e.g., MI_FLUSH).
DWord Bit                                                Description
0        31:29 Command Type
               Default Value:                                   3h GFXPIPE
               Format:                                          OpCode
         28:27 Pipeline
               Default Value:                                          2h Media
               Format:                                                 OpCode
       26:24 Media Command Opcode
             Default Value:                                                       1h
             Format:                                                              OpCode
       23:16 SubOpcode
             Default Value:                                            04h MEDIA_
             Format:                                                   OpCode
       15:9 Reserved
            Project:                                                             All
            Format:                                                              MBZ
       8       Predicate Enable
               Project:                                                                   All
               Format:                                                                    U1
               If set, this command is executed (or not) depending on the current value of the MI Predicate internal
               state bit. This command is ignored only if PredicateEnable is set and the Predicate state bit is 0.

       7:0     DWord Length
               Format:                         =n Total Length -2


               There are 4 DW needed to specify the Thread Group ID and the execution mask.
                 Value                         Name                                     Description
               6h        DWORD_COUNT_n      [Default]                       Excludes DWord (0,1)
1      7       Shared Local Memory Fixed Offset
               This bit, if set, specifies that the offset into the 64k Shared Local Memory for the current thread group is
               specified by software in the Shared Local Memory Offset field.
               Value             Name                                           Description
               0      Thread Groups Offset Offset to start of segment determined by hardware based on concurrently
                                                  running thread groups.
               1      Shared Local Memory Offset to start of the Shared Local Memory segment supplied in Shared
                      Offset                      Local Memory Offset
       6       Reserved
               Project:                                                             All




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                        5/31/2012                                                        75
                                           GPGPU_OBJECT
           Format:                                                             MBZ
     5:0   Interface Descriptor Offset
           Format:                                                                            U5
           This field specifies the offset from the interface descriptor base pointer to the interface descriptor which
           will be applied to this object. It is specified in units of interface descriptors.In VLD mode, this field is
           ignored by hardware.

2    31:28 Shared Local Memory Offset
           Format:                                                                           U4


                                                      Description                                             Project
           If the Shared Local Memory Fixed Offset is set, this field provides the offset to the start of the
           Shared Local Memory for this thread group. The value of this field is multiplied by 4k to get the
           starting address. All threads in the thread group must have the same value.
           Offset must be aligned with Shared Local Memory Size of the thread group.
     27:25 Reserved
           Project:                                                          All
           Format:                                                           MBZ
     24    End of Thread Group
           Project:
           This bit indicates that this dispatch is the last for the current thread group.

     23:20 Reserved
           Project:                                                            All
           Format:                                                             MBZ
     19    Reserved
           Project:
           Format:                                                             MBZ
     18:17 Half-Slice Destination Select
           This field selects the half slice that this thread must be sent to.
            Value             Name                                           Description
           10b       Half-Slice 1              Cannot be used in products without a Half-Slice 1.
           01b       Half-Slice 0
           00b       Either Half-Slice         Hardware will choose the slice based on load.
     16:0 Indirect Data Length
          Format:                                     U17 in bytes


           This field provides the length in bytes of the indirect data. A value zero indicates that indirect data
           fetching is disabled – subsequently, the Indirect Data Start Address field is ignored. Thread IDs
            This field must have the same alignment as the Indirect Object Data Start Address.
            It must be DQWord (32-byte) aligned. As the indirect data are sent directly to URB, range is limited to
           496 DW. When both inline and indirect data are fetched for this command, the total size in 8-DW
           registers must be less than or equal to 63 (with both inline data length and indirect data length rounded
           up to 8-DW aligned).

3    31:0 Indirect Data Start Address
          This field specifies the Graphics Memory starting address of the data to be loaded into the kernel for




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                      5/31/2012                                                      76
                                           GPGPU_OBJECT
            processing. This pointer is relative to the Indirect Object Base Address.
             Hardware ignores this field if indirect data is not present.
             The start address is a 64-byte aligned address.
             (Bits 31:29 MBZ)
                                           Value                                             Name
            [0,512MB)
4      31:0 Thread Group ID X
            This is the X coordinate of the group id.
5      31:0 Thread Group ID Y
            This is the Y coordinate of the group id for all channels generated by this command.
6      31:0 Thread Group ID Z
            This is the Z coordinate of the thread group id.
7      31:0 Execution Mask
            This provides a bit per channel enable for the SIMD32 dispatch. The LSB of the Mask enables the
            execution of SIMD32 channel 0; the remaining bits enable the corresponding channel numbers.
            SIMD16 and SIMD8 dispatches should use the LSB bits of the mask. Any disabled channel will not
            read or write data to memory.




1.8.10 GPGPU_WALKER Command

                                           GPGPU_WALKER

Length Bias:                                                                                          2
                                             Programming Notes
If the threads spawned by this command are required to observe memory writes performed by threads spawned
from a previous command, software must precede this command with a command that performs a memory flush
(e.g., MI_FLUSH).
DWord Bit                                                Description
0        31:29 Command Type
               Default Value:                                    3h GFXPIPE
               Format:                                           OpCode
         28:27 Pipeline
               Default Value:                                          2h Media
               Format:                                                 OpCode
       26:24 Media Command Opcode
             Default Value:                                               1h
             Format:                                                      OpCode
       23:16 SubOpcode A
             Default Value:                                               05h
             Format:                                                      OpCode
       15:11 Reserved
             Project:                                                     All
             Format:                                                      MBZ
       10      Indirect Parameter Enable
               Project:                                                             All
               Format:                                                              U1




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                  5/31/2012                                                  77
                                             GPGPU_WALKER
               If set, the values in DW 4, 6, 8 are ignored and replaced by the current values of the corresponding
               GPGPU_xxx MMIO registers:


           
                 GPGPU_DISPATCHDIMX (instead of DW4)
           
                 GPGPU_DISPATCHDIMY (instead of DW6)
           
                 GPGPU_DISPATCHDIMZ (instead of DW8)


     9         Reserved
               Project:                                                          All
               Format:                                                           MBZ
     8         Predicate Enable
               Project:                                                                   All
               Format:                                                                    U1
               If set, this command is executed (or not) depending on the current value of the MI Predicate internal
               state bit. This command is ignored only if PredicateEnable is set and the Predicate state bit is 0.

     7:0       DWord Length
               Project:                       All
               Format:                        =n Total Length - 2




                    Value                     Name                                               Description
               9h           DWORD_COUNT_n [Default]                                    Allowed value is 9
1    7:6       Reserved
               Project:                                                               All
               Format:                                                                MBZ
     5:0       Interface Descriptor Offset
               Format:                                                                            U5
               This field specifies the offset from the interface descriptor base pointer to the interface descriptor which
               will be applied to this object. It is specified in units of interface descriptors.

2    31:30 SIMD Size
           This field determines the size of the payload and the number of bits of the execution mask that are
           expected. The kernel pointed to by the interface descriptor should match the SIMD declared here.
              Value         Name                                       Description
           0            SIMD8           8 LSBs of the execution mask are used
           1            SIMD16          16 LSBs used in execution mask
           2            SIMD32          32 bits of execution mask used
     29:22 Reserved
           Project:                                                        All
           Format:                                                         MBZ
     21:16 Thread Depth Counter Maximum




Doc Ref #: IHD-OS-V2 Pt 2 – 05 12                        5/31/2012                                                       78
                                         GPGPU_WALKER
            The maximum value of the thread depth counter.
             Thread_Depth_Max*Thread_Height_Max*Thread_Width_Max <= 32 for SIMD32, <= 64 for SIMD16
            and SIMD8
     15:14 Reserved
           Project:                                                       All
           Format:                                                        MBZ
     13:8 Thread Height Counter Maximum
          The maximum value of the thread height counter
     7:6    Reserved
            Project:                                                      All
            Format:                                                       MBZ
     5:0    Thread Width Counter Maximum
            The maximum value of the thread width counter
3    31:0   Thread Group ID Starting X
            This is the initial value of the X component of the thread group. When X reaches the maximum value it
            rolls around to 0, not to this value.
4    31:0   Thread Group ID X Dimension
            The X dimension of the thread group (maximum X is dimension -1)
5    31:0   Thread Group ID Starting Y
            This is the initial value of the Y component of the thread group. When Y reaches the maximum value it
            rolls around to 0, not to this value.
6    31:0   Thread Group ID Y Dimension
            The Y dimension of the thread group (maximum Y is dimension -1)
7    31:0   Thread Group ID Starting Z
            This is the initial value of the Z component of the thread group
8    31:0   Thead Group ID Z Dimension
            The Z dimension of the thread group (maximum Z is dimension -1)
9    31:0   Right Execution Mask
10   31:0   Bottom Execution Mask




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

1.0               First 2012 OpenSource edition         May 2012




                                                  §§




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