[Thread Ufficiale - GM200] Geforce GTX TITAN X - GTX 980ti

[Thunder-74]

Ragazzi, fatto prologo di MGS V, i frame sono lockati a 60...
pur contemplando la mia res, mi mostrava 2 belle bande nere ai lati e così ho giocato in 16/9... con tutte le impostazioni al massimo, le schede stavano sul 30% con le freq. sul profilo più basso (1020 mhz circa), solo in caso di esplosioni salivano a freq boost.

Poi ho cercato in rete e ho trovato il fix per i 21:9 (si sotituisce il file .exe)
il titolo merita veramente, sopratutto per i fan di MGS

Prima...




Dopo....

[Nurabsa]

Originariamente inviato da TigerTank

Io uso i cotton fioc, prima asciutti e poi imbevuti di alcool isopropilico

grazie proverò

ho messo su la "famosa" gelid extreme gc sto giro, tanto consigliata su sto thread..

20ina di min su mgs5 40° in fhd 57° in 4kdsr provero meglio nei prossimi giorni.

sulla cpu rispetto alla noctua direi un 5° meno, sto sui 50° (tamb 30)

[mikael84]

Originariamente inviato da Thunder-74

Ragazzi, fatto prologo di MGS V, i frame sono lockati a 60...
pur contemplando la mia res, mi mostrava 2 belle bande nere ai lati e così ho giocato in 16/9... con tutte le impostazioni al massimo, le schede stavano sul 30% con le freq. sul profilo più basso (1020 mhz circa), solo in caso di esplosioni salivano a freq boost.

Poi ho cercato in rete e ho trovato il fix per i 21:9 (si sotituisce il file .exe)
il titolo merita veramente, sopratutto per i fan di MGS

Prima...



Dopo....

Buono, mettigli uno sweet fx vedrai che resa

Intanto anche il benchmark


http://www.pcgameshardware.de/Metal-...-Test-1169803/

Originariamente inviato da maxmix65

Appena si fresca un po' voglio testare per bene quella con asic piu' basso ma se non sbaglio saliva forse 4/5 mhz meno di quell'altra..
Pero' non avevo usato Msi AB con bios sbloccato e voltaggio a 1.24...potrebbe essere una sorpresa chi lo sa'

Ma gli hai selezionati te stesso i silici

[Fabryce]

Originariamente inviato da Thunder-74

Poi ho cercato in rete e ho trovato il fix per i 21:9 (si sotituisce il file exe)

interessa anche a me il fix... magari lo si mette anche in prima pagina del thread di MGSV

[eXeS]

Originariamente inviato da Thunder-74

Io la vedo così .... Come dici tu la situazione è triste perché nvidia assicura la compatibilità piena delle dx12 con Maxwell, senza dirci che superati 31 calls simultanei di questo "comando", le prestazioni crollano

Aspetta, secondo un bench sintetico sviluppato da un utente credo di beyond3d, che comunque si dichiara neofita e quindi i risultati andrebbero presi con le pinze, la 980ti sino a 128 call non soffre particolarmente rispetto a Fury, anzi, sino a 32 va il doppio, e il problema sembrerebbe manifestarsi dopo le 128 call.

Se i dati di quel bench sintetico sono corretti anche se le prestazioni crollano dopo le 128 call, non significa che Maxwell non è pienamente compatibile con le dx12, ma piuttosto che a causa di scelte architetturali differenti rispetto a AMD, in un contesto di forte parallelismo, è penalizzato.

Ti faccio un semplice esempio, supponi di avere 2 cpu con stesso ipc, una con 32 core e una con 128, la cpu con 32 core opera a 4GHz mentre l'altra a 1GHz

Se fai girare un'applicazione che impegna solo 32 core la prima lo eseguirà ad esempio in 1 secondo, mentre l'altra in 4 secondi.

Se impegni 64 core la prima la eseguirà in 2.1 secondi (sto sparando un numero a caso), 2.1 e non 2 perché c'è di mezzo lo scheduler che spreca tempo nello switchare i 64 thread sui 32 core, mentre l'altra ancora in 4 secondi.

Se impegni 128 core la prima la eseguirà in 4.4 secondi (sto continuando sparare numeri a caso), 4.4 e non 4 sempre perché c'è di mezzo lo scheduler, mentre l'altra ancora in 4 secondi.

Se impegni 256 core la prima la eseguirà in 8.8 secondi (sto continuando a sparare numeri a caso), 8.8 e non 8 sempre perché c'è di mezzo lo scheduler, mentre l'altra in 8.1 secondi, e finalmente interviene lo scheduler della seconda.

Questo esempio cosa dimostra, che il peso dello scheduler all'aumento del numero di thread concorrenti può introdurre delle latenze tali per cui nonostante i 4GHz, la cpu a 32 core in contesti particolari prenderà la paga da quella a 1GHz con 128 core, ma non significa che una è da buttare mentre l'altra è un'opera divina, ma più semplicemente, che sono diverse.

Io come programmatore che farei, rendendomi conto che lo scheduler dell'OS mi riduce troppo le prestazioni, la schedulazione potrei provare a farla a codice, ad esempio, anziché sparare tutti i thread contemporaneamente alla cpu ne serializzerei l'esecuzione tenendo conto del numero di core, supponendo che i thread siano 256 nel caso della cpu a 32 core li distribuirei su 4 code che invierei sequenzialmente alla cpu e nel caso della cpu con 256 core li distribuirei tutti su una sola coda. Con questo workaround potrei mitigare l'impatto dello schedulatore sui tempi di esecuzione relativi alla cpu con 32 core, oppure peggiorarli, chissà

Penso che probabilmente gli stessi concetti siano applicabili agli async shader, se Maxwell è vero che li supporta in hardware, è possibile che quel bench di Oxide spari alla GPU un numero di comandi asincroni così elavato da mandare in crisi lo schedulatore di maxwell, che magari è anche meno efficiente di quello di AMD, ma come dicevo nell'altro thread, continuo a non spiegarmi perché nVidia che si dice abbia avuto diversi contatti con Oxide anziché collaborare con il developer per adeguare il codice, lo abbia liquidato chiedendo di disabilitare l'uso degli async shader

[Thunder-74]

Originariamente inviato da eXeS

Aspetta, secondo un bench sintetico sviluppato da un utente credo di beyond3d, che comunque si dichiara neofita e quindi i risultati andrebbero presi con le pinze, la 980ti sino a 128 call non soffre particolarmente rispetto a Fury, anzi, sino a 32 va il doppio, e il problema sembrerebbe manifestarsi dopo le 128 call.

Se i dati di quel bench sintetico sono corretti anche se le prestazioni crollano dopo le 128 call, non significa che Maxwell non è pienamente compatibile con le dx12, ma piuttosto che a causa di scelte architetturali differenti rispetto a AMD, in un contesto di forte parallelismo, è penalizzato.

Ti faccio un semplice esempio, supponi di avere 2 cpu con stesso ipc, una con 32 core e una con 128, la cpu con 32 core opera a 4GHz mentre l'altra a 1GHz

Se fai girare un'applicazione che impegna solo 32 core la prima lo eseguirà ad esempio in 1 secondo, mentre l'altra in 4 secondi.

Se impegni 64 core la prima la eseguirà in 2.1 secondi (sto sparando un numero a caso), 2.1 e non 2 perché c'è di mezzo lo scheduler che spreca tempo nello switchare i 64 thread sui 32 core, mentre l'altra ancora in 4 secondi.

Se impegni 128 core la prima la eseguirà in 4.4 secondi (sto continuando sparare numeri a caso), 4.4 e non 4 sempre perché c'è di mezzo lo scheduler, mentre l'altra ancora in 4 secondi.

Se impegni 256 core la prima la eseguirà in 8.8 secondi (sto continuando a sparare numeri a caso), 8.8 e non 8 sempre perché c'è di mezzo lo scheduler, mentre l'altra in 8.1 secondi, e finalmente interviene lo scheduler della seconda.

Questo esempio cosa dimostra, che il peso dello scheduler all'aumento del numero di thread concorrenti può introdurre delle latenze tali per cui nonostante i 4GHz, la cpu a 32 core in contesti particolari prenderà la paga da quella a 1GHz con 128 core, ma non significa che una è da buttare mentre l'altra è un'opera divina, ma più semplicemente, che sono diverse.

Io come programmatore che farei, rendendomi conto che lo scheduler dell'OS mi riduce troppo le prestazioni, la schedulazione potrei provare a farla a codice, ad esempio, anziché sparare tutti i thread contemporaneamente alla cpu ne serializzerei l'esecuzione tenendo conto del numero di core, supponendo che i thread siano 256 nel caso della cpu a 32 core li distribuirei su 4 code che invierei sequenzialmente alla cpu e nel caso della cpu con 256 core li distribuirei tutti su una sola coda. Con questo workaround potrei mitigare l'impatto dello schedulatore sui tempi di esecuzione relativi alla cpu con 32 core, oppure peggiorarli, chissà

Penso che probabilmente gli stessi concetti siano applicabili agli async shader, se Maxwell è vero che li supporta in hardware, è possibile che quel bench di Oxide spari alla GPU un numero di comandi asincroni così elavato da mandare in crisi lo schedulatore di maxwell, che magari è anche meno efficiente di quello di AMD, ma come dicevo nell'altro thread, continuo a non spiegarmi perché nVidia che si dice abbia avuto diversi contatti con Oxide anziché collaborare con il developer per adeguare il codice, lo abbia liquidato chiedendo di disabilitare l'uso degli async shader

Sicuramente i tempi non sono maturi per avere un quadro completo della situazione e il fare un po' "strano" di nvidia, probabilmente ha creato più clamore di quanto non sarebbe stato, se avesse provato a collaborare come dici tu.
io avevo visto al volo questo grafico della 980ti dove ogni 32 calls, aumentano i tempi di esecuzione:


Mentre da questo si capisce la relazione tra 980ti e Fury X, come dici tu

[TigerTank]

Originariamente inviato da maxmix65

Vai di palit JS su amazon


Bellissimo pcb il problema e' solo la garanzia ..in caso di Rma..
Comunque sulla review vedo la comparazione tra le schede che salgono di piu'..la Palit JS e' la migliore..sara' un caso

Il fatto è che a questo giro le alimentazioni custom possono poco se non sotto freddo estremo e con possibilità di overvolt stabili, tutto si gioca soprattutto nella bontà della gpu nel salire praticamente a vdef.

Originariamente inviato da Nurabsa

grazie proverò

ho messo su la "famosa" gelid extreme gc sto giro, tanto consigliata su sto thread..

20ina di min su mgs5 40° in fhd 57° in 4kdsr provero meglio nei prossimi giorni.

sulla cpu rispetto alla noctua direi un 5° meno, sto sui 50° (tamb 30)

Prego! Io ho preso un flacone sulla baia e ha pure un odore che mi piace moltissimo

Ottima la pasta, la proverò anch'io una volta finita la Noctua.

[AndreTM]

Originariamente inviato da mikael84

AMD ha ben 8 ACE che gestiscono 64 code ma vederla come una situazione triste al momento ce ne passa
Per ora hai un 25% su AMD in stock

Cmq review della colorful, peccato non si reperisca qui
http://www.techpowerup.com/reviews/C..._980_Ti/3.html

PCB davvero serio
http://www.techpowerup.com/reviews/C...ages/front.jpg

Quoto

Molto bella Avevano fatto la stessa cosa con la 980. Dovrebbe essere l'unica a utilizzare quei condensatori

[Luca T]

Originariamente inviato da mikael84

Buono, mettigli uno sweet fx vedrai che resa

Intanto anche il benchmark


http://www.pcgameshardware.de/Metal-...-Test-1169803/



Ma gli hai selezionati te stesso i silici

Ora hanno rilasciato il reshade, solo che non so mai come impostarli e alla fine cerco un profilo già fatto

[eXeS]

Originariamente inviato da Thunder-74

Sicuramente i tempi non sono maturi per avere un quadro completo della situazione e il fare un po' "strano" di nvidia, probabilmente ha creato più clamore di quanto non sarebbe stato, se avesse provato a collaborare come dici tu.
io avevo visto al volo questo grafico della 980ti dove ogni 32 calls, aumentano i tempi di esecuzione:

Certo, ma quello è un per limite architetturale, se maxwell è stato concepito per poter elaborare contemporaneamente 32 call, è normale che se gliene ficchi in pancia di più i tempi aumentano, è come se cercassi di mettere 2 litri di acqua in un contenitore da 1 litro, se la capienza è quella, potrai farlo solo in due passaggi.

Originariamente inviato da Thunder-74

Mentre da questo si capisce la relazione tra 980ti e Fury X, come dici tu

Era esattamente quello a cui mi riferivo

[Thunder-74]

Ragazzi, Mad Max non è affatto male e sfrutta lo SLI in modo pazzesco: schede sempre al max ... senza Vsync ho punte di 200 frames.
Anche da rece si vede molto bene, scala più dello 90%:


Graficamente e come gameplay, ricorda un po' TR/Uncharted/Rage

Originariamente inviato da mikael84

Buono, mettigli uno sweet fx vedrai che resa

Intanto anche il benchmark


http://www.pcgameshardware.de/Metal-...-Test-1169803/



Ma gli hai selezionati te stesso i silici

Cavoli Andrea...alla faccia tua ho ancora la terza config piu potente in sli ahahah....vabbè tornando seri....sti giochi cappati stanno un po rompendo.

[cloe1]

980 Ti arrivata...
Domani la testo

[athlon xp 2400]

ma quindi 2 780 ti rullano sempre alla grande? non era morto Kepler?

[Pozhar]

Originariamente inviato da cloe1

980 Ti arrivata...
Domani la testo

Quale hai preso?

[AndreaMan]

Originariamente inviato da fabietto27

Cavoli Andrea...alla faccia tua ho ancora la terza config piu potente in sli ahahah....vabbè tornando seri....sti giochi cappati stanno un po rompendo.

Ma va la patacca!!!!
cUmpra!!!!!

Originariamente inviato da Pozhar

Quale hai preso?

MSI gaming

Inviato dal mio Nexus 6

[mikael84]

Originariamente inviato da AndreTM

Molto bella Avevano fatto la stessa cosa con la 980. Dovrebbe essere l'unica a utilizzare quei condensatori

Bellissima purtroppo non si riesce ad avere informazioni più tecniche. Il VRM è del tutto diverso dal chil delle classy o dai classici Onsemi
Cmq si anche la 980 era uguale, rimane interessante in quanto l'unica ad integrare i PLL (che sono anche r47, le fasi della giga kepler) come la Kingpin

Originariamente inviato da gianfernando

Ho già sentito amazon, la sostituzione non riesce a farla perché gainward 980ti al momento non sono disponibili, potrei proporre se possono spedirmi un altra marca pagando la differenza, questa la ho pagata 664€, ma la cosa mi sembrava strana perché il sigillo della scatola mi sembrava già stato sollevato....


Inviato dal mio iPhone utilizzando Tapatalk

A 669 hanno le zotac amp codice zt 90503....

[mikael84]

Originariamente inviato da athlon xp 2400

ma quindi 2 780 ti rullano sempre alla grande? non era morto Kepler?

Ma quando mai

[ilcose]

In ogni caso per il discorso async shader su Maxwell 2 usando il programma di test su beyond 3d nessun possessore di Maxwell esegue in maniera asincrona i calcoli. In tutti i report il tempo computazionale di grafica e compute è sempre uguale a un intorno della somma dei 2. Sulle AMD fino a 128 kernel è un intorno del maggiore dei 2 valori. Ovvero al momento anche con quel test Maxwell non computa in maniera asincrona.

Inviato dal mio SM-G920F