Multi-Threaded Rendering
Se si parla di Multi-Threaded rendering, è facile contestare che gli sviluppatori sono già in grado di gestirlo al meglio, visto che lavorano da anni con CPU multi-core. Non si tratta, quindi, di nulla di nuovo, almeno in apparenze. Potrebbe sorprendervi, ma i motori odierni usano ancora il single-thread per il rendering. Gli altri thread sono usati per il suono, la decompressione delle risorse, la fisica,etc. Il rendering, però, è molto pesante per la CPU, come sappiamo; quindi perché non ottimizzarlo in multi-thread? Ci sono molte ragioni, alcune legate al modo in cui lavora la GPU, e altre legate direttamente alle API 3D. Microsoft ha quindi cercato di risolvere questi problemi, almeno per quanto riguarda la parte delle librerie (chi ha detto Larabee?).
Organizzare in thread il processo di rendering è un'idea molto attraente, ma, resta il fatto che la GPU è solo una (anche quando più GPU sono connesse in SLI o Crosfire, infatti, l'obiettivo è di creare un'illusione che ci sia un'unica GPU virtuale), e quindi un unico buffer comandi. Quando una singola risorsa è condivisa da vari thread, si verifica una mutua esclusione (mutex), per evitare che più thread di comandi scrittura interagiscano simultaneamente, disturbandosi a vicenda.
Questo significa che tutti i vantaggi dell'usare più thread vengono cancellati da alcune sezioni che serializzano il codice. Le API non possono risolvere questo problema, che è legato al modo in cui CPU e GPU comunicano. Ma Microsoft sta per offrire un'API che potrà lavorare attorno a questo problema. Le Direct3D 11 introducono, infatti, un buffer di comandi secondario, che può essere salvato e usato più tardi.
I comandi di scrittura vengono registrati in una lista, che può essere inserita successivamente nel flusso dati principale. Quando si richiama la lista dal thread principale (l'"Execute" nel grafico "Multi-threaded Submission" qui sotto) ci si deve assicurare che il suo thread abbia finito di riempirla. Quindi, c'è ancora una sincronizzazione da effettuare, ma questo modello esecutivo permette almeno di rendere paralleli alcuni lavori, anche se l'accelerazione risultante non è ottimale.
Un altro problema con la precedente versione delle Direct3D ha a che fare con la creazione di risorse, come le texture. Nella corrente versione delle API (9 e 10), la creazione di risorse deve avvenire nel thread di rendering. Gli sviluppatori risolvono il problema creando un thread che legge e decomprime le texture dal disco, e "riempie" le risorse (l'oggetto Direct3D), create nel thread principale.
Ma, come potete immaginare, una grossa parte del lavoro è ancora nel thread principale, decisamente sovraccaricato. Questa impostazione porta ad un lavoro mal bilanciato, mentre sarebbe necessario più equilibrio per ridurre i tempi d'esecuzione. Microsoft ha quindi deciso d'introdurre una nuova interfaccia, con le Direct3D11; con questa nuova versione un programmatore può creare un "Device object" per ogni thread, usato per caricare le risorse. La sincronizzazione all'interno delle funzioni del Device è gestita in maniera migliore dalle Direct3D 10, ed è più economica rispetto al tempo impiegato dalla CPU.
