[Thread Ufficiale] ASRock 4CoreDual Sata2 rev. 2.0 - VIA PT880 pro/ultra

[roccia1234]

ci sto giocando anche io a prototype!!! troppo ignorante sto giochino .
e già che c'ero... ho fatto acnhe io il grafico di utilizzo cpu/gpu.

http://img32.imageshack.us/img32/4149/prototypek.jpg (135 kb)

Anche da me entrambi i core sono occupati alla stessa maniera... e quasi al 100%. Ora non so se dire che in questa situazione sono cpu-limited, perchè mi ricordo che con il vecchio pc (p4 3,06 ghz e x1950 pro) quando si sentiva il cpu-limited, l'utilizzo cpu era costante e fisso al 100%... proprio una linea piatta. Quindi non saprei se dire che la cpu basta "al pelo" e c'è qualcos'altro che limita, oppure sono cpu limited nonostante l'utilizzo cpu sia intorno al 90-95%. Io sarei per la seconda ipotesi, visto anche che ci sono dei punti in cui entrambi i core sono al 100% e si vede proprio la linea piatta da cpu-limited di cui parlavo prima (uno è circa a 1/3, l'altro circa a metà). Se fossi sempre cpu-limited, il grafico dovrebbe essere tutto uguale a questi punti qua.

Edit:
per dare un'idea migliore di quella che posso dare le parole:
http://img146.imageshack.us/img146/5...siscpultd2.jpg (30 kb)
ho fatto il bench di crysis sul p4 di cui parlavo prima, a 800x600 e dettagli al minimo (per scaricare la vga ed evidenziare il cpu-limited)
la config in dettaglio è questa:

p4 northwood 3,06 ghz (133x23) @ 3,33 ghz (145*23)
2 gb ddr (4*512) @ 145 mhz
mobo asus p4p800-x
vga x1950 pro agp 512mb @ default

Dall'immagine si vede benissimo la linea piatta di cui parlavo prima. Questo da più credito all'ipotesi che la cpu basti "al pelo" e che ci sia qualcosa d'altro che limita.

[jamby93]

Originariamente inviato da halnovemila

Per verificare se nel caso da te riportato il collo di bottiglia è rappresentato maggiormente dal bus PCI-E o dalla RAM dovresti fare delle controverifiche con CPU alla stessa potenza e FSB a frequenze diverse: nel tuo caso potresti provare 2.4GHz@266*9 e 2.4GHz@300*8
Poi dovresti attivare e disattivare nel BIOS il lock della frequenza PCI-E sui 100MHz, lasciando quindi che nella configurazione 2.4@300*8 possa verificarsi un overclock del bus PCI-E tale da poter eventualmente influire sui risultati.

Sarebbe veramente molto utile poter inalzare ancora il FSB (anche abbassando il molti) peccato che appena provo anche solo a metterlo a 281 non boota più. Qualsiasi moltiplicatore io metta. Sarebbe comodo raggiungere i 333 Mhz (magari 333*8 = 2664 Mhz) in modo da poter impostare le RAM a 667 MT/s dato che ora sono abbassate notevolmente rispetto alle normali frequenze (800 MT/s).
Proverò a breve con la mod se riesco a risolvere qualcosa!

Originariamente inviato da halnovemila

Siamo ancora in attesa del tuo test CPU al 3DMark06 con l'affinità impostata su un singolo core
Giusto per fare il confronto con quello postato da Roccia1234.

Ed eccomi pronto dopo una mattinata di test.

• Screen completo di 3D Mark 06 con un solo core abilitato. (230KB)
  
  Ho raggiunto 8036 punti, ma del resto in processore è a un quarto delle sue potenzialità
  Infatti ho "perso" più di 2500 punti nella CPU, 500 nel SM2.0 e 400 nel SM3.0
  Avendo però notato un incremento del framerate solamente in alcune scene, ho voluto fare dei grafici raffiguranti tutti gli FPS di ogni scena, confrontando la soluzione con un solo core abilitato e quella con tutti e quattro.
  
  
• Grafico utilizzo CPU/GPU
  
  Si nota immediatamente come sia abilitato solo il Core1 (con il Core0 crashava ).
  Tuttavia è visibile anche, che in non tutte le scene è il processore a dettare il limite, soprattutto nella scena "Canyon Flight" si nota subito come la GPU sia pressochè sempre al 100% dell'utilizzo, generando la situazione "limited".
  
  
• Grafico "Return to Proxycon"
  
  Questo grafico (come tutti quelli che seguono) è stato effettuato importando gli FPS di ogni secondo, calcolati da ATT, in Excel e generando il grafico.
  Le differenze di FPS non sono così notevoli da generare un tempo totale molto maggiore in grado di "sballare" il grafico, dunque ho optato per questa opzione.
  In questo grafico, si nota che l'incidenza di 3 core in più non comporta grandi cambiamenti nel framerate infatti queste sono le percentuali di miglioramento riscontrate:
  Media: 5,81%
  Massimo: 32,65%
  Minimo: -15,00%
  É da considerare però, che alcuni aumenti o diminuzioni di FPS possono essere dovuti semplicemente al caso o alla non esatta coincidenza dei framerate a causa dei tempi globali inferiori e non per forza alla limitazione del processore.
  
  
• Grafico "Firefly Forest"
  
  Situazione completamente diversa in questo caso, nel quale il processore si fa sentire, e anche molto. Questa situazione era già visibile dal grafico di utilizzo CPU/GPU nel quale si notava come la GPU non raggiungesse percentuali molto elevate di utilizzo.
  Queste le percentuali di miglioramento:
  Media: 15,66%
  Massimo: 30,55%
  Minimo: -3,278%
  
  
• Grafico "Canyon Flight"
  
  Questa situazione ricorda molto la prima scena. Qui si nota in modo ancora più accentuato come il processore abbia un influenza minima, e la GPU abbia il maggiore carico di influenza.
  Queste le percentuali di miglioramento:
  Media: 0,84%
  Massimo: 16,00%
  Minimo: -9,25%
  
  
• Grafico "Deep Freeze"
  
  In questa scena invece ritroviamo la situazione di processore-dipendente riscontrata anche nella scena "Firefly Forest".
  In questo caso il miglioramento è netto e non scende mai sotto lo 0.
  Media: 15,44%
  Massimo: 20,83%
  Minimo: 3,846%

Non ho creato i grafici anche delle due scene CPU in quanto avrebbero avuto poco significato per tre motivi:
1)L'influenza del processore è ovvia e indiscutibile, infatti in qualsiasi caso la percentuale di impiego della GPU rimane sempre a 0%. É quindi logico che con un solo core abilitato le prestazioni calino a picco.
2)I dati esportati da ATT (stranamente) non riportano le cifre decimali che invece riconosce tranquillamente. Mi sono dunque trovato in una situazione nella quale, essendo i FPS delle due scene CPU generalmente molto bassi, nel caso di un solo core abilitato, i FPS erano sempre 1 (arrotondato all'unità da ATT) mentre con il processore completo variavano, giustamente, da 1 a 3-4. Si sarebbe dunque visto un grafico con una linea retta della soluzione con un core solo, quindi priva di senso.
3)I tempi globali in questo caso sono aumentati terribilmente, rendendo quasi impossibile allineare le piccolissime variazioni di framerate mentre si utilizzava un core solo.

Per chi vuole approfondire qui trova un file riassuntivo (58 KB)
Saluti.

[halnovemila]

Ma siete miticiiiii
Tra te e Roccia c'è l'imbarazzo della scelta tra chi aggiudicare la coppa del premio "ricercatore pazzo"

Comunque quella differenza di Fps in due dei quattro test deve essere collegata non tanto alla "capacità" del 3DMark06 di utilizzare più core, ma al kernel a 64bit ,al driver 64 bit della scheda video o alle API DirectX che su Vista 64bit evidentemente riescono a sfruttare la presenza di più core anche se l'applicazione 3D non progettata a tale fine.

Infatti sotto XP la differenza di risultati tra test normale e test eseguito con affinità ad un solo core è molto meno evidente, direi marginale (parlo sulla base dei risultati dei miei test eseguiti con 1 core e 2 core su 19 combinazioni diverse di FSB e frequenza CPU)

Sono andato a guardarmi i grafici da te postati precedentemente
qui con XP: http://www.hwupgrade.it/forum/showpo...postcount=1141
e qui con Vista: http://www.hwupgrade.it/forum/showpo...postcount=1083

entrambi i test sono effettuati senza affinità ma si nota come in XP, durante i test GT e HDR, la percentuale di occupazione del core "principale" (core 0) sia maggiore, mentre è minore quella residuale degli altri core.

Insomma, si potrebbe dire che Vista 64 è un sistema operativo (kernel, drivers, API) che rende al meglio con le CPU multi core.

Se non l'hai già "cestinato" potresti fare la controprova (con affinità e senza) sotto XP.

Originariamente inviato da jamby93

Le differenze di FPS non sono così notevoli da generare un tempo totale molto maggiore in grado di "sballare" il grafico

Cosa intendi dire?
Mi pare sia normale che i test abbiano sempre la stessa durata complessiva.
A differenza del test con Crysis, nel quale è fisso il numero di fotogrammi (2000 per il GPU benchmark e 1500 per il CPU benchmark) e varia la durata complessiva in base alla velocità con cui vengono renderizzati i singoli fotogrammi, nei test 3DMark06 la durata della scena è sempre quella, mentre il numero dei fotogrammi renderizzati varia a seconda degli Fps che il sistema è in grado di produrre.

[jamby93]

Originariamente inviato da halnovemila

Se non l'hai già "cestinato" potresti fare la controprova (con affinità e senza) sotto XP.

Non l'ho cestinato, certamente, solo che non è collegato l'hard disk.. Quindi se riesco farò qualche prova domani. Per oggi è già tanto..
Magari sta sera provo a fare un grafico di utilizzo con 3D Mark Advance (Specifico per Vista) per vedere l'utilizzo di diversi core quanto influenza.

Originariamente inviato da halnovemila

Cosa intendi dire?
Mi pare sia normale che i test abbiano sempre la stessa durata complessiva.
A differenza del test con Crysis, nel quale è fisso il numero di fotogrammi (2000 per il GPU benchmark e 1500 per il CPU benchmark) e varia la durata complessiva in base alla velocità con cui vengono renderizzati i singoli fotogrammi, nei test 3DMark06 la durata della scena è sempre quella, mentre il numero dei fotogrammi renderizzati varia a seconda degli Fps che il sistema è in grado di produrre.

Non credo sia come dica tu.. Non ho controllato ogni volta il tempo delle scene ma credo che cambi, ma il numero di frame sia lo stesso. Non avrebbe senso se no che tutte le scene inizino e finiscano nello stesso modo, vorrebbe dire che qualche frame "centrale" verrebbe saltato, il che non ha molto senso in quanto qualche frame potrebbe essere più complesso da renderizzare di altri.
Per questo credo che sia il numero totale di frame a rimanere invariato, piuttosto che il tempo totale. A riprova, ho contato che nel test CPU 1, con tutti e 4 i core il tempo è di 43 "825 millesimi" (lo step che avevo impostato in ATT) quindi circa 35 secondi e mezzo. Con un core solo invece, impiega 131 "825 millesimi" quindi circa un minuto e 48 secondi.
Provare per credere

[halnovemila]

Originariamente inviato da jamby93

Non credo sia come dica tu.. Non ho controllato ogni volta il tempo delle scene ma credo che cambi, ma il numero di frame sia lo stesso. Non avrebbe senso se no che tutte le scene inizino e finiscano nello stesso modo, vorrebbe dire che qualche frame "centrale" verrebbe saltato, il che non ha molto senso in quanto qualche frame potrebbe essere più complesso da renderizzare di altri.

Si, infatti, in generale, durante i giochi vengono prodotti più o meno frames.
Comunque la mia era un'impressione (cioè ho sempre avuto l'impressione che la durata del test fosse sempre quella) ma non ho mai fatto una verifica...
tu l'hai fatta e io chino la testa e umilmente accetto il mio torto di fronte all'evidenza delle tue misurazioni indubbiamente valide

...uhm... però forse... devo verificare una cosa...

[halnovemila]

Originariamente inviato da halnovemila

io chino la testa e umilmente accetto il mio torto di fronte all'evidenza delle tue misurazioni indubbiamente valide

Ecco... e ti pareva...
una volta su un milione che potevo aver torto... e invece no... anche stavolta ho ragione io!


In effetti mi pareva strano di aver torto... non per niente... ma un numero fisso di fotogrammi avrebbe comportato (così come accade con il benchmark di Crysis) al variare dalla potenza CPU e GPU, un aumento o diminuzione della velocità in cui si muove la camera, i soggetti, gli oggetti, più o meno come aumentare o diminuire la velocità di riproduzione di una pellicola cinematografica... mentre a me le scene dei test (esclusi quelli CPU) hanno sempre dato l'impressione che si svolgessero nello stesso identico modo, con la camera, i soggetti e gli oggetti che si muovevano sempre alla "solita" velocità, indipendentemente dalla potenza della CPU e GPU impiegate per il test.
Un discorso a parte sono invece i CPU test... in questo caso la durata non è costante... ma di questo me n'ero accorto anch'io

[jamby93]

Originariamente inviato da halnovemila

Ecco... e ti pareva...
una volta su un milione che potevo aver torto... e invece no... anche stavolta ho ragione io!

Ehehe..
In effetti io avevo fatto il calcolo in base al test CPU, nel quale ero sicuro c'erano stati miglioramenti notevoli, non avevo controllato negli altri test, che a quanto pare non cambia la lunghezza finale. Buono a sapersi allora!
Ci si arricchisce sempre di nuove scoperte

[halnovemila]

Ecco qua le differenze tra un 3DMark06 eseguito su una CPU dual core,
eseguito impostando l'affinità del task solo sul di un core,
eseguito sostituendo l'HAL e il Kernel multiprocessore con la versione Uniprocessore.

La parte di grafico colorata in rosso è l'occupazione CPU da parte del kernel del sistema operativo (quindi anche dei driver).
Come si può osservare, impostando l'affinità di 3DMark06 su di un solo core non si impedisce al Kernel di continuare ad usare l'altro, di conseguenza l'unica parte del benchmark che che viene effettivamente condizionata è quella relativa ai test CPU (nel grafico superiore il test CPU occupa sia il core 0 che il core 1, mentre nel grafico centrale si nota l'assoluta assenza di verde nel riquadro relativo al core 1).
I risultati ai test GT e HDR non sono quindi destinati a cambiare a causa dell'impostazione dell'affinità del task 3DMark06 su un solo core.

Sostituendo il Kernel e l'HAL multiprocessore con la versione Uniprocessore, il secondo core della CPU diventa praticamente invisibile al sistema operativo.
In questo terzo e ultimo caso il Kernel (e i driver) è necessariamente costretto a usare lo stesso Core in uso dall'applicazione 3DMark, contribuendo ad aumentare l'occupazione CPU.
In questa condizione, se la CPU raggiunge il 100% di occupazione in tratti del benchmark dove prima la percentuale era inferiore al 100%, è possibile che si creino le condizioni per una limitazione della GPU altrimenti non presente.
In questo caso quindi, oltre ai test CPU, anche gli altri potrebbero subire delle riduzioni di Fps e di punteggi rispetto a quelli ottenibili con la disponibilità di entrambi i core.


Test effettuati con CPU Core2 [email protected], Fsb@275 e HD3850 AGP con clock GPU/RAM di default (670/830)

Saluti.
Alessio

Edit: per chi volesse misurare la tensione Vagp sulla propria scheda madre... oggi ho fatto questa foto

Il pin #64, lato A del connettore AGP è uno degli 11 dove la scheda madre fornisce la tensione Vddq 1.5V. Sulla 4CoreDual-Sata2 questa tensione è di 1.61V; ma nel mio caso, avendo effettuato una modifica, è presente un overvolt di +0,04V.

[jamby93]

Ho eseguito i grafici con affinità anche con 3D Mark Vantage e questi sono risultati:

• Grafico utilizzo CPU/GPU con 4 core abilitati (per sbaglio in jpg )
  
  Si nota subito come questo benchmark in confronto a 3D Mark 06 abbia un tempo di caricamento decisamente più lungo, in cui il processore "impazzisce" con utilizzi dei core molto vari.
  Durante le scene però, l'influenza del processore sembra essere abbastanza bassa.
  Migliore a mio opionione invece l'utilizzo del processore nei test CPU, che in confronto a 3D Mark 06 mi sembra molto più "stressato".
  
  
• Grafico utilizzo CPU/GPU con 1 core abilitato
  
  Come si era notato prima, l'influenza del processore è molto bassa, infatti un solo core è sufficente per non generare la situazione "CPU limited" infatti la GPU raggiunge sempre il 100% senza influenza. Diversamente da quanto accadeva con 3D Mark 06.
  
  
• Grafico FPS 1 Core/ 4 Core
  
  Come c'era da aspettarsi, le linee delle due soluzioni si appaiano sempre, dato che era la GPU ad essere limite.

Non ho fatto i grafici del test CPU in quanto ho notato che, soprattutto nel secondo test, 3D Mark "analizza" le prestazioni della CPU e in base al primo test genera una scena più o meno complessa per il secondo test. Nel caso specifico quando utilizzavo 4 core erano presenti 8 "gommoni" nella scena, mentre con un solo core ne erano presenti solo 2. Per questo motivo i FPS nei due casi si assomigliavano.
Da notare come, in questo caso, l'influenza del punteggio CPU influenzava notevolmente in punteggio finale. Il punteggio CPU è passato da ~8800 a ~2300 e il punteggio totale da ~7600 a ~4500.

[roccia1234]

bestia jamby93!! ti stai sbizzarrendo con i test!! complimenti!!
un piccolo appunto nei primi 2 test grafici (dove si vede la gpu spiattellata al 100%) viene praticemtne utilizzato un solo core (il core 3 per la precisione), mentre gli altri, a parte qualche picco casuale, sono quasi sempre in idle o poco più. Quindi manco il 3dmark vantage (nei test gpu) sfrutta tutti i 4 core, a differenza di prototype, che ha un'ottimizzazione multicore oserei dire esemplare.
Se sfruttasse tutti i core (il 3dmark) , dovremmo vederli tutti all'opera, anche magari al 15-20% a testa, non uno che va e gli altri che dormono.
Per il resto niente da dire, complimenti ancora!

[Six1]

Ciao a tutti!
Ho notato che in questi giorni di mia assenza è stato rimarcato più di qualche volta il punto sul limite imposto dello Slot PCIEx4x, sopratutto da halnovemila......
A queste eccezioni imposte dal Limite del PCIEx 4x, vorrei provare ad applicare delle soluzioni.




Dai Test effettuati da T.Hardware qui di seguito:
http://www.tomshw.it/graphic.php?gui...s-2-scaling-06
Ho notato una cosa molto interessante, tra l'altro evidenziato anche da loro nelle conclusioni e considerazioni.......
Benchmark come Futuremark 3DMark06, PCMark Vantage, Prey o Quake mettono in luce il risvolto della medaglia: sono in grado di sfruttare i 512 MB (Radeon HD 3850) o i 2x 512 MB (GeForce 9800 GX2) di dati grafici, e quindi tutto fila liscio, anche senza la banda massima.




Questo significa che la memoria Video nel nostro caso assume un ruolo importantissimo e cruciale.


Allora dai test da Noi effettuati risulta che il 4x anche se in circostanze ben precise e molto rare, ad oggi potrebbe risultare un limite in determinati Giochi e più in specifico in determinati punti di gioco, dove :

nei giochi dalla grafica più curata e più spettacolare, la scena è formata da un gran numero di personaggi ed oggetti caratterizzati da superfici completamente diverse (dalla pelle agli abiti, dal legno alle pareti in muratura, dai pannelli metallici ai pavimenti di ogni tipo), per il cui disegno il processore grafico effettua un processo in due fasi: prima approssima l'andamento delle superfici con un modello composto di innumerevoli piccoli poligoni o triangoli, poi cerca in un repertorio di textures il tipo di “rivestimento” da applicare, e con esso effettua il vero e proprio “riempimento” (campitura) delle superfici. In questo processo è un po' come se le textures fossero campioni di carta da parati di vari colori con cui rivestire un'armatura in filo di ferro (wireframe) che approssima la sagoma del soggetto da disegnare.

È chiaro che se le superfici sono tante e di tanti tipi diversi, occorre un ampio repertorio di textures. Inoltre, se si lavora con superfici molto più grandi della texture, questa dovrà ovviamente essere disegnata più volte fino a “tappezzare” completamente l'oggetto. Questo potrebbe causare un evidente effetto di ripetizione (si pensi ad un muro che viene disegnato usando una piccola texture a mattoni in cui, per renderla più realistica, è stata disegnata una imperfezione o una scrostatura: questo particolare sarebbe ripetuto ad intervalli regolari e si noterebbe immediatamente). La soluzione per attenuare questo problema è utilizzare texture di grandi dimensioni.

Chiarito che per questo genere di applicazioni occorre avere a disposizione molte texture di grandi dimensioni, risulta immediatamente chiaro che occorre avere molta memoria ed un velocissimo canale di comunicazione con la CPU. Infatti, le texture non sono altro che grosse immagini disegnate con grande accuratezza, e le immagini occupano molta memoria. Normalmente, se la scheda video dispone di molta memoria locale, si farà in modo di parcheggiare a bordo di essa un repertorio di textures il più possibile vasto in modo tale che, per usarle, non sia necessario passare dal bus di sistema.

Tuttavia, anche solo per la popolazione iniziale rimane la necessità di far arrivare alla scheda video queste textures, che si trovano sul CD del gioco o sull'hard disk. La strada da percorrere per questo trasferimento è ovviamente il bus di sistema. La quantità di textures che possono essere usate in un gioco di ultima generazione può facilmente superare la quantità di memoria video a disposizione della scheda. (Questo era però forse vero fino a un paio di anni fà oggi una GPU può avere a disposizione fino a 2G di memoria Video)

Questo significa che, durante l'esecuzione del gioco, la CPU di sistema dovrà trasmettere alla scheda video le texture che le servono, e poiché non è facile o possibile prevedere in anticipo quali texture serviranno, perché ciò dipende dal percorso seguito dal giocatore, dalle sue azioni e dalla direzione verso cui volge lo sguardo, il trasferimento alla scheda video delle texture mancanti dovrà avvenire nel momento stesso in cui il gioco si accorge che servono per comporre la scena. In altre parole, in pochi millisecondi si dovrà riuscire a trasferire diversi megabyte di materiale grafico dalla RAM di sistema alla scheda video, passando per il bus di sistema.

Sempre per il bus di sistema viaggiano poi gli ordini che il programma principale impartisce alla scheda video: come comporre la scena, come generare le ombre, quali texture usare, quali elaborazioni tridimensionali applicare, quale illuminazione adottare, e così via. Solo le informazioni sulla costruzione della scena sono costituite da liste di coordinate dei vertici di migliaia o milioni di piccoli triangoli o poligoni che costituiscono il reticolo tridimensionale che approssima la sagoma degli oggetti, su cui andrà poi applicata la texture appropriata per ognuno.

Se per ogni triangolo devono essere fornite le coordinate tridimensionali precise dei tre vertici, ogni triangolo richiede l'invio di 3x3=9 numeri floating point, ognuno dei quali richiede diversi byte. “Inviare la descrizione della scena”, quindi, tradotto in numeri, significa “megabyte e megabyte al secondo” di dati da trasferire, passando per il bus di sistema.

Infine la scheda video, o più precisamente il suo processore grafico (Graphics Processor Unit, GPU), è rapida nell'esecuzione dei compiti su cui è specializzata ma deve essere costantemente istruita sul da farsi, e questo spetta al programma principale che gira sul processore principale del PC (Central Processing Unit, CPU). Il canale di comunicazione fra CPU e GPU, su cui devono viaggiare tutte queste informazioni, è naturalmente, ancora una volta, il bus di sistema.

Per tutti i motivi citati risulterà ora chiaro come mai il bus di sistema usato dalla scheda video abbia tanta rilevanza per l'aumento delle prestazioni, e perché negli anni si siano succeduti così tanti tipi di bus sempre più veloci, specializzati per le schede grafiche: se un normale bus PCI (banda di 133 Mbyte/s) è sicuramente sufficiente per le esigenze di un controller USB, questo non è vero per una scheda grafica.

Ecco perché negli anni sono statiproposti bus accelerati, in tre “dinastie” principali: AGP, PCI-X e PCI Express (all'epoca dei PC 486 esisteva anche un altro bus grafico denominato VESA Local Bus o VL-Bus, tramontato già con l'introduzione dei Pentium ed oggi completamente in disuso).

Ricordiamo che la larghezza di banda che un bus può assicurare dipende da due semplici fattori: la larghezza del canale, in bit, e la frequenza alla quale vengono trasferiti i dati su questo canale. Moltiplicando questi due valori si ottiene la banda. Si può paragonare il flusso di dati su un bus alla portata d'acqua in un fiume, che dipende dalla sezione (larghezza e profondità) e dalla velocità della corrente d'acqua.

Per esempio, un canale largo 8 bit che lavora a 1 MHz effettua 1 milione di trasferimenti da 8 bit ogni secondo. In altre parole, la sua banda è di 1 Megabyte/secondo. Per aumentare la sua banda si può costruire un canale più largo a parità di frequenza, oppure aumentare la frequenza a parità di larghezza di canale, o entrambe le cose. Come vedremo, le strategie seguite finora sono state diverse.

La prima famiglia, AGP, fece la sua comparsa nel 1997. Adottava una larghezza di canale a 32 bit come quella del normale bus PCI, ma lavorava a frequenze più elevate con uso di ulteriori tecniche per aumentare la frequenza efficace. Nel bus AGP 1x, per esempio, la frequenza era di 66 MHz, il doppio del PCI, e la banda era anch'essa doppia: 266 Mbyte/s. Le successive evoluzioni di AGP hanno mantenuto la larghezza di canale a 32 bit, ma hanno aumentato la frequenza efficace mediante tecniche come dual-pumping o quad-pumping.

Sono nati così gli standard AGP 2x, AGP 4x e AGP 8x (figura 1_AGP8x.jpg), capaci di assicurare, rispettivamente, bande massime di 533, 1.066 e 2.133 Mbyte/s. Lavorando a frequenze così elevate questi bus andavano incontro anche a problemi elettrici, che è stato possibile attenuare riducendo progressivamente la tensione di lavoro: se l'AGP 1x funzionava a 3.3V, l'AGP 8x usava tensioni di soli 0.8V.

La seconda soluzione tentata per assicurare alte prestazioni sul bus è stata il PCI-X, introdotto nel 1998, in piena era AGP, come tecnologia di bus alternativa al PCI. Il suo scopo, quindi, non si limitava all'accelerazione delle schede grafiche, ma consisteva in un aggiornamento dell'intero bus di sistema, per qualsiasi uso. Questo bus ricorreva sia ad un allargamento del canale (lavorava infatti a 64 bit), sia ad un aumento della frequenza (133 MHz). La sua banda di 1.066 Mbyte/s equivaleva a quella di un bus AGP 4x. Il PCI-X non è riuscito ad imporsi come standard generale per il bus nell'architettura PC, forse perché per le schede grafiche o di futura realizzazione non appariva comunque sufficientemente potente, mentre le periferiche PCI meno “esigenti” non ne avevano bisogno.

La terza famiglia, che oggi sembra avere definitivamente preso piede nell'architettura PC tanto da essere stata incorporata anche nel nuovo standard ExpressCard per le schede di espansione dei PC portatili, è quella del PCI-Express, o PCIe, da non confondere naturalmente con PCI-X.

Il PCI Express adotta un approccio originale rispetto alle strategie seguite finora per aumentare la banda del bus: la larghezza di canale si riduce a 1 bit soltanto, mentre la frequenza sale vertiginosamente, a ben 2500 MHz. Si tratta quindi di un bus seriale (fra l'altro con un connettore piccolissimo, solo 18 pin, dal momento che vi è un'unica linea dati e, quindi, un basso numero di contatti), che trasferisce 250 Mbyte/s (a causa della codifica usata per assicurare l'integrità dei dati, occorrono 10 cicli di clock per trasferire 8 bit).

Questo valore può apparire deludente se confrontato con quelli che caratterizzano le ultime evoluzioni di AGP e lo stesso PCI-X, e in effetti lo sarebbe, se non si tenesse conto di una fondamentale caratteristica prevista dallo standard PCI-Express: quella di aggregare un certo numero di canali seriali elementari PCIe per ottenere una banda complessiva superiore.

In quest'ottica, un bus PCIe elementare è detto PCIe 1x, mentre le versioni “aggregate” si chiamano PCIe x4, x8 e x16, ed assicurano rispettivamente una banda complessiva di 1Gbyte/s, 2 Gbyte/s e 4 Gbyte/s. Da non sottovalutare poi il fatto che il bus PCIe nelle sue versioni aggregate consente alle varie periferiche di utilizzare contemporaneamente, e in modo indipendente, piccole “quote” della banda complessivamente disponibile, semplicemente usando una “corsia” del bus aggregato. La flessibilità assicurata da questa possibilità di utilizzo concorrente del bus è propria della natura di bus multipli seriali aggregati del PCIe e costituisce, al di là dell'elevato valore di banda, una novità architetturale di grande importanza.



Alla luce di quanto detto per evitare di incorrere in possibili limiti su Slot PCIEx4x, basterebbe avere alcune accortezze nell' acquisto della propria scheda grafica:

Cause scatenanti il limite imposto dallo Slot 4x alla GPU e di conseguenza al Gioco in cui si è verifcato un calo di FPS.

1°Per questo genere di applicazioni occorre avere a disposizione molte texture di grandi dimensioni, risulta immediatamente chiaro che occorre avere molta memoria ed un velocissimo canale di comunicazione con la CPU. Infatti, le texture non sono altro che grosse immagini disegnate con grande accuratezza, e le immagini occupano molta memoria.
2° La quantità di textures che possono essere usate in un gioco di ultima generazione può facilmente superare la quantità di memoria video a disposizione della scheda.
3° La CPU gestisce la Fisica, e quindi per forza di cose viene coinvolta.

Eliminazione del Limite limite imposto dallo Slot 4x alla GPU e di conseguenza al Gioco in cui si è verifcato un calo di FPS.(Quindi Soluzioni)

1°Normalmente, se la scheda video dispone di molta memoria locale, si farà in modo di parcheggiare a bordo di essa un repertorio di textures il più possibile vasto in modo tale che, per usarle, non sia necessario passare dal bus di sistema.
2° Acquistare GPU con la massima memoria video disponibile, ad oggi esistono GPU fino ad un massimo di 2G (questo è importantissimo)
Questo può e di molto alleggerire, se non annullare la limitazione imposta su Slot PCIEx4x
3°Con Phisx di nVidia e Havok di ATI Radeon, anche la fisica è gestita dalle GPU, sempre più giochi permettono già oggi la gestione della Fisica da parte di Phisx, lo stesso avverrà con le prossime GPU di ATI con Havok. Il passaggio di dati tra CPU e GPU sarà sempre inferiore, la GPU sarà in grado di gestire un video gioco senza dover comunicare la quantità di dati che oggi comunica e che comunque nonostante questo come abbiamo riscontrato sono rare le situazioni in cui la Banda su SlotPCIEx4x risulta saturata.

Concusioni:
Quindi quando acquistate una GPU non risparmiate sulla Memoria Video, e cercate di acquistare GPU in grado di gestire la fisica in maniera indipendente alla CPU (Phisx,Havok)

Inoltre per tornare ai nostri Test è probabile che il limite riscontrato da halnovemila con la sua HD4870 da 1G, non venga riscontarto da GPU HD4870 con Memoria Video maggiore: 1,5G, 2G. Oppure con altri Giochi in grado di sfruttare la memoria video in maniera corretta.
Spero di essere stato chiaro.

[jamby93]

Originariamente inviato da Six1

Concusioni:
Quindi quando acquistate una GPU non risparmiate sulla Memoria Video, e cercate di acquistare GPU in grado di gestire la fisica in maniera indipendente alla CPU (Phisx,Havok)

Inoltre per tornare ai nostri Test è probabile che il limite riscontrato da halnovemila con la sua HD4870 da 512MB, non venga riscontarto da GPU HD4870 con Memoria Video maggiore: 1G, 1,5G, 2G.
Spero di essere stato chiaro.

Ben tornato in auge e complimenti per l'ottima recensione dei diversi bus creati ed esistenti.
Ottima descrizione davvero.

Riguardo a quanto tu dici però, potrebbe esserci qualche errore in quanto abbiamo già verificato come anche nel mio caso (1GB) alcune volte ho riscontrato il fenomeno limitante del bus. Potremo dirlo definitivamente soltanto quando riuscirò ad inalzare le RAM se questo fenomeno si ripresenta anche in Protoype (come analizzato precedentemente), ma le possibilità sono abbastanza alte.
Basti pensare che nei test da noi effettuati, in scene particolarmente complesse del benchmark di Crysis, dove sono presenti molti oggetti, vegetazione, texture ecc ecc, la mia 4850 1GB ottiene FPS inferiori alla 3850 di halnovenila, su AGP 8X. Sono differenze non troppo elevate (attorno ai 5 FPS) ma è anche da considerare che sono GPU architetturalmente completamente differenti, dovrebbe infatti riscontrarsi un notevole guadagno per la 4850, mentre abbiamo verificato che in questi casi persino ne perde.
E le possibili cause non sono tante

PS: Nota che, almeno per il settore ATI, le uniche GPU a superare la soglia di 1GB sono la 4870X2 e la 4850X2 entrambe con 2GB di GDDR5, peccato che non siano supportate dalla nostra mobo
Stessa cosa vale per Nvidia.

[Six1]

Ma in fatti ad oggi, come detto:
Benchmark come Futuremark 3DMark06, PCMark Vantage, Prey o Quake mettono in luce il risvolto della medaglia: sono in grado di sfruttare
Questo sono in grado è importante.

Quindi non tutte le applicazioni ad oggi sono in grado di sfruttare la memoria video in maniera ottimale, ma questo handicap andrà scomparendo....
Come già è avvenuto con: Futuremark 3DMark06, PCMark Vantage e Prey o Quake.
Quindi prova a fare i Test sopra mensionati e poi paragonali con la HD3850 e poi ne riparliamo......

Poi ovviamente vi è tutta la restante parte della gestione della Fisica che per ora voi non vi sentite di prendere in considerazione perchè avete una GPU non in grado di effettuare questo lavoro.(legittimo, ma non per questo deve essere escluso).
Havok, Phisx e una memoria video superiore ai 512MB possono essere e saranno di grande aiuto.

[jamby93]

Originariamente inviato da Six1

Come già è avvenuto con: Futuremark 3DMark06, PCMark Vantage e Prey o Quake.
Quindi prova a fare i Test sopra mensionati e poi paragonali con la HD3850 e poi ne riparliamo......

Beh, escludendo PCMark che non capisco cos'abbia a che fare con la GPU in quanto sono pochissime le applicazioni "daily" che sfruttano la GPU. In quel benchmark viene sfruttata la CPU e le RAM da quanto so...
Per i paragoni con 3DMark lo puoi notare tu da solo dai risultati in prima pagina.
Abbiamo visto come halnovenila ha ottenuto in 3DMark 06 un punteggio GPU ben più alto del mio, nonostante abbia una GPU più datata.
Il mio risultato:
PUNTEGGIO: 11735 di cui: SM2.0: 4583, SM3.0: 5324, CPU: 3621.

Contro quello di halnovenila:
PUNTEGGIO: 11713 di cui: SM 2.0: 4982, SM3.0: 5366, CPU: 3052

Ha riscontrato 400 punti in più nel punteggio SM2.0.
Da considerare che entrambe le GPU erano Overclockate, forse la mia di meno, ma oltre non reggeva, e cè la possibilità che sia sempre il bus a limitare, infatti i problemi che ho avuto in O.C. sono stati solo quando facevo partire i benchmark, con quindi un'elevata richiesta di poligoni e texture passanti, che è possibile a frequenze elevate il bus non regga. Sono solo supposizioni in ogni caso.. Non abbiamo dati certi.

[roccia1234]

un piccolo appunto. Le hd4870x2, e 4850x2 hanno si 2gb di vram, però è come se ne avessero uno... mi spiego.
dato che queste vga hanno 2 gpu, ogni gpu ha la sua parte di memoria dedicata, i due gb non sono condivisi tra le due gpu. Quando renderizzano una scena, le due gpu hanno nella memoria gli stessi identici dati, quindi se dovessero aver bisogno di immagazzinare 512 mb nella ram, l'occupazione totale di ram sarebbe 512mbx2=1024 mb, proprio per il fatto spiegato prima. Quindi alla fine la scheda ha si 2 gb di ram, ma è come se ne avesse 1 gb.

[Six1]

Originariamente inviato da jamby93

PS: Nota che, almeno per il settore ATI, le uniche GPU a superare la soglia di 1GB sono la 4870X2 e la 4850X2 entrambe con 2GB di GDDR5, peccato che non siano supportate dalla nostra mobo
Stessa cosa vale per Nvidia.

No non è così........
ATI ha prodotto già scheda singola con 2G di Memoria Video....
Vapor-X da 2G:
http://www.sapphireitaly.com/content/view/604/59/

Comunque questo poco importa perchè.....
Per quanto riguarda la memoria video da 1G (di cui abbiamo disponibile la versione di nVidia GTS250+Phisx) questa è già abbondantemente sufficiente al nostro scopo se questa venisse sfruttata a dovere.....come detto poco prima.

Per la compatibilità......non è la memoria video a definire se una GPU è compatibile o meno, tanto è vero che dalla lista vi sono solo GPU compatibili da 512MB, invece noi usiamo tranquillamente GPU da 1G.

[halnovemila]

Originariamente inviato da Six1

Inoltre per tornare ai nostri Test è probabile che il limite riscontrato da halnovemila con la sua HD4870 da 512MB, non venga riscontarto da GPU HD4870 con Memoria Video maggiore: 1G, 1,5G, 2G

Caro Six1
ho letto tutto il tuo lungo post...
devi averci messo un bel po' nel scriverlo...
allora ti meriti i complimenti per l'impegno
Di quello che c'è scritto il 99% già lo conoscevo (mi mancava la parte relativa al bus del PCI-X) e sostanzialmente posso confermare quasi tutta la parte teorica...
ma le conclusioni mi lasciano un po' perplesso.
Prima cosa: Tanto per cominciare la HD4 870 Vapor-X che ho utilizzato per i test disponeva di 1GB di RAM GDDR5 (l'ho scritto nei dati relativi alla configurazione del PC; vedi il post #1195).
Seconda cosa: il trasferimento delle texture verso la RAM video avviene in fase di precaricamento del livello o comunque in "burst", e non in streaming... ovvero l'intasamento del Bus dovuto al traferimento delle texture può avvenire, se avviene, ad intermittenza, e si manifesta più come un'interruzione, uno scatto, nel rendering della scena, piuttosto che come una riduzione degli Fps.
Come ho dimostrato con la misurazione "continua" degli Fps nell'arco di una scena di circa un minuto (vedi il post #1261) date "certe circostanze" la perdita di Fps dovuta alla limitazione del bus è invece presente in modo lineare senza "strappi" o picchi.
Ergo la limitazione imposta da una non sufficiente larghezza di banda del bus non è sempre dovuta al trasferimento delle texture e non è risolvibile con l'aumento della memoria video on-board.
Terza cosa: non ho ancora approfondito l'argomento ma ho molte perplessità in merito al fatto che lo spostamento sulla GPU dell'onere di elaborazione della fisica comporti una riduzione del traffico dati sul bus CPU->GPU.
Allo stato attuale il fatto che la fisica sia calcolata dalla CPU non comporta alcuna sollecitazione sul bus (dato che l'elaborazione rimane tutta sul versante CPU/RAM e la GPU non viene interessata) e pertanto non può essere considerato uno degli elementi che potrebbero contribuire alla saturazione del bus PCIe (o AGP).
Al contrario, lo spostamento dell'elaborazione della fisica degli oggetti sulla GPU, se da un lato "alleggerisce" la CPU e può contribuire a rimuovere eventuali condizioni di CPU-limited, dall'altro credo che implicherà una maggiore e più stretta comunicazione tra CPU e GPU, anche bidirezionale, per la trasmissioni di dati di elaborazione controllo e sincronizzazione di cui, in caso contrario, non ci sarebbe bisogno.
Quindi, a conclusione, dubito che l'utilizzo delle tecnologie Phisx e Havok possa portare beneficio ai casi e nelle scene in cui il bus PCI-E non è in grado di garantire sufficiente larghezza di banda.

Saluti.
Alessio

@Jamby93
Approposito del test su Crysis...
parlando con Roccia1234 (e sulla base degli Fps da lui misurati sullo stesso fotogramma 1299) sono giunto alla conclusione che la prova che ti ho proposto non è sufficientemente affidabile/riproducibile per valere come dato sperimentale su cui fare o basare delle valutazioni.
In realtà io ho elaborato molti altri dati che confermano la mia ipotesi ma sarebbe troppo complicato pubblicarli per via sia delle dimensioni dei grafici (che per mantenere una adeguata risoluzione sono molto lunghi) che della loro non semplice lettura.

[halnovemila]

Originariamente inviato da jamby93

Da considerare che entrambe le GPU erano Overclockate, forse la mia di meno, ma oltre non reggeva

Non ti preoccupare la HD3 850 anche con un overclock da fargli scoppiare VRM e condensatori non supera i 1200 punti al test Unigine Sanctuary Demo.
La HD4870 rimane sempre il doppio più potente.
Del resto hai voglia ad overcloccare quando la differenza quando la HD3850 ha 320 unità shaders e la HD4870 ne ha 800!

[Six1]

Originariamente inviato da halnovemila

devi averci messo un bel po' nel scriverlo...
allora ti meriti i complimenti per l'impegno

Non meno di quanto tu ci metti a scrivere i tuoi, e per cui ogni volta ti facciamo i complimenti per il tuo impegno.

Originariamente inviato da halnovemila

Ergo la limitazione imposta da una non sufficiente larghezza di banda del bus non è sempre dovuta al trasferimento delle texture e non è risolvibile con l'aumento della memoria video on-board.
Terza cosa: non ho ancora approfondito l'argomento ma ho molte perplessità in merito al fatto che lo spostamento sulla GPU dell'onere di elaborazione della fisica comporti una riduzione del traffico dati sul bus CPU->GPU.

Allora spiegami cosa satura(forse) o meglio cosa nella maggior parte dei casi satura(forse) tutta la banda a disposizione 1GBps(che non è poca), una volta esclusi i dati di Fisica e Texture.

Originariamente inviato da halnovemila

Al contrario, lo spostamento dell'elaborazione della fisica degli oggetti sulla GPU, se da un lato "alleggerisce" la CPU e può contribuire a rimuovere eventuali condizioni di CPU-limited, dall'altro credo che implicherà una maggiore e più stretta comunicazione tra CPU e GPU, anche bidirezionale, per la trasmissioni di dati di elaborazione controllo e sincronizzazione di cui, in caso contrario, non ci sarebbe bisogno.

Non credo. Io penso che la Fisica gestita dalla GPU rimanga pura gestione e lavoro di quest' ultima.
La Physics Processing Unit o PPU, è un microprocessore dedicato e ottimizzato per la gestione del calcolo della fisicità degli oggetti virtuali.
È quindi un'enorme rivoluzione, soprattutto nel campo della grafica tridimensionale, in quanto tutti i movimenti degli oggetti, le collisioni tra poligoni e tutto quello che riguarda il tridimensionale non viene più elaborato dalla CPU del computer, ma dal processore della Scheda Video, ottimizzato per quel tipo di calcoli.(non avrebbe senso da parte della GPU comunicare alla CPU un lavoro già compiuto, svolto in tempo reale)
Alla CPU viene quindi tolta una notevole mole di lavoro, quindi la potenza di calcolo può essere impiegata ad altri scopi, tra cui la gestione del sistema operativo, del motore di gioco, dell'intelligenza artificiale ecc. (in questo caso vi sarà uno scambio di dati ed ha un senso lo scambio GPU/CPU)
Tratto da WiKipedia: http://it.wikipedia.org/wiki/Physics_Processing_Unit
Phisx da nVidia: http://www.nvidia.it/object/physx_new_it.html

Originariamente inviato da halnovemila

Prima cosa: Tanto per cominciare la HD4 870 Vapor-X che ho utilizzato per i test disponeva di 1GB di RAM GDDR5 (l'ho scritto nei dati relativi alla configurazione del PC

Ho editato....al posto dei 512MB ho messo 1G, ma tanto la risultante non cambia, perchè come detto a jamby93:
non tutte le applicazioni ad oggi sono in grado di sfruttare la memoria video in maniera ottimale(COD-4 fà parte di questi....) ma questo handicap andrà scomparendo.......
Come già è avvenuto con: Futuremark 3DMark06, PCMark Vantage e Prey o Quake.

[halnovemila]

Originariamente inviato da Six1

Allora spiegami cosa satura(forse) o meglio cosa nella maggior parte dei casi satura(forse) tutta la banda a disposizione 1GBps(che non è poca), una volta esclusi i dati di Fisica e Texture.

Ovviamente la geometria; ovvero l'insieme di quelle milioni di coordinate spaziali che definiscono le superfici poligonali (hai usato tu la parola "wireframe"? ) sulle quali poi vanno calcolati gli effetti di luce e applicate le texture.
Poi ovviamente ci sono tutti i dati relativi alle proprietà delle superfici.
Poi ci sono i dati relativi alle proprietà degli oggetti particellari.

Originariamente inviato da Six1

Non credo. Io penso che la Fisica gestita dalla GPU rimanga pura gestione e lavoro di quest' ultima.

Anche se fosse, ciò non porterebbe ad alcuna riduzione del carico di dati in transito sul Bus rispetto alla situazione in cui l'elaborazione della fisica rimane in carico alla CPU; infatti in quest'ultimo caso, dato che la GPU è esclusa dal processo, non ci sono dati relativi in transito sul bus dalla CPU alla GPU.
La cosa sarebbe ben diversa se oltre al calcolo della fisica la GPU provvedesse in maniera autonoma o semi-autonoma anche al calcolo della geometria.

Originariamente inviato da Six1

Ho editato....al posto dei 512MB ho messo 1G, ma tanto la risultante non cambia, perchè come detto a jamby93:
non tutte le applicazioni ad oggi sono in grado di sfruttare la memoria video in maniera ottimale(COD-4 fà parte di questi....) ma questo handicap andrà scomparendo.......

Sarà anche un handicap come tu dici, fattostà che di questo handicap la HD3 850 con 512MB e AGP 8x (metà della memoria on board della HD4870 da me testata) sembra non curarsi dato che nello stesso identico punto dello stesso identico gioco produce molti più Fps.
Riepilogando con 1GB e una scheda da 2000 punti Unigine e PCIe@4x ottengo 33 fps, invece con 512MB, una scheda da 1000 punti Unigine e AGP@8x ne ottengo 47.

Comunque CoD4 è un gioco che funziona fluidamente (senza scatti o stuttering dovuti al trasferimento delle texture) con il massimo della qualità sulle texture anche su schede video dotate di 256MB on-board, o addirittura con 128MB... provato personalmente con una GeForce 6800LE 128MB DDR, una X800Pro e XT 256MB DDR e una 6800 Ultra 256MB DDR3 (insomma tutto il mio parco di schede video attualmente ancora operative )