[Thread Ufficiale] Aspettando Larrabee

[Foglia Morta]

Graphics Coming Back to Intel Architecture: Interview with Intel Visual Computing Group

http://www.xbitlabs.com/articles/vid...interview.html

[appleroof]

la cosa che reputo più interessante in assoluto è questa:

X-bit labs: It is obvious that it is crucial to be the first with introduction of next-generation products. But it looks like Larrabee will not be the first DirectX 11 chip on the market. How do you plan to compete against rivals?

Nick Knupffer: We have not announced specific DirectX version support.However Larrabee features a software renderer, this means that supporting any API is simply a question of updating the driver.

in pratica tramite driver hai una vga pronta per dx10, dx11 dx12 ecc ecc...mi pare quasi una rivoluzione...peccato che ovviamente con il passare del tempo sarà la potenza di calcolo, in relazione ai giochi che si avvicenderanno, a costringere a cambiare vga (ma la chiameremo così Larrabee? ) e quindi siamo punto e a capo, almeno parlando strettamente di giochi

cmq, se sarà valida come alternativa, porterà sicuramente uno scossone al duopolio e se Nvidia e Ati reagiranno bene (non falliscono) noi ne avremo solo da beneficiarne...

[yossarian]

Originariamente inviato da appleroof

la cosa che reputo più interessante in assoluto è questa:

X-bit labs: It is obvious that it is crucial to be the first with introduction of next-generation products. But it looks like Larrabee will not be the first DirectX 11 chip on the market. How do you plan to compete against rivals?

Nick Knupffer: We have not announced specific DirectX version support.However Larrabee features a software renderer, this means that supporting any API is simply a question of updating the driver.

in pratica tramite driver hai una vga pronta per dx10, dx11 dx12 ecc ecc...mi pare quasi una rivoluzione...peccato che ovviamente con il passare del tempo sarà la potenza di calcolo, in relazione ai giochi che si avvicenderanno, a costringere a cambiare vga (ma la chiameremo così Larrabee? ) e quindi siamo punto e a capo, almeno parlando strettamente di giochi

cmq, se sarà valida come alternativa, porterà sicuramente uno scossone al duopolio e se Nvidia e Ati reagiranno bene (non falliscono) noi ne avremo solo da beneficiarne...

l'avevo anticipato circa 20 giorni fa

http://www.hwupgrade.it/forum/showthread.php?t=1870824
ultimo messaggio della pagina

le operazioni di scheduling at compile time rendono l'architettura di larrabee molto flessibile e adattabile alle richieste dei diversi SM. In più, rispetto all'arhcitettura dei chip ATi (in cui manca lo scheduler come nel progetto intel), in larrabee mancano anche le fixed pipeline (ad esempio le RBE) e solo le operazioni di texturing sono, in parte, affidate a delle fixed function. Le alu di larrabee sono unità ancora più generiche di quelle ATi o nVIDIA e svolgono anche molti calcoli che nelle gpu sono tradizionalmente svolte dalle fixed pipeline.

SM sta per shader model

ATi è a mezza via con le operazioni di scheduling via SW ma con ancora fixed function pipeline nelle rop's e nelle tmu (anche larrabee le avrà nelle tmu, a dire la verità).
nVIDIA, invece, ha scelto la direzione opposta: tutte le operazioni gestite in HW (maggior efficienza ma minor flessibilità e alu terribilmente grandi)

[Foglia Morta]

Originariamente inviato da yossarian

l'avevo anticipato circa 20 giorni fa

http://www.hwupgrade.it/forum/showthread.php?t=1870824
ultimo messaggio della pagina

le operazioni di scheduling at compile time rendono l'architettura di larrabee molto flessibile e adattabile alle richieste dei diversi SM. In più, rispetto all'arhcitettura dei chip ATi (in cui manca lo scheduler come nel progetto intel), in larrabee mancano anche le fixed pipeline (ad esempio le RBE) e solo le operazioni di texturing sono, in parte, affidate a delle fixed function. Le alu di larrabee sono unità ancora più generiche di quelle ATi o nVIDIA e svolgono anche molti calcoli che nelle gpu sono tradizionalmente svolte dalle fixed pipeline.

SM sta per shader model

ATi è a mezza via con le operazioni di scheduling via SW ma con ancora fixed function pipeline nelle rop's e nelle tmu (anche larrabee le avrà nelle tmu, a dir ela verità).
nVIDIA, invece, ha scelto la direzione opposta: tutte le operazioni gestite in HW (maggior efficienza ma minor flessibilità e alu terribilmente grandi)

La scelta in direzione opposta pare sia anti economica nel lungo periodo... quindi potrebbero anche cambiare totalmente l'architettura con le DX11 rinnegando le scelte fatte con GT200.

ps: non lo vuoi dire ma IMO anche tu sei dell'opinione che RV740 avrà 640 alu

[yossarian]

Originariamente inviato da Foglia Morta

La scelta in direzione opposta pare sia anti economica nel lungo periodo... quindi potrebbero anche cambiare totalmente l'architettura con le DX11 rinnegando le scelte fatte con GT200.

ps: non lo vuoi dire ma IMO anche tu sei dell'opinione che RV740 avrà 640 alu

e, magari, sarà anche dx11

Un cambio di architettura comportarebbe tempi lunghissimi e spese ingenti.

[Foglia Morta]

Originariamente inviato da yossarian

e, magari, sarà anche dx11

Qualcuno di AMD parlando del gpgpu aveva detto che nel Q1 2009 avrebbero avuto una gpu più adeguata. E per esser adeguata secondo AMD significa che deve supportare Opencl e DX11 . Sarebbe bello ma sinceramente faccio fatica a crederci

Originariamente inviato da yossarian

Un cambio di architettura comportarebbe tempi lunghissimi e spese ingenti.

Se non cambiano radicalmente architettura allora vuol dire che quella caratteristica dello shader core di GT200 di cui non volevi parlare mesi fa è uno step eovolutivo importante in direzione DX11 .

[yossarian]

Originariamente inviato da Foglia Morta

Qualcuno di AMD parlando del gpgpu aveva detto che nel Q1 2009 avrebbero avuto una gpu più adeguata. E per esser adeguata secondo AMD significa che deve supportare Opencl e DX11 . Sarebbe bello ma sinceramente faccio fatica a crederci

anche io faccio fatica a credere che esca un'architettura che esponga le dx11 nel Q1 2009

Originariamente inviato da Foglia Morta

Se non cambiano radicalmente architettura allora vuol dire che quella caratteristica dello shader core di GT200 di cui non volevi parlare mesi fa è uno step eovolutivo importante in direzione DX11 .

parli delle alu fp64? Non serviranno per i giochi, ma sicuramente per il gpgpu (infatti il supporto di G8x e derivati è incompleto e utile ad un numero limitato di applicazioni).

[Foglia Morta]

Originariamente inviato da yossarian

anche io faccio fatica a credere che esca un'architettura che esponga le dx11 nel Q1 2009

quindi sarebbe solo questione di attendere l'uscita delle DX11 e relativi driver ATi.

Originariamente inviato da yossarian

parli delle alu fp64? Non serviranno per i giochi, ma sicuramente per il gpgpu (infatti il supporto di G8x e derivati è incompleto e utile ad un numero limitato di applicazioni).

No altro ancora... parlando di GT200 io avevo detto che l'unica novità dello shader core di GT200 rispetto a G92 erano le alu fp64 . Tu , se ricordo bene , avevi detto che c'era dell'altro e non potevi parlarne

[appleroof]

Originariamente inviato da yossarian

l'avevo anticipato circa 20 giorni fa

http://www.hwupgrade.it/forum/showthread.php?t=1870824
ultimo messaggio della pagina

le operazioni di scheduling at compile time rendono l'architettura di larrabee molto flessibile e adattabile alle richieste dei diversi SM. In più, rispetto all'arhcitettura dei chip ATi (in cui manca lo scheduler come nel progetto intel), in larrabee mancano anche le fixed pipeline (ad esempio le RBE) e solo le operazioni di texturing sono, in parte, affidate a delle fixed function. Le alu di larrabee sono unità ancora più generiche di quelle ATi o nVIDIA e svolgono anche molti calcoli che nelle gpu sono tradizionalmente svolte dalle fixed pipeline.

SM sta per shader model

ATi è a mezza via con le operazioni di scheduling via SW ma con ancora fixed function pipeline nelle rop's e nelle tmu (anche larrabee le avrà nelle tmu, a dire la verità).
nVIDIA, invece, ha scelto la direzione opposta: tutte le operazioni gestite in HW (maggior efficienza ma minor flessibilità e alu terribilmente grandi)

me l'ero perso

dunque, saresti d'accordo con il dire che Larrabee (parliamo di quello in questo tread no? ), pur essendo enormemente più flessibile di Ati e Nvidia, all'atto pratico non porta alcun vantaggio all'utente finale?

Insomma, quello di essere una "scheda" pronta per qualsiasi libreria grafica è un vantaggio solo virtuale, perchè con il passare del tempo l'utente sarebbe comunque costretto a cambiare vga per la limitata potenza di calcolo non più al passo con le richieste dei giochi....come la vedi? (imho Larrabee stà diventando per me la più interessante novità all'orizzonte, molto più delle nuove Ati o Nvidia )

[yossarian]

Originariamente inviato da Foglia Morta

quindi sarebbe solo questione di attendere l'uscita delle DX11 e relativi driver ATi.



No altro ancora... parlando di GT200 io avevo detto che l'unica novità dello shader core di GT200 rispetto a G92 erano le alu fp64 . Tu , se ricordo bene , avevi detto che c'era dell'altro e non potevi parlarne

'sta cosa non me la ricordo proprio. C'è qualcosa di cui non si è parlato; ad esempio, la possibilità teorica di accelerare alcune operazioni in fp32 utilizzando le alu fp64 (una sorta di SFU che in G8x manca). Si tratta di una feature per ora solo su carta, non esposta neppure in CUDA (potrebbe rischiare di fare il paio con la MUL mancante di G8x, però). Ma non ha nulla a che fare con le dx11

[Foglia Morta]

Originariamente inviato da yossarian

'sta cosa non me la ricordo proprio. C'è qualcosa di cui non si è parlato; ad esempio, la possibilità teorica di accelerare alcune operazioni in fp32 utilizzando le alu fp64 (una sorta di SFU che in G8x manca). Si tratta di una feature per ora solo su carta, non esposta neppure in CUDA (potrebbe rischiare di fare il paio con la MUL mancante di G8x, però). Ma non ha nulla a che fare con le dx11

allora forse non si trattava di una novità relativa allo shader core ma che riguardava altro ancora. Terrò appunti delle quest insolute così al momento opportuno te le riproporrò

[yossarian]

Originariamente inviato da appleroof

me l'ero perso

dunque, saresti d'accordo con il dire che Larrabee (parliamo di quello in questo tread no? ), pur essendo enormemente più flessibile di Ati e Nvidia, all'atto pratico non porta alcun vantaggio all'utente finale?

come no: ho un avga dx11 top oggi che diventa una dx11.1 o dx12 mainstream domani

Originariamente inviato da appleroof

me l'ero perso
Insomma, quello di essere una "scheda" pronta per qualsiasi libreria grafica è un vantaggio solo virtuale, perchè con il passare del tempo l'utente sarebbe comunque costretto a cambiare vga per la limitata potenza di calcolo non più al passo con le richieste dei giochi....come la vedi? (imho Larrabee stà diventando per me la più interessante novità all'orizzonte, molto più delle nuove Ati o Nvidia )

facili battute a parte, il grande salto verso le architetture unificate c'è stato e nelle fasi di transizione non è la potenza che difetta. R580 aveva una capacità di calcolo teorica comparabile a quella di G80 e su applicazioni dx9 non di rado si avvicinava alla 8800 320 Mb. Il problema è che non era compatibile con le nuove librerie. Con larrabee il problema della compatibilità sarà molto meno sentito. Certo, chi cambia spesso vga per avere sempre il top, sarà del tutto indifferente a questa possibilità. Per chi è abituato a tenere a lungo la popria scheda video, può essere un vantaggio avere, comunque, la compatibilità con le ultime api (anche se non la massima fluidità).
Questo è un aspetto molto interessante, anche per le SWHouse ed i produttori di HW: hai il vantaggio di lavorare su un'architettura che nel tempo non subisce grossi stravolgimenti se non, magari, nella potenza di calcolo; questo rende più semplici le ottimizzazioni.
Da questo punto di vista, l'approccio di intel può costituire un punto di svolta, accelerando, magari, anche la transizione da parte di amd verso gpu sempre più versatili e flessibili. L'adozione di filtri di tipo custom può spingere in questa direzione

[Athlon 64 3000+]

Interessante l'architettura Intel.
Più che altro sono curioso di sapere se RV870 uscirà veramente a fine 2009 e se per periodo Laberlee sarà gia fuori.

[Foglia Morta]

Originariamente inviato da yossarian

facili battute a parte, il grande salto verso le architetture unificate c'è stato e nelle fasi di transizione non è la potenza che difetta. R580 aveva una capacità di calcolo teorica comparabile a quella di G80 e su applicazioni dx9 non di rado si avvicinava alla 8800 320 Mb. Il problema è che non era compatibile con le nuove librerie. Con larrabee il problema della compatibilità sarà molto meno sentito. Certo, chi cambia spesso vga per avere sempre il top, sarà del tutto indifferente a questa possibilità. Per chi è abituato a tenere a lungo la popria scheda video, può essere un vantaggio avere, comunque, la compatibilità con le ultime api (anche se non la massima fluidità).
Questo è un aspetto molto interessante, anche per le SWHouse ed i produttori di HW: hai il vantaggio di lavorare su un'architettura che nel tempo non subisce grossi stravolgimenti se non, magari, nella potenza di calcolo; questo rende più semplici le ottimizzazioni.
Da questo punto di vista, l'approccio di intel può costituire un punto di svolta, accelerando, magari, anche la transizione da parte di amd verso gpu sempre più versatili e flessibili. L'adozione di filtri di tipo custom può spingere in questa direzione

PRO: possono accelerare di parecchio l'adozione di nuove api da parte delle software house, soprattutto se una gpu Intel sarà adottata da una console con un certo successo commerciale.

Contro: mi pare che sia anche la scelta ideale per Microsoft con la console che succederà la 360. Già Intel è piuttosto influente, se dovesse anche avere una gpu su una console la vedo triste per i suoi competitor.

[Foglia Morta]

http://www.hpcwire.com/blogs/Larrabe...-36336839.html

Larrabee for HPC: Not So Fast

For those of you who thought Intel was angling for an HPC play with its upcoming Larrabee processor family, think again. In case you're not a regular reader of this publication, Larrabee is Intel's manycore x86 GPU-like processor scheduled to debut in late 2009 or early 2010. With Larrabee, Intel is gearing up to challenge NVIDIA and AMD for GPU leadership, but doesn't appear interested in exploiting the chip for GPGPU.

Although the company has engaged in some mixed messaging with regard to Larrabee, recent conversations with Richard Dracott, the general manager of the Intel's high performance computing business unit, and Stephen Wheat, Intel's senior director of HPC, has convinced me that Larrabee will be targeted only for standard graphics applications and the more generalized visual computing realm. The latter does overlap into the HPC space, inasmuch as visual computing encompasses applications like video rendering and other types of compute-intensive image processing. But for general-purpose HPC, Intel has other designs in mind.

My first hint that Larrabee was being more narrowly targeted came from a recent chat with Dracott at the Wall Street on HPC Conference, where he talked about how the CPU will eventually prevail over accelerator offload engines (GPUs, FPGAs, Cell-type processors and FP ASICs), which I wrote about back in September. His basic point was that CPUs offered a better long-term value proposition than accelerators because industry standard processors like the x86 offer lower and more predictable software development costs. Also, any performance advantage demonstrated by an accelerator would eventually erode as CPUs continued to evolve -- a dubious assumption, I thought, since GPUs and FPGAs are evolving at least as quickly as CPUs. From his perspective, though, a relatively small number of HPC users would continue to experiment with acceleration over the next several years, but would eventually return to the comfort of the CPU.

What I didn't mention from that conversation is that while Dracott was trash talking accelerators, he also managed to diss Larrabee -- at least as a scientific computing architecture. Although Larrabee would at least offer an x86 compatible ISA, the problem, he said, was that the implementation contains some of the same drawbacks as the traditional GPU for scientific computing -- namely the lack of ECC memory to protect against soft errors and a shortage of double precision floating point capability. From his perspective that would prevent Larrabee or GPUs to be deployed more generally in high performance computing, "But," Dracott added, "we are working on products that will meet that need."

At this point, the nature of those products is a mystery. But Dracott did offer that "it will be feasible to have products that combine small IA cores and large IA cores that would be more suited for some HPC workloads." To speculate a bit, the architecture will likely have many of the attributes of Larrabee, that is, a manycore x86 architecture with fully coherent L1 and L2 caches. At least some of those cores will contain wide SIMD units similar to the Larrabee design, but those units will support lots of 64-bit floating point horsepower and be fully IEEE 754 compliant. Also, instead of GDDR-type memory, ECC-capable DDR memory will be supported. In short, it would be an x86 vector processor.

When I talked with Stephen Wheat at the Supercomputing Conference in Austin last month, he reiterated Dracott's (and Intel's) CPU-centric view of the universe. Wheat suggested that if accelerator features, like vector processing, become more widely used, they will naturally migrate onto the CPU. There is historical precedence for such a position. Before the 80486 chip, floating point operations were performed in external coprocessors (the x87 series). In the late 80s Intel decided FP operations were general-purpose enough to warrant transistor space on the CPU.

The rationale behind feature integration is that it's difficult to have different silicon engines move forward individually and maintain a balanced performance profile without being tied to a unified architecture. This dovetails nicely with Intel's business strategy, in which the x86 CPU ISA is the common denominator in all IT sectors -- desktop, mobile, enterprise, HPC, and, if Larrabee is successful, gaming and visualization.

So is now the time for heavy-duty vector processing to be integrated as well? "It's not that far in the future where the things that make these [accelerators] attractive can become an integral part of the processor itself," offered Wheat.

The market for this family of chips is not necessarily going to be driven by server-based HPC. Intel has a whole strategy around model-based computing, called RMS (PDF), which requires teraflops a-plenty. RMS encompasses a range of advanced apps from real-time rendering to portfolio management, and some of these will be running on desktop and mobile platforms.

The company is already starting to build a software foundation for such applications with Intel Parallel Studio. Released as a beta this week, Intel Parallel Studio is a suite of tools and libraries for Windows C/C++ developers that supports Threading Building Blocks (TBB), OpenMP, auto-vectorization and other parallel programming goodies. It is built around the concept of "forward scaling," Intel's nomenclature for automatic application scaling for multicore/manycore architectures.

The idea is that the same programs that are initially built for quad-core Nehalems can transparently scale up to 8-core Nehalems, manycore Larrabees, and all their descendents. Intel's research language for manycore throughput computing, Ct, will probably get productized into the company's software offerings at some point as these manycore products start to hit the streets. If all goes according to plan, by 2015 manycore x86 will be the dominant processor species and parallel programming will be the norm.

[appleroof]

Originariamente inviato da yossarian

come no: ho un avga dx11 top oggi che diventa una dx11.1 o dx12 mainstream domani



facili battute a parte,

ok. allora la vedi come me

Originariamente inviato da yossarian

il grande salto verso le architetture unificate c'è stato e nelle fasi di transizione non è la potenza che difetta. R580 aveva una capacità di calcolo teorica comparabile a quella di G80 e su applicazioni dx9 non di rado si avvicinava alla 8800 320 Mb. Il problema è che non era compatibile con le nuove librerie. Con larrabee il problema della compatibilità sarà molto meno sentito. Certo, chi cambia spesso vga per avere sempre il top, sarà del tutto indifferente a questa possibilità. Per chi è abituato a tenere a lungo la popria scheda video, può essere un vantaggio avere, comunque, la compatibilità con le ultime api (anche se non la massima fluidità).
Questo è un aspetto molto interessante, anche per le SWHouse ed i produttori di HW: hai il vantaggio di lavorare su un'architettura che nel tempo non subisce grossi stravolgimenti se non, magari, nella potenza di calcolo; questo rende più semplici le ottimizzazioni.
Da questo punto di vista, l'approccio di intel può costituire un punto di svolta, accelerando, magari, anche la transizione da parte di amd verso gpu sempre più versatili e flessibili. L'adozione di filtri di tipo custom può spingere in questa direzione

in che senso? e per Nvidia come la vedi?

Per il resto si aprono scenari molto molto interessanti per le ripercussioni su Ati e Nvidia...

[yossarian]

Originariamente inviato da appleroof

in che senso? e per Nvidia come la vedi?

Per il resto si aprono scenari molto molto interessanti per le ripercussioni su Ati e Nvidia...

RV770 è vliw; intel ha molta esperienza di architetture parallele vliw ed epic (itanium, ad esempio); in larrabee sarà il compilatore a gestire le operazioni di scheduling o, almeno, buona parte di esse (esiste una differenza tra vliw, vliw dinamico ed epic, sotto questo profilo). Quindi, come puoi capire, le similitudini sono molte. In rv770, però, le operazioni di rasterizzazione sono gestite da pipeline non programmabili. Questo limita la flessibilità del chip. Larrabee gestirà anche le operazioni delle rop's attraverso unità programmabili.
nVIDIA ha scelto la strada opposta: chip interamente gestito in HW di tipo superscalare, con elevata efficienza architetturale, ma quasi nulla flessibilità (lo dimostra anche il fatto che non sono riusciti ad implementare le dx10.1 nel passaggio da g80 a gt200, così come il fatto di aver dovuto far ricorso ad alu fisiche per implementare i calcoli a fp64 su gt200). La mancata adozione delle dx10.1 non è stata una scelta libera m,a obbligata: adottarle avrebbe significato modificare buona parte dell'architettura del chip, per poi modificarla di nuovo per le dx11.

[appleroof]

Originariamente inviato da yossarian

RV770 è vliw; intel ha molta esperienza di architetture parallele vliw ed epic (itanium, ad esempio); in larrabee sarà il compilatore a gestire le operazioni di scheduling o, almeno, buona parte di esse (esiste una differenza tra vliw, vliw dinamico ed epic, sotto questo profilo). Quindi, come puoi capire, le similitudini sono molte.

si..

Originariamente inviato da yossarian

In rv770, però, le operazioni di rasterizzazione sono gestite da pipeline non programmabili. Questo limita la flessibilità del chip. Larrabee gestirà anche le operazioni delle rop's attraverso unità programmabili.
nVIDIA ha scelto la strada opposta: chip interamente gestito in HW di tipo superscalare, con elevata efficienza architetturale, ma quasi nulla flessibilità (lo dimostra anche il fatto che non sono riusciti ad implementare le dx10.1 nel passaggio da g80 a gt200, così come il fatto di aver dovuto far ricorso ad alu fisiche per implementare i calcoli a fp64 su gt200). La mancata adozione delle dx10.1 non è stata una scelta libera m,a obbligata: adottarle avrebbe significato modificare buona parte dell'architettura del chip, per poi modificarla di nuovo per le dx11.

ok...ma la domanda che mi pongo è se l'entrata in scena di Larrabee con le caratteristiche da te elencate (come sempre in maniera chiara ed esaustiva anche se son concetti che ai non tecnici come me risultano ostici) non "costringa" Nvidia a rivedere completamente i propri progetti futuri (certo per le vga dx11 ormai la vedo durissima)

[yossarian]

Originariamente inviato da appleroof

si..



ok...ma la domanda che mi pongo è se l'entrata in scena di Larrabee con le caratteristiche da te elencate (come sempre in maniera chiara ed esaustiva anche se son concetti che ai non tecnici come me risultano ostici) non "costringa" Nvidia a rivedere completamente i propri progetti futuri (certo per le vga dx11 ormai la vedo durissima)

non credo: nVIDIA ha scelto la sua strada e difficilmente farà retromarcia. Sconfessare il porgetto G80 sarebbe ammetterne il fallimento. E sarebbe sbagliato e dannoso, considerato ciò che si investe in un progetto a livello di tempo e soldi. Ciò che può fare un'architettura superscalare può farlo anche una epic o una vliw: in maniera diversa, ovviamente e, a seconda, dell'applicazione, con risultati differenti. Ma non in misura take da poter dire che una scelta è sbagliata e l'altra è giusta. Si tratta di scelte progettuali diverse. L'unica cosa che, secondo me, rischia di penalizzare nVIDIA, è la decisione di restare aggrappati all'idea del chippone monolitico, a causa degli enormio costi e delle bassissime rese produttive. Certo, un'architettura superscalare è molto più rigida, ha alu più grandi (molto più grandi) e complesse e questo significa molta meno potenza teorica a parità di superficie; ma è anche più efficiente e permette di sfruttare quasi al massimo la potenza a disposizione, cosa che una epic o una vliw permettono di fare solo a condizione di fare un grosso lavoro di ottimizzazione sui driver e sulle applicazioni.

[appleroof]

Originariamente inviato da yossarian

non credo: nVIDIA ha scelto la sua strada e difficilmente farà retromarcia. Sconfessare il porgetto G80 sarebbe ammetterne il fallimento. E sarebbe sbagliato e dannoso, considerato ciò che si investe in un progetto a livello di tempo e soldi. Ciò che può fare un'architettura superscalare può farlo anche una epic o una vliw: in maniera diversa, ovviamente e, a seconda, dell'applicazione, con risultati differenti. Ma non in misura take da poter dire che una scelta è sbagliata e l'altra è giusta. Si tratta di scelte progettuali diverse. L'unica cosa che, secondo me, rischia di penalizzare nVIDIA, è la decisione di restare aggrappati all'idea del chippone monolitico, a causa degli enormio costi e delle bassissime rese produttive. Certo, un'architettura superscalare è molto più rigida, ha alu più grandi (molto più grandi) e complesse e questo significa molta meno potenza teorica a parità di superficie; ma è anche più efficiente e permette di sfruttare quasi al massimo la potenza a disposizione, cosa che una epic o una vliw permettono di fare solo a condizione di fare un grosso lavoro di ottimizzazione sui driver e sulle applicazioni.

perfetto, tutto chiarissimo...l'unica cosa che mi sento di "appuntare" è l'accenno all' "ammettere il fallimento di g80": non sarebbe un fallimento perchè parliamo (in ipotesi) semplicemente di un'architettura nuova per delle nuove librerie (certo molto più affini alle precedenti, sia hw che sw, che le dx10 rispetto alle dx9)....per fare una battuta non è che G80 abbia rappresentato l'ammettere il fallimento di G70

cmq per tornare in topic i limiti che indicavi (in neretto) saranno ancora più evidenti in larrabee, sulla carta, almeno mi pare di capire....