Il Command Processor (CP)
Secondo AMD il command processor (CP) di R600 è un processore vero e proprio. Intendiamoci, non è una CPU x86 ma comunque un vero processore microcode. Ha pieno accesso alla memoria, può eseguire calcoli matematici e altre elaborazioni in maniera indipendente.
In teoria questo significa che il command processor può alleviare i driver di parte del lavoro, siccome può scaricare micro codice ed eseguire istruzioni vere e proprie.
Nella pratica, il CP analizza il flusso di comandi inviato dal driver ed esegue alcune elaborazioni associate a questo flusso. In seguito, sincronizza alcuni degli elementi all'interno del chip e ne valida perfino alcuni all'interno del flusso. Parte della pipeline è stata progettata per eseguire a sua volta validazioni, come per esempio la determinazione dello stato in cui si trova la modalità di rendering.
Demers ha dichiarato che "l'intero chip è stato progettato allo scopo di sollevare da tutto questo lavoro il driver". Se c'è un conflitto di risorse e stati, il driver può sospendersi temporaneamente mentre pensa cosa fare come passo successivo. Ciò che dovete pensare è che il driver è gestito dalla CPU. Il problema inerente al driver quindi è che sta rubando cicli dal processore, che nel frattempo potrebbe fare altre cose più utili. AMD dichiara di aver trasferito tutte queste attività e, ancor più importante, tutto il lavoro di validazione nell'hardware della scheda video.
Il command processor esegue parecchio di questo lavoro con un chip che è definito "consapevole". L'architettura gli permette di "dare un'occhiata in giro" per scoprire cosa stanno facendo le altri componenti hardware. Un esempio di questo si verifica quando lo Z buffer verifica cosa stia facendo il pixel shader, ovvero sta verificando se può terminare dei pixel in anticipo. Se una risorsa sa che questo sta accadendo, può passare alla modalità più adatta affinché l'operazione di cui sopra si concluda nel modo migliore e più rapido possibile.
I miglioramenti in questo campo possono spiegare perché le console, in certi campi applicativi, sono più veloci dei PC. I PC sono sempre in fase di verifica dello stato dell'applicazione. La conseguenza di questo modello comportamentale paranoico è parecchio overhead. Se l'applicazione richiede l'invio di un comando draw con uno stato associato, il runtime di Microsoft ne verificherà prima una parte, il driver poi ne verificherà un'altra parte. Infine bisogna validare tutto e inviare all'hardware. AMD ritiene che questo overhead sia non trascurabile, ecco perché ha trasferito tutto quanto poteva nell'hardware.
Questo è quanto tipicamente chiamato lo "small batch problem". David Blythe di Microsoft a riguardo ha commentato che le maggiori lamentele degli sviluppatori riguardano la mancanza di comunicazione inerenti le richieste delle applicazioni, i diversi stili di elaborazione e l'accoppiamento errato tra hardware e API.
Secondo AMD gli avanzamenti in termini di hardware possono ridurre ulteriormente l'overhead del driver nella CPU fino al 30%. Questo non significa però che le applicazioni andranno più veloci del 30%, ma solo che la CPU avrà più cicli a disposizione per svolgere altri compiti. A seconda dell'applicazione, l'uso del processore può andare da cifre risibili come l'1% fino al 10-15%. In media dovremmo essere sul 5-7%; nell'ipotesi più ottimistica, si scaricherà il processore del 30%. Sebbene questo discorso non sia il Santo Graal del frame rate elevato, è un passo nella giusta direzione. Ci dovrebbero essere benefici già nelle applicazioni DX 9, mentre le DX 10, progettate per essere più "amichevoli" dal punto di vista dello "small batch" dovrebbero godere di benefici superiori.