Intel 815 Manuel D’Utilisation

  

147 

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. 

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. 

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