Prezzi dei componenti per PC Uber-Enthusiast: Intel risponderà a Titan Z?

[Mitch]

Continua qui

[Fottemberg]

Non ci vedo nulla di male, non sono prodotti "normali", per me possono essere venduti senza problemi.
Come si dice qui in romagna, sono prodotti "ignoranti".

[Alessio89]

le API attuali (comprese le prossime DX12) adottano l'approccio con un solo thread-master che supervisiona gli altri

Direct3D 12 – Command Creation Parallelism

• About that context…
• No Immediate Context
  • All rendering via Command Lists
  • Command Lists are submitted on a Command Queue

Command Lists and Command Queue

• Application responsible for
  • Hazard tracking
  • Declaring maximum number of recording command lists
  • Resource renaming with GPU signaled fence
  • Resources lifetime referenced by command lists
• Fence operations on the Command Queue
  • Not on Command List or Bundle
  • Signals occur on Command List completion
• Command List submission cost reduced by WDDM 2.0

Direct3D 12 – CPU Parallelism

• Direct3D 12 has several parallel tasks
  • Command List Generation
  • Bundle Generation
  • PSO Creation
  • Resource Creation
  • Dynamic Data Generation
• Runtime and driver designed for parallelism
• Developer chooses what to make parallel

Veramente in D3D12 hanno reso tutta la parte che era relativa device context (responsabile dell'utilizzo delle risorse) totalmente multi-threading, e visto che già la device (responsabile della creazione delle risorse) era thread-safe in d3d11, ora l'api supporta in toto il multi-threading e in maniera completamente libera.

Prima al massimo potevi affiancare all'immediate context (che era il contesto sul thread di rendering principale) dei deferred context (solitamente sul thread dell'applicazione e non su quello di rendering) che registravano i command list da inviare alla gpu (qualora il driver li supportasse, aka non gpu di AMD) ma che poi venivano passati ed eseguiti sempre dall'immediate context.

Ora non so cosa volete di più, ma la fonte di quella sparata sbaglia di brutto.


...


Tornando in tema: ora che la Titan Z costa ben 200$ in meno farà il tutto esaurito

[Mitch]

http://www.bitsandchips.it/images/2014/ ... 2_2/11.jpg
come vedi, anche se ridotto enormemente, il thread-master c'è sempre anche sulle DX12

[Alessio89]

Intendi quello verde? Quello è il thread relativo alla logica dell'applicazione, non del rendering. Quelli che devi guardare nel grafico sono le parti gialle.

Nel multi-threading c'è sempre un thread principale, mentre l'utilizzo di un thread che regola gli altri è semplicemente una tecnica che a volte conviene e a volte no e in D3D11 era praticamente l'unica opzione sana.

In D3D12 come regolare i thread sta completamente agli sviluppatori, l'unico paletto che mette l'api è l'utilizzo dei signal (piuttosto dei mutex o dei semafori). Se guardi il grafico puoi vedere che la parte gialla è stata suddivisa molto più equamente con la nuova api (che è ancora in versione pre-alpha). Certo il primo thread rimane quello più esoso, pure nella parte di rendering, ma di poco e non certo perché doveva coordinare gli altri, semplicemente non tutto il carico di lavoro può essere suddiviso in parti perfettamente uguali.

In quella demo a detta di uno dei responsabili del team di conversione si è semplicemente attenuto a convertire il back-end, senza utilizzare funzionalità nuove che non erano in qualche modo presenti in D3D11. Nonostante ciò pure la logica dell'applicazione (la parte verde) ne ha giovato parecchio (proprio perché sui thread secondari ora i command-list vengono buttati direttamente nella coda dei comandi della gpu, senza dover passare per un thread principale).
Se guardi di nuovo il grafico ti accorgi che in D3D11 il thread principale, per quanto concerne il tempo dedicato al rendering ha un tempo di esecuzione più o meno triplo rispetto ai thread secondari proprio perché riceve indietro i command lists dei thread secondari per poi eseguirli lui stesso.

[Mitch]

Infatti ho specificato che l'hanno ridotto sensibilmente, ma c'è sempre anche perchè nemmeno le api low-level possono eliminarlo ... bisognerebbe programmare direttamente on-chip xD

Ovvio che con le DX12 il multi-threading è spalmato molto meglio, le hanno fatte apposta, ma mi servivano per dire che 18C/36T sono comunque inutili su sistemi da gaming dove c'è un theread che "potrebbe" fare da collo di bottiglia

[Il nabbo di turno]

Non ci vedo nulla di male, non sono prodotti "normali", per me possono essere venduti senza problemi.
Come si dice qui in romagna, sono prodotti "ignoranti".

Nooo!Sei romagnolo?Sono di rimini

[Alessio89]

Infatti ho specificato che l'hanno ridotto sensibilmente, ma c'è sempre anche perchè nemmeno le api low-level possono eliminarlo ... bisognerebbe programmare direttamente on-chip xD

Ovvio che con le DX12 il multi-threading è spalmato molto meglio, le hanno fatte apposta, ma mi servivano per dire che 18C/36T sono comunque inutili su sistemi da gaming dove c'è un thread che "potrebbe" fare da collo di bottiglia

Non è che l'hanno ridotto sensibilmente, quel che chiami "master thread" per quanto concerne il rendering ora non esiste più: l'immediate context non c'è più, ora i comandi vengono direttamente inviati alla GPU da ogni thread dedicato al rendering. Come questi comandi vengono eseguiti (in sequenza o in parallelo) dipende dal driver che a sua volta si spera sia configurato in base al numero di thread della CPU e dell'architettura della GPU.

Rimangono solo due cose che devono essere spalmante su un unico e stesso thread : il passaggio attraverso DXGKrnl.sys e la chiamata di present. Su quale thread non ha importanza, l'importante è che non ve ne siano altri ancora in esecuzione.

Il primo è il tramite fra l'infrastruttura DirectXe il kernel del SO, è l'unica cosa che va in kernel-mode ed è stato ridotto drasticamente (ca 1/5 nella demo di futuremark).
Il suo lavoro consiste praticamente nel dire al SO e all'adattatore video circa il buffer da riservare per l'output. Averlo su più thread non ha alcun senso, uno perché fa il context-switch (che richiede un unico thread) e due perché le cose che deve fare sono sequenziali e molto brevi.

Il secondo consiste nel dire alla GPU: bene, ora che ti sei divertita a fare le tue cose assembla il tutto come ti dico (cosa importante) nel buffer per l'output.
Anche questa chiamata è stata drasticamente velocizzata (sempre nella demo impiega meno della metà di prima) e averla su più thread non avrebbe molto senso visto che l'output è uno solo (anche per più schermi) e avrebbe richiesto una sincronizzazione manuale, mentre invece lo fa il driver della GPU (e lo fa sicuramente meglio di noi visto che è una cosa legata all'architettura della GPU).
Averlo su più thread avrebbe potuto forse avere senso per alcune funzioni di debugging (es: avere in output più buffer diversi, come il rendering finale, il g-buffer, lo-zbuffer ecc), il problema è che è strettamente legato al passaggio di DXG Kernel. Nemmeno in ambito multi-GPU ha senso visto che questo è praticamente sinonimo di AFR.

Persino il driver ora gira completamente in user-mode, in modo da non avere problemi di join dei thread per il context-switch, e il kernel-mode driver è sparito in toto, cosa che prima tranquillamente occupava oltre un terzo del tempo di tutta l'infrastruttura dedicata al rendering.

Tieni sempre presente che quello che è stato fatto vedere è un benchmark e non un gioco vero e proprio. Nei giochi il "cpu-time" dedicato al rendering è spesso (sempre) volentieri drasticamente inferiore, e poter fare virtualmente le stesse cose di prima nella metà del tempo (sempre che non si sia GPU-bound) vuol dire tantissimo.

[Mitch]

No.
Quello che hanno fatto vedere nella demo è il best-case-scenario, nei giochi veri il vantaggio secondo me sarà inferiore (anche perchè voglio proprio vedere se tutti gli sviluppatori si sbattono ad ottimizzare/personalizzare ).
Pochi ci hanno fatto caso (probabilmente offuscati dall'altra demo, quella di Forza 5 con Titan) ma la prova al 3dmark con le DX12 è stata fatta su questa piattaforma: "Tested on GIGABYTE BRIX Pro (Intel Core i7-4770R + Iris Pro Graphics 5200)" proprio per sbrigliare la CPU

[Alessio89]

So benissimo che quei grafici sono stati fatti esclusivamente per enfatizzare i tempi che la CPU dedica a ciascun parte dell'applicazione in un frame. Lo scopo era mostrare che i tempi che la CPU dedica al renderer (che non è il tempo di rendering impiegato dalla GPU!) viene dimezzato e può essere spalmato su più thread in una maniera quasi del tutto omogenea.

I tempi di rendering impiegati dalla GPU sono tutt'altra cosa, tant'è che spesso e volentieri nelle applicazioni reali l'applicazione stessa fra un frame e l'altro deve attendere che la GPU finisca di lavorare prima di ripartire con la parte logica (in caso contrario si ha un'enorme incoerenza fra input del giocatore, simulazione di gioco e output a video).

In un'applicazione reale che diciamo voglia raggiungere i 60FPS in una determinata configurazione, deve impiegare 16.67 ms a frame.
Di questi 16.67 ms, a seconda del gioco, ben 10-12-14 vengono impiegati dalla logica dell'applicazione, i restanti 6-4-2 ms (a seconda della tipologia e del momento di gioco) sono dedicati al renderer (che è sempre una parte software). Come se non bastasse va anche tenuto il conto del tempo che la GPU impiega per fare il suo lavoro (ed è qui che si capisce perché nel multi-GPU si utilizza quasi esclusivamente l'AFR come algoritmo di rendering: invece che aspettare ogni volta che la GPU finisca il suo lavoro si può iniziare a dare i comandi alla GPU successiva).

Oltre all'enorme differenza di overhead, l'API si mappa meglio e sfrutta meglio l'hardware delle moderne GPU a shader unificati (cosa che anche dovrebbe aiutare la GPU nel tempo di rendering)

Se ora io cambiando API di riesco a fare col renderer (non con la GPU!) le stesse cose di prima ma dimezzando il tutto e pure semplificando la logica dell'applicazione (che non è mai del tutto estranea al renderer) ho un vantaggio considerevole come puoi ben intuire, se poi ci mettiamo anche una maggiore facilità di sfruttare al meglio la GPU capisci che tutti gli sviluppatori saranno ben lieti di avere una nuova API del genere.

Infine tieni conto che tutto quello mostrato è una versione d'anteprima, una alfa (con funzionalità quindi incomplete e non disponibili, nelle slide del GDC c'è una lista parziale delle cose disabilitate e di quella ancora non implementate per nulla, e non sono poche!).

Gli obiettivi di DirectX12 sono gli stessi di Mantle ma molto più ambiziosi:
- overhead drasticamente ridotto (idem mantle).
- multi-vendor (mantle lo è a parole visto che è stata pensata attorno a GCN).
- riuscire a mappare bene l'hardwre pur mantenendo una buona astrazione (cosa che mantle purtroppo non ha)
- far girare tutto in user-mode ed eliminare un sacco di overhead dovuto al context-switch e alle relazioni con il sistema operativo (e qui mantle da sola può farlo solo in parte visto che sono necessari cambiamenti al sistema operativo).
- facilitare e migliorando le prestazioni dello sharing delle risorse fra CPU e GPU (qui invece mantle potrebbe avere migliori vantaggi se accoppiato con HSA, ma solo su sistemi full AMD di recente produzione e per ora sappiamo che HSA completo e perfettamente funzionante è ancora lontano).
- Introdurre nuove nuove funzionalità hardware, programmabili e non (qui volendo mantle potrebbe essere sicuramente aggiornato).
- Essere cross-platform (qui c'è poco da fare, xone e windows phone sono chiusi da Microsoft).