Sequencing
A ogni arbitro è associato un sequencer. Si tratta di un piccolo program counter con associazione di stato che, in pratica, dice "il thread X ha vinto l'arbitraggio". Dopo questa importante comunicazione, fa in modo che il thread sia il prossimo a essere eseguito dalla matrice SIMD.
Il sequencer esegue un segmento del thread, fino a che non sarà necessario sospenderlo in attesa che si liberino le risorse richieste. Il thread dormirà finché l'arbitro delle fetch delle texture non dirà diversamente. Quando questo accade, il thread viene svegliato e può procedere all'elaborazione del set successivo d'istruzioni. Dopo aver eseguito l'ambito prelievo di texture, andrà ancora a nanna in attesa che i dati ritornino, in modo da non perdere preziosi cicli dell'ALU.
Visto tutto ciò, nell'uso di tutti i giorni non sarà insolito trovare un mucchio di thread addormentati, mentre altri vengono eseguito in tempo reale. Mentre un thread dorme, ci sono sempre altre istruzioni in esecuzione che, a loro volta, sono autorizzate dall'arbitro ad accedere alle risorse in quel determinato momento. Questo per garantire che l'hardware sia sempre sfruttato al 100%.
Che succede però quando ci sono più thread che risorse libere? Questa dovrebbe essere una situazione comune, visto che ci sono almeno due thread in circolo in ogni SIMD. Ovvero, la metà del lavoro da fare non è in esecuzione e, soprattutto, serve più cache di quanta ne sia disponibile fisicamente. Per ovviare a questa situazione, entra in gioco la virtualizzazione.