Tutti i prezzi sono validi al momento della pubblicazione. Se fai click o acquisti qualcosa, potremmo ricevere un compenso.

Snapdragon 1000 confermato il TDP di 12 W e altre informazioni

22 Giugno 2018 240

Aggiornamento 22/06

WinFuture ha avuto modo di snocciolare ulteriori dettagli attorno a Snapdragon 1000, il prossimo SoC Qualcomm dedicato ai computer Windows on Arm. Per prima cosa viene confermato il codice SDM1000, quindi non ci sono dubbi sulla nomenclatura che verrà adottata dal chip, così come è stato appurato il TDP di 12 Watt ipotizzato in precedenza.

Una novità importante riguarda il fatto che il SoC verrà alloggiato in un socket, quindi non sarà integrato nella scheda madre del prodotto. Stando a quanto emerso, la piattaforma di sviluppo è attualmente equipaggiata con 16GB di memoria LPDDR4X e due moduli di memoria UFS 2.1 da 128GB ciascuno.

Insomma, Snapdragon 1000 potrebbe essere il primo SoC Arm in grado di competere ad armi pari con alcune delle soluzioni Intel pensate per la stessa categoria di prodotto. Ora non si parla più di un chip proveniente dal mondo smartphone e riadattato all'utilizzo su PC, bensì di una piattaforma che nasce appositamente per supportare al meglio Windows on Arm.

Articolo originale del 7 giugno

Snapdragon 1000 potrebbe essere il più ambizioso passo compiuto Qualcomm nel mondo dei PC basati su Windows on Arm. Avvistato pochi giorni fa, poco prima del debutto di Snapdragon 850, il SoC in questione dovrebbe essere dedicato esclusivamente all'impiego nei portatili sempre connessi. Oggi emerge un nuovo rumor riportato da WinFuture che ci suggerisce quella che potrebbe essere una delle caratteristiche chiave di Snapdragon 1000: un TDP da ben 12 Watt.

Se ciò dovesse essere confermato, si tratterebbe del primo SoC Arm ad esibire un TDP solitamente ad appannaggio dei chip Intel dedicati ai portatili. La mossa di Qualcomm sembra essere proprio una sfida diretta allo strapotere della casa di Santa Clara in ambito Windows.

Un chip Arm con un TDP da 12 W potrebbe impiegare core molto più grandi e complessi di quelli attualmente presenti sugli smartphone e persino sul più recente Snapdragon 850, il quale non si spinge oltre i 6,5 W. Qualcomm potrebbe far affidamento sul processo produttivo a 7nm di TSMC, applicato alla propria variante custom dei nuovi core Cortex-A76, spingendoli verso frequenze vicine ai 3,0GHz per un periodo di tempo decisamente superiore rispetto a quanto possibile su smartphone e tablet.

Qualcomm ha dalla sua la possibilità di offrire SoC capaci di autonomie impressionanti in ambito Windows, senza rinunciare alla presenza di modem di classe Gigabit sempre attivi. Intel non starà sicuramente a guardare e già nelle scorse ore ha dimostrato particolare interesse verso la realizzazione di nuove proposte a basso consumo, probabilmente basate sul suo processo produttivo a 10nm (non comparabile con i 7nm di TSMC).


240

Commenti

Regolamento Commentando dichiaro di aver letto il regolamento e di essere a conoscenza delle informazioni e norme che regolano le discussioni sul sito. Clicca per info.
Caricamento in corso. Per commentare attendere...
Gios

E ripeto il TDP è un dato tecnico non commerciale, i commercianti lo hanno trasformato in altro a livello commerciale.

DeeoK

Snapdragon di solito neanche lo fornisce.
Sei tu che confondi i dati di progettazione con quelli commerciali.
Al pubblico arriva sempre e comunque quello commerciale, a prescindere da chi sia il produttore. Resta comunque una scelta totalmente discrezionale.

Federico

Se per OS intendi Windows, e non vedo come altro potrebbe essere visto che parliamo di Windows on ARM, allora è a 32 bit.
Se invece intendi che AL DI FUORI del sistema di emulazione Intel potrebbe venir eseguito codice PE compilato per ARM 64, allora sì può essere fatto.
Ma questo non fa del sistema operativo nulla di diverso da un 32 bit.

pietro

Ma l'os è a 64bit. È un fatto inconfutabile.

Gios

Mi sa che ti sei fatto confondere dai sensi commerciali. Non sta al produttore decidere come calcolarlo, é il punto di riferimento per il progetto termico è tale deve essere.

Solo intel si è inventata il suo tdp, tutte le altre case, amd in testa fornisce il vero tdp

DeeoK

Facciamo così: guardati i test di CPU Intel e poi dimmi che il TDP dichiarato dia il worst case.

DeeoK

Ma chi se ne frega.
Il TDP è utile per i desktop, perché ti serve come indicazione per psu e raffreddamento. E da sempre per il TDP conviene guardare i test.
Sui notebook non è mai stato davvero rilevante se non in modo indicativo.

DeeoK

No, dipende dal produttore. In generale sono um ottimo compromesso tra consumi e prestazioni.

Davide

è migliore in efficienza a basse prestazioni, lo scaling non è lineare

pirata_1985

Scaffale ™

Nessuno

E le marmotte confezionano cioccolata

Leon94

Ma qualche informazione sull'Adreno?
Immagino che su Snapdragon 1000 sarà integrata una GPU altrettanto valida da concorrere con una Nvidia MX150.

Signor Citrus

Ottimi non direi.
E generano parecchio calore.
Sta diventando insostenibile la cosa di anno in anno.

Alberto

In entrambi i casi ti devi fidare fino a quando non uscirá un report tdpgate (dopo il dieselgate ci manca anche questo)

Gios

No rappresenta la Potenza termica da dissipare non il calore infatti si misura in watt (non leggere Wikipedia che la scrivono dei cani).

Il riferimento della TDP é il worst case che è la massima Potenza che deve essere dissipata quando il processore è mandato a massimo regime, quella a cui si riferiscono tutte le "persone normali".

Intel ha dato una sua definizione di TDP commerciale (precisando che i progettisti DEVONO fare riferimento alla sezione termica del datasheet dove forniscono il vero tdp), amd la chiama ATP.

DeeoK

L'alimentatore lo prendi sovradimensionato sui consumi stimati della somma delle componenti. Se lo prendi usando il TDP come valore esatto vedrai come ti si spegnerà il pc come alzi il carico.
Comunque sei libero di non credermi. Quello che ho scritto lo puoi leggere in qualunque recensione di hardware.

Ps: il TDP è in tutte le schede tecniche. Solo nei SoC per smartphone non lo trovi da quel che ho visto fino ad ora, ma perché tu utente ci faresti poco.

DeeoK

Ni, alla fine dipende sempre da quanto il produttore vuole essere onesto.

DeeoK

Nah. I Core M sono generalmente ottimi per efficienza. Se si vuole solo l'autonomia si punta sulle CPU ULV, i Core M sono pensati per dare anche prestazioni quando serve.

Federico

Beh... no.
In che senso è comunque a 64 bit?
Ai fini di Windows e del software Win32 è a 32 bit.
Io posso avere pure una CPU a un milione di bit, ma se poi questo milione di bit lo uso per emulare una CPU a 32 bit il sistema che viene eseguito lì sopra vedrà 32 bit.
Il milione di bit lo vedrebbe solo il software compilato nativamente per quella CPU perchè non passerebbe per l'emulatore (vero in parte, perchè eventuali chiamate a sistema verrebbero poi gestite a 32 bit perchè l'OS guest è a 32 bit).

E' una presa in giro con la quale si sta tentando di infinocchiare il cliente. Tutto è basato sul ragionamento che prima o poi le maggiori software house inizieranno a compilare per ARM, un po' come in passato sostenevano prima che avrebbero iniziato a programmare per UWP e quando videro che NESSUNO programmava per UWP cominciarono a fire che avrebbero fatto i porting tramite Centennial,
Nessuno programma in UWP, nessuno fa porting Centennial in UWP e nessuno compilerà mai per ARM. Non esistono condizioni di mercato sufficienti a giustificare i costi.

pietro

Ok, ma il sistema è comunque a 64bit

Federico

Baci & Abbracci

Alessio Ferri

Molto divertente... Tu invece sei laureato in comicità

Federico

Nessuno lo mette in dubbio.
Laureato in lettere?

Alessio Ferri

Avrai studiato te su Wikipedia, io ho studiato all'università

Federico

No, non hai spiegato proprio nulla.

Cosa c'entrano gli obiettivi?
Non è che un obiettivo abbia un qualche influsso sulla categoria architetturale, semmai lo avrà sui dettagli implementativi.

A me invece sembra più che evidente di trovarmi dinanzi l'ennesimo sciocco con una cultura wikipediana, che prima scrive una castroneria e poi invece che scusarsi continua a cercare il modo di uscirne.

Alessio Ferri

L'implementazione è differente solo a livello di decodifica, la parte seguente cambia solo per il numero di operandi (solitamente 2 per x86 e 3 per ARM)

Alessio Ferri

Non ha senso dire "un RISC che emula un CISC"! Te l'ho già detto è spiegato.
Il clock e l'ipc sono gli obiettivi principali quando si progetta una microarchitettura, è evidente a questo punto che non sai una mazza di quello che dici.

Cerbero

Davide, ARM è già migliore di x86 da diversi anni in quanto efficienza (non è l'unico RISC ad esserlo...). Questo però non è detto basti per imporsi in un mercato già fortemente monopolizzato e con un'ecosistema solido. Vedremo.

Federico

In che senso non valgono?
Il fatto che un RISC emuli un CISC implica un disegno del processore differente proprio a causa dell'ISA.
Un ISA (Instruction Set Architecture per i neofiti) CISC ed un ISA RISC portano con sè una implementazione in termini di porte completamente differente, ma questo è assolutamente evidente per chi conosce come sono costruiti i microprocessori mentre evidentemente NON lo è a quanti (ad es. l'autore del post a cui rispondevo) dicono che in una architettura Intel al crescere dell'Instruction Set cresca in modo corrispondente la complessità architetturale perchè la maggior crescita è solo nel microcodice.

Ancor meno c'entrano le velocità di clock, la velocità & co., cosa introdotta da te.

La tua mi è sembrata una contestazione fatta per il puro gusto di contestare o, più probabilmente, è la contestazione fatta da uno che poi di è andato a leggere tra cose su Internet e si è accorto do aver scritto una bestialità.

Federico

Essere un RISC che emula un CISC cambia tutto a livello di architettura, intendendo con questo proprio il disegno del processore.
Sono il clock e la velocità a non entrarci assolutamente niente.
Credo tu abbia le idee un po' confuse. ;)

Alessio Ferri

Che non è un RISC che emula un CISC, e soprattutto fa di microcodice solo per le istruzioni molto complesse, se lo facesse per tutte te lo sogni il clock a 4.0 ghz e l'ipc di 3.7, non arrivi a 1 nell'ipc e non arrivi a 1 ghz come velocità (più è grande il microcodice più è lento l'accesso).

Alessio Ferri

Ho appena detto RISC e CISC sono proprietà dell'ISA, all'interno sia i RISC che i CISC hanno unità di decodifica che trasformano l'istruzione dell'ISA nei segnali di controllo interni e portano avanti solo quelli, per cui è una differenza che inizia al fetch e finisce al decode.
I segnali di controllo interni non costituiscono un'ISA quindi non valgono i discorsi del tipo "CISC emulato da RISC".

ricky aty

già ARM è migliore ci vuole sempre tempo e anni :) mi piacerebbe usare questo processore snap dragon 1000 spero sia 8 cores o magari 10 sarebbe bello ma ci arriveremo

Federico

Un'ora fa mi hai detto che confondevo i dettagli implementativi con il set di istruzioni sotto un mio post che diceva ESATTAMENTE le stesse cose che hai appena scritto.
Che succede, hai dato una rapida occhiata a Wikiperdia? :)

Mio post:
"Ma gli Intel non sono dei RISC che emulano dei CISC gestiti da microcodice?"

Federico

Quali sarebbero i fatti?
Il sistema operativo identifica sè stesso come Windows 10 32 bit e Microsoft stessa dice che NON esegue software 86 a 64 bit.
Devo dedurre che tu hai informazioni certe riguardo al fatto che Microsoft stia mentendo sul suo stesso prodotto?

Federico

... e tutto questo cosa c'entra con l'essere un RISC che emula un CISC eseguendo un micro codice?

Vittorio Vaselli

tue supposizioni sbugiardate dai fatti.

Federico

No, quella non credo sia soggetta a brevetto.
In Intel i percorsi dell'architettura 32 bit e quella 64 bit furono differenti, mi pare di ricordare che in qualche modo ci sia entrata anche AMD ma è passato tanto tempo e io non mi sono mai interessato alla vicenda, comunque nulla di strano che sia brevettato solo uno dei due instruction set.

Federico

No, non funziona così.
La CPU emulata è x86_32 e quindi può eseguire unicamente software x86_32 in modalità emulata, e difatti anche il sistema operativo è il Windows 86 per x86_32.
Può eseguire codice s 64 bit ma solo al di fuori dell'emulazione, quindi codice ARM64, ma non esite software commerciale compiato per ARM64 e neppure esiterà mai, così come non esiste e non esisterà mai software commerciale scritto o portato su UWP.
Nota che sempre più spesso si compila per i soli target Intel a 64 bit perchè supportare anche l'architettura inferiore crea seri problemi nella scelta degli algoritmi da usare.
Anche un semplice sort, se deve essere veloce sul serio, viene scritto in modo differente se l'architettura sottostante e a 32 o a 64 bit e supportarle entrambe introduce un sacco di lavoro in più e di complicazioni.

Alessio Ferri

Adesso partono quelli del RISC vs CISC e che "x86 è in realtà RISC".
Lo diciamo una volta sola per tutti: la complessità è in relazione all'ISA, non all'implementazione.
Per tutti quelli che "all'interno è.. etc" ricordo che per le microarchitetture a pipeline in order o out of order perdono l'istruzione all'inizio dello stadio "Decode" e portano avanti solo i segnali di controllo orizzontali per le unità di esecuzione durante tutti gli eventuali stadi, va così per tutti: per ARM, per Intel, per Apple, per AMD.

pietro

No è a tutti gli effetti un bel niente di tutto cio.
L'os gira a 64bit, le uwp a 32 e 64 bit, le win32 a 32bit. Fine. Sono fatti, che piacciano o meno.
Che poi si possa discutere su quanto sia limitante il solo supporto alle win32 a 32 bit è pacifico, ma il sistema è a tutti gli effetti a 64bit.
Sono fatti, inutile discuterne ancora.

Vittorio Vaselli

Se il problema fossero le royalties non esisterebbe neanche l'emulazione a 32bit

Signor Citrus

Dovrebbero migliorare il prima possibile questo aspetto.
Alla fine sono passati 20 anni...

Federico

L'OS gira su un processore avviato a 64 bit che esegue codice ARM64 per emulare un x85_32, quindi è a tutti gli effetti un 32 bit sia per quel che riguarda il sistema operativo che per la CPU CISC (x86) che lo supporta.
Le UWP non esistono, dunque il problema non si pone.

Alessio Ferri

? Risc o cisc è una proprietà dell'ISA, non dell'implementazione.
Da quando sono in pipeline le istruzioni interne sono come per tutti i segnali di controllo in orizzontale, quindi Word da 200/300 bit.

Federico

Quanto al "non si fanno pagare" la normativa internazionale sui brevetti impone ai detentori del brevetto di concederne l'utilizzo dietro un "equo compenso"
Cosa si debba intendere con "equo compenso" non è specificato, quindi da sempre le aziende sono state libere di fissare il loro "equo compenso" ad un livello tale da trasformarlo in una sostanziale impossibilità.
Se Intel ha voglia di chiedere mille dollari per ogni copia di emulatore commerciale in grado di SSE e VT-X non esiste modo di impedirlo, è quello che hanno sempre fatto e continuano a fare tutti.
Va da sè che senza SSE non si mette sul mercato proprio nessun Windows 10 a 64 bit (e ormai neppure nessun applicativo, visto che TUTTI compiliamo flaggando il supporto ad SSE).

Alessio Ferri

Confondere dettagli implementativi con il set di istruzioni.
Il set di istruzioni x86 è un set complesso, inconsistente e lungo da decifrare, la CPU ha problemi in molti casi a decodificare le istruzioni in un solo ciclo, per cui tutte le microarchitetture attuali usano un grosso buffer di istruzioni già decodificate che nei cicli permette di spegnere le 4 unità di decodifica per core.
Per il set interno non ha senso parlare di caratteristiche e regolarità in quanto si tratta semplicemente di Word enormi contenenti tutti i segnali di controllo della CPU nelle varie fasi, segnali di controllo che differiscono da generazione a generazione e che non ha senso rilasciare.

Arm ha un ISA più regolare e più consistente per cui ha meno problemi di timing in decodifica e ha decoder più piccoli.

Il resto son cagate, quello che dovrebbe fare Intel è buttare le modalità vecchie dell'architettura (virtual x86, real mode, le istruzioni privilegiate per cambiare task, etc), in modo da semplificare la decodifica.

pietro

L'os gira a 64bit, le uwp pure, le Win 32 a 32bit

Federico

"Esiste software applicativo PC compiato ARM 64? risposta: SI.
Sul sistema viene eseguito un OS a 64 bit? risposta: SI."

La risosta è NO ad entrambe, non esiste software PC compilato per ARM ed il sistema operativo è il normalissimo Windows 10 a 32 bit.

Federico

Può eseguire software compilato per l'instruction set specifico del suo processore, basta che il proocessore stesso venga avviato in modalità 64 bit.
Una CPU avviata in modalità 64 bit può eseguire sia software 64 bit che software 32 bit, che in questo caso è quello del sistema operativo stesso
Non può eseguire software PE 64 in versione x86_64, ma solo ed esclusivamente per limitazioni legali legate ai brevetti Intel.
Micorosoft già domani mattina potrebbe distribuire la versione completa a 64 bit, solo che Intel le farebbe immediatamente causa.

Recensione e Riprova Google Pixel Buds Pro, rinate con l'aggiornamento

24H con Oppo Find N2 Flip, la sfida a Samsung è servita | VIDEO

Abbiamo provato i nuovi Galaxy Z Fold4 e Z Flip4, ecco le novità! | VIDEO

Copertura 5G, a che punto siamo davvero? La nostra esperienza in città