ARCHITETTURA UNIFICATA

[Defragg]

Originariamente inviato da ATi7500

stroncato

bYeZ!

già

[Window Vista]

Originariamente inviato da Defragg

già

Non penso proprio, perchè programmare su shader unificati vuol dire non sapere dove il collo di bottiglia, intendo dire: se Nvidia fa un scheda con 24 pippe e 8 vertex shader, si sa gà qual'è il collo di bottiglia, o l'uno o l'altro, invece nell'altro hanno una lunghissima pipèline composto da tot. shader e non sanno come devono fare il gioco, dove il punto di forza.
Questo l'aveva detto anche tomshw.it in una news.

[Andrea deluxe]

il discorso dei problemi di resa non e' cio' che pensi tu!

il problema e' far uscire dalle fabriche chip con 400-500 milioni di transistor!


la storia delle 7950 e' una cosa ben diversa!(hanno ottimizzato l'architetttura per ridurre i transistor cosiche' si possano avere rese superiori!

sai che bello avere un wafer 40x40cm con il 50% di die (da 500milioni di transistor) difettati!

molto meglio avere un wafer 40x40cm con il 50% di die (da 275milioni di transistor) difettati

[Andrea deluxe]

se il ragionamento entra bene in testa, entra bene in testa anche il motivo dell' esistenza delle soluzioni dual gpu

[ATi7500]

Originariamente inviato da Window Vista

Non penso proprio, perchè programmare su shader unificati vuol dire non sapere dove il collo di bottiglia, intendo dire: se Nvidia fa un scheda con 24 pippe e 8 vertex shader, si sa gà qual'è il collo di bottiglia, o l'uno o l'altro, invece nell'altro hanno una lunghissima pipèline composto da tot. shader e non sanno come devono fare il gioco, dove il punto di forza.
Questo l'aveva detto anche tomshw.it in una news.

veramente programmare su un'architettura a shader separati è di gran lunga più limitativo rispetto ad agire su di una a shader unificati; l'importante non è sapere dove sono i colli di bottiglia, ma proprio eliminarli alla base; e avendo libertà di bilanciare il carico vertex/pixel shader, potenzialmente i soli limiti derivano dalla velocità di elaborazione del chip (leggi frequenza), che si può abbastanza facilmente incrementare senza stravolgimenti architetturali.
Uno che programma un gioco con architettura a shader separati dice: "no questo non lo possiamo fare perchè quell'architettura ha solo 8vertexshader, quindi puntiamo sull'effetto col pixelshader"
Uno che programma su un'architettura a shader unificati dice: "Allora, abbiamo piena libertà, possiamo creare effetti basandoci senza preferenze su vertex e pixel shader; l'unica cosa a cui dobbiamo stare attenti è non sovraccaricare la pipeline grafica e non introdurre troppi stati d'attesa"

ovviamente aspetto correzioni da Vifani e Yossarian se necessarie


bYeZ!

[ATi7500]

Originariamente inviato da Andrea deluxe

il discorso dei problemi di resa non e' cio' che pensi tu!

il problema e' far uscire dalle fabriche chip con 400-500 milioni di transistor!


la storia delle 7950 e' una cosa ben diversa!(hanno ottimizzato l'architetttura per ridurre i transistor cosiche' si possano avere rese superiori!

sai che bello avere un wafer 40x40cm con il 50% di die (da 500milioni di transistor) difettati!

molto meglio avere un wafer 40x40cm con il 50% di die (da 275milioni di transistor) difettati

più che ridurre i transistor si tende a ridurre il processo produttivo, "per farcene stare di più nello stesso spazio"

bYeZ!

[Andrea deluxe]

lo so!

ma stavo discutendo della situazione 7950!

[Window Vista]

Vifani & co. fatevi sentir, battete un colpo se ci siete

[Vifani]

Non è vero che programmare per un'architettura a shader unificati significa non conoscerne i limiti ed il collo di bottiglia. Diciamo che a causa della variabilità di configurazione delle varie unità di calcolo questi limiti non si possono più definire in maniera fissa, ma variano da situazione a situazione, ma un range di riferimento sulle operazioni che è possibile effettuare a livello di vertex, pixel e texturing viene sicuramente comunicato agli sviluppatori.

Comunque al di là di questo discorso bisogna considerare che i videogames sono quasi esclusivamente limitati nelle operazioni di pixel shading, blending e texturing. E' estremamente raro vedere un gioco limitato a livello di vertex shading perché i modellatori delle mappe e dei personaggi la prima cosa che fanno è ridurre al minimo possibile il dettaglio poligonale. Del resto effetti come il bump mapping o il parallax mapping servono proprio per conferire dettaglio a superfici che in realtà, dal punto di vista poligonale, sono piatte.

Inoltre è ormai di uso comune nei motori grafici effettuare una prima passata di rendering dedicata solo alla scrittura dei valori dello z-buffer e tutte le successive passate, invece, sono realizzate senza scrivere in questo buffer. Sto parlando delle passate di rendering necessarie alla realizzazione di un fotogramma. Questa operazione viene effettuata perché una volta fissato lo z-buffer, tutte le altre passate possono essere elaborate con una rimozione delle superfici nascoste praticamente totale e ciò limita il numero di pixel da elaborare essenzialmente al numero di pixel visualizzati sullo schermo (dovuti, quindi, alla risoluzione). Quella prima passata di rendering, non dovendo elaborare alcun colore dei pixel, ma solo la posizione dei vertici, vede le unità di vertex shading completamente occupate e quelle di pixel shading completamente a riposo. Con un'architettura a shader unificati l'efficienza in una situazione di questo tipo aumenta drammaticamente.

Esiste inoltre una tecnica di rendering piuttosto innovativa (non ricordo, ma forse non è ancora mai stata usata) chiamata deferred shading (o anche quad shading) che consiste nel fare la prima passata di rendering per memorizzare i valori dello z-buffer, della posizione, delle normali, ecc... (essenzialmente tutti i dati geometrici) in texture in formato floating point e successivamente renderizzare la scena come un rettangolo che copre l'intera superficie dello schermo (da qui il termine quad shading) usando queste texture come fonti di informazioni geometriche, ma eseguendo di fatto solo calcoli con i pixel shader in tutte le passate successive alla prima. Questo è un altro esempio in cui un'architettura a shader unificati è infinitamente più efficiente di una classica perché dedica tutte le unità disponibili all'esecuzione dei pixel shader.

Personalmente penso che un'architettura unificata a parità di capacità di calcolo, se la gestione delle unità di calcolo è efficiente e, come giustamente osservato da yossarian, non richiede troppi cicli di clock, è sempre + efficiente di una classica.

[Defragg]

Originariamente inviato da Vifani

Non è vero che programmare per un'architettura a shader unificati significa non conoscerne i limiti ed il collo di bottiglia. Diciamo che a causa della variabilità di configurazione delle varie unità di calcolo questi limiti non si possono più definire in maniera fissa, ma variano da situazione a situazione, ma un range di riferimento sulle operazioni che è possibile effettuare a livello di vertex, pixel e texturing viene sicuramente comunicato agli sviluppatori.

Comunque al di là di questo discorso bisogna considerare che i videogames sono quasi esclusivamente limitati nelle operazioni di pixel shading, blending e texturing. E' estremamente raro vedere un gioco limitato a livello di vertex shading perché i modellatori delle mappe e dei personaggi la prima cosa che fanno è ridurre al minimo possibile il dettaglio poligonale. Del resto effetti come il bump mapping o il parallax mapping servono proprio per conferire dettaglio a superfici che in realtà, dal punto di vista poligonale, sono piatte.

Inoltre è ormai di uso comune nei motori grafici effettuare una prima passata di rendering dedicata solo alla scrittura dei valori dello z-buffer e tutte le successive passate, invece, sono realizzate senza scrivere in questo buffer. Sto parlando delle passate di rendering necessarie alla realizzazione di un fotogramma. Questa operazione viene effettuata perché una volta fissato lo z-buffer, tutte le altre passate possono essere elaborate con una rimozione delle superfici nascoste praticamente totale e ciò limita il numero di pixel da elaborare essenzialmente al numero di pixel visualizzati sullo schermo (dovuti, quindi, alla risoluzione). Quella prima passata di rendering, non dovendo elaborare alcun colore dei pixel, ma solo la posizione dei vertici, vede le unità di vertex shading completamente occupate e quelle di pixel shading completamente a riposo. Con un'architettura a shader unificati l'efficienza in una situazione di questo tipo aumenta drammaticamente.

Esiste inoltre una tecnica di rendering piuttosto innovativa (non ricordo, ma forse non è ancora mai stata usata) chiamata deferred shading (o anche quad shading) che consiste nel fare la prima passata di rendering per memorizzare i valori dello z-buffer, della posizione, delle normali, ecc... (essenzialmente tutti i dati geometrici) in texture in formato floating point e successivamente renderizzare la scena come un rettangolo che copre l'intera superficie dello schermo (da qui il termine quad shading) usando queste texture come fonti di informazioni geometriche, ma eseguendo di fatto solo calcoli con i pixel shader in tutte le passate successive alla prima. Questo è un altro esempio in cui un'architettura a shader unificati è infinitamente più efficiente di una classica perché dedica tutte le unità disponibili all'esecuzione dei pixel shader.

Personalmente penso che un'architettura unificata a parità di capacità di calcolo, se la gestione delle unità di calcolo è efficiente e, come giustamente osservato da yossarian, non richiede troppi cicli di clock, è sempre + efficiente di una classica.

Window...vuoi qualcosa d +

[ATi7500]

Originariamente inviato da Vifani

Non è vero che programmare per un'architettura a shader unificati significa non conoscerne i limiti ed il collo di bottiglia. Diciamo che a causa della variabilità di configurazione delle varie unità di calcolo questi limiti non si possono più definire in maniera fissa, ma variano da situazione a situazione, ma un range di riferimento sulle operazioni che è possibile effettuare a livello di vertex, pixel e texturing viene sicuramente comunicato agli sviluppatori.

Comunque al di là di questo discorso bisogna considerare che i videogames sono quasi esclusivamente limitati nelle operazioni di pixel shading, blending e texturing. E' estremamente raro vedere un gioco limitato a livello di vertex shading perché i modellatori delle mappe e dei personaggi la prima cosa che fanno è ridurre al minimo possibile il dettaglio poligonale. Del resto effetti come il bump mapping o il parallax mapping servono proprio per conferire dettaglio a superfici che in realtà, dal punto di vista poligonale, sono piatte.

Inoltre è ormai di uso comune nei motori grafici effettuare una prima passata di rendering dedicata solo alla scrittura dei valori dello z-buffer e tutte le successive passate, invece, sono realizzate senza scrivere in questo buffer. Sto parlando delle passate di rendering necessarie alla realizzazione di un fotogramma. Questa operazione viene effettuata perché una volta fissato lo z-buffer, tutte le altre passate possono essere elaborate con una rimozione delle superfici nascoste praticamente totale e ciò limita il numero di pixel da elaborare essenzialmente al numero di pixel visualizzati sullo schermo (dovuti, quindi, alla risoluzione). Quella prima passata di rendering, non dovendo elaborare alcun colore dei pixel, ma solo la posizione dei vertici, vede le unità di vertex shading completamente occupate e quelle di pixel shading completamente a riposo. Con un'architettura a shader unificati l'efficienza in una situazione di questo tipo aumenta drammaticamente.

Esiste inoltre una tecnica di rendering piuttosto innovativa (non ricordo, ma forse non è ancora mai stata usata) chiamata deferred shading (o anche quad shading) che consiste nel fare la prima passata di rendering per memorizzare i valori dello z-buffer, della posizione, delle normali, ecc... (essenzialmente tutti i dati geometrici) in texture in formato floating point e successivamente renderizzare la scena come un rettangolo che copre l'intera superficie dello schermo (da qui il termine quad shading) usando queste texture come fonti di informazioni geometriche, ma eseguendo di fatto solo calcoli con i pixel shader in tutte le passate successive alla prima. Questo è un altro esempio in cui un'architettura a shader unificati è infinitamente più efficiente di una classica perché dedica tutte le unità disponibili all'esecuzione dei pixel shader.

Personalmente penso che un'architettura unificata a parità di capacità di calcolo, se la gestione delle unità di calcolo è efficiente e, come giustamente osservato da yossarian, non richiede troppi cicli di clock, è sempre + efficiente di una classica.

il mio obiettivo è arrivare al livello di quest'uomo

bYeZ!

[Defragg]

Originariamente inviato da ATi7500

il mio obiettivo è arrivare al livello di quest'uomo

bYeZ!

anche il mio

[Vifani]

Comunque fek sarebbe sicuramente un candidato più competente di me per spiegare queste cose perché io programmo motori grafici per hobby, mentre lui lo fa per professione e tra l'altro ha già programmato per l'X-Box 360 e quindi ha a che fare con un'architettura a shader unificati.

[Andrea deluxe]

FEEEEEEEEEEEEEK

[Defragg]

Originariamente inviato da Andrea deluxe

FEEEEEEEEEEEEEK

ghghgh

[P3pPoS83]

Originariamente inviato da Andrea deluxe

FEEEEEEEEEEEEEK

Non nominare il suo nome invano

Bye

[DjLode]

Originariamente inviato da Vifani

perché io programmo motori grafici per hobby

Dai, questa non la sapevo. Urge vedere qualcosa

[fede27]

Originariamente inviato da Vifani

Comunque fek sarebbe sicuramente un candidato più competente di me per spiegare queste cose perché io programmo motori grafici per hobby, mentre lui lo fa per professione e tra l'altro ha già programmato per l'X-Box 360 e quindi ha a che fare con un'architettura a shader unificati.

sarebbe parecchio interessante sentire le prime impressioni di un programmatore su shader unificati..magari riesce a darci qualche idea concreta delle potenzialità di questa soluzione!!

ps: motori grafici per hobby.. in media quanto ci metti a finirne uno??

[Vifani]

Originariamente inviato da fede27

ps: motori grafici per hobby.. in media quanto ci metti a finirne uno??

In realtà questa domanda non ha senso perché se non hai un obiettivo del tipo "serve un motore per fare questo gioco e che faccia questo", in realtà non finisci mai Ed è quello che capita a me. Diciamo più che altro che mi diletto nel programmare, fare shaders, implementare HDR, shadows, ecc.. così come passa tempo.

Riguardo a farvi vedere qualcosa... se ne parla quando ci sarà qualcosa che posso far vedere. Onestamente non sono un grafico e quindi benché possa far creare stencil shadows o bump mapping, le scene su cui li faccio girare sono al massimo qualche composizione delle primitive di 3D Studio Max (sfere, parallelepipedi, piramidi, ecc...).

[fede27]

Originariamente inviato da Vifani

In realtà questa domanda non ha senso perché se non hai un obiettivo del tipo "serve un motore per fare questo gioco e che faccia questo", in realtà non finisci mai Ed è quello che capita a me. Diciamo più che altro che mi diletto nel programmare, fare shaders, implementare HDR, shadows, ecc.. così come passa tempo.

Riguardo a farvi vedere qualcosa... se ne parla quando ci sarà qualcosa che posso far vedere. Onestamente non sono un grafico e quindi benché possa far creare stencil shadows o bump mapping, le scene su cui li faccio girare sono al massimo qualche composizione delle primitive di 3D Studio Max (sfere, parallelepipedi, piramidi, ecc...).

il senso della domanda era appunto questo io credevo ti ponessi degli obiettivi tipo "provo a fare un motore che su queste basi mi dia questi risultati" e penso sia comunque impegnativo come lavoro, non male come hobby!!

quindi mi pare di capire che tu ti metti davanti al pc cominci a scrivere e vedi cosa ti viene fuori..molto artistico

ps: ot-ma sei laureato ing. informatico, informatico o matematico ?