Intel demonstreert Meteor Lake-processor voor het eerst

Intel heeft een selecte groep journalisten, waaronder Tweakers, een eerste demonstratie van een Meteor Lake-processor gegeven. Deze processors komen later dit jaar uit voor laptops en bevatten een neural processing unit, die Intel aan het werk liet zien in een preproductielaptop.

Render van een Intel Meteor Lake-processor

De werking van de Meteor Lake-chip en specifiek de npu werd gedemonstreerd in het generative AI-programma Stable Diffusion, dat de gegenereerde beelden via een plug-in direct liet zien in GIMP. Met een prompt en negative-prompt van twee regels duurde het genereren van een plaatje van 512x512 pixels twintig seconden. Als de software alleen de cpu en gpu zou gebruiken, zou dat volgens de chipfabrikant 'veel langer' hebben geduurd en bovendien veel meer stroom hebben verbruikt.

De geïntegreerde npu maakt gebruik van een doorontwikkelde techniek van Movidius, dat in 2016 door Intel werd overgenomen. In 2017 kwam een AI-accelerator met die technologie beschikbaar als uitbreidingsmodule in USB-stickformaat. De npu zal compatibel zijn met de Onnx-, DirectML-, W3C WNN- en OpenVino-standaarden. Volgens Intel is de npu met name geschikt voor het overnemen van langdurige AI-workloads. Voor kortdurende taken zou de cpu de aangewezen processor blijven; voor AI-toepassingen in media- of renderpipelines blijft dat de gpu. Het inschakelen van de npu brengt namelijk ook wat latency met zich mee. Bij een kleine taak weegt dat niet op tegen de extra rekenkracht.

Voorafgaand aan de demonstratie, die aan de vooravond van de Computex-beurs plaatsvond in Taipei, bevestigde Intel dat Meteor Lake en diens opvolger Arrow Lake uit tiles, oftewel chiplets bestaan. Een deel van die tiles wordt door Intel zelf geproduceerd. De npu is onderdeel van de SoC-tile. Onder meer de gpu-tile wordt echter door TSMC geproduceerd. Een Intel-woordvoerder bevestigde tegenover Tweakers dat die gpu-tile vergelijkbaar is met een low-end Arc-gpu. Vermoedelijk gaat dat om de A380 met 128 execution units, al ligt het voor de hand dat de igpu-versie door lagere kloksnelheden wel wat langzamer zal zijn.

Hoewel Intel de rest van de specificaties van de getoonde processor niet wilde bevestigen, gaat het vermoedelijk om een chip met zes P-cores, acht E-cores en nog twee extra E-cores die géén onderdeel zijn van de op 'Intel 4' geproduceerde compute-tile, maar net als de npu in de SoC-tile zitten. Deze cores zijn volgens betrouwbare geruchten nog zuiniger dan de reguliere E-cores en zouden actief blijven als het systeem in connected standby staat. Daarmee zou de compute-tile in de slaapstand zelf volledig gedeactiveerd kunnen worden om stroom te besparen.

Over de Meteor Lake-processors voor desktops, die volgens recente geruchten grotendeels geannuleerd zijn, wilde Intel nog niets zeggen. Ook op vragen over de potentiële merkwijziging naar 'Core Ultra' wilde het bedrijf niets kwijt. Over dat laatste belooft het in de komende maanden, dus nog voor Meteor Lake op de markt komt, meer duidelijkheid te geven.

Reacties (79)

[Luchtbakker]

Hardstikke leuk die AI techniek in een chip. Maar wat heeft een gemiddelde consument hiervan? Volgens mij vooral een techniek dat de prijzen van CPU's onnodig laat stijgen.

[wildhagen]

Tsja, dit is een reactie die je bij vrijwel elke nieuwe techniek hoort. Toen de eerste multicore-processors kwamen hoorde je exact hetzelfde: wat heeft een consument aan meer dan één core, dat werkt toch ook, en nu wordt het produkt duurder?

Zo kan je nooit iets nieuws meer introduceren en ga je stilstand krijgen. En in de techniek is stilstand uiteindelijk achteruitgang.

Het gaat hier om generatieve AI. Dus het zou gebruikt kunnen worden in rendering toepassingen, om maar één concreet voorbeeld te noemen. Er zullen er ongetwijfeld nog wel meer zijn te noemen.

Ook die 2 'speciale' E-cores is wel interessant, zeker op een laptop (waar Meteor Lake dus voor bedoeld is). Kan je toch net weer wat extra stroom besparen in de standby stand, waardoor de accu weer wat langer meegaat op één lading.

[harakiri576]

Toen de eerste multicore-processors kwamen hoorde je exact hetzelfde: wat heeft een consument aan meer dan één core, dat werkt toch ook

In alle eerlijkheid, voor een gewone kantoor gebruikspatroon heb je zelfs vandaag niet te veel aan multicore CPUs. Word/excel maakt hier amper gebruik van, en terwijl je browser wel kan meerdere cores offloaden, voor de meeste nieuwspagina's zoals tweakers enzo is het ook niet noodzakelijk.

[SinergyX]

'dit is een reactie die je bij vrijwel elke nieuwe techniek hoort', is inmiddels ook de standaard zin je die bij elke nieuwe techniek hoort.

'random dingen tegen de muur gooien in de hoop dat iets blijft plakken' is geen tegenvorm van stilstand, dat is gewoon aankloten in de tijd dat je toch al stil stond. Tot heden is geen enkele AI gemaakt (in grote vorm) zonder 'cloud of cluster' opslag, welke vooruitgang is er dan in een singleuse case voor zo'n cpu, waar domweg 99% geen gebruik van zal maken?

Oh wacht, we creeren gewoon voor die 99% random bullshit zodat ze die kunnen gebruiken, de schwarzernegger singalong video's, de random thumbnails, de 'what ifs' plaatjes..

Er is een groot verschil tussen verfijning van een het wiel opnieuw uitvinden.

[Coolstart]

Dus zo random ranten tegen AI vind je dan wel normaal?

Het is niet omdat je door onwetendheid geen toepassingen kan bedenken of gewoon ‘tegen ai’ dat AI geen zin heeft.

Tot heden is geen enkele AI gemaakt (in grote vorm) zonder 'cloud of cluster' opslag, welke vooruitgang is er dan in een singleuse case voor zo'n cpu, waar domweg 99% geen gebruik van zal maken?

Er is een verschil tussen AI trainen in de cloud en AI lokaal gebruiken photo to text, beeldstabilisatie, muziek editors, HDR, object detectie tot zelfs in game AI voor conversaties en computergestuurde vijanden zullen allemaal langs de NPU lopen om de GPU te ontlasten.

Je moet het gewoon zien als een extra core maar dan voor zeer specifieke instructies.

[graey]

Inderdaad, zat toepassingen die nu versneld en met minder TDP gedaan kunnen worden. En de volgende spurt van ontwikkeling vindt een stuk eerder plaats als Jan en alleman ermee kan hobbyen zonder dat het uren duurt of bakken geld kost.

[Getest]

Precies dit, underrated comment!

[Stukfruit]

welke vooruitgang is er dan in een singleuse case voor zo'n cpu, waar domweg 99% geen gebruik van zal maken?

Privacy en de (realtime) omgang met gevoelige data zijn een goede om mee te beginnen.

Dat is geen random dingen tegen de muur gooien in de hoop dat het blijft plakken. Het is visie voor een wereld waarin men steeds minder afhankelijk wil zijn van gecentraliseerde oplossingen.

[Reactie gewijzigd door Stukfruit op 22 juli 2024 13:27]

[foobar79]

Aan de andere kant:
AVX512 is ook niet echt een success geworden, zeker niet op consumenten hardware, en is inmiddels ook al weer uit flink wat cpus gehaald.

Dus het is helemaal niet zo gek om na te denken en te vragen om concrete toepassingen dan maar hopen dat die er vanzelf komen …

[Blokker_1999]

Wat wil je dan, dat we eerst de toepassingen bedenken en die dan enkele jaren op de plank laten liggen totdat de CPUs er klaar voor zijn? Soms moet je gewoon een stap durven zetten. Soms is de kip er eerst, dan weer het ei.

[_JGC_]

AVX512 wordt op zich wel gebruikt, maar compilers hebben een voorkeur voor AVX256 omdat het gebruik van AVX512 op een groot aantal Intel CPUs ervoor zorgt dat de CPU in zijn geheel moet terugklokken.
Je moet dus per workload gaan kijken of AVX512 gebruiken winst op gaat leveren op dergelijke CPUs.

[MSalters]

Dat is overigens niet uniek voor AVX-512. Op een aantal oudere Intel CPU's (zonder AVX-512) had je hetzelfde effect als je AVX-256 gebruikt in plaats van AVX-128.

Voor AI doeleinden is AVX-512 overigens prima geschikt, maar ik snap de logica van een dedicated NPU. Dat is nog efficienter.

[uiltje]

M'och. Dat Intel het nooit goed heeft te weten optimaliseren betekend niet dat het dood is. Het zit volgens mij nog steeds in hun Xeon CPU's en de nieuwere AMD chips worden er ook mee uitgerust. Het is wel degelijk handig voor bijvoorbeeld de meeste asymmetrische cryptografische algoritmen. Die toepassingen zijn er wel hoor, het is vooral de noodzaak om de frequentie aan te passen aan de instructie dat het probleem is.

[Reactie gewijzigd door uiltje op 22 juli 2024 13:27]

[Frame164]

De toepassingen komen pas als de hardware er geschikt voor is. Niemand gaat geld steken in de ontwikkeling van software die nergens op kan draaien. En Intel is ook niet gek. Voordat zij iets naar de markt brengen is dat natuurlijk al lang besproken met relevante software ontwikkelaars, experts uit verschillende industrieën etc. De researchers bij mijn werkgever zitten in allianties met allerlei andere bedrijven, waaronder Intel, HP, AMD, etc zodat daar toekomstige ontwikkelingen worden besproken zodat de juiste dingen kunnen worden ontwikkeld. Het is niet dat Intel zomaar wat probeert.

[johnbetonschaar]

Toen de eerste multicore-processors kwamen hoorde je exact hetzelfde: wat heeft een consument aan meer dan één core, dat werkt toch ook, en nu wordt het produkt duurder?

Misschien heb ik zitten slapen dan, want dat heb ik dus echt nog nooit iemand horen zeggen. Wat ik me er van herinner is dat ten tijde van de Core Duo die CPU’s extreem populair waren en het sentiment juist was dat je echt wel dual core wilde hebben.

[old_spice]

Zeker in die tijd gebruikte maar zeer weinig applicaties meer dan 1 core. Ik denk voornamelijk in de grafische sector voor rendering.

[bwerg]

Ook toen draaide je gewoon altijd meerdere processen. Al waren het maar de processen van je OS.

Een moderne octa-core ga je niet benutten met single-threaded applicaties maar een dual core zeker wel. De tweede core hoeft ook geen 100% load te hebben om nuttig te zijn.

[Reactie gewijzigd door bwerg op 22 juli 2024 13:27]

[freaq]

Hoorde het toen ook hoor,
en toen was het ook dom.
Is gewoon kip ei geval.

Kijk naar apples M1 die gebruikt de accelerator goed, super snelle encoding, foto bewerking etc etc.
En super zuinig en nu het er standaard is beginnen developers het te gebruiken.

[Raymond Deen]

In het geval van Apple is het makkelijk, namelijk maar 1 variant om tegenaan te praten, of misschien voor elke Mx iteratie wat aanpassingen/uitbreidingen.
In het geval van Intel is het toch net een ander verhaal, want als je je op hun techniek gaat richten dan ga je dikke workstations met AMD processoren en dedicated videokaarten uitsluiten en dat wil je niet.
Dus moet je voor meerder verschillende systemen, die waarschijnlijk behoorlijk van elkaar verschillen, gaan ondersteunen.

En over het aantal cores in een cpu; een groot deel van mijn vrienden en bekenden kan dat geen biet schelen, als de volgende pc of mobiel maar weer flink sneller is dan de vorige.

[freaq]

Een intel of amd specific compiler pakt je meestal slechts een paar procent winst hoor.

Tis vooral de brede bussen en pipelines die het hem hier doen. En bredere pipelines vooral zijn lastig in x86 en niet in ARM.

[Reactie gewijzigd door freaq op 22 juli 2024 13:27]

[Raymond Deen]

Bepaalde delen van de instructieset wel of niet kunnen gebruiken, maakt wel degelijk veel meer uit dan die paar procent die je noemt. Snelheid en stroomverbruik kunnen soms op een dramatische manier vooruitgeholpen worden. Kijk maar naar bijvoorbeeld de extensies AVX* en AES-NI; vector- en aes-berekeningen gaan echt een pak sneller met de instructies in die extensies.
Wanneer je nu, zoals vroeger met de numerieke co-processor, nog meer optionele onderdelen in een processor gaat onderbrengen die bij je concurrent niet te krijgen zijn dan wordt de wereld er niet makkelijker op.

[old_spice]

Wist niet dat bijvoorbeeld Windows in die tijd gebruik maakte van meer dan 1 core. Maar ook echt veel applicaties die er gebruik van maakte? Ik heb het over de periode 2006 t/m 2010.

[bwerg]

Maar ook echt veel applicaties die er gebruik van maakte? Ik heb het over de periode 2006 t/m 2010.

Dat is nou net het punt. Sinds windows 95 kun je meerdere processen (applicaties) tegelijk runnen. En dat betekent dat een enkel proces niet meer dan 1 core hoeft te gebruiken om de hele PC wel meer dan 1 core te laten gebruiken: gewoon enkele processen tegelijk draaien, en dan kunnen verschillende processen op verschillende cores naast elkaar draaien.

Dat binnen een proces nog niks over cores verdeeld kan worden, omdat die processen nog niet in meerdere threads zijn opgedeeld, maakt dan niet eens uit.

[Reactie gewijzigd door bwerg op 22 juli 2024 13:27]

[memphis]

In het geval van processoren en computers is het ook maar hoe goed het OS en de software geschreven wordt. Ik kan mij de programmeerwedstrijden nog herinneren waar de mooiste dingen zoals Heaven7 binnen 64k werd geschreven. Lompe compilers en luie programmeurs zorgen ook voor grote en langzame codes met als reden: Waarom zou je met zoveel HDD ruimte, geheugen en zware processoren?
Heet dat dan ook vooruitgang?

[Blokker_1999]

Hoewel er ongetwijfeld programmeurs zijn die zo denken, verwacht ik dat de meesten vandaag nog altijd enorm veel optimaliseren, net omdat het voor vele toepassingen gewoon belangrijk is en blijft om performant te zijn. Maar 1 van de grootste uitdagingen waar we vandaag mee zitten is net dat ze met enorm veel factoren rekening moeten houden.

Heaven7 erbij nemen is natuurlijk ook niet eerlijk. Dat is evenveel kunst als programmeren. Net zoals men vroeger hele games in 64k kon plaatsen (en niet enkel de intro ervoor). Maar vergelijk wat je toen had eens met wat we vandaag hebben.

Je code vandaag moet draaien op een 10 jaar oude CPU, maar moet ook zo performant mogelijk zijn op de meeste moderne CPUs met nieuwe instructiesets, dat moet je allemaal meenemen in je code, in je compiler. Dat kost allemaal weer ruimte. Het is dan eenvoudig om te zeggen dat alles maar groter wordt, maar wij worden ook steeds meer veeleisend.

[ByteArray]

Vraag ik me af, tegenwoordig is het ook nogal gebruikelijk om overal maar een softwarebibliotheek voor te importeren in de code. Of een lomp 'framework'.

Als je het puur vanuit het perspectief van functionaliteit bekijkt heeft bijna iedereen nog genoeg aan Windows XP, of een lichte Linux-distro. Kun je nieuws mee lezen, e-mailen, (video)bellen, documenten maken/bewerken/bekijken, rekenbladen gebruiken, presentaties met PowerPoint, (natuur)filmpjes kijken/bewerken, foto's bekijken/bewerken etc. etc. Zelfs met een laptop uit 2010 kon je die dingen allemaal doen, afgezien van beeldbewerking en andere zware toepassingen. Misschien een SSD erin, wat extra RAM en een nieuwe accu.

Voor de nostalgie:
Microsoft Windows XP Startup Sound
https://www.youtube.com/watch?v=7nQ2oiVqKHw

[Reactie gewijzigd door ByteArray op 22 juli 2024 13:27]

[Argantonis]

Ik word toch echt zo moe van die mensen die huidige programmeurs steeds lui blijven noemen en echt geen enkel idee hebben hoe zowel softwarecomplexiteit als de bijbehorende kosten en baten in die tijd zijn veranderd. Ik maakte vroeger ook demo’s in die scene en dat waren idd niet veel regels code en gebruikte niet zoveel geheugen, maar wat ik nu doe is toch echt een stukje complexer, dat het nu honderden mb’s inneemt doet daar echt niet aan af.

[vgroenewold]

Lui staat dan ook tussen aanhalingstekens. Toen ik begon met programmeren in de jaren 90 leerde ik echt om alles uit de kast te halen zeg maar. Nieuwe programmeurs hoeven dat niet perse meer te doen omdat er voldoende ruimte is. Echter krijg je dan snel van die electron apps en andere zaken die soms nogal "gaar" lopen. Een goede middenweg tussen optimalisatie en snelle ontwikkeling is het beste.

[Argantonis]

Lui staat helemaal niet tussen aanhalingstekens in de comment waar ik op reageerde.

[vgroenewold]

Ah sorry, ik had de verkeerde post waarin dat zo stond.

[Prince]

De mensen die programmeurs lui noemen, hebben vaak geen realistisch idee van het leven van een programmeur of de levensloop van hoe een stuk software geschreven wordt.

Voor deze mensen:
- een projectmanager (of applicatie consultant oid) heeft het grote plan hoe de software er moet uit zien. Hij heeft de samenhang tussen de functies die aangeroepen worden en de database(s) en webservices in kaart gebracht en heeft door een architect/analist de flows in kaart laten brengen voor de logica.

Vervolgens geeft hij aan programmeur(s) de opdracht om elk een subset aan functies te schrijven die bepaalde inputparameters krijgen en een welbepaalde output moeten geven (+ hopelijk de tests om aan te voldoen - maar vaak ook niet).
Deze functies zijn vaak vrij generiek en steeds zo klein mogelijk. Een functie "moet" namelijk steeds 1 ding doen volgens veel coderingstandaarden.
Al deze functies worden geschreven door een hele groep aan programmeurs (collega's van elkaar, externe firma's, maar evengoed nieuwe mensen omdat er een paar ergens anders gaan werken). "Samen werken" is dus vaak niet mogelijk en dan is documentatie en generiek zijn juist een sterkte om software goedkoop te houden.

Vergelijk het even met een straat aanleggen. De programmeurs zijn vaak de mensen die het werk doen, niet de architect, teamleader of persoon die kiest waar de grondstoffen aangekocht worden.
Eens dat de werkmannen een rechtstreekse invloed hebben op de kwaliteit, maar met slecht materiaal kan je maar beperkte kwaliteit opleveren, als het werk van de onderliggende laag slecht is, dan kan je ook maar een beperkte kwaliteit opleveren en is het zeker niet de verantwoordelijkheid van iemand die asfalt giet om de betonlaag eronder te herstellen. Vaak wordt er dan ook gekozen om gewoon door te gaan om later dat defect te patchen; het belangrijkste is dat de baan (weer) open gaat voor het verkeer. Ook hier geldt dat als je niet de tijd krijgt om de onderlaag te inspecteren of behandelen, dat het werk nooit dezelfde kwaliteit zal hebben (denk aan het verven van een muur); maar programmeurs zijn duur, dus ze willen het aantal uren reduceren waar mogelijk.
Wat er ook vaak gebeurt, is dat er detacheringsfirma's zijn die mensen van de straat plukken, ze een maand een opleiding geven en deze mensen inzetten als programmeurs. Ook daar is de kwaliteit vaak minder van te noemen; deze mensen moeten tenslotte ervaring opdoen voordat ze foutloos werken - laat staan snelle code opleveren.

Elke programmeur kan optimaliseren, maar dit is secundair aan het snel (=goedkoop) opleveren van functionele code die geen bugs bevat. Bugs killen heeft leesbare code nodig.

Indien een programmeur 2x zoveel tijd besteed aan optimaliseren, dan is de software ook +/- 2x zo duur. Wil jij voor alle software 2x zoveel betalen omdat het sneller werkt, of ga je een beperkte som geld uitgeven aan een processor die sneller is waardoor ALLE software sneller werkt?

[IStealYourGun]

Compilers zullen zelden het probleem zijn. De reden dat de ontwikkelaars van UNIX ooit zijn overgestapt van assembly naar C is omdat de kwaliteit van de compiler evenwaardig was aan het rechtstreeks coderen in assembly.

Dat developers vandaag de dag misschien "lui" zijn, is misschien wel waar, maar de prijs van memory en storage is dan ook niets in vergelijking met de begindagen. Waarom zou je uren spenderen aan het super optimaliseren van code zodat je misschien enkele bytes wint op een systeem dat minstens 8 Gigabyte heeft. 🤷‍♂️

[MallePietje]

Het "super optimaliseren" van code heeft soms meer nadelen dan voordelen.
De leesbaarheid/begrijpelijkheid neemt vaak af. Dat maakt de code gevoeliger voor bugs. Zeker als daar later door iemand anders iets in gewijzigd moet worden.
Het is ook de vraag of het kosten/baten interessant is om erg te optimaliseren. Wat nu als we alle software die we gebruiken enorm zouden optimaliseren? Dan zou hardware goedkoper zijn, maar software veel duurder (optimaliseren kost veel tijd). Althans, dat verwacht ik, hoewel bij pricing natuurlijk meer factoren spelen.

[peke]

Inderdaad, time is money, optimaliseren heeft zelden nut in de zin dat het meestal al vlot genoeg loopt.
Ik kies zelf om de code zo simpel mogelijk te houden. Als ik iets kan doen in 10 lijnen code maar het zou sneller lopen als ik 30 regels gebruik er dus "optimaliseer", dan vraag ik mij eerst af hoe vaak die code zal worden opgeroepen. Ik zou zelf pas optimaliseren als het eigenlijk enorm vaak in een loop wordt opgeroepen of het gaat om een stuk library code die op zeer veel plaatsen gaat gebruikt worden.
Het is eigenlijk veel nuttiger om niet te optimaliseren en die extra tijd te gebruiken om meer unit tests te schrijven.
Meer unit tests maakt betere code, betere interfacing, minder timing gevoelige code, betere opspliting van de code, ik test ook vaak eerst code met een unit test dan op het product, dus test driven development, en dan uiteraard ook de hoofdreden van unit tests, als je iets veranderd in je code en je breekt iets dan zie je dit vrij snel, dus m.a.w. minder bugs, dat is enorm veel belangrijker dan optimalisatiewerk.
De hardware wordt op termijn enkel sneller, houd daar ook rekening mee.

[Arumes]

Compilers zullen zelden het probleem zijn. De reden dat de ontwikkelaars van UNIX ooit zijn overgestapt van assembly naar C

Je kan sowieso niet echt zeggen dat ze "van assembly naar C" zijn overgestapt. De stap was een geleidelijk proces, met verschillende talen als tussenstap. De eerste stap was TMG. Ken Thompson wou TMG gebruiken om een Fortran-compiler te schrijven. Dat werd uiteindelijk B gebaseerd op BCPL ipv Fortran, en via B2 evolueerde die taal tot de eerste versie van C.

Dat ze van assembly af wilden was vooral om het programmeerwerk makkelijker te maken: "readability, modifiability, and portability" volgens Dennis Ritchie. Eigenlijk gewoon dezelfde reden die we nu nog steeds hebben om high-level talen te gebruiken.

is omdat de kwaliteit van de compiler evenwaardig was aan het rechtstreeks coderen in assembly.

De code was goed genoeg; ik ken geen enkele uitspraak uit die tijd die suggereert dat de code evenwaardig was.

Dit is wat Dennis Ritchie zelf heeft gezegd: "Thus, in 1971, work began on what was to become the C language. The story of the language developments from BCPL through B to C is told elsewhere, and need not be repeated here. Perhaps the most important watershed occurred during 1973, when the operating system kernel was rewritten in C. It was at this point that the system assumed its modern form; the most far-reaching change was the introduction of multi-programming. There were few externally-visible changes, but the internal structure of the system became much more rational and general. The success of this effort convinced us that C was useful as a nearly universal tool for systems programming, instead of just a toy for simple applications."

Dus ja, het was een "succes". Dat de code evenwaardig was heb jij zelf verzonnen.

[Reactie gewijzigd door Arumes op 22 juli 2024 13:27]

[RoestVrijStaal]

Goed dat je de introductie van multi-core CPU's aan snijd, want het succes ervan valt of staat (nog steeds) door of software developers het aansturen in hun code of niet.

En de vraag is ook of developers met die keuze moet worden opgezadeld of dat beter een SDK, framework, library en/of compiler dat beter kunnen beslissen.

Ook bij dit soort "expansion-chips". Idealiter hoeft er enkel een nieuwe versie van de compiler geïnstalleerd te worden of een extra optionele dependency drag-n-drop "geïnstalleerd" te worden, om nieuwe versie van de applicatie die dan deze chip KAN gebruiken te builden.

[dj-vj]

Ik begrijp je reactie, maar ik denk dat veel mensen moe worden van nieuwe technologieën die geen problemen oplossen voor de normale consument. Op het moment zoek ik juist goedkopere zuinige processoren die nog steeds snel zijn. Een AI cpu kan me gestolen worden.

[dePannenkoekjes]

Er zijn nu geen AI dingen die lokaal op PC's draaien voor zover ik weet. Al die dingen draaien in de cloud. Dit voelt meer als een 'we moeten meedoen met de AI hype'-actie die een oplossing maakt voor een probleem dat niet bestaat. Ik heb ook geen goede voorbeelden gehoord van dingen die ik op een computer doe die mogelijk geoptimaliseerd kunnen worden door dit soort AI-chips.

Edit: dit is specifiek gericht op normale mensen, zoals ik, niet creative professionals ofzo. Ik weet niet wat hun wensen zijn. Maar voor dat soort nichere use cases wil ik eigenlijk niet mee betalen bij mijn volgende processor.

Edit 2: ik lees nu het artikel over NPC generatieve AI van Nvidia. Dat klinkt wel veelbelovend, maar heb je daar nou een extra NPU voor nodig? Voor de hoeveelheid tijd die ik met NPC's praat in games (die niet voor de main story is, het gedeelte waar je waarschijnlijk niet wilt dat de AI die voor elke speler anders maakt), klinkt het alsof ik dit makkelijk op de GPU moet kunnen draaien.

[Reactie gewijzigd door dePannenkoekjes op 22 juli 2024 13:27]

[MSalters]

Serieus? Ik heb AI's die op Raspberry Pi's draaien, en daar precies één core gebruiken. Gespecialiseerde AI's kunnen erg klein zijn. Niet alles is een Large Language Model; ChatGPT is echt een uitzondering qua grootte.

[dePannenkoekjes]

Maar heb je er dan een NPU voor nodig als je het al op een Pi kan draaien?

[blorf]

Door multi-core ging de potentiële prestatie omhoog bij toepassingen die onafhankelijke threads kunnen benutten. In welke situatie verbetert een AI-chip iets? De techniek opzich spreekt zichzelf eigenlijk al een beetje tegen. Als een bepaalde constructie die door een AI-proces is 'verzonnen' een zekere prestatie-winst oplevert maar dat wordt vervolgens niet hard in een statische chip toegepast is het voordeel waarschijnlijk niet echt.

[d3x]

Tsja, het is altijd iets vernieuwend... maar als ze dat al nodig hebben van hype om de rest van hun erbarmelijke staat vna CPU te verbergen is het natuurlijk voor de doorsnee consument die de eerste jaren niks heeft aan de hype geen toegevoegde waarde.

Kan je vergelijken met de huidige generatie datacenter CPU sapphire rapids... snel en zuinig in offloading taken maar als puntje bij paaltje komt in algemene workload succed big time en niks tegen de concurrentie.... tsja daar sta je dan met je platform dat nog 80% gebruikt wordt voor generieke taken. Al een geluk dat INtel Xeon een trouwe fan base heeft voor aankopen.
https://www.hpcwire.com/2...ating-from-amd-next-year/
https://www.google.com/ur...f55iinP8CFQAAAAAdAAAAABAD

[elteck]

Van wat ik er over gehoord heb, gaat om eighenlijk hetzelfde wat Sundar Pichai in dit interview noemt: https://youtu.be/2eK9TtRwKFY (scroll naar de laatste 10 minuten). De bedoeling is om spraak en eenvoudige beeldverwerking te versnellen, zodat je een PC deels met spraak en gebaren kan bedienen. De reden om dit met een NPU te doen is om het energie zuinig te maken, waardoor het zelfs in standby nog actief kan zijn. Er gaat een gerucht dat Microsoft samen met AMD een zoortgelijke samenwerking heeft (https://www.cnbc.com/2023...ting-on-ai-chip-push.html), maar Microsoft ontkent dat. We zullen zien.

[Mic2000]

Op het moment dat ze een standaard maken voor npu's die je als pci-e insteekkaart in je pc kunt prikken, en straks veel grotere afbeeldingen kunt genereren... Ja dat is zeker belangrijk voor de creatieve sector.

Met een beetje geluk dat je het straks ook kunt gebruiken voor video's genereren en je hebt daadwerkelijk naast gpus een nieuwe productlijn in computerland.

[gekkeh3nk]

Windows kan al NPU's gebruiken om webcam beelden real-time te verbeteren. Momenteel alleen op Qualcomm processors omdat dat de enige zijn met NPU. Deze Intel chip kan dat ook doen. Verder zou het me niet verbazen als je offline tekst kan genereren in bijvoorbeeld Word met deze NPU.

[dePannenkoekjes]

Maar zou dat niet net zo makkelijk op de iGPU kunnen? Ik weet dat Nvidia Broadcast een tijd geleden dit soort optimalisatiedingen aanbood, dus dan kan het toch ook op je (i)GPU van Intel of AMD in principe?

Ik wist een minuut geleden niet eens dat deze optimalisatie überhaupt bestond, vandaar de vraag.

[kabelmannetje]

Ik zie vooral mogelijkheden voor games. AI voor NPC, dialogen, strategie/simulatiegames, etc.

[tedades]

Nu ben ik niet heel bekend met deze chip, zover ik kon zien is het een FPGA (via-software-programmeerbare-logica chip). Er is ook een trend om lagere precisie floating-point berekeningen te ondersteunen voor AI toepassingen. Een processor is zeer geschikt voor logica en integer berekeningen, een video chip kan veel floating-point berekeningen in parallel uitvoeren (en daarom om geschikter voor AI toepassingen dan je CPU).
Of het voor deze NPU van toepassing is weet ik niet, maar een AI module zal waarschijnlijk tussen beide in zitten, niet zo uitgebreid als een GPU maar sneller dan een CPU voor AI. En alles wat dit soort type berekeningen gebruikt zal dan efficiënter lopen op dit soort chips.
In het algemeen zijn FPGA's inderdaad niet goedkoop om te maken, maar de optie om een soft-core te draaien voor AI toepassingen zou erg handig kunnen zijn. Mocht de markt deze functionaliteit veel gebruiken zou dat een unique-selling-point voor Intel kunnen zijn, beetje als de voordelen van CUDA voor de gebruiker waardoor je nVidia zou kiezen. Daarnaast is AI op het moment erg hip en Intel loopt daar nog wel wat achter i.v.m. nVidia.

[Verwijderd]

Gezien Microsoft met Windows 11 Copilot AI gaat integreren in het systeem lijkt het erop dat Windows in de toekomst ook veel meer met AI gaat doen:
https://www.youtube.com/watch?v=FCfwc-NNo30

Hier zullen vast nog wel het een en ander aan toevoegingen gedaan worden waardoor een NPU van toegevoegde waarde is in je processor.

[dePannenkoekjes]

Copilot tot nu toe leek me gewoon de nieuwe AI Bing met een soort van Windows plugin waardoor hij het een en ander kan doen op je PC. Maar alle processing word nog steeds op MS servers gedaan lijkt het.

Waar voor soort toevoegingen zouden er kunnen komen die gebruik maken van een NPU i.p.v. dat ze op de MSFT servers gedraaid worden? Dat hele Bing AI verhaaltje lokaal draaien lijkt me veels te zwaar op je internetverbinding en zo'n klein NPU'tje in ieder geval. Ik bedoel bij die AI datacenters gebruiken ze toch beesten van GPU's voor die berekeningen, dus misschien zit ik ernaast maar ik kreeg de indruk dat het vrij zwaar was.

[Verwijderd]

Waar voor soort toevoegingen zouden er kunnen komen die gebruik maken van een NPU i.p.v. dat ze op de MSFT servers gedraaid worden?

Windows Copilot is pas het begin van AI-integratie in Windows in ieder geval, met ontwikkelingen op zowel hard- als software niveau zal er vast vanuit Microsoft de beschikbaarheid van een NPU zeker ook gaan benutten.

Dit kan je ook opmaken uit het feit dat ze de Surface-apparaten gaan leveren met een ingebouwde NPU:
https://pureinfotech.com/microsoft-npu-ai-surface/

According to sources, Microsoft plans to include its new NPU chips in the next generation of Surface devices in an effort to speed up AI and ML (machine learning) capabilities, which is a critical component to improve performance and new AI features, such as task automation.

Of dat tegelijkertijd betekent dat de AI (gedeeltelijk) offline kan werken, durf ik niet te zeggen, is nog te vroeg om daarover iets te zeggen als de Copilot volgens mij zelfs voor Insiders nog niet beschikbaar is.

[Hans1990]

Ik denk redelijk veel. Als je naar 1 van Intel's concurrenten bekijkt, NVIDIA, dan lossen zij dat op met GPUs. Ik bedoel 'concurent' in de algemene zin van 'compute'.
NVIDIA doet al ontzettend veel met AI: DLSS upscaling (ook voor media playback), maar ook raytracing engines gebruikt AI om te denoisen. De GPU is namelijk echt niet snel genoeg om elke pixel (8M op 4K) 1 voor 1 te raytracen met tal van bounces en tal van lichtbronnen. Die combinatie is eigenlijk wat kennen als marketingnaam 'RTX'. Verder hebben ze RTX Voice dat schijnbaar redelijk goed omgevingsruis uit een audio stream kan halen.

En lang niet al die features hoeven perse op een (relatief) dikke NVIDIA GPU te draaien. Het trainen van een neuraal netwerk is erg zwaar (geschikt voor GPUs), maar zodra die getraind is kan je vaak met relatief weinig rekenkracht dat uitvoeren.
Ik denk bvb dan aan een toepassing zoals RTX Voice al doet, maar ook een AI upscaler voor media playback lijkt mij een prima invulling naast een Intel iGPU en een mainstream CPU. Daar komt nog bij dat GPT chatbots enorm populair zijn, en er zullen ongetwijfeld ook versies uitkomen die lokaal moeten kunnen draaien met beperktere complexiteit (denk aan games, maar ook copilots in office paketten, code IDEs of CAD programma's - je wilt niet 24/7 afhankelijk zijn van internet).

Er zal waarschijnlijk nog enige tijd overheen gaan totdat er een goede standaardisatie komt (als die al komt). Maar dan moet een partij als Intel (en ook AMD) al wel begonnen zijn met hardware daarvoor te bouwen. De uitspraak 'hardware heeft ooit gewerkt, software gaat ooit werken' is zoals gebruikelijk van toepassing.

[MallePietje]

Ik vermoed dat Intel juist verwacht dat het wel voor een breed publiek interessant is/wordt. Ik vind dat een redelijke verwachting gezien de ontwikkelingen op AI gebied en bijvoorbeeld de voornemens om bepaalde AI in het OS te verwerken, maar de tijd zal het leren.
Ook het feit dat er wat special purpose dingen op een cpu zitten, is natuurlijk niet nieuw. Denk aan geïntegreerde graphics dingen voor 3d of video encoding/decoding.

[ALittleTooLate]

Die AI techniek is gewoon hardware die matrix multiplitcaties snel kunnen berekenen. Dus deze kan elk probleem die je kan vectoriseren snel oplossen. Het is eigenlijk raar dat ze er nu pas mee komen.

[HerrPino]

Laten we hopen dat AI ooit voornamelijk on-premise draait en niet in de cloud. On-premise AI heeft veel meer mogelijkheden en hoeft niet (minder) aan EU richtlijnen of andere beperkende eisen wat betreft privacy ed te voldoen. Met private AI kun je wat dat betreft helemaal los gaan en je goed laten informeren over al je fetishes en je bent niet beperkt tot een X aantal prompts.

[Stetsed]

Dit wordt zeer interessant omdat het betekent dat je niet zo veel meer naar external services moet stappen zoals midjourney maar lokale versies van models zoals stable diffusion can runnnen. Dat wordt een hele interessante situtatie

[JSLV]

Misschien gaat je punt me een beetje over het hoofd, maar kan dit niet al veel langer dmv Automatic1111's Stable Diffusion WebUI? Dat draait ook gewoon lokaal.

Begrijp me niet verkeerd, het is knap dat Intel dit lukt op enkel een NPU binnen zulke tijd, maar wie een beetje een redelijke Nvidia GPU heeft (RTX 20xx/30xx/40xx) kan dit al veel langer, veel sneller.
(Ter vergelijking, mijn mobile RTX 3070 doet 2 seconden over een 512*512, 20 Steps, 8 CFG, plaatje. Ongeveer 8-9 it/s)

[Cergorach]

Als ik de documentatie lees van Automatic1111's Stable Diffusion WebUI, dan lijkt dit inderdaad allemaal lokaal te draaien. Een 3070 mobile is twee jaar oud, alles behalve goedkoop en slurpt waarschijnlijk meer dat wat er in de CPU (met npu) standaard is ingebakken (maar dat moeten we eerst ook nog maar zien).

Hoeveel laptops hebben een dergelijke GPU aan boord? In 2024 zit dit zo een beetje in elke (Intel) laptop en 5 jaar later is het gros van de laptops ermee uitgerust (ik verwacht dat AMD ook snel zal volgen).

Zo te zien draait dit ook al op Apple Slicon en dat is super efficiënt.

Maar een super interessante link! Thanks!

https://github.com/AUTOMATIC1111/stable-diffusion-webui

[Zoop]

Heb een 3060 met 6gb ram in lenovo laptop, heb dit ook draaiend, en de vram is vrijwel de bottleneck voor alles. Settings en resolutie laag houden zo dat het uberhaupt iets kan maken. WebUI heeft iig wel optimalisaties erin zitten voor low vram configuraties, zodat het iig iets kan doen. Ik geloof dat het geoptimaliseerd is voor 14gb vram, dus 16gb kaarten (je kan zelden 100% van de vram gebruiken, dus vandaar dat ze er net wat onder optimaliseren). En dat zijn over algemeen al vrij prijzige gpu's.

Je bent vrij snel beter af met een Google Collab accountje, dat geeft je zo al 40gb vram, echter diffusion is niet meer gratis sinds begin deze maand geloof ik (zal ook vast met de populariteit van diffusion te maken hebbe). Je betaald voor processing units dus dit wordt ook vrij snel een dure grap als je wat serieus probeert te doen.
https://github.com/camenduru/stable-diffusion-webui-colab clonen naar je google drive, en gaan, als je eerste optie pakt heb je zonder bs binnen een half uurtje stable diffusion draaien met webui.

Meer lokale hardware die dit mogelijk maakt zonder dat je 2k uit moet geven om ergens een 24gb 3090 op de kop te tikken (of zijn er 40 series met zoveel vram? volges mij niet), of helemaal niet te betalen apu's, tpu's, npu's of whatever ze die dingen noemen , zou nice zijn. Maar de hardware zelf is niet eens het probleem, een paar jaar oude gpu kan dit heus ook allemaal prima (al dan langzamer). Maar die VRAM is de bottleneck (zo ook bij gaming), daar moeten ze iets aan zien te doen, want die maakt bepaalde opties gewoon onmogelijk of irritant moeilijk. En zo ver ik weet kan je de consumenten gpu's niet aan elkaar knopen om vram te delen (SLi werkt wat dat betreft meer als Raid0, je krijgt niet meer capaciteit).

Zou prima zijn als je 4 4060's a 8gb in 1 kast kon douwen, maar daar heb je dus helaas niks aan.

[Reactie gewijzigd door Zoop op 22 juli 2024 13:27]

[Cergorach]

(of zijn er 40 series met zoveel vram? volges mij niet)

Een 4090 heeft ook 24GB VRAM aan boord. €1650+
RTX A6000 48GB VRAM. €5100+
Nvidia H100 80GB VRAM. €???

Ik vraag me af hoe dat gaat werken op een Apple M1 of M2. Een MacMini M2 pro met 12‑core CPU, 19‑core GPU en 16‑core Neural Engine en 32GB is €2374, in een MacStudio past 128GB aan RAM...

[z1rconium]

Dat werkt (hier) op zich prima op een M2 pro met automatic1111, maar als je Mochi Diffusion draait (gebruikt CoreML modellen), gaat het 2x zo snel. In automatic1111 - 512x768 euler A, 25 steps duurt hier ongeveer 35 seconden [00:36<00:00, 1.40s/it] - 768x1024 - [01:37<00:00, 3.59s/it].

Geen top performance, maar goed te doen. Mochi diffusion is aanzienlijk sneller, maar heeft niet de mogelijkheden van automatic.

[dePannenkoekjes]

Oh ik dacht dat als je VRAM vol zit op een laptop dat je dan normaal RAM-geheugen gaat gebruiken. Is dat te traag ofzo voor deze situatie?

Je zou toch ook denken dat een NPU niet de (V)RAM vereisten zou verlagen, of zit ik nou dom te denken?

[Zoop]

Van wat ik begrepen heb is dit een limitatie van PyTorch. CUDA ondersteund wel unified memory (waar je het dus over hebt), maar pytorch (en dus diffusion) niet. Dus wellicht dat er aan de software nog te beteren valt voordat je 2k kostende graka's nodig hebt voor dit spul.

Oh en btw, qua laptop graka, het is een dedicated gpu, heeft ook een Radeon onboard, die doet waarschijnlijk wat je bedoelt (wel vreemd, zowel een radeon als een geforce in je laptop). En nee, daar wil je je spul waarschijnlijk niet op draaien als je de optie tot een 3060rtx hebt, denk ik.

[Reactie gewijzigd door Zoop op 22 juli 2024 13:27]

[dePannenkoekjes]

Oké, goed om te weten dat unified memory dan niet altijd zo werkt. Hier kan dus idd nog het een en ander geoptimaliseerd worden met dGPU's.

[d3x]

AMD heeft ze al tijdje geleden aangekondigd, zelfs eerste versies nu al te koop.

https://www.xda-developer...eon-7000-mobile-ces-2023/

[Cergorach]

Je heb gelijk, dat zit echter niet in de hele AMD 7000 (mobile) serie, zelfs niet in alle ZEN4 CPUs, alleen in de Phoenix serie en dat is 7x40U/H/HS en bv. niet de 7x45HX. Er staan momenteel 5 modellen laptops met die chips in PW, drie daarvan (van ASUS) zijn direct leverbaar...

Bron:
https://en.wikipedia.org/wiki/Zen_4

[JSLV]

Daar heb je natuurlijk volledig gelijk, een dGPU is duurder en verbruikt meer stroom (al ben ik benieuwd naar hoeveel Watt deze NPU nu daadwerkelijk gebruikt).

Ik ben ook zeker hoopvol dat Intel (en AMD) deze techniek voortzetten en we in de nabije toekomst voor minimaal stroomverbruik plaatjes kunnen generen.

[dePannenkoekjes]

maar als deze user het binnen 2 seconden kan, dan kan een tragere GPU het toch ook, maar dan gewoon trager? Voor de weinige keren per jaar dat ik wens een stock foto te hebben kan ik best een halve minuut wachten voor een goeie resolutie en kwaliteit versie via een normale GPU. Is dat het nou waard om weer extra voor te betalen? Die functie gaan AMD en Intel weer gebruiken voor een leuke prijsverhoging

[Cergorach]

...dan kan een tragere GPU het toch ook...

Dat ligt er natuurlijk aan de gebruikte techniek in die GPU, het zou zomaar kunnen dat een tragere GPU het niet aan boord heeft, maar ik zie nergens een lijst requirements. Daarnaast is natuurlijk de vraag of als iets het kan, hoe lang dit duurt. Leuk dat je oude tragere GPU het kan, maar ipv. 2 seconden, duurt het 2 dagen of zelfs 2 weken...

[Sp3ci3s8472]

Die NPU gaat in ieder geval niet voor dit gebruikt worden, het is leuk dat het kan maar ik ga geen 20 seconden op een plaatje wachten . Het zal eerder voor andere dingen gebruikt gaan worden gok ik zo, eerder in de lijn van wat Nvidia doet met hun ruis onderdrukking.

Zonder de settings te weten is het lastig om te weten of het snel is of niet; mijn RTX 3070m doet iets van 6.5-7.5 zonder xFormers en een oude versie van Stable Diffusion en mijn 7900 XTX doet 18-21 it/s (helaas nog ook zonder xFormers).

Dit is de default euler-a met 20 iteraties.

[Robin4]

Wat is een NPU precies? Is dat een GPU op CPU niveau of zo? Dus cpu core, met de basis van een gpu? Hoe moet ik dat zien?

[Reactie gewijzigd door Robin4 op 22 juli 2024 13:27]

[Zoop]

Basically een GPU achtige chip maar dan niet voor videobeeld (dus ook niet de nodige outputs en video decoders). Een beetje zoals die crypto-mine kaarten, wat eigenlijk gewoon videokaarten zonder display poorten zijn. Alleen zijn deze processors wel toegespitst op dit soort taken.

Vergelijkt in ieder geval meer met een gpu dan een cpu.

[MSalters]

Uit m'n hoofd had de eerste Movidius NPU wél een video-decoder. Dat was omdat je daarmee de binnenkomende videostream van een camera kon decoden, om daarna je AI op los te laten. Dit was efficienter dan de videostream via de CPU en de GPU te routeren.

[mutley69]

Als ze dat met Gimp gebruiken gaat dat ook voor AI-Video-rendering en grafische AI-verwerking gebruikt kunnen worden.

[Jdewit]

Jammer dat datapoint intel door liet gaan om die 8008 uit te brengen. Zonder die gekke texanen hadden we nu geen x86 instructieset gehad.

[andru123]

Wat is so gek aan die instructies?

[Timmmeeehhh]

Vind de demo niet heel speciaal. Snap het nut van dedicated hardware hiervoor wel, maar Stable diffusion is op mijn 4090 vele malen sneller. Ja dat is een beest van een gpu, maar je zou verwachten dat gespecialiseerde hardware wel in de buurt zou komen.

[Jan Onderwater]

Mooi dit, Peak '86