desing gcnAlla Game Developers Conference 2014 di San Francisco, Emil Persson, (ex-ATI) che da diversi anni guida il team di Avalanche Studios (lo sviluppatore della serie Just Cause), ha parlato della programmazione a basso livello per l'architettura GCN. Raramente capita di assistere ad una presentazione così interessante e ricca d'informazioni utili per aiutare gli sviluppatori di videogiochi a comprendere ed ottimizzare il codice di quella che è l'architettura alla base delle due nuove console di Microsoft e Sony. Person apre le porte segrete dello shader code di GCN ed offre diversi suggerimenti su come spremere al meglio la potenza di Durango (il nome in codice dalla XB1) e Orbit (PS4).

shader in

A nostro avviso una parte molto importante è quella delle limitazioni sulle ROPs della PS4 e della Xbox One (ma lo stesso vale per quasi tutte le schede video). Negli ultimi anni la crescente potenza computazionale delle ALU della GPU non è stata accompagnata da un adeguato aumento delle ROP (che ricordiamo forniscono il numero di pixel generati per ciclo di clock). La PS4 dispone di 32 ROPs, la XB1 ne ha solo 16 ed ha anche una bandwidth minore, ma può contare sull'aiuto dei velocissimi 32MB di eSRAM. Confrontata con il backend della HD 7970, la PS4 ha un comportamento lineare ma va in saturazione già con un buffer a 64bit (RGBA16F), risultando limitata dalla bandwidth (cioè dalla banda passante delle memorie GDDR5 con interfaccia a 256-bit) rispetto alla GPU Tahiti. Discorso separato per l' XB1 che con il buffer RGBA8 è limitata sempre dalle ROP ma con l'RGBA16F è limitata sia dalle ROP per l'eSRAM che dalla bandwidth delle memorie DDR3.

On the XB1, if we are rendering to ESRAM, 64bit just about hits the crossover point between ROP and bandwidth-bound. But even if we render to the relatively slow DDR3 memory, we will still be ROP-bound if the render-target is a typical 32bit texture

rop

La soluzione proposta da Persson?

The solution is to use a compute shader. Writing through a UAV bypasses the ROPs and goes straight to memory. This solution obviously does not apply to all sorts of rendering, for one we are skipping the entire graphics pipeline as well on which we still depend for most normal rendering. However, in the cases where it applies it can certainly result in a substantial performance increase. Cases where we are initializing textures to something else than a constant color, simple post-effects, this would be useful.

E' possibile scaricare l'intera presentazione a questo indirizzo.