Forum

Ci voleva proprio questa spiegazione. In 24 ore sono usciti articoli uno più cazzone dell'altro.

Grazie Alessio, anche se completamente ignorante in materia almeno ho maggior chiarezza di quello che è il panorama lato API (DX 12) e lato hardware.

Fottemberg ha scritto:Ci voleva proprio questa spiegazione. In 24 ore sono usciti articoli uno più cazzone dell'altro.

Inviare l'articolo a ogni cazz... editore del settore?

Grazie Alessio: sei stato abbastanza dettagliato e al contempo sintetico da risultare comprensibile anche a persone ignoranti in materia come il sottoscritto

Non capisco una cosa: ipotizzando di essere nel 2017 e di aver sottomano un gioco tripla A che sfrutti al 100% le DX3D12, io con una HD 7790 (GCN 1.1) non potrei giocarci oppure potrei ma (esempio) gli effetti non supportati dalla mia GPU sarebbero gestiti dal motore grafico tramite le DX11? (Ormai la maggior parte dei "gioconi" ha motori che possono renderizzare in DX11/10/9)

@george_p mi hai battuto sul tempo con i ringraziamenti!

è lui il messiah

grazie per la spiegazione

GLORIA GLORIA GLORIA ad Alessio

FusRoDah ha scritto:Grazie Alessio: sei stato abbastanza dettagliato e al contempo sintetico da risultare comprensibile anche a persone ignoranti in materia come il sottoscritto

Non capisco una cosa: ipotizzando di essere nel 2017 e di aver sottomano un gioco tripla A che sfrutti al 100% le DX3D12, io con una HD 7790 (GCN 1.1) non potrei giocarci oppure potrei ma (esempio) gli effetti non supportati dalla mia GPU sarebbero gestiti dal motore grafico tramite le DX11? (Ormai la maggior parte dei "gioconi" ha motori che possono renderizzare in DX11/10/9)

@george_p mi hai battuto sul tempo con i ringraziamenti!

Dipende come gli sviluppatori hanno deciso di affrontare il supporto delle varie funzionalità hardware opzionali in quanto nessuno impedisce a degli sviluppatori di scrivere del codice permette ad un gioco di funzionare solo se una data funzionalità è supportata. Nel 2017 tuttavia reputo difficile che vi siano in molti a non voler supportare l'architettura GCN 1.1, anche perché è quella alla base di XB1, sarebbe inoltre una decisione molto stupida. Infine alcune funzionalità di D3D12 non sono pensate per le schede grafiche dedicate su PC.

Se un motore grafico avrà o meno un back-end (un'implementazione) con le DX11 anche questo sta in mano agli sviluppatori, fra D3D11 e D3D12 vi sono enormi differenze per quanto riguarda le modalità di utilizzo e funzionamento; sebbene una mescolanza fra le due API è possibile tramite l'utilizzo di una terza denominata D3D11on12 la cosa non è quasi plausibile al di fuori di compiti che non richiedono un sensibile sforzo dell'hardware, come l'interfaccia grafica di un'applicazione 3D. In pratica è necessario fornire quanto meno due back-end separati ed implementati in maniera diversa (cercare di implementare un back-end per D3D12 sul modello di uno per D3D11 porta irrimediabilmente a disastri, a detta di uno sviluppatore della Square Enix, un lavoro "fatto bene" in quel modo porterebbe come minimo ad una perdita prestazionale del 50%, quindi sono necessari lavori diversi e distinti).

Passare da un'API all'altra non è una cosa automatica e richiede un certo lavoro da parte degli sviluppatori. Da D3D10.1 a D3D11.2 (e anche con la prossima 11.3) è permesso tramite Direct3D 10Level9 di supportare hardware altrimenti fruibile solo tramite Direct3D 9 (escluso lo SM 3.0 - shader model 3.0) oltre che i feature level relativi e l'hardware SM4/4.1 (e ovviamente l'hardware SM 5.0).
Con le DX12 è stato data una sforbiciata a tale supporto in quanto l'hardware di generazioni precedenti non supportano i due requisiti fondamentali (memoria virtuale e tiled resource) attorno alle quali è stata ridisegnata per intero l'API di D3D 12. L'unica vera componente ereditata quasi pari pari da D3D11 è lo SM 5.0 al quale sono stati affiancati il nuovo SM 5.1 e e l'HLSL di root signature v1 (come alternativa al codice scritto direttamente C++), ma tutto il resto è stato praticamente re-implementato da zero (ecco il motivo della lunga attesa).

Fottemberg ha scritto:Ci voleva proprio questa spiegazione. In 24 ore sono usciti articoli uno più cazzone dell'altro.

Ora inizieranno a dire che NV ha fatto apposta a non supportare pienamente le specifiche del FL 11.1 perché non conveniva ai giocatori citando questo link http://nvidia.custhelp.com/app/answers/ ... a_id/3196/ senza però capirci un cazzo di quello di cui si parla e prendendo per oro colato quel che il reparto PR-marketing di NV ha spacciato sotto forma di "comunicato per gli sviluppatori".

Le due funzionalità non supportate dell'hardware di NV non così innocue come vogliono far credere, ma hanno ripercussione su tutta la nuova meccanica delle UAV introdotta con D3D 11.1.
Infatti Microsoft - che ha sempre l'ultima parola - ha deciso di non esporre tramite cap-bit la terza funzionalità da loro supportata ("UAVs in the vertex, geometry and tessellation shaders") senza il supporto di quelle due funzionalità, inoltre non è esposta tramite cap-bit neanche la possibilità di passare da 8 a 64 UAV (cosa che il reparto PR-marketing di NV furbamente non cita), e la stessa cosa è accaduta con D3D 12.0.

Le funzionalità non riguardanti le UAV invece Microsoft ha deciso di esporle lo stesso anche al feature level 11.0 in quanto non rompono alcun meccanismo interno dell'API se prese sincolarmente e anche questo è accaduto nuovamente con D3D 12.0.

Per motivi di NDA non posso citare le fonti, ma posso solo dire che se in D3D12 fosse stato possibile esporre il FL 11.1 anche per Fermi, Kepler e Maxwell 1.0 la cosa sarebbe stata fatta e alla grande, ci avrebbero guadagnato tutti.
Paradossalmente ora i progetti minori o dove non ci sono le risorse per supportare ogni singola funzionalità o ogni singolo feature level è più facile che si sviluppi esclusivamente ancora attorno al feature level 11.0 in quanto quello supportato da tutti. Ovviamente per i progetti dove non vi sono questi problemi, lo sviluppo attorno a tutti i feature level e le funzionalità singole necessari agli sviluppatori continuerà ad esserci come è stato fatto fino ad ora (in molti più titolo che l'utente medio pensa, semplicemente sono cose nascoste al giocatore).

Tutto questo non è accaduto perché c'è stato dietro ad un complotto capitanato da AMD e Microsoft brutte e cattive ma perché le architetture Fermi, Kepler e Maxwell 1.0 hanno forti limitazioni nella gestione delle UAV che sono la chiave di algoritmi general purpose sia dedicati alla grafica che non. Chiamalo poco.

Ottima notizia chiarificatrice su come sono strutturate le dx12.
Ringrazio sopratutto Alessio che grazie ai suoi post mi ha dato molto chiarezza riguardo sia la struttura delle dx12 e spegato le varie differenze tra i tier e le freature level delle nuove api Microsoft.
Una cosa che non mi aspettavo è la notevole differenza a livello di supporto dx12 tra GCN 1.0 e 1.1.
Mi ricordo che quando lessi le caratteristiche architetturali di Hawaii erano state fatte modifiche "qua e la" rispetto a Tahiti senza stravolgere le prestazioni nei giochi.

Una bella complicazione, fatta apposta per confondere persino gli appassionati.

<Rant Mode ON> Considerando poi che i giochi sono sviluppati al 99% per l'hardware delle console queste cose sono totalmente fuorvianti, visto che queste funzionalità non verranno sfruttate.
Per me l'unico motivo serio per cambiare la scheda video oggi è il passaggio a monitor con definizione maggiore. <Rant Mode OFF>

Complimenti ad Alessio. Benche abbia capito poco (mia ingnoranza), fa sempre piacere vedere persone preparate e disponibili.
Cmq penso che tutta questa storia sia piu votata al marketing becero. Il "bello" non lo vedremo prima delle 16nm

Ps. Che lavoro fai?