Intel 815 manual Instruction Arbitration, Arbitration Rationale, Wait Instructions

Intel® 815 Chipset: Graphics Controller PRM, Rev 1.0

R

10.4.6.Instruction Arbitration

The Instruction Parser supports up to four sources of pending instructions: two Ring Buffers and two Batch Buffer sequences (one batch buffer per ring buffer). The IP employs a set of rules to arbitrate among these instruction stream sources. This section describes these rules and discusses the reasoning behind them.

10.4.6.1.Arbitration Rationale

The Low Priority Ring Buffer (LPRB) is considered the primary mechanism by which drivers will pass instructions to the GC. However, the insertion of instruction sequences into the LPRB must be a synchronous operation, i.e., software must guarantee mutually exclusive access to the LPRB among contending sources (drivers). This ensures that one driver does not corrupt another driver's partially- completed instruction stream.

There are two general sources of requirements for asynchronous instruction generation and execution: interrupt handlers and contending drivers. An interrupt handler may be invoked when a driver is in the process of inserting instructions into the LPRB. To permit the interrupt handler to generate an instruction stream, the Interrupt Ring Buffer (IRB) is provided. The IRB instruction stream is considered higher priority than the LPRB stream; this priority is manifested in how the IRB is treated in the arbitration rules.

Note, however, that software retains some control over this arbitration process. The GFXCMDPARSER_ARB_ON_OFF instruction can be used from the LP instruction stream (RB or batch buffer) to temporarily disable the IRB from arbitration. This can be used to define uninterruptible critical sections in the LP stream (e.g., where some GC state needs to be protected from IRB instruction execution).

Another requirement for asynchronous instruction generation arises from competing (and asynchronous) drivers (e.g., user-mode driver libraries). In this case, the desire is to allow these entities to construct instruction sequences in an asynchronous fashion, via batch buffers. Synchronization is then only required to dispatch the batch buffers via GFXCMDPARSER_BATCH_BUFFER instructions inserted into the LPRB. Batch buffers can also be initiated from the IRB, though in this case the batch buffer is intended more for performance reasons -- where pre-generated (or "canned") instruction streams can be dispatched without having to copy them into the IRB.

LPRB batch buffers are considered non-interruptible for a number of reasons (IP complexity, GC context management, etc.). To provide some gross limits on IRB latency, batch buffers are interruptible at chain points (between the GFXCMDPARSER_BATCH_BUFFER which ends a batch and the start of the new batch). Using this mechanism, software can segment batched instruction sequences into chains of smaller batches. Batch buffers initiated from the IRB cannot, by definition, be interrupted so chaining them is of limited use.

10.4.6.2.Wait Instructions

The GFXCMDPARSER_WAIT_EVENT instruction is provided to allow instruction streams to be held pending until an asynchronous event occurs. When executed directly from a RB, the IP will treat the RB as if it were empty until the specific event occurs. This will temporarily remove that RB from arbitration. Therefore, a wait instruction placed in the IRB can allow LPRB activity to start/resume, even though there may be IRB instructions still pending.

When executed from a batch buffer, the IP will simply wait for the event to occur without performing rearbitration. As this basically halts the IP for a length of time, the use of wait instructions in batch

147