[Thread Ufficiale] Aspettando Larrabee

[Kharonte85]

Originariamente inviato da appleroof

p.s.: ricordo havock fx, l'ho riportato perchè secondo me nulla vieta che esso possa essere implementato su schede Nvidia (come physx su Ati), dipende tutto dai citati giochi di potere...

per forza, credo che sia scritto in C/C++ quindi facilmente portabile su qualsiasi compilatore compatibile...

[appleroof]

Intel e raytracing (certo che ci stà proprio dando dentro, Intel )

TG Daily: Intel finally disclosed a few details about Larrabee earlier this week. What is Larrabee from your perspective. What is the underlying architecture and the programming model?

Daniel Pohl: Larrabee was primarily built as a rasterizering processor. Therefore you have support for DirectX and OpenGL. But it will also be a freely programmable x86-architecture. That means you could, for example, write your own rasterizer with your own API, a ray tracer, a voxel renderer or combinations of those. You could also use it for non-graphical applications that benefit from parallelization.

TG Daily: How did you get the API to enable ray-tracing? What API is Intel using to showcase ray tracing demos?

Daniel Pohl: Some of the important features of a graphics API are to be able to setup your geometry, define material properties, camera values and a lighting environment. We wrote our own API for that and tuned that through several internal revisions. The shading system uses a HLSL-like syntax that allows you also to shoot new rays within a shader. With that capability, special effects like glass and mirrors become very easy tasks. Everything you see in the Quake Wars: Ray Traced demo is done over that API. Using that API the programmer has no need to manually multi-thread the rendering and does not need to optimize the shading with SSE as this is done by the shading compiler automatically. Of course there always people who want to go really low-level to squeeze out every last percent of performance. For that case, our API can also be bypassed to directly access all internal structures. Let me make sure here that we are doing this for research reasons, so it might be that this API never sees the public light.

http://www.tgdaily.com/content/view/38795/113/

[Simon82]

Originariamente inviato da appleroof

Intel e raytracing (certo che ci stà proprio dando dentro, Intel )

TG Daily: Intel finally disclosed a few details about Larrabee earlier this week. What is Larrabee from your perspective. What is the underlying architecture and the programming model?

Daniel Pohl: Larrabee was primarily built as a rasterizering processor. Therefore you have support for DirectX and OpenGL. But it will also be a freely programmable x86-architecture. That means you could, for example, write your own rasterizer with your own API, a ray tracer, a voxel renderer or combinations of those. You could also use it for non-graphical applications that benefit from parallelization.

TG Daily: How did you get the API to enable ray-tracing? What API is Intel using to showcase ray tracing demos?

Daniel Pohl: Some of the important features of a graphics API are to be able to setup your geometry, define material properties, camera values and a lighting environment. We wrote our own API for that and tuned that through several internal revisions. The shading system uses a HLSL-like syntax that allows you also to shoot new rays within a shader. With that capability, special effects like glass and mirrors become very easy tasks. Everything you see in the Quake Wars: Ray Traced demo is done over that API. Using that API the programmer has no need to manually multi-thread the rendering and does not need to optimize the shading with SSE as this is done by the shading compiler automatically. Of course there always people who want to go really low-level to squeeze out every last percent of performance. For that case, our API can also be bypassed to directly access all internal structures. Let me make sure here that we are doing this for research reasons, so it might be that this API never sees the public light.

http://www.tgdaily.com/content/view/38795/113/

Interessante, anceh se conoscendo certe sparate mi viene alla mente una certa MMX Technology....

[appleroof]

Originariamente inviato da Simon82

Interessante, anceh se conoscendo certe sparate mi viene alla mente una certa MMX Technology....

già...tra l'altro guarda come conclude l'autore dell'articolo:

Intel's research group is pushing ray-tracing development on Intel's chips, but we should not forget that there are companies such as JulesWorld, a small company from Los Angeles that is offering ray-tracing technology on graphics cards of today, not tomorrow.

certo è più marketinghese che altro, imho quello che è interessante è vedere la decisa scesa in campo di questo gigante, non perde occasione...

[Simon82]

Originariamente inviato da appleroof

già...tra l'altro guarda come conclude l'autore dell'articolo:

Intel's research group is pushing ray-tracing development on Intel's chips, but we should not forget that there are companies such as JulesWorld, a small company from Los Angeles that is offering ray-tracing technology on graphics cards of today, not tomorrow.

certo è più marketinghese che altro, imho quello che è interessante è vedere la decisa scesa in campo di questo gigante, non perde occasione...

Infatti. Comunque non escludo che possano davvero mostrarsi innovativi in questo campo. Effettivamente come in molti settori lontani da questo, avere target differenti alla fine e' un obbligo dettato dai nuovi mercati che richiedono fonti attive ovuqune e non basta piu' dedicarsi in uno solo. Quante aziende old sono diventate colossi che fanno tutto e il contrario di tutto (vedi IBM ad esempio, ma anche Microsoft stessa, Google.. ).
Il problema e' COME e CON CHE COSA comincieranno. A me queste sparate da "risolviamo noi in un'attimo cio' che nella conoscenza 3D e' rimasto sempre un utopistica futura aspettativa decennale" mi sa di esagerazione paragonabile solo a quelle di Sony con la PS2.

[appleroof]

Originariamente inviato da Simon82

Infatti. Comunque non escludo che possano davvero mostrarsi innovativi in questo campo. Effettivamente come in molti settori lontani da questo, avere target differenti alla fine e' un obbligo dettato dai nuovi mercati che richiedono fonti attive ovuqune e non basta piu' dedicarsi in uno solo. Quante aziende old sono diventate colossi che fanno tutto e il contrario di tutto (vedi IBM ad esempio, ma anche Microsoft stessa, Google.. ).
Il problema e' COME e CON CHE COSA comincieranno. A me queste sparate da "risolviamo noi in un'attimo cio' che nella conoscenza 3D e' rimasto sempre un utopistica futura aspettativa decennale" mi sa di esagerazione paragonabile solo a quelle di Sony con la PS2.

sono completamente d'accordo

qui qualche ulteriore spiegazione di come larrabee differisce dalle gpu Nvidia e Ati:

The really interesting parts of the Larrabee presentation concerned the software and how Larrabee will run 3D games.

All previous real-time ray-tracing hype aside, Larrabee will run standard DirectX and OpenGL games using the same programmable rendering pipeline as traditional GPUs from NVIDIA and ATI. The difference, however, is that while traditional GPUs implement that rendering pipeline as an ordered series of hardware steps, some of which are individually programmable, Larrabee implements it entirely in software using a combination of general-purpose x86 cores and fixed-function hardware accelerators.

I've tried to illustrate this fundamental contrast in the two diagrams below. Figure 2 shows a traditional GPU with a fixed-function pipeline and two programmable stages (yellow and purple). The sequence of steps in the graphics pipeline is fixed, as is the amount of hardware dedicated to each stage. The data used to render the frame containing the tree is stored in memory, along with the programs for the two programmable stages.

Figure 3 shows Larrabee's approach, in which most of the pipeline is implemented in software that runs on the general-purpose x86 cores. What this means is that the sizes and even order of the rendering stages aren't fixed, so the rendering pipeline can be reconfigured dynamically from one moment to the next to match the game engine's needs by reallocating hardware resources. Steps can be skipped entirely if they're not needed, and other steps can be beefed up with extra hardware.

Figure 3 shows Larrabee's approach, in which most of the pipeline is implemented in software that runs on the general-purpose x86 cores. What this means is that the sizes and even order of the rendering stages aren't fixed, so the rendering pipeline can be reconfigured dynamically from one moment to the next to match the game engine's needs by reallocating hardware resources. Steps can be skipped entirely if they're not needed, and other steps can be beefed up with extra hardware.

http://arstechnica.com/news.ars/post...ntium-pro.html

[Simon82]

Originariamente inviato da appleroof

sono completamente d'accordo

qui qualche ulteriore spiegazione di come larrabee differisce dalle gpu Nvidia e Ati:

The really interesting parts of the Larrabee presentation concerned the software and how Larrabee will run 3D games.

All previous real-time ray-tracing hype aside, Larrabee will run standard DirectX and OpenGL games using the same programmable rendering pipeline as traditional GPUs from NVIDIA and ATI. The difference, however, is that while traditional GPUs implement that rendering pipeline as an ordered series of hardware steps, some of which are individually programmable, Larrabee implements it entirely in software using a combination of general-purpose x86 cores and fixed-function hardware accelerators.

I've tried to illustrate this fundamental contrast in the two diagrams below. Figure 2 shows a traditional GPU with a fixed-function pipeline and two programmable stages (yellow and purple). The sequence of steps in the graphics pipeline is fixed, as is the amount of hardware dedicated to each stage. The data used to render the frame containing the tree is stored in memory, along with the programs for the two programmable stages.

Figure 3 shows Larrabee's approach, in which most of the pipeline is implemented in software that runs on the general-purpose x86 cores. What this means is that the sizes and even order of the rendering stages aren't fixed, so the rendering pipeline can be reconfigured dynamically from one moment to the next to match the game engine's needs by reallocating hardware resources. Steps can be skipped entirely if they're not needed, and other steps can be beefed up with extra hardware.

Figure 3 shows Larrabee's approach, in which most of the pipeline is implemented in software that runs on the general-purpose x86 cores. What this means is that the sizes and even order of the rendering stages aren't fixed, so the rendering pipeline can be reconfigured dynamically from one moment to the next to match the game engine's needs by reallocating hardware resources. Steps can be skipped entirely if they're not needed, and other steps can be beefed up with extra hardware.

http://arstechnica.com/news.ars/post...ntium-pro.html

Rispondo (estremizzando/semplificando/ironizzando) con questi due flashback...


EnT&L -----> ...blablablablabla....

Verite 1000 Risc c/gpu -------> ...blablablablablabla...

[appleroof]

Originariamente inviato da Simon82

Rispondo (estremizzando/semplificando/ironizzando) con questi due flashback...


EnT&L -----> ...blablablablabla....

Verite 1000 Risc c/gpu -------> ...blablablablablabla...

ti vedo molto entusiasta riguardo Larrabee...

personalmente mi interessano 2 aspetti, uno persoanle ed un altro più generale: le prestazioni della "scheda" rispetto a quelle Nvidia e Ati (un'alternativa in più non può che farmi piacere ) e i riflessi di questa discesa in campo sull'intero scenario (che è quello di cui discutevamo su questo tread)

per il primo aspetto non mi sento di bollare Larrabee come fetecchia o come supersoluzione, aspetto di vederlo all'opera: non nascondo che sono abbastanza scettico sulle sue prestazioni con i giochi, almeno nella sua versione iniziale, ma d'altra parte non credo che Intel lanci la sua I alternativa ad Ati/Nvidia con un prodotto sottotono rispetto a quelli dei competitori...vediamo

[Simon82]

Originariamente inviato da appleroof

ti vedo molto entusiasta riguardo Larrabee...

personalmente mi interessano 2 aspetti, uno persoanle ed un altro più generale: le prestazioni della "scheda" rispetto a quelle Nvidia e Ati (un'alternativa in più non può che farmi piacere ) e i riflessi di questa discesa in campo sull'intero scenario (che è quello di cui discutevamo su questo tread)

per il primo aspetto non mi sento di bollare Larrabee come fetecchia o come supersoluzione, aspetto di vederlo all'opera: non nascondo che sono abbastanza scettico sulle sue prestazioni con i giochi, almeno nella sua versione iniziale, ma d'altra parte non credo che Intel lanci la sua I alternativa ad Ati/Nvidia con un prodotto sottotono rispetto a quelli dei competitori...vediamo

Mi interesserebbero "straeccome" ma quando si dice di voler emulare (perche' poi di questo si tratta) tutti gli stage con core x86 (quanti, quanto potenti, ma il codice x86 non era non adatto a questo genere di calcoli? ma e' possibile?) e' paragonabile solo a Grillo che dice che con la macchina da 100kg di peso e elettrica (era elettrica boh non ricordo) si puo' girare il mondo come con una macchina normale.... e si risparmia!

Poi magari si gira con il Cayenne... pero'...

[appleroof]

Originariamente inviato da Simon82

Mi interesserebbero "straeccome" ma quando si dice di voler emulare (perche' poi di questo si tratta) tutti gli stage con core x86 (quanti, quanto potenti, ma il codice x86 non era non adatto a questo genere di calcoli? ma e' possibile?) e' paragonabile solo a Grillo che dice che con la macchina da 100kg di peso e elettrica (era elettrica boh non ricordo) si puo' girare il mondo come con una macchina normale.... e si risparmia!

Poi magari si gira con il Cayenne... pero'...

Lascia stare quello che dice Grillo, il suo unico merito è solo fare il rumore giusto a non far dormire la gente (che poi preferibilmente si fà una sua idea senza drograrsi di tiggì-a-busta-paga e talkshow-teatro alla portaaporta/matrix) , per il resto è solo un comico, mica il Messia (per la cronaca, si riferiva al motore ad idrogeno)

tornando a Larrabee, sono d'accordo sui rilievi "tecnici" e le tue sono le mie stesse perplessità....

[Simon82]

Originariamente inviato da appleroof

Lascia stare quello che dice Grillo, il suo unico merito è solo fare il rumore giusto a non far dormire la gente (che poi preferibilmente si fà una sua idea senza drograrsi di tiggì-a-busta-paga e talkshow-teatro alla portaaporta/matrix) , per il resto è solo un comico, mica il Messia (per la cronaca, si riferiva al motore ad idrogeno)

tornando a Larrabee, sono d'accordo sui rilievi "tecnici" e le tue sono le mie stesse perplessità....

Era solo per fare un esempio, preferisco non aprire ulteriore discussioni su certe persone se no non finisco piu.

Il problema di Intel pero' e' a mio parere elaborare un tipo di calcolo nato ed evolutosi proprio sulla attuale "staticita'" che nell'intervista di Intel veniva criticata circa gli attuali stage a livello hw. Il rendering funziona cosi' e farlo alla maniera di Intel, magari nel caso che il software agisca nel modo a lui piu' congegnale sarebbe anche prestazionalmente valido (migliore non so) ma devi sempre fare qualcosa che viene fatto cosi' da anni e anni e farlo alternativamente a mio occhio e' sempre una sorta di emulazione e laddove c'e' emulazione c'e' perdita di prestazioni, compatibilita' ecc ecc... magari ci riesce a mo' di PowerVR ma ci sono troppi interessi in gioco e alla fine e' tutto dato in mano alle software house.

[nAo]

Originariamente inviato da Simon82

Mi interesserebbero "straeccome" ma quando si dice di voler emulare (perche' poi di questo si tratta) tutti gli stage con core x86 (quanti, quanto potenti, ma il codice x86 non era non adatto a questo genere di calcoli? ma e' possibile?) e' paragonabile solo a Grillo che dice che con la macchina da 100kg di peso e elettrica (era elettrica boh non ricordo) si puo' girare il mondo come con una macchina normale.... e si risparmia!

Poi magari si gira con il Cayenne... pero'...

Larrabee adotta una nuova estensione del set di istruzioni x86 chiamato temporaneamente LRBni. MMX e SSE sono stati rimossi e LRBni e' molto diverso da quest'ultimi, e' molto piu' simile a quello che le GPU moderne offrono.
Siccome ogni core puo' eseguire 2 istruzioni per ciclo di clock una puo' essere una classica istruzione x86 mentre la seconda puo' essere una istruzione che opera su questi nuovi registri a 16 componenti in singola precisione o interi (o 8 componenti in doppia precisione).

Inoltre Larrabee ha una texture unit con 32kb di cache per core (che supporta virtual texturing, Carmack sara' contento..), cosa buona e' giusta dato che samplare e filtrare una texture non mappa molto bene su una CPU general purpose.

E' difficile sapere se in anticipo se avra' successo o meno e se sara' competitivo o meno, ma di sicuro e' qualcosa di molto interessante. Avendo scritto software rasterizer per anni sul mio avecchio amiga mi attizza l'idea di poterlo fare ancora su una architettura molto piu' avanzata.

Per quanto mi riguarda scommetto che la prima versione del chip sul mercato avra' almeno 32 core clockati ad almeno 2 Ghz -> 2 Teraflop/s

[Foglia Morta]

Ora potrebbero cominciare a fare solo chipset con video integrato...

[Kharonte85]

Una specie di hybrid da INTEL...Basta che non sia esclusivo per le GPU discrete di altre marche e potrebbe andare bene...


PS: certo che alla intel paiono dei mortaccioni guardando quella foto...

[Foglia Morta]

Originariamente inviato da Kharonte85

Una specie di hybrid da INTEL...Basta che non sia esclusivo per le GPU discrete di altre marche e potrebbe andare bene...

IMO quando avranno le loro schede grafiche sarà esclusiva della loro piattaforma

Originariamente inviato da Kharonte85

PS: certo che alla intel paiono dei mortaccioni guardando quella foto...

In effetti pare che abbiano il braccino corto a giudicare da quella foto . Però se i risultati finanziari gli danno ragione non gli si può dire nulla

[Simon82]

Sebbene apparentemente fuori dal contesto larrabee, interessante questa idea dello switch tra gpu su bus e integrata cosi' da risparmiare energia. Il contesto appare attuabile soprattutto nei notebook e nei dispositivi (umpc) che hanno gpu discrete che consumano troppa corrente. Effettivamente per l'uso 2D di Windows il sottosistema grafico dedicato sarebbe da spegnere proprio totalmente dal momento che basterebbe un sistema 2D integrato nei chipset a sostenere le richieste ormai palesi anche per le peggiori configurazioni.
Basti pensare che l'umpc che mi sono comprato ultimamente con cpu AMD Geode e sottosistema AMD con 2D integrato riesce perfettamente a sostenere tutto il lavoro grafico di Windows senza grosse difficolta, con un consumo totale davvero ridicolo paragonato a un computer desktop.

[Foglia Morta]

Posto qui perchè Intel ha investito dei soldini su LucidLogix: http://www.pcper.com/article.php?aid...e=expert&pid=1

Praticamente dividono il carico di lavoro in tasks e li distribuiscono alle gpu. Nel link c'è anche una scena che mostra come certe parti siano a carico di una gpu e altre parti a carico dell'altra.

La cosa migliore è che se le gpu hanno gli stessi driver si possono usare anche gpu diverse ( tipo RV670 + RV770 ) . Hydra divide il carico di lavoro in base alla potenza delle gpu ( in situazioni asimmetriche quindi potrebbe anche dare il 20% del lavoro ad una gpu che comunque l'impegnerebbe al massimo delle sue potenzialità e il restante 80% all'altra gpu che in teoria dovrebbe essere sempre impegnata efficientemente ). Quindi in caso di simmetria ( 2 4870 X2 o 3-4 GTX 280 ) promettono uno scaling lineare : se una gpu fa 100 fps , 2 gpu 200 fps , 3 faranno 300fps e così via...

Ci vogliono test per verificare l'attendibilità di ciò che dicono. IMO è interessante ma i test diranno tutto

[Simon82]

Ottimo se la ripartizione avviene a prescindere dalla volontà dello sviluppatore di supportare la cosa. Rimango comunque dell'idea che due schede video per il singolo scopo siano e sempre saranno scelte di nicchia di pochi appassionati facoltosi. E comprarne due dopo avrebbe poco senso se lo sviluppo delle api avviene con la stessa velocità.

[jok3r87]

Originariamente inviato da Foglia Morta

Posto qui perchè Intel ha investito dei soldini su LucidLogix: http://www.pcper.com/article.php?aid...e=expert&pid=1

Praticamente dividono il carico di lavoro in tasks e li distribuiscono alle gpu. Nel link c'è anche una scena che mostra come certe parti siano a carico di una gpu e altre parti a carico dell'altra.

La cosa migliore è che se le gpu hanno gli stessi driver si possono usare anche gpu diverse ( tipo RV670 + RV770 ) . Hydra divide il carico di lavoro in base alla potenza delle gpu ( in situazioni asimmetriche quindi potrebbe anche dare il 20% del lavoro ad una gpu che comunque l'impegnerebbe al massimo delle sue potenzialità e il restante 80% all'altra gpu che in teoria dovrebbe essere sempre impegnata efficientemente ). Quindi in caso di simmetria ( 2 4870 X2 o 3-4 GTX 280 ) promettono uno scaling lineare : se una gpu fa 100 fps , 2 gpu 200 fps , 3 faranno 300fps e così via...

Ci vogliono test per verificare l'attendibilità di ciò che dicono. IMO è interessante ma i test diranno tutto

Cosi dal microstuttering si passerà direttamente al lag vero è proprio, vedendo tutti i passaggi supplementari che questa tecnologia prevede...

[Foglia Morta]

Originariamente inviato da Simon82

Ottimo se la ripartizione avviene a prescindere dalla volontà dello sviluppatore di supportare la cosa. Rimango comunque dell'idea che due schede video per il singolo scopo siano e sempre saranno scelte di nicchia di pochi appassionati facoltosi. E comprarne due dopo avrebbe poco senso se lo sviluppo delle api avviene con la stessa velocità.

E soprattutto pare ( almeno sulla carta ) una valida all'alternativa all'AFR e SFR ( e pure al tile mi pare ).
Ma io penso che il futuro ci riservi schede grafiche multi-core ( fascia mainsream e performance ) e multi-core + multi-die ( per la fascia enthusiasth ) e Hydra potrebbe essere usata in maniera trasparente per l'utente finale nel caso vada sulla singola scheda grafica con più gpu.

Originariamente inviato da jok3r87

Cosi dal microstuttering si passerà direttamente al lag vero è proprio, vedendo tutti i passaggi supplementari che questa tecnologia prevede...

Dubbio legittimo ma nel link c'è scritto:

And according to Lucid all of this is done with virtually no CPU overhead and no latency compared to standard single GPU rendering

Quindi non ci resta che attendere i test per verificare ciò che promettono.