Hardware Upgrade Forum

Hardware Upgrade Forum (https://www.hwupgrade.it/forum/index.php)
-   Schede Video - Discussioni generali (https://www.hwupgrade.it/forum/forumdisplay.php?f=28)
-   -   [Thread Ufficiale] Aspettando le nuove vga nVidia (https://www.hwupgrade.it/forum/showthread.php?t=2457431)


Pelvix 06-09-2016 14:16

Quote:

Originariamente inviato da fraussantin (Messaggio 44002214)
ci vorranno 1,2 anni dalla diffusione.

Nal passaggio ai dual-core prima, e ai quad-core dopo ci è voluto molto di più: addirittura ancora oggi non so quanti giochi sfruttino davvero un quad core

fraussantin 06-09-2016 14:20

Quote:

Originariamente inviato da Pelvix (Messaggio 44002272)
Nal passaggio ai dual-core prima, e ai quad-core dopo ci è voluto molto di più: addirittura ancora oggi non so quanti giochi sfruttino davvero un quad core

beh basta un assassin creed di turno , o un gta 6 , e vedi come corrono a comprarlo. però il processore , a differenza della vga si scala male , e devono stare accorti a non accelerare troppo altrimenti rischiano di non vendere ne l'uno , ne l'' altro.

anche perchè la cpu non si cambia come la vga. bisogna farsi il pc nuovo in pratica

Ale55andr0 06-09-2016 14:21

Quote:

Originariamente inviato da fraussantin (Messaggio 44001940)
Ma sicuro che ricambiano il socket di nuovo?


Cmq il 6700k è pure troppo per giocare.

no, mai detto, il socket non cambia, ma non è che il 7700k al lancio costerà quanto costa OGGI il 6700k...starà sui 400 e dintorni e comunque sopra i 350 per un bel po', come il 6700 qualche mese fa del resto, non è che sia calato da eoni. Per la scheda madre teoricamente potrebbe andar bene una "vecchia" z-170 se il costruttore a aggiorna il bios, ma poi che fai, ti pigli il 7700k e non ci metti una nuova mobo z-270? :stordita:

Quote:

Originariamente inviato da mikael84 (Messaggio 44002134)



Perchè fermacarte, una 960 con requisiti da 750ti. :)

giusto, un fermacarte coi requisiti di un'altro ferma carte quindi :O

:D

Quote:

Originariamente inviato da mikael84 (Messaggio 44002263)
Si c'è un piccolo miglioramento branch prediction e sulla edram, migliori latenze in generale ma niente di che. Se si vuole cambiare una CPU con il socket attuale tanto vale farsi un buon skylake.:)
.


che è esattamente quello che farò pigliando un 6700k che ora si trova poco sopra i 300 :)

Luca T 06-09-2016 21:37

Quote:

Originariamente inviato da mikael84 (Messaggio 44002134)
Stesso socket, ma non cambierà nulla, è come broadwell per haswell, molte testate non l'hanno neppure recensito. Unica miglioria l'integrata.:)
I primi 10nm non li vedremmo per desktop ma per netbook e tablet. Le CPU desktop saranno Coffee lake, nuovo socket e probabili 6 core anche sulla fascia performance.D

Intendi che kaby lake per desktop lo chiameranno Coffe-lake?

mikael84 06-09-2016 22:45

Quote:

Originariamente inviato da Ale55andr0 (Messaggio 44002294)


giusto, un fermacarte coi requisiti di un'altro ferma carte quindi :O

:D




che è esattamente quello che farò pigliando un 6700k che ora si trova poco sopra i 300 :)

Non è un fermacarte:p
Se costa poco più di 120 euro e va quanto una 960 e consuma quanto una 750 non mi pare male.:)
Certo non fa per te, o meglio al caso tuo per sostituire la 290.:)

Quote:

Originariamente inviato da Luca T (Messaggio 44003793)
Intendi che kaby lake per desktop lo chiameranno Coffe-lake?

No Kaby è su socket skylake, coffee quello dopo.:)

Devourer88 09-09-2016 19:49

@mikael84

Stavo leggendo rumor in giro e dopo aver fantasticato ho pensato: "fammi chiedere a chi ne sà più di me nel forum!" :D

Ipotesi 1° Volta con architettura simile ad amd che si rifletterebbe con un aumento enorme del numero di shader ed aggiunta dell'Asynchronous compute che eleverebbe le performance di un 50-100% rispetto a pascal

Ipotesi 2° Volta con Cuda core migliorati con performance massimo 50% superiori a pascal anche se ipotizziamo cuda raddoppiati e mancanza di Asynchronous compute


Tutte ste pippe mentali per aver letto che nvidia vuole aggiungere in futuro l'Asynchronous compute :confused:

eXeS 09-09-2016 20:20

Quote:

Originariamente inviato da Devourer88 (Messaggio 44014098)
Tutte ste pippe mentali per aver letto che nvidia vuole aggiungere in futuro l'Asynchronous compute :confused:

Che hai letto dove ?

Ale55andr0 09-09-2016 20:50

Quote:

Originariamente inviato da Devourer88 (Messaggio 44014098)

Tutte ste pippe mentali per aver letto che nvidia vuole aggiungere in futuro l'Asynchronous compute :confused:

no possibile, è stato spiegato molte volte che nvidia ha un'architettura efficiente e non ne ha bisogno :O fosse altrimenti vorrebbe dire due cose:

-o che con volta faranno appositamente una architettrua inefficiente (:asd:) che avrà gli ace per compensare (spiegazione data da alcuni in merito a gcn)

-o che la cosa di cui sopra è una cazzata e che nvidia non ha gli ace perchè semplicemente non aveva nulla di gia pronto dopo maxwell che li avesse :stordita:

mikael84 09-09-2016 23:22

Quote:

Originariamente inviato da Devourer88 (Messaggio 44014098)
@mikael84

Stavo leggendo rumor in giro e dopo aver fantasticato ho pensato: "fammi chiedere a chi ne sà più di me nel forum!" :D


Ipotesi 1° Volta con architettura simile ad amd che si rifletterebbe con un aumento enorme del numero di shader ed aggiunta dell'Asynchronous compute che eleverebbe le performance di un 50-100% rispetto a pascal

Ipotesi sbagliata, AMD ed nvidia hanno un'architettura diversa, una utilizza 4 vettori e 16 ALU e relativa cache, l'altra lavora in proporzione 4:1:1 con unità funzionali ALU/lds/SFU (che si occupano di calcoli anche come seno, coseno, radice quadrata).
La prima architettura soffriva di overhead, questo rende praticamente impossibile alle radeon (tranne la 480) di sfruttare a corsia completamente il multi thread delle CPU, fattore che creava un buco di calcolo enorme.
Gli ACE lavorano parallelamente su diversi tipi di calcolo per poi inviarlo allo shader core limitando le perdite. La GCN non è in grado come Pascal di memorizzare dati in cache e metterli in coda, tutto ciò che viene calcolato passa in shader core.
La GCN pur operando a latenze in ms non soffre come maxwell la gestione delle code.

Quindi se un'architettura ti lavora al 60%, con il lavoro parallelo puoi elaborare shader affinchè le ALU non rimangano in IDLE.
Avere ACE hardware significa che si possono programmare 1000 shader su shader core 2 25000 asyncroni.

La RX 480 utilizza 2 HWS e limita quasi del tutto il problema overhead, Nvidia invece sfrutta l'architettura quasi sempre al meglio, e con Pascal usa i buffer cache (in ns) per memorizzare dati ed elaborarli quando richiesto, ma se l'architettura viene sfruttata al 90%, che te ne fai di dati in memoria (rimangono in coda);)

Quote:

Originariamente inviato da Devourer88 (Messaggio 44014098)
Ipotesi 2° Volta con Cuda core migliorati con performance massimo 50% superiori a pascal anche se ipotizziamo cuda raddoppiati e mancanza di Asynchronous compute

Su Nvidia come detto sopra l'asynch non manca, può magari essere perfezionato.
Su Volta prevedo un simil Tesla con 1024 istruzioni per cuda e lavoro su 64 cuda, per fare in modo di avvicinarla maggiormente a GCN (thread max multiprocessor 2048).
Ricorda che più istruzioni hai contemporanee meno accedi in cache, meno accedi in cache (10-12 cicli) ti ritrovi con latenze migliori, banda sgravata e minimi migliori.

Quote:

Originariamente inviato da Devourer88 (Messaggio 44014098)
Tutte ste pippe mentali per aver letto che nvidia vuole aggiungere in futuro l'Asynchronous compute :confused:

No tranquillo, di Volta ancora non si sa nulla (magari sapessi almeno un minimo):)

appleroof 10-09-2016 09:18

Quote:

Originariamente inviato da mikael84 (Messaggio 44014569)
cut


No tranquillo, di Volta ancora non si sa nulla (magari sapessi almeno un minimo):)

esatto :D

Legolas84 10-09-2016 10:25

Quote:

Originariamente inviato da Ale55andr0 (Messaggio 44014280)
no possibile, è stato spiegato molte volte che nvidia ha un'architettura efficiente e non ne ha bisogno :O fosse altrimenti vorrebbe dire due cose:

-o che con volta faranno appositamente una architettrua inefficiente (:asd:) che avrà gli ace per compensare (spiegazione data da alcuni in merito a gcn)

-o che la cosa di cui sopra è una cazzata e che nvidia non ha gli ace perchè semplicemente non aveva nulla di gia pronto dopo maxwell che li avesse :stordita:

:asd: che ti fumi per avere queste visioni???? :asd:

Fortuna che c'è mikael che subito sotto spiega la reale situazione... ah no ma mikael e ren non sono affidabili, sparano supercazzole :asd:

NVIDIA già supporta e usa pienamente l'async compute sebbene in modo diverso da AMD.... ne beneficia meno però perchè si, ha un'architettura molto più efficiente di AMD attualmente.

mirkonorroz 10-09-2016 11:04

@mikael

da quello che hai scritto si puo' dedurre che per le 480 gli ACE sono meno influenti che per le schede precedenti?

devil_mcry 10-09-2016 11:54

Quote:

Originariamente inviato da mirkonorroz (Messaggio 44015204)
@mikael

da quello che hai scritto si puo' dedurre che per le 480 gli ACE sono meno influenti che per le schede precedenti?

In effetti di un poco si



Se guardi la 480 Nitro e la 390 Nitro, che hanno quasi gli stessi FPS in DX11, nel passaggio in DX12 abbiamo

+ 25% circa per la 390 Nitro
+ 19% circa per la 480 Nitro

Ci sono oscillazioni in base ai preset, quello è il più pesante, a 1440p con un preset più morbido la 480 va persino di più in DX11 della 390 per poi andare di meno in DX12



Si parla ovviamente di percentuali basse di per se, un fps e mezzo ma se si considera che 3 fps sono la differenza in quel gioco tra la 390 e 390x comunque non ci sono nemmeno 4fps...

Ale55andr0 10-09-2016 13:28

Quote:

Originariamente inviato da Legolas84 (Messaggio 44015101)
:asd: che ti fumi per avere queste visioni???? :asd:

.



quello che dici tu :Prrr:, che nvidia non ha ace perchè "non ne ha bisogno". Quindi se sulla prossima architettura li avesse le ipotesi sono quelle: o sono inefficienti e dovranno montarli per mettere na pezza (tua spiegazione in merito alla presenza degli ace in gcn) o semplicemente che non li aveva prima perchè non ne ve ne era "bisogno" era una bubbola, delle due l'una. Quanto detto da mikael non c'entra col discorso di cui sopra: ha detto che di volta non sa nulla come nessuno del resto e a quello mi riferisco, le future gpu
Quindi io vorrei proprio sapere che diresti se su volta nvidia dichiarasse esplicitamente delle unità async compute hardware :D

egounix 10-09-2016 13:37

Quote:

Originariamente inviato da Ale55andr0 (Messaggio 44015639)
quello che dici tu :Prrr:, che nvidia non ha ace perchè "non ne ha bisogno". Quindi se sulla prossima architettura li avesse le ipotesi sono quelle: o sono inefficienti e dovranno montarli per mettere na pezza (tua spiegazione in merito alla presenza degli ace in gcn) o semplicemente che non li aveva prima perchè non ne ve ne era "bisogno" era una bubbola, delle due l'una. Quanto detto da mikael non c'entra col discorso di cui sopra: ha detto che di volta non sa nulla come nessuno del resto e a quello mi riferisco, le future gpu
Quindi io vorrei proprio sapere che diresti se su volta nvidia dichiarasse esplicitamente delle unità async compute hardware :D

Mica ci sono per forza solo queste due ipotesi, potrebbe metterli per rendere ancora più efficiente la sua scheda, o magari solo per "gabbare" alessandro :stordita:

JHH ha mille risorse, e si è sbattuto le poppone di lisa su.

Legolas84 10-09-2016 13:38

Quote:

Originariamente inviato da Ale55andr0 (Messaggio 44015639)
quello che dici tu :Prrr:

Guarda mi sono fermato a leggere le prime 4 parole... :asd: Il resto nemmeno lo guardo.

Quello che penso io è quello che ho scritto sopra, ed è quello che Mikael e Ren ripetono da mesi :asd:

Ale55andr0 10-09-2016 13:44

Quote:

Originariamente inviato da Legolas84 (Messaggio 44015672)
Guarda mi sono fermato a leggere le prime 4 parole... :asd:


..eeeh comodo così, ha perso il meglio: la provocazione finale :read: :Prrr:

Ale55andr0 10-09-2016 13:45

Quote:

Originariamente inviato da egounix (Messaggio 44015669)
Mica ci sono per forza solo queste due ipotesi, potrebbe metterli per rendere ancora più efficiente la sua scheda.

eeeeh comodo così 2.0 :asd:

mikael84 10-09-2016 14:05

Quote:

Originariamente inviato da mirkonorroz (Messaggio 44015204)
@mikael

da quello che hai scritto si puo' dedurre che per le 480 gli ACE sono meno influenti che per le schede precedenti?

Con la 480 AMD ha introdotto gli HWS per limitare notevolmente il problema overhead.
Ha scelto quindi di dimezzare gli ACE per poter migliorare l'overhead.


Qua siamo di fronte ad un passo netto, tuttavia AMD ancora non riesce a fruttare completamente le ALU che i vettori forniscono.
Le ALU su questa scheda sono molto performanti, tanto che a livello di puro calcolo supera tranquillamente sia 980 che 1060, avvicinandosi a schede superiori come 1070 e 980ti.
Il trucco sta nello spremere il più possibile le unità di calcolo e cercare di fare lavorare il più possibile lo shader core.

La 480 ha un handicap, ovvero il bus di memoria troppo stretto che spesso si satura, tale scheda dovrebbe integrare un 384bit o delle ddr5x belle spinte almeno 12gb/s.
Ricordo che i dati di banda sono solo teorici e vanno rapportati all'MC e duna 290x con 263gb/s effettivi (non 312 teorici) è piuttosto più potente.

Chi necessita realmente del calcolo asyncrono è la fury, una scheda sbilanciata con problemi di overhead e con delle ALU che devono essere sfruttate.
A livello di ALU (float/vect4), una fury x è simile ad una 1080 ma ha un reparto geometrico scadentissimo, problemi con il backfaceculling, e delle rop's che sono specializzate per blending MSAA.
64 rop's AMD battono 128 rop's Nvidia su MSAA campionato 4x e passano ben avanti su MSAA8x.

Chiaramente la scheda spesso in 1080p e 1440p va quanto una 980 custom, questo è dovuto ad architettura totalmente sballata e non sfruttata.

Se un gioco dx11 usa principalmente i punti carenti di una fury è finita.

La 1080 no, usa quasi tutta l'architettura e grazie ai GPC ogni stadio moltiplicatore rende la scheda equilibrata e potente su ogni calcolo.

Pelvix 10-09-2016 14:21

Quote:

Originariamente inviato da mikael84 (Messaggio 44015744)
Con la 480 AMD ha introdotto gli HWS per limitare notevolmente il problema overhead.
Ha scelto quindi di dimezzare gli ACE per poter migliorare l'overhead.


Qua siamo di fronte ad un passo netto, tuttavia AMD ancora non riesce a fruttare completamente le ALU che i vettori forniscono.
Le ALU su questa scheda sono molto performanti, tanto che a livello di puro calcolo supera tranquillamente sia 980 che 1060, avvicinandosi a schede superiori come 1070 e 980ti.
Il trucco sta nello spremere il più possibile le unità di calcolo e cercare di fare lavorare il più possibile lo shader core.

La 480 ha un handicap, ovvero il bus di memoria troppo stretto che spesso si satura, tale scheda dovrebbe integrare un 384bit o delle ddr5x belle spinte almeno 12gb/s.
Ricordo che i dati di banda sono solo teorici e vanno rapportati all'MC e duna 290x con 263gb/s effettivi (non 312 teorici) è piuttosto più potente.

Chi necessita realmente del calcolo asyncrono è la fury, una scheda sbilanciata con problemi di overhead e con delle ALU che devono essere sfruttate.
A livello di ALU (float/vect4), una fury x è simile ad una 1080 ma ha un reparto geometrico scadentissimo, problemi con il backfaceculling, e delle rop's che sono specializzate per blending MSAA.
64 rop's AMD battono 128 rop's Nvidia su MSAA campionato 4x e passano ben avanti su MSAA8x.

Chiaramente la scheda spesso in 1080p e 1440p va quanto una 980 custom, questo è dovuto ad architettura totalmente sballata e non sfruttata.

Se un gioco dx11 usa principalmente i punti carenti di una fury è finita.

La 1080 no, usa quasi tutta l'architettura e grazie ai GPC ogni stadio moltiplicatore rende la scheda equilibrata e potente su ogni calcolo.

Scusa se mi intrometto, ma ho notato che in più occasioni fai riferimento alla banda reale e non teorica: potresti spiegarmi perchè la banda dichiarata in realtà non è tale? :help:


Tutti gli orari sono GMT +1. Ora sono le: 00:44.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Hardware Upgrade S.r.l.