[Thread Ufficiale] Aspettando Bulldozer *leggere prima pagina con attenzione*

[riuzasan]

Originariamente inviato da gianni1879

Ho fatto un pò di pulizia, non capisco perchè si deve polemizzare appena si inserisce una notizia che non va a genio, non penso si devono scrivere solo le cose positive ed invece cestinare le notizie negative. Vanno semmai commentate ed eventualmente analizzate/smentite.

Paolo, scrat1702 e Marchigiano appena polemizzate ancora voi tre ed eventualmente altri che si aggiungeranno vi mando in esilio.

Ma non si era detto che di Llano, Trinity etc si parlava altrove?!?

[capitan_crasy]

Originariamente inviato da riuzasan

Ma non si era detto che di Llano, Trinity etc si parlava altrove?!?

Si ma solo per le versioni Mobile...

[digieffe]

Originariamente inviato da bs82

Siamo arrivati a un livello di ragionamenti su LLano che sto thread ormai potrebbe essere fuso con quello delle nuove GPU AMD che si baseranno su concetti di condivisione della memoria tra cpu e gpu, cache coerenti e costrutti x86 su gpu!

io trovo difficoltà a capire dove postare...

dovrei postare in un thread e poi postare nell'altro il link al precedente

io non parlo di fusione dei thread e sinceramente non saprei neanche come riorganizzare il tutto

certo è che ci sono degli argomenti che potrebbero andare in entrambi

es: iommu (quindi memoria condivisa tra cpu e apu), modalità di interazione tra cpu e gpu, ecc

Ps: non vuol essere una critica, ma soltanto fornire spunti di riflessione, tant'è, ribadisco, che io no ho idea di come eventualmente riorganizzare, spero in chi ha più esperienza nella gestione forum.

grazie

[affiu]

Originariamente inviato da gefri

ma pensando al futuro non prossimo, almeno in ambito amd, ci saranno solo apu? o il sistema migliore sarà sempre superprocio + vga high end?

una mia opinione

il fatto che ci possa essere un certo scetticismo,o nostalgia, il cercare di far ''convergere'' 2 tipi di hardware cosi diversi,secondo me ,non nasce dal voler essere alternativi o cercare di tamponare una mancanza di potenza offrendo prodotti piu equilibrati o ricambiati a favore di un altro componente,quanto piuttosto una esigenza imposta dal futuro,mi spiego meglio

il futuro che ci attende,si vuole o non si vuole,richiederà molta potenza ,ad esempio fra 3-4 anni qualsiasi contenuto web-video(es youtube,video giornalistici,video in generale) aumentera sempre piu verso l'alta definizione,quindi i contenuti saranno sempre piu pesanti sia da manipolare sia da spostare e dunque come si puo pensare che non servino processori PIU ADATTATI e seguenti l'evoluzione per poter affrontare questo cambiamento?

si puo pensare che possano bastare sempre piu core,ma a che consumo pero?l'evoluzioni dei giochi,l'aumento dei contenuti in 1080 (prima o poi saranno sempre di piu),per forza ci vuole un processore in grado di rispondere a questo bisogno.

in qualsiasi settore ci sono esempi di adattamento alle necessita(agricoltura,genetica,farmaci,ecc) impellenti,e quest'ultimo ne rappresenta lo stimolo,dunque perchè non pensare che anche l'hardware si appresta a cambiare e con esso anche i software?

puo darsi che mi sbagli ,ma piu si va avanti e piu un processore IBRIDO si dimostrera migliore ,nel senso di piu adattato e associato sempre al connubio

quantita di dati elaborati-consumo

[bs82]

Originariamente inviato da digieffe

io trovo difficoltà a capire dove postare...

dovrei postare in un thread e poi postare nell'altro il link al precedente

io non parlo di fusione dei thread e sinceramente non saprei neanche come riorganizzare il tutto

certo è che ci sono degli argomenti che potrebbero andare in entrambi

es: iommu (quindi memoria condivisa tra cpu e apu), modalità di interazione tra cpu e gpu, ecc

Ps: non vuol essere una critica, ma soltanto fornire spunti di riflessione, tant'è, ribadisco, che io no ho idea di come eventualmente riorganizzare, spero in chi ha più esperienza nella gestione forum.

grazie

Per carità qua si parla di CPU e la GPU .. però anche la mia frase era un segnale di come si sta evolvendo la situazione GRAZIE ad AMD...

Siamo di fronte a delle grosse novità future... e sembra che AMD in questi laghi ci sappia navigare bene!

LLano è solo il primo step, quell'architettura GPU presentata il secondo (condivisione dati in memoria)... il terzo step sarà il chippone unico capace di lavorare sia dati di un tipo che dell'altro.

[gianni1879]

per il momento le due discussioni sono separate altrimenti vien fuori un macello.
SE avete notizie strettamente per il reparto gpu dovete postare nell'altro thread altrimenti se riguarda entrambe postate in entrambi i thread.

[bjt2]

Originariamente inviato da floydbarber

Nell'articolo di Tom's è scritto questo riguardo a Llano:



Per me è appena comprensibile ma mi sembra quello di cui parli tu. E' così? Esiste già su Llano questa cosa?

Originariamente inviato da The3DProgrammer

http://mohamedfahmed.wordpress.com/2...py-approaches/

Fondamentalmente è come dice bjt2 (il vantaggio principale è quello che la CPU non dover passare dal bus PCI e per scrivere nel buffer della scheda video). Il resto, anche per non avere problemi con l'infrastruttura dei driver attuali, è praticamente uguale a prima (a parte forse la possibilita' della GPU di llano di andare a interrogare direttamente la L2)

L'approccio migliore sarebbe quello che ho detto io, ma attualmente (sopratutto il post del blog) sembra che sia ancora come il vecchio IGP, con l'ottimizzazione che la GPU ha accesso diretto alle caches delle CPU e i dati non passano sul bus PCI express... Addirittura sembra che la scrittura dei dati sulla memoria "locale" della GPU (che è comunque memoria RAM normale perchè è condivisa) debba passare per la GPU. Questo perchè i drivers sono ancora con il vecchio paradigma della memoria RAM dedicata... Però non mi è chiaro come a livello di driver video e kernel si possa evitare le copie: l'unico modo è che la RAM video possa essere mappata arbitrariamente sulla RAM fisica e sembra sia così visto che nel post del blog si parla di memoria virtuale sulla GPU... Se fosse così allora non ci sarebbe bisogno di fare copie, e già adesso si potrebbe sfruttare questo fatto in OpenCL e grafica...

In definitiva non si capisce se c'è o non c'è questo meccanismo. Certo è che lo spazio di indirizzamento non è ancora unificato e la memoria della GPU nonn è ancora coerente, quindi non può essere vista come un coprocessore, ma forse a livello di driver si possono evitare le copie, se è vero che la GPU ha una MMU (memoria virtuale).

Perchè?

Il classico meccanismo delle IGP prevedeva che tot MB di memoria FISICA venisse assegnata alla GPU/IGP. Sempre la stessa. Così se il mio programma deve sparare una texture, una mesh o una matrice per il calcolo GPGPU alla IGP, deve ricopiare i dati dalla memoria dedicata alla CPU su quella della GPU. Un vero spreco, ma questo passava il convento... Per evitare questo si dovrebbe fare due cose: una hardware e una software. Quella hardware è dotare la GPU di una MMU, per la memoria virtuale. E sembra che Llano l'abbia, da quel post di blog, ma non mi fiderei...

La seconda è software. Ma non è una questione banale, perchè si deve interagire a basso livello con il gestore della memoria e il kernel di windows... Questo perchè? Supponiamo che io voglia spedire una mesh, una texture o una matrice alla GPU. Per evitare la copia fisica dei dati, il driver video dovrebbe far in modo che il gestore della memoria di windows deallochi le pagine in cui sono contenuti i dati, senza cancellarli e ne deve prendere possesso la GPU, cambiando opportunamente le tabelle delle pagine nella MMU della GPU. Questo può essere tranquillamente fatto dal driver, ma la cosa diventa complicata dal punto di vista del kernel windows (ad esempio). Quella memoria risulterà allocata al driver video? Va nel kernel pool? (che è una risorsa preziosa in quanto limitato) Come è gestita? Insomma è una cosa complicata anche se fattibile già adesso...

[marchigiano]

Originariamente inviato da gianni1879

da questo momento in poi sono vietati discussioni su Llano MOBILE, aprite un'apposita discussione nell'apposita sezione e ne parlate là.

Quì siamo nella sezione PROCESSORI DESKTOP

mi autosospendo qualche giorno da questo thread per non essermi ricordato di questa regola e aver discusso dei processori mobile

intanto chiedo se è possibile citarli qui se si discute sul silicio, oppure è meglio aspettare le versioni desk?

[XB-J]

2 Slide di Gigabyte su Llano Desktop

[The3DProgrammer]

Originariamente inviato da bjt2

L'approccio migliore sarebbe quello che ho detto io, ma attualmente (sopratutto il post del blog) sembra che sia ancora come il vecchio IGP, con l'ottimizzazione che la GPU ha accesso diretto alle caches delle CPU e i dati non passano sul bus PCI express... Addirittura sembra che la scrittura dei dati sulla memoria "locale" della GPU (che è comunque memoria RAM normale perchè è condivisa) debba passare per la GPU. Questo perchè i drivers sono ancora con il vecchio paradigma della memoria RAM dedicata... Però non mi è chiaro come a livello di driver video e kernel si possa evitare le copie: l'unico modo è che la RAM video possa essere mappata arbitrariamente sulla RAM fisica e sembra sia così visto che nel post del blog si parla di memoria virtuale sulla GPU... Se fosse così allora non ci sarebbe bisogno di fare copie, e già adesso si potrebbe sfruttare questo fatto in OpenCL e grafica...

In definitiva non si capisce se c'è o non c'è questo meccanismo. Certo è che lo spazio di indirizzamento non è ancora unificato e la memoria della GPU nonn è ancora coerente, quindi non può essere vista come un coprocessore, ma forse a livello di driver si possono evitare le copie, se è vero che la GPU ha una MMU (memoria virtuale).

Perchè?

Il classico meccanismo delle IGP prevedeva che tot MB di memoria FISICA venisse assegnata alla GPU/IGP. Sempre la stessa. Così se il mio programma deve sparare una texture, una mesh o una matrice per il calcolo GPGPU alla IGP, deve ricopiare i dati dalla memoria dedicata alla CPU su quella della GPU. Un vero spreco, ma questo passava il convento... Per evitare questo si dovrebbe fare due cose: una hardware e una software. Quella hardware è dotare la GPU di una MMU, per la memoria virtuale. E sembra che Llano l'abbia, da quel post di blog, ma non mi fiderei...

La seconda è software. Ma non è una questione banale, perchè si deve interagire a basso livello con il gestore della memoria e il kernel di windows... Questo perchè? Supponiamo che io voglia spedire una mesh, una texture o una matrice alla GPU. Per evitare la copia fisica dei dati, il driver video dovrebbe far in modo che il gestore della memoria di windows deallochi le pagine in cui sono contenuti i dati, senza cancellarli e ne deve prendere possesso la GPU, cambiando opportunamente le tabelle delle pagine nella MMU della GPU. Questo può essere tranquillamente fatto dal driver, ma la cosa diventa complicata dal punto di vista del kernel windows (ad esempio). Quella memoria risulterà allocata al driver video? Va nel kernel pool? (che è una risorsa preziosa in quanto limitato) Come è gestita? Insomma è una cosa complicata anche se fattibile già adesso...

scusa bjt non sono stato chiaro, quando ho scritto "fondamentalmente è come dice bjt" ovviamente mi riferivo allo step 1) del tuo thread precedente (che descriveva quali saranno probabilmente gli step evolutivi delle apu) che si riferiva alla semplice integrazione, per llano, di una GPU senza differenze
rispetto a quanto avviene per un IGP/scheda classica discreta (a parte, come detto, la possibilita' di bypassare il bus pcie nelle scritture da parte della CPU nella memoria video). Il resto, per il momento, è identico praticamente all'implementazione di un IGP classico in quanto a gestione della memoria (almeno dalle info che sono riuscito a trovare su internet). Siamo ben lontani quindi dall'avere una memoria condivisa e/o un accesso alle risorse della GPU a mo di coprocessore.

[carpo93]

Originariamente inviato da marchigiano

mi riferivo allo screen.. spero ad aria

sotto azoto 5.5 non è neanche tantissimo

quel processore ha il moltiplicatore bloccato, per cui sono già un bel traguardo

[Dre@mwe@ver]

Originariamente inviato da carpo93

quel processore ha il moltiplicatore bloccato, per cui sono già un bel traguardo

Se il molti è bloccato è un bel traguardo anche secondo me!

[stefanonweb]

Viste tutte le passate vicessitudini, Voi un laptop con Llano adesso lo coprereste?

[stefanonweb]

Viste tutte le passate vicessitudini, Voi un laptop con Llano adesso lo comprereste?

[kiriranshelo]

Originariamente inviato da stefanonweb

Viste tutte le passate vicessitudini, Voi un laptop con Llano adesso lo coprereste?

io penso di si. comuque qui l'argomento è OT

IT: Clicca qui

[Pihippo]

Edit.

[bjt2]

Originariamente inviato da The3DProgrammer

scusa bjt non sono stato chiaro, quando ho scritto "fondamentalmente è come dice bjt" ovviamente mi riferivo allo step 1) del tuo thread precedente (che descriveva quali saranno probabilmente gli step evolutivi delle apu) che si riferiva alla semplice integrazione, per llano, di una GPU senza differenze
rispetto a quanto avviene per un IGP/scheda classica discreta (a parte, come detto, la possibilita' di bypassare il bus pcie nelle scritture da parte della CPU nella memoria video). Il resto, per il momento, è identico praticamente all'implementazione di un IGP classico in quanto a gestione della memoria (almeno dalle info che sono riuscito a trovare su internet). Siamo ben lontani quindi dall'avere una memoria condivisa e/o un accesso alle risorse della GPU a mo di coprocessore.

Però da quel link a quel blog che ho citato io c'era scritto che anche LLano ha la memria virtuale... Quindi il dubbio mi era venuto...

[appleroof]

non so se già postata, riguarda llano http://www.anandtech.com/show/4448/a...rmance-preview

[sniperspa]

Originariamente inviato da appleroof

non so se già postata, riguarda llano http://www.anandtech.com/show/4448/a...rmance-preview

diverso tempo fa

[appleroof]

Originariamente inviato da sniperspa

diverso tempo fa

azz scusate