Intel Arc "Alchemist" första grafikkorten från Intel – demas i flera speltitlar

Okej, men när går de att faktiskt köpa? 2023?

Sjukt aggressivt rabatterat prissatt mot OEMs/SI

Så... Seriöst... INGEN på Intel tyckte det kändes tärt att döpa sin nya fina tekniska pryl till samma som en fil-extension som varenda utvecklare värd namnet stött på de senaste 35 åren? Ja, jösses...

För egen del ser jag mest fram emot GPGPU-tester på dessa kort. Nvidias CUDA behöver en relevant konkurrent, enda som ligger på liknande teknisk nivå är Apples Metal compute men dels har inte Apple (än så länge, ryktas om att det kommer ändras under 2022) några high-end GPUer och dels är Metal APIet låst till MacOS/iOS.

Intel har jobbat på rejält med sitt OneAPI. GPGPU-delen i OneAPI bygger på Khronos SYCL, som till skillnad från OpenCL, faktiskt kan konkurrera med CUDA kraftfullhet och enkelhet för programmeraren. Designen i SYCL möjliggör faktiskt automatisk optimering (i.e. kan göras av "runtime") av saker som man måste hand-jaga i CUDA (och även i OpenCL och Metal compute).

Intel verkar också fatta att om man ska få igång användningen räcker det inte med att sätta en "öppen källkod" stämpel på det hela och tro att problemet löser sig själv. Intel har lagt rätt stora resurser på att lägga in OpenAPI-baserad acceleration i en lång rad program och ramverk, Nvidia insåg tidigt hur viktigt detta är och CUDAs dominas idag beror mycket på att att Nvidia lägger så mycket resurser på CUDA-stöd i grundläggande ramverk.

Även om OneAPI också fungerar på Xe som finns i Tiger Lake plattformen och att det ger ett bra tillskott om man måste jobba på en bärbar dator, räcker inte det för mer komplexa problem och det visar inte heller huruvida HW och OneAPI går att skala upp till high-end!

Trist att det nu går in i 2022 innan man kan få lite av denna data

Antar du menar Ethereum, eller?

256-bitars minnesbuss med GDDR6 där överföringshastigheten ligger mellan 14-18 Gbit/s per pinne ger en teoretisk prestanda på 56-72 MH/s. Kollar man på Ampere och RDNA2 ligger faktiskt prestanda rätt nära teoretisk prestanda, samma bör rimligen gälla här.

Givetvis endast om vissa shady klausuler upprätthålls, så som att det endast gäller de OEM som bygger exklusivt med Intels komponenter.

ARC är inte helt nytt inom grafik heller, det kom väl iom HDMI 1.4, så typ dussinet år sedan.

Med tanke på att det väl står får Audio Return Channel (?) och inte har något med grafik att göra så kan jag nog ursäkta dem för det.

En dum fråga, kommer det versioner med kylning från MSI,Asus,Zotac,Gainward osv. tro?

Japp men hade varit kul om de släpptes i år, men verkar som att Arc? mjukvaran och drivrutiner inte är redo

Ska bli intressant att se vad korten hamnar på för hash rate.

Har aldrig hört talas om arc. Är det något för så kallade "gamla rävar"?

TL;DR är att Gallum lär göra saker bättre, men är SPIR-V/DXIL som lär plocka bort majoriteten av de problem vi historiskt sett i form av inkompatibilitet mellan GPUer.

Längre variant...

Gallium borde rimligen minska skillnaderna mellan olika GPU-tillverkare, för tanken med det projektet är att en rad saker är egentligen generellt i ramverk som OpenCL, OpenGL, Vulkan etc och det vore riktigt trevligt att man bara har en sådan implementation.

Men det finns fortfarande en lager som måste implementeras för varje GPU-arkitektur

Dock en klar förbättring jämfört med tidigare när väldigt mycket av OpenGL/OpenCL duplicerades i varje drivare

Men är inte i implementationer av API:erna mot applikationer, d.v.s. biblioteken för Vulkan, OpenGL och OpenCL jag upplevt de flesta buggarna utan de har främst dykt upp i kod för kernel/shader.

Exempel på problem är att koden för en "OpenCL kernel", <namn>.cl, innehållit buggar i form av avsteg från specifikationen men att detta ändå accepterats av det man testat med (typiskt AMDs drivare, då CUDA används långt mer och presterar typiskt bättre för Nvidia jämfört med OpenCL). Enligt specifikationen är programmet inkorrekt och det är egentligen odefinierat vad programmet egentligen gör. När detta körs på Intels drivare ser det ut som en bug, programmet startat inte då deras drivare vägrar kompilera kernel då den inte är korrekt.

Just den typen av problem är så vanliga både i shaders och compute-kernels att man insåg att det hela var "broken by design". Det har fixats i DX12, Vulkan och OpenCL >=2.2

Problemet med OpenCL 2.x visade sig (specifikt Nvidia bevisade detta) att OpenCL 2.x innehåller delar som gör det i stort sätt omöjligt att implementera den specifikationen både korrekt och effektivt om man kör på dGPU.

Vid det här läget tror jag de flesta gett upp på OpenCL som API för "vanliga" applikationer, men det har ändå ett värde som "low-level driver" för andra ramverk så man skapade OpenCL 3.x, det är i praktiken OpenCL 1.2 fast med den nya (korrekta) designen för hur kernels kompileras till specifika GPUer (via något som kallas SPIR-V).

Gallium+SPIR-V borde göra det långt enklare att i framtiden skriva program som faktiskt fungerar korrekt på de flesta GPUer

SPIR-V används också av Vulkan. DX12 använder något som kallas DXIL, allt fler Vulkan drivers kan även använda DXIL för shaders utöver SPIR-V.

Fördelen med ett format som SPIR-V och DXIL (båda är kan ses som en generell GPU-assembler) över att direkt översätta kod till faktiskt GPU-maskinkod är att kod lämnar långt mer öppet för tolkning -> olika personer tolkar saker olika -> detta är orsaken till majoriteten av alla buggar som gör att något fungerar på vissa GPUer men inte andra. Nu finns en implementation som översätter från kod till SPIR-V (tillverkas via Khronos) och DXIL (tillverkas av Microsoft).

Gallium3D gör som sagt motsvarande för runtime biblioteket för Vulkan, OpenCL och OpenGL (och implicit för SYCL då de flesta implementation använder OpenCL som "driver", men är inget krav och SYCL implementeras ovanpå CUDA för Nvidia).

Intel Ars Technica?

En kommentar från "JayzTwoCents" var att Intel ARC riskerar förväxling med Intel ARK, men jag tror inte det.
Intel föredrar säkert att C-et uttalas som S för att undvika det problemet...