Intel vill förse miljontals spelare med grafikkort

Kan du ge lite mer detaljer om exakt hur sådana deals görs?
Betalar Intel även mer för denna förtur eller väljs de bara för att TSMC bara tycker om dem så att säga?

Ett par punkter som skulle antyda motsatsen -

Intel och TSMC är i princip direkta konkurrenter.
Intel investerar i nya fabriker och har därmed tydligt inga planer på att bli "fabless"
AMD är uppenbart en stor kund/partner till TSMC som kopplar dem till Microsoft och Sony med deras konsoler.
Det är tydligt att det finns mer demand än lines just nu även typ bara med AMDs combo av CPU, GPU och konsoller.

Även på 3nm måste Intel buda mot apple om kapacitet hos TSMC.

Varför exakt skulle intel då få förtur över de andra tillverkarna när de även är en direkt konkurrent, vars vinster på allt de tillverkar hos TSMC går dels till att bygga upp sitt eget utbud från egna fabriker?

Det låter lite bakvänt tycker jag.

Blir självklart kul att se hur Intels GPUer presterar i spel. Men ser själv långt mer fram emot hur Intel klarar av att konkurrera med Nvidias CUDA för GPGPU, det med deras OneAPI.

Intel har en rejäl uppförsbacke, proppen har riktigt gått ur användningen av GPGPU (som i praktiken är CUDA och till mindre utsträckning Metal på MacOS). Även rätt klena GPUer kan ge stor vinst, ett exempel är Blender där iGPU hos M1 ger 3-4 gånger prestandaboost i Cycles (finns Metal stöd från 3.1 som nu är i beta).

Ovanpå det kan man numera göra ”normal programmering” i t.ex. Python och få brutala prestandaförbättringar (får att få upp mot x100 prestandaökningar även mot ”high-end” desktop CPUer) i ”rätt” fall, vilket typiskt är de fall som går att sprida över kärnor (så långt ifrån alla fall, men går det att beskriva med matriser så går det att accelerera).

Klicka för mer information

CuPY är en CUDA-accelererad variant av Python biblioteket NumPy, som i sin tur är en väldigt välanvänt bibliotek för AI/ML, bildanalys etc.

Visa mer

Det krävs tyvärr rätt stora arbetsinsatser för att nå den mognadsgrad vi nu ser för CUDA-integration. Det kommer aldrig hända om inte Intel själva skjuter till rejäla resurser. Nvidia har ungefär 10 gånger fler som jobbar med programvara mot de som jobbar med HW-design.

För datacenter börjar man redan nu se rätt bra OneAPI stöd, får se hur det tar sig för konsumentmarknaden…

En sådan deal är rätt exakt det Apple har med TSMC. Motivationen för TSMC är att de får pengar i förskott vilket minskar risken för dem medan motivationen för Apple i det läget är att de får förtur.

Så om Intel har en sådan deal även för 6 nm (vet inte om det är så, allt pekar på att det är exakt vad deal:en på 3 nm bygger på) har Intel fått betalat för privilegiet.

Det är exakt vad AMDs HIP är. Eller det är enklare än så, HIP är i stort sätt AMDs implementation av CUDA (d.v.s man implementerar samma API, behövs därför ingen "översättning" när man kör).

Kan verka som en bra strategi då kostnaden att komma igång blir mycket lägre då man kan utnyttja det som redan finns.

Fast problemen är många

• HIP kommer alltid ligga efter CUDA då det inte finns någon information kring vad som läggs till i nästa version, i praktiken ligger HIP 3-5 generationer efter CUDA

• CUDA är enbart designat med utgångspunkt kring vad som är optimalt för Nvidias GPU-design. På hög nivå fungerar alla GPUer rätt lika, men på mikroarkitekturnivå finns flera rätt fundamentala skillnader mellan Nvidias, AMDs och även Intels GPU-designer

• Om "originalet" är ungefär lika dyrt som kopian, varför skulle man då inte köpa originalet?

Nämnde CuPY ovan och där kan man rätt snabbt se exakt vilka problem en sådan lösning får i praktiken. Kollar man på projektsidan ser det riktigt lovande ut för Radeon, man listar stöd för totalt 3 st ROCm versioner.

ROCm är namnet på Linux-drivaren som implementerar bl.a. HIP, så ett problem är avsaknad av Windows stöd (CUDA fungerar både på Linux och Windows).

Men det riktigt stora problem hittar man under sektionen Limitations. Det är ett totalt minfält att försöka använda en GPU som kör HIP i stället för CUDA. Finns flera saker som inte fungerar, det är nog svårt att skriva problem utan ha sådana problem... Vissa fungerar inte för att det ännu inte är implementerat, det skulle kunna lösa sig i framtiden. Men andra saker är inte implementerat då CUDA som sagt är designat för Nvidias HW och det finns inget vettigt sätt att implementera motsvarande på AMDs GPUer.

Intels väg kräver betydligt mer arbete up-front, men det är hur man rimligen måste gå tillväga om på allvar ska utmana Nvidias CUDA-dominans.

Specifikt för GPGPU använder OneAPI Khronos SyCL. Nvidia är nog måttligt intresserade att stödja det, och utan stöd på Nvidia GPUer är GPGPU i nuläget rätt DoA. Så Intel har inte bara implementerat stöd för sina egna GPUer, man har även implementerat stöd för Nvidias GPUer (det genom att använda CUDA "under huven").

Det är bara en förutsättning för att man ska ha någon chans. OpenCL var chanslös mot CUDA då den senare var långt enklare att jobba med. Här har Khronos lärt sig, SyCL är lika lätt och i vissa fall enklare än CUDA att jobba med på ett effektivt sätt.

Ovan är ändå inte garanti för framgång. Problemet är att massor med viktig projekt är idag specifikt byggda mot CUDA, dessa projekt lär fortsätta med det fram till att Intel (för ingen annan lär göra jobbet i nuläget) kan få liknande stöd med OneAPI. Best-case (för Intel) är att OneAPI/SyCL blir vägen framåt, teoretisk möjligt då det även fungerar på Nvidia GPUer. Mer realistiskt finns i alla fall också stöd för OneAPI (är det vi börjar se mer och mer för Metal, program stödjer Metal på MacOS utöver att stödja CUDA på Windows/Linux).