[Waiting for] AMD GPU Polaris & Vega (ex-Arctic Islands)

[FusRoDah]

C'è qualche novità trapelata sulle Polaris in merito alla presentazione del 15 marzo?

Novità veramente interessanti? Koduri si è tolto i baffi

Ottimo, è davvero un bel uomo.

Spoiler: mostra

[Masciale]

C'é qualquadra che non cosa in quel rumour

[Il nabbo di turno]

C'é qualquadra che non cosa in quel rumour

Sembra quasi un cut di hawaiii in effetti.

[Radeon80]

http://www.overclock.net/t/1595594/vari ... t_25019528

Ho trovato questo post(post 85) dove si parla del Graphics Command Processor.
Dovrebbe essere il componente di cui parlavo l'altro giorno(magari sbagliando nome)che dovrebbe far si che Polaris 10 e 11 siano meno dipendenti dalla CPU rispetto alle serie GCN 1.0,1.1 e 1.2 in giochi dx11.

[Radeon80]

Sul forum semiaccurate nella discussione su Polaris 10 e 11 si è generata una discussione dove si dice che Polaris non avrà tutte le novità di GCN 4.0 pubblicate nelle slide rilasciate al CES e anche che la versione di shader core sarà lo stesso di Tonga e Fiji.

[Alessio89]

Tutte cose di cui non me ne frega nulla sinceramente. Cosa voglio? ISA con granulairtà volumetrica per il tiling a 64KB (l'ideale sarebbe un tiling a granularità da 4KB come su x86 ma mi sa che è chiedere troppo, un po' come il page faulting), rasterizer e bland-state finalmente programmabili (garantirebbe supporto a ROVs e CR, e future funzionalità dello sM 6.0), root buffer almeno 4 volte più generoso e ciliegina sulla torta: isa con supporto FP 10 bit (ok forse questo è chiedere troppo, gli half precision sono già una gran cosa).
gran chissenefrega del numero delle code, del dispatcher o altro, quelle sono tutte pippe mentali dato che sono artifici architetturali per far quadrare il resto che conta veramente, e per fare slide da distribuire senza raccontare nulla di significativo.

[Sasha]

AMD: "We have now 10bit FP support!"
Initial response: "Wow"
Reviews: "Look, AMD is not so efficient in gaming as NVIDIA"
Readers: "buuuuuu, I won't buy AMD anymore!"
Someone: "ehi, look, it's normal that AMD wastes more power because it supports more functions. NVIDIA loses on FP64 before, what now that it doesn't support FP 10bit?"
Readers: "buuuu AmD is crap. NVIDIA is golden! Look at that power consumption values!"

Un valido motivo per cui, ad esempio, gli FP spero non li implementino prima di NVIDIA
Molto meno utili di Async Compute e pure deleteri per la sua lotta contro NVIDIA

In ogni caso, cosa comporterebbe avere un root buffer 4 volte più grande? Quali i vantaggi?

[Radeon80]

http://abload.de/img/765q9rae.jpg

https://semiaccurate.com/forums/showpos ... tcount=115

Questa immagini che sono apparse 2-3 giorni fa al massimo e secondo poi alcuni post di utenti su vari forum esteri direbbero che Polaris non avrà tutte le novità architetturali mostrate nella slide AMD a gennaio al CES,ma sarebbe di fatto un Tonga con modifiche architetturali meno spinte(tipo passaggio da GCN 1 e GCN 3)unità ad una elevata efficienza energetica.

[Alessio89]

AMD: "We have now 10bit FP support!"
Initial response: "Wow"
Reviews: "Look, AMD is not so efficient in gaming as NVIDIA"
Readers: "buuuuuu, I won't buy AMD anymore!"
Someone: "ehi, look, it's normal that AMD wastes more power because it supports more functions. NVIDIA loses on FP64 before, what now that it doesn't support FP 10bit?"
Readers: "buuuu AmD is crap. NVIDIA is golden! Look at that power consumption values!"

Un valido motivo per cui, ad esempio, gli FP spero non li implementino prima di NVIDIA
Molto meno utili di Async Compute e pure deleteri per la sua lotta contro NVIDIA

In ogni caso, cosa comporterebbe avere un root buffer 4 volte più grande? Quali i vantaggi?

Il root buffer nelle AMD funziona da memoria veloce dove vengono memorizzati i parametri della pipeline. Tutto quello che non ci entra subisce un livello di indirezione in più, pertanto un degrado prestazionale rispetto a ciò che riesce a stare dentro al root buffer sin da subito. Con D3D12 tutti i parametri che prima il driver gestiva automaticamente ora devi ficcarli tu dentro manualmente al root buffer. Hai 15 o 16 DWORD slot sulle GCN (a seconda di come imposti la pipeline), tutto sta fuori. Avere un root buffer 4 volte più grande con D3D12 non vi sarebbero più penalità di alcun tipo su come viene impostato il tutto. Altre architetture non hanno questi problemi o perché hanno un root buffer più generoso o proprio perché non lo hanno (e averlo ma usarlo male non significa essere meglio di chi non lo ha affatto). Altre architetture poi hanno altri problemi, per esempio le geforce hanno un rapporto sado-masochistico con i constant buffer, mentre AMD non ha alcun problema al riguardo.

[Alessio89]

AMD: "We have now 10bit FP support!"
Initial response: "Wow"
Reviews: "Look, AMD is not so efficient in gaming as NVIDIA"
Readers: "buuuuuu, I won't buy AMD anymore!"
Someone: "ehi, look, it's normal that AMD wastes more power because it supports more functions. NVIDIA loses on FP64 before, what now that it doesn't support FP 10bit?"
Readers: "buuuu AmD is crap. NVIDIA is golden! Look at that power consumption values!"

Un valido motivo per cui, ad esempio, gli FP spero non li implementino prima di NVIDIA
Molto meno utili di Async Compute e pure deleteri per la sua lotta contro NVIDIA

In ogni caso, cosa comporterebbe avere un root buffer 4 volte più grande? Quali i vantaggi?

Il root buffer nelle AMD funziona da memoria veloce dove vengono memorizzati i parametri della pipeline. Tutto quello che non ci entra subisce un livello di indirezione in più, pertanto un degrado prestazionale rispetto a ciò che riesce a stare dentro al root buffer sin da subito, in pratica funziona come una cache veloce ma è di ritoddittissime dimensioni (16 DWORD = 512 bit). Con D3D12 tutti i parametri che prima il driver gestiva automaticamente ora devi ficcarli tu dentro manualmente al root buffer. Hai 15 o 16 DWORD slot sulle GCN (a seconda di come imposti la pipeline), tutto sta fuori. Avere un root buffer 4 volte più grande con D3D12 non vi sarebbero più penalità di alcun tipo su come viene impostato il tutto (D3D12 permette di impsotare sino a 64 DROWDs). Altre architetture non hanno questi problemi o perché hanno un root buffer più generoso o proprio perché non lo hanno (e averlo ma usarlo male non significa essere meglio di chi non lo ha affatto). Altre architetture poi hanno altri problemi, per esempio le geforce hanno un rapporto sado-masochistico con i constant buffer, mentre AMD non ha alcun problema al riguardo.