Tim Sweeney aveva capito tutto 10 anni fa

[lowenz]

Fa un po' venire i brividi (o ho dormito scoperto? ) leggere queste parole del 1999

http://arstechnica.com/articles/paed...-interview.ars

"Inflection point" is a much abused word these days, but if it's appropriate anywhere, then it's appropriate for describing the moment in the history of computing that we're rapidly approaching. It's a moment in which the shift to many-core hardware and multithreaded programming has quite literally broken previous paradigms for understanding the relationship between hardware and software, and the industry hasn't yet sorted out which new paradigms will replace the old ones.

Importantly, the entire computing industry won't pass through this inflection point all at once; it will happen at different times in different markets, as Moore's Law increases core and thread counts for different classes of processors. The first type of device to pass this inflection point will be the GPU, as it goes from being a relatively specialized, function-specific coprocessor to a much more generally programmable, data-parallel device. When the GPU has fully made that shift, game developers will have the opportunity to rethink real-time 3D rendering from the ground up.

For Tim Sweeney, co-founder of Epic Games and the brains behind every iteration of the widely licensed Unreal series of 3D game engines, this inflection point has been a long time coming. Back when Unreal 1 was still in stores and the 3Dfx Voodoo owned the nascent discrete 3D graphics market, Sweeney was giving interviews in which he predicted that rendering would eventually return to the CPU. Take a 1999 interview with Gamespy, for instance, in which he lays out the future timeline for the development of 3D game rendering that has turned out to be remarkably prescient in hindsight:

2006-7: CPU's become so fast and powerful that 3D hardware will be only marginally beneficial for rendering, relative to the limits of the human visual system, therefore 3D chips will likely be deemed a waste of silicon (and more expensive bus plumbing), so the world will transition back to software-driven rendering. And, at this point, there will be a new renaissance in non-traditional architectures such as voxel rendering and REYES-style microfacets, enabled by the generality of CPU's driving the rendering process. If this is a case, then the 3D hardware revolution sparked by 3dfx in 1997 will prove to only be a 10-year hiatus from the natural evolution of CPU-driven rendering.

Sweeney was off by at least two years, but otherwise it appears more and more likely that he'll turn out to be correct about the eventual return of software rendering and the death of the GPU as a fixed-function coprocessor. Intel's forthcoming Larrabee product will be sold as a discrete GPU, but it is essentially a many-core processor, and there's little doubt that forthcoming Larrabee competitors from NVIDIA and ATI will be similarly programmable, even if their individual cores are simpler and more specialized.

At NVIDIA's recent NVISION conference, Sweeney sat down with me for a wide-ranging conversation about the rise and impending fall of the fixed-function GPU, a fall that he maintains will also sound the death knell for graphics APIs like Microsoft's DirectX and the venerable, SGI-authored OpenGL. Game engine writers will, Sweeney explains, be faced with a C compiler, a blank text editor, and a stifling array of possibilities for bending a new generation of general-purpose, data-parallel hardware toward the task of putting pixels on a screen.
Goodbye, graphics APIs

JS: I'd like to chat a little bit about Larrabee and software rendering. I'm sure you're NDA'd on it, but Intel just did a pretty substantial reveal so we can talk in more detail about it. So first off, I'm wondering if you're looking at any of the Larrabee native stuff. What do you think about the prospects of this whole idea of not doing Direct3D or OpenGL, but writing directly to Larrabee's micro-OS?

TS: I expect that in the next generation we'll write 100 percent of our rendering code in a real programming language—not DirectX, not OpenGL, but a language like C++ or CUDA. A real programming language unconstrained by weird API restrictions. Whether that runs on NVIDIA hardware, Intel hardware or ATI hardware is really an independent question. You could potentially run it on any hardware that's capable of running general-purpose code efficiently.

JS: So you guys are just going to skip these graphics APIs entirely?

TS: That's my expectation. Graphics APIs only make sense in the case where you have some very limited, fixed-function hardware underneath the covers. It made perfect sense back with the 3Dfx Voodoo and the first NVIDIA cards, and the very first GeForces, but now that you have completely programmable shaders, the idea that you divide your scene up into triangles rendered in a certain order to a large framebuffer using fixed-function rasterizer features is really an anachronism. With all that general hardware underneath, why do you want to render scenes that way when you have more interesting possibilities available?

[Mercuri0]

Originariamente inviato da lowenz

Fa un po' venire i brividi (o ho dormito scoperto? ) leggere queste parole del 1999

2006-7: CPU's become so fast and powerful that 3D hardware will be only marginally beneficial for rendering, relative to the limits of the human visual system, therefore 3D chips will likely be deemed a waste of silicon (and more expensive bus plumbing), so the world will transition back to software-driven rendering. And, at this point, there will be a new renaissance in non-traditional architectures such as voxel rendering and REYES-style microfacets, enabled by the generality of CPU's driving the rendering process. If this is a case, then the 3D hardware revolution sparked by 3dfx in 1997 will prove to only be a 10-year hiatus from the natural evolution of CPU-driven rendering.[/b]

A me non fa venire i brividi, perché la profezia non s'è avverata: le CPU di oggi non sono affatto sufficientemente potenti per fare il software rendering.

Probabilmente Twilight ha ciccato perché proprio intorno al 2001 le CPU hanno raggiunto "il muro di consumi" e la curva di evoluzione della loro capacità di calcolo si è appiattita in maniera drammatica rispetto a una stima lineare.

Quello che sta succedendo invece è che le GPU sono diventate più general purpose e con meno hardware specializzato. Però persino Larrabee dovrà avere hardware specializzato se vuole fare rendering, e persino Larrabee non sarà "general purpose" quanto lo sono le attuali CPU... ma questo è un altro discorso.

[lowenz]

Le GPU sono CPU quasi a tutti gli effetti ora, quindi IMHO la profezia si è avverata.

[yossarian]

Originariamente inviato da Mercuri0

A me non fa venire i brividi, perché la profezia non s'è avverata: le CPU di oggi non sono affatto sufficientemente potenti per fare il software rendering.

Probabilmente Twilight ha ciccato perché proprio intorno al 2001 le CPU hanno raggiunto "il muro di consumi" e la curva di evoluzione della loro capacità di calcolo si è appiattita in maniera drammatica rispetto a una stima lineare.

Quello che sta succedendo invece è che le GPU sono diventate più general purpose e con meno hardware specializzato. Però persino Larrabee dovrà avere hardware specializzato se vuole fare rendering, e persino Larrabee non sarà "general purpose" quanto lo sono le attuali CPU... ma questo è un altro discorso.

non è neppure vero che le GPU sono diventate enormi con aggravio di costi e spreco di metallizzazioni, o meglio, è vero solo in parte (i chip nVIDIA presentano queste caratteristiche) ma non vale per i chip ATi. Con RV670 prima ed RV770 in seguito, si è avuta un'inversione di tendenza rispetto a quanto visto con la serie R5x0 e precedenti e si sta virando verso il multigpu con core piccoli ed economici.

[Mercuri0]

Originariamente inviato da lowenz

Le GPU sono CPU quasi a tutti gli effetti ora

Mica tanto

Comunque secondo me in futuro si continuerà a programmare su DirectX, OpenGL e prossimamente OpenCL, ma con l'importante differenza che queste si trasformeranno progressivamente da API in "Virtual Machine con Just in Time Compiler" alla Java, in modo che il codice custom scritto dai programmatori giri su qualsiasi hardware di quella categoria.

Già mi sa non sono troppo distanti, gli shaders funzionano così, no?
(non che sia esperto)

Originariamente inviato da yossarian

(i chip nVIDIA presentano queste caratteristiche)

Suvvia yossy tutti riconosciamo ad AMD di aver fatto un eccellente lavoro con RV770, ma non si può dire che il chip di nVidia sia inefficiente, perché il TDP dei due è della stessa classe, e ormai il TDP conta più dell'area come parametro di efficienza. (e di "grossezza")

Senza comunque togliere il grande vantaggio di RV770: i costi. (l'area, appunto)


p.s. c'è da dire che su Beyond3d stavano speculando che nVidia volesse togliere le unità di calcolo a precisione doppia su i chip futuri non destinati al GPGPU...

[yossarian]

Originariamente inviato da lowenz

Le GPU sono CPU quasi a tutti gli effetti ora, quindi IMHO la profezia si è avverata.

direi di no; al momento si può parlare di convergenza cpu-gpu, a dir la verità più di gpu che convergono verso le cpu (ma non sono amcora cpu), anche se con larrabee avremo anche una cpu con funzionalità tipiche di una gpu.
Ma, al momento, tranne che in alcuni ambiti specifici, cpu e gpu sono ancora due cose distinte con compiti differenti e proprie peculiarità architetturali

[lowenz]

Originariamente inviato da Mercuri0

p.s. c'è da dire che su Beyond3d stavano speculando che nVidia volesse togliere le unità di calcolo a precisione doppia su i chip futuri non destinati al GPGPU...

Beh è sensato, non è che serva poi tanto fuori dall'ambito scientifico/matematico.

[lowenz]

Originariamente inviato da yossarian

direi di no; al momento si può parlare di convergenza cpu-gpu, a dir la verità più di gpu che convergono verso le cpu (ma non sono amcora cpu), anche se con larrabee avremo anche una cpu con funzionalità tipiche di una gpu.
Ma, al momento, tranne che in alcuni ambiti specifici, cpu e gpu sono ancora due cose distinte con compiti differenti e proprie peculiarità architetturali

Mi riferivo anche io alla convergenza in fieri non certo una convergenza GIA' raggiunta

[Mercuri0]

Originariamente inviato da lowenz

Mi riferivo anche io alla convergenza in fieri non certo una convergenza GIA' raggiunta

Guarda, fieri o fdomani che sia, secondo me dire "La CPU diverrà tanto potente da poter fare rendering" e "La GPU diventerà sempre più programmabile" c'è una bella differenza.

Poi si sa, il bello delle profezie fatte bene è che sono sempre giuste negli occhi di chi legge

Originariamente inviato da lowenz

Beh è sensato, non è che serva poi tanto fuori dall'ambito scientifico/matematico.

Fino alla curva però, perché dovrebbe comunque mantenere due linee, e sopratutto perché sulle ATI c'è (probabilmente anche sulla 4650, per dire).

Se vuoi diffondere seriamente il GPGPU in campo consumer non puoi segmentare troppo le tue GPU per funzionalità, ti immagini che casino? Comunque era solo una speculazione tra le tante su beyond3d.

[yossarian]

Originariamente inviato da Mercuri0

Mica tanto


Suvvia yossy tutti riconosciamo ad AMD di aver fatto un eccellente lavoro con RV770, ma non si può dire che il chip di nVidia sia inefficiente, perché il TDP dei due è della stessa classe, e ormai il TDP conta più dell'area come parametro di efficienza. (e di "grossezza")

Senza comunque togliere il grande vantaggio di RV770: i costi. (l'area, appunto)


p.s. c'è da dire che su Beyond3d stavano speculando che nVidia volesse togliere le unità di calcolo a precisione doppia su i chip futuri non destinati al GPGPU...

infatti non ho parlato di efficienza, ma commentavo semplicemente l'affermazione di Sweeney circa il fatto che le gpu sarebbero diventate enormi con grande spreco di metallizzazioni: è evidente che non aveva preso in considerazione l'ipotesi del multigpu, poichè la sua affermazione sarebbe stata sicuramente valida solo per gpu di tipo monolitico (e non era una previsione difficile da fare neppure 10 anni fa considerato il trend secondo il quale la riduzione del processo produttivo non è in grado di compensare l'aumento di potenza richiesto e ciò si traduce in un aumento delle dimensioni del die.

In quanto all'ultima parte, è un'ipotesi da non trascurare e che permetterebbe di guadagnare spazio per allocare altre unità di calcolo o per ridurre le dimensioni degli attuali die (con conseguente riduzione dei costi di produzione). Questo a patto che rimanga sostanzialmente inalterata l'impostazione dell'architettura di G80 e GT200

[appleroof]

Originariamente inviato da yossarian

cut

In quanto all'ultima parte, è un'ipotesi da non trascurare e che permetterebbe di guadagnare spazio per allocare altre unità di calcolo o per ridurre le dimensioni degli attuali die (con conseguente riduzione dei costi di produzione). Questo a patto che rimanga sostanzialmente inalterata l'impostazione dell'architettura di G80 e GT200

tempo fà qualcuno sosteneva che per le dx11 sarebbero state necessarie esclusivamente unità di calcolo a precisione doppia....non so se è vero, al riguardo non ho torvato nulla...tu ne sai qualcosa? ( )

[yossarian]

Originariamente inviato da appleroof

tempo fà qualcuno sosteneva che per le dx11 sarebbero state necessarie esclusivamente unità di calcolo a precisione doppia....non so se è vero, al riguardo non ho torvato nulla...tu ne sai qualcosa? ( )

no
e comunque mi meraviglierebbe alquanto il fatto che si passi a fp64 obbligatorio (non opzionale, cioè) per i calcoli matematici, tenendo conto che ci sono ancora, ad oggi, con le dx10, operazioni di blending che permettono l'uso di INT8

[appleroof]

Originariamente inviato da yossarian

no
e comunque mi meraviglierebbe alquanto il fatto che si passi a fp64 obbligatorio (non opzionale, cioè) per i calcoli matematici, tenendo conto che ci sono ancora, ad oggi, con le dx10, operazioni di blending che permettono l'uso di INT8

capito, grazie