Intel schrapt Data Center GPU Max 1350, werkt aan Max 1450 voor 'andere markten'

Intel heeft zijn Data Center Max GPU 1350 geannuleerd. Die videokaart, die is bedoeld voor gebruik in supercomputers en datacenters, werd vorig jaar door Intel aangekondigd. Het bedrijf komt later dit jaar met een Data Center Max GPU 1450 die is bedoeld voor 'andere markten'.

Intel bevestigt het schrappen van de Data Center GPU Max 1350 tegenover Tom's Hardware. Het bedrijf zegt zijn datacenterline-up te 'stroomlijnen' door de videokaart in kwestie te annuleren. Het bedrijf bracht vorig kwartaal zijn eerste gpu voor datacenters uit. Deze Data Center Max GPU 1550 betrof het topmodel in Intels line-up, met 128 Xe-cores, 128GB geheugen en een tdp van 600W. De 1350 zou daaronder gepositioneerd worden, met een lagere tdp van 450W, minder geheugen en minder Xe-cores. Die verschijnt dus niet langer. Een GPU Max 1150-instapmodel staat nog wel op de planning.

Ter vervanging komt Intel met een Data Center GPU Max 1450. Die gpu krijgt volgens Intel 'een lagere i/o-bandbreedte'. Het bedrijf deelt verder geen specificaties, maar mogelijk gaat het om een afgeslankte versie van de 1550. De gpu krijgt ondersteuning voor water- en luchtkoeling, net als de 1550. De gpu komt 'later dit jaar' uit, maar Intel deelt geen concrete releasedatum.

De chipmaker zegt zich met de 1450 te richten op 'andere markten' dan de 1350. Het bedrijf verduidelijkt niet om welke markten dat gaat. Vorig jaar introduceerden de Verenigde Staten echter exportrestricties op geavanceerde chips naar China. Die restricties gelden onder meer voor gpu's met een i/o-bandbreedte tussen verschillende chips die hoger is dan 600GB/s. Nvidia bracht eerder aangepaste versies van zijn A100- en H100-gpu's met lagere bandbreedtes uit om aan die restricties te ontkomen. Intel bevestigt niet of het diezelfde weg neemt met zijn Data Center GPU Max 1450.

Intel was aanvankelijk van plan om dit jaar zijn eerste Rialto Bridge-gpu's uit te brengen, als opvolger voor zijn eerste datacenter-gpu's in de Data Center GPU Max-serie. Volgend jaar zouden Falcon Shores-chips volgen. Intel annuleerde zijn Rialto Bridge-serie begin maart en stelde Falcon Shores toen uit naar 2025. Het bedrijf deed eind vorig jaar een reorganisatie van zijn AGX-divisie, die verantwoordelijk is voor gpu's en accelerators.

Reacties (32)

[Verwijderd]

Intel is te terughoudend als je het mij vraagt ( niet dat ik er verstand van heb maar goed). De markt staat te springen voor een Nvidia alternatief voor data science taken waaronder machine learning, deep-learning, 3d rendering, point cloud manipulatie etc.

Als intel gewoon producten op de markt brengt die in de buurt komen van Nvidia, en goede software support leveren, dan weet ik zeker dat de open-source community ze met open armen zal ontvangen, al was het maar om Nvidia een concurrent te geven.

Intel hoeft Nvidia niet te verslaan, ze hoeven alleen maar mee te doen in de zelfde markt. Als intel te lang wacht dan raakt de markt zo vergroeit met Nvidia only software, dat geen concurrent er straks nog tussen kan komen.

[d3x]

Ik stel voor dat je even wat verder onderzoek doet naar de AMD Instinct GPU en het initiatief voor open-source met het ROCm en MIOpen project.

[Guru Evi]

AMD's MxGPU ondersteuning echter staat al jaren stil: https://github.com/GPUOpe...SDKs/MxGPU-Virtualization

Voor datacenters wil dit dus zeggen dat AMD zo goed als dood is, weinig mensen die vandaag een volledige GPU nodig hebben, met oa. Docker containers die een volledige kaart nodig heeft voor elk proces wordt dit een dure gelegenheid, een nVIDIA A40 kun je gemakkelijk opsplitsen in 48 TensorFlow containers, dus in 2U kun je 192 containers draaien elk met een individuele vGPU, Intel heeft ook open source vGPU ondersteuning zelfs voor de iGPU op een Xeon/Core processor.

Daarnaast is oa. CUDA een quasi-standaard en de alternatieven van AMD of OpenCL zijn misschien wel beschikbaar, maar de TCO is wel hoger en AMD heeft al jaren problemen om hun CPU's en GPU's op schaal te leveren, dus als je een datacenter wilt vullen, vallen ze meestal ook af. De Intel kaarten zijn nog niet beschikbaar, maar eenmaal ze een product hebben ze wel de interne fab capaciteit om te leveren, terwijl AMD 3-4 jaar op voorhand bij oa TSMC capaciteit moet bestellen.

[Reactie gewijzigd door Guru Evi op 23 juli 2024 16:52]

[BramVroy]

Voor datacenters wil dit dus zeggen dat AMD zo goed als dood is

Deze comment verdient niet de upvotes die het krijgt. Het klopt gewoon niet. Om even twee voorbeelden te geven (ROCm en supercluster):

- De ROCm stack wordt actief ontwikkeld en is open-source
- Er zijn ROCm dockers en prebuilt wheels voor tensorflow en pytorch. Support zit dus gewoon goed
- De Europese supercomputer LUMI die nu klaar is (#1 van Europa, #3 van de wereld) is full AMD met AMD Trento en AMD Instinct GPUs. Enkel de GPU partition heeft al 2560 nodes met elk een 64c AMD Trento en 4x MI250X. Ik denk dus dat dat je argument over "op schaal leveren" even herzien of verduidelijkt moet worden

Er wordt altijd nogal overdreven als het over AMD in de datacenter/supercluster gaat. Je mag niet blijven vastzitten in het scenario van 5 jaar geleden - de tech-wereld verandert elke week.

[Reactie gewijzigd door BramVroy op 23 juli 2024 16:52]

[d3x]

dat is wederom een heel andere doelgroep. Die ik trouwens op de voet gevolgd heb, ook hier was er weer duidelijk sprake van inmenging, het was gemakkelijk voor nvidia om hun producten door te duwen tegen een zeer kleine niche speler.

"en AMD heeft al jaren problemen om hun CPU's en GPU's op schaal te leveren"
Ik ben er zeker van dat jij op het niveau zit dat je weet dat AMD problemen heeft met leveringsproblemen op schaal....

kijk trouwens even waar Intel zijn GPU gaat halen en een deel van zijn CPU zelfs in de toekomst....

[Reactie gewijzigd door d3x op 23 juli 2024 16:52]

[Guru Evi]

Inmenging? AMD kon gewoon VFIO/IOMMU gratis ondersteunen ipv nVIDIA's betaalde opties en via de markt voor oa kleinere bedrijven en onderzoeksinstellingen (waar de kosten meer wegen) MxGPU verder ontwikkelen, maar ze wouden er gewoon niet investeren.

5 jaar geleden was AMD met Microsoft aan het gokken om vGPU via processen op de hypervisor (zoals oa VirGL en VMWare het toen deden), je kunt nog steeds Azure instanties verkrijgen met de AMD GPU technologie, echter was het nooit open source en zelfs Microsoft heeft het uiteindelijk laten vallen in HyperV omdat het niet goed schaalt voor moderne applicaties.

De grootste klant voor nVIDIA is commercieel (75%), deels ook door hun aankoop van oa. Mellanox de grootste klant voor AMD is gamers en het commercieel aandeel is grotendeels gedreven door Xilinx (FPGA en SoC).

Ivm leveringsproblemen: inderdaad, daar heb ik al een paar jaar problemen mee, kijk maar bij de grote serverboeren - Dell, HP etc - een Xeon server kun je krijgen in 3 dagen, een Genoa server, tenminste een maand.

[bwerg]

Xeons bakt Intel zelf, maar hun GPU's komen bakken ze in dezelfde fabriek als AMD.

[d3x]

een genoa server een maand? Dat is standaard server leveringen bij HPE, Dell, Cisco in een BTO systeem, wat jij aangeeft van 3 dagen zijn gewoon configs die bij de locale distro liggen. wat een aanname.....welkom in de server wereld.
De intel 4th gen scalable xeon is bestelbaar vanaf midden januari, allee alvast de prijzen dan toch beschikbaar, ze worden nu amper uitgeleverd... en die hebben dan zogezegd hun eigen fabs...(en ja,heb er al een paar als test draaien, maar er zullen er niet al te veel zijn die dat kunnen zeggen)

Dat de Xeon 3th gen beschikbaar is, ja dat is niet moeilijk, als het voor geen meter verkoopt ook al is de markt defacto standaard 80% in handen dan hebben de meeste distro zo wel wat van die shit op stock .. voor de kleine prutsjes zo als jij blijkbaar die al jaren eens iets koopt met een standaard config.

ivm MxGPU, de groote spelers zijn van in de begin met nvidia gestart (vmware, citrix) en de OEM gaven 99% support enkel voor nvidia kaarten waarbij AMD op prof GPU het al zeer moeilijk had in die tijd tegen nvidia, dan is het niet simpel om je zomaar in de markt te positioneren, maarja jij weet er blijkbaar alles van, als je verwacht dat een server er is op 3 dagen.....ik heb trouwens ook nooit gesproken over open source vGPU, jij komt met het vGPU verhaal af terwijl het over AI modellen ging (remember andere doelgroep...)

Waffer hoeveelheid bij TSMC is trouwens niet het probleem, maarja waarom proberen uitleggen aan tunnel visionairs..... https://www.techgoing.com...u-pcb-substrate-shortage/

[Reactie gewijzigd door d3x op 23 juli 2024 16:52]

[Guru Evi]

Ik heb nu ~55 4th gen Xeon servers met 4xA100 (HPC) draaien, besteld en verkregen in 2 weken tijd en die zijn BTO, de vertraging had te maken met de voedingen (2.4kW) die moeilijk verkrijgbaar zijn.

Cisco Nexus 9K switches echter hebben momenteel al meer dan een jaar vertraging, we draaien nu een hoop Dell switches en oudere Cisco switches zonder contract omdat Cisco ze gewoon niet kan leveren op schaal en die zijn helemaal niet BTO. Je kunt inderdaad wel bepaalde switches in kleine oplagen bestellen, maar een datacenter vullen gaat niet.

vGPU en AI gaan hand in hand in de datacenter, we spreken niet over "kleine prutsjes", als je vandaag nog steeds 'bare metal' draait in je datacenter, en nog steeds niet met VM+containers draait, doe je iets verkeerd, AI modellen van vandaag hebben heus geen 48 of 96GB VRAM nodig, zelfs ChatGPT draait op minder, gemiddeld model trainen heeft 4-8GB nodig voor wat wij doen. Als je op de cloud gaat krijg je heus niet de volledige kaart. vGPU via nVIDIA is beschikbaar in elke hypervisor omdat elke vGPU zich voordoet als een aparte PCIe kaart, gelijkaardig had AMD MxGPU, en die was open source, maar AMD heeft die laten vallen in voordeel van een soort van VirGL in oa. HyperV - in bed gesprongen met Microsoft en nooit MxGPU verder ontwikkeld.

Je kunt nVIDIA niet verwijten van de juiste keuzes te maken, zou AMD MxGPU ontwikkeld hebben en open source gehouden, dan hadden veel mensen in bedrijven dat gekozen voor oa. TensorFlow in Kubernetes/Docker, waar de nVIDIA licenties duur kunnen worden (als je een A40 opsplitst in 48 containers, betaal je bijna 5000 euro/jaar/kaart aan licenties). Je kunt inderdaad wel bepaalde AMD kaarten draaien maar dan heb je veel meer kaarten nodig en kom je plaats tekort.

Wij hadden bijna voor HyperV gekozen vanwege de AMD ondersteuning, maar de performance was bagger en Microsoft heeft die uiteindelijk laten vallen, er is gewoon geen keuze dan. En ja, er zijn andere "accelerator" kaarten met chips van oa. Xilinx (ook AMD) als alternatief, maar opnieuw, drivers en ondersteuning voor Linux/KVM en andere open source projecten zoals TensorFlow of PyTorch is er bijna niet.

[Reactie gewijzigd door Guru Evi op 23 juli 2024 16:52]

[Verwijderd]

Ben ja laren bekend met AMDs ROC project, en kan ze alleen maar toejuichen.

Intel heeft nu al een werkende pytorch versie voor hun GPU's : GPU
En ze hebben support voor acceleratie via hun CPU's : CPU

Intel neemt het in tegenstelling tot AMD wel serieus, dat zie je niet alleen aan hun software maar ook aan de GPU hardware. De "midrange" a770 heeft bijv standaard al 16GB en kost slechts 390 euro. Vergelijk dat met AMD hun goedkoopste 16GB kaart is geloof ik de RX 6800 (non XT) voor 580 euro. De goedkoopste Nvidia kaart met 16GB is de RTX A4000, zie de invloed van hun monopoly...

Ben normaal geen intel fan, maar AMD kan hier beter zijn best doen.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 16:52]

[CrazyJoe]

De A770 is niet bedoeld voor data science applicaties. Intel heeft geen workstation level GPU's. Ze hebben alleen consumer GPU's zoals de A380, A750 & A770 en Data center GPU's zoals de GPU Max en Flex series (alhoewel die laatste meer op Video applicaties lijkt gericht). Ze hebben niets daartussen.

[Reactie gewijzigd door CrazyJoe op 23 juli 2024 16:52]

[d3x]

het topic gaat over data center en data science applicaties, niet over wat ze in een consumenten versie insmijten van geheugen, alsof die 16GB met een specifieke reden gedaan is daarvoor .
"Intel neemt het in tegenstelling tot amd wel serieus" een grap neem ik aan? AMD staat op het punt om de MI300 series te releasen en staat overal in de top 500 , Intel moet nog beginnen om iets effectief in gang te krijgen in een echt datacenter met eigen GPU combo.

[Guru Evi]

De RTX A4000 kun je niet vergelijken met een RX6800. De RTX A4000 is voor serieuze toepassingen, kijk eerder naar de Radeon Pro series.

[Verwijderd]

Dit is niet alleen een reactie op u maar ook op vergelijkbare reactie hierboven.

Het maakt niet zo veel uit, tenzij je de GPU in een server hebt voor een 24/7 workload in a mission critical scenario (zoals hosting ofzo). Een game runnen is net zo "serieus" als een machine learning model trainen of het eiwitten vouwen. Dat hebben de crypto miners ook wel aangetoond, die GPUs zijn echt door de ringer gehaald, en hebben meer werk verricht dan een GPU in bijv een research workstation ooit zal moeten doen.
Het verschil in prijs tussen een RTX 4000 en een 3060TI komt voor 90% uit het verschil in VRAM, de overige 10% is voor kwaliteit controle.. en de "speciale" drivers en certificaten etc is gebakken lucht puur voor marketing.

[Guru Evi]

Dat dacht ik vroeger ook, totdat je een probleem hebt. Naast de grotere VRAM is er ook ECC en meer bandbreedte in de "Pro" chips (beide bij AMD en nVIDIA) voor GPGPU, niet voordelig voor 'gamers', maar het maakt wel uit voor grotere pakketten. Zelfs mining werkt beter op een Pro GPU, maar de meerprijs komt er echter niet uit.

Daarnaast is er echt geen (0,0) ondersteuning als je oa. SolidWorks of gelijk welk ander wetenschappelijk pakket draait op een GeForce, gebakken lucht voor een gecertifieerde driver, maar een pakket dat 50k/jaar/computer in licenties kost (~250 euro per werkdag) niet kunnen draaien omdat je een paar honderd euro wou sparen komt niet goed over naar de gebruiker, een probleem aan de voeten van de ontwikkelaars kunnen leggen en binnen 4u een antwoord van nVIDIA verkrijgen met een oplossing, daarvoor betaal je de meerprijs.

[Reactie gewijzigd door Guru Evi op 23 juli 2024 16:52]

[cptjibberjabber]

Ik heb er ook geen verstand van, maar het lijkt me erg kort door de bocht om te zeggen "als Intel nou een gelijkwaardig product maakt als de marktleider dan willen mensen het wel hebben".

Natuurlijk zou het dan goed gaan, maar het product van de marktleider is ook niet zo simpel te kopiëren, al helemaal niet in zo'n technisch onderlegde industrie als GPU chips.

Er zit ongelooflijk veel kennis en IP achter de technologie van Nvidia, en er zijn zoveel bedrijven die hun software specifiek hebben afgestemd op de hardware van Nvidia dat het heel moeilijk is om dat te evenaren. Zelfs al zou Intel exact weten hoe ze hun chip architectuur moeten inrichten, dan zitten er vast bergen patenten van Nvidia op. Zo hebben AMD en Nvidia jaren geleden al een contract afgesloten om delen van hun IP voor elkaar toegankelijk te maken zodat de hele markt niet vastloopt.

[Verwijderd]

Zie mijn post hierboven, intel heeft het al voor elkaar gekregen om pytorch backend te schrijven voor hun eigen GPUs, en daarnaast zijn de intel GPUs de beste bang for buck. Nu moeten doorzetten, en dan over tijd zal hun product vanzelf in de buurt komen van Nvidia.

Niemand verwacht dat Intel direct met de marktleider op dit gebied kan concurreren, en dat is ook niet direct noodzakelijk.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 16:52]

[hooibergje]

Het nadeel is dat een hoop wetenschappelijke software op CUDA hangt, wat NVidia-only is.
Voor een bredere hardwarekeuze moet er openCL geprogrammeerd worden, wat minder mooi en lastiger is, en waar een minder grote community achter zit.

[Verwijderd]

Klopt, zie mijn reactie hierboven voor wat meer context

Intel doet goed hun best wat betreft software support, nu moeten ze doorzetten als ze willen concurreren met CUDA.

[CrazyJoe]

Intel heeft zijn eigen proprietary software genaamd OneAPI.

[Verwijderd]

proprietary software genaamd OneAPI.

Zou beter zijn als ze het in OpenAPI zouden veranderen en bijv met de cuncurent AMD zouden samenwerken om zo een goed alternatief te bieden voor Nvidia, die nu de markt heel sterk domineert.

[CrazyJoe]

OpenAPI bestaat al, dus dat is niet zo'n handige naam. Het probleem dat Intel zich aangedaan heeft met OneAPI is dat ze proberen al hun devices hier onder te brengen: GPU, CPU en FPGA. Dit vereist een eigen framework omdat een CUDA-achtige API, zoals AMD aan het creëren is met HIP, niet gaat werken voor CPU en FPGA.

Intel zet dus in op een "one size fits all" API, met alle problemen van dien: tooling moet alle gebruiksmodi van de API ondersteunen (dus compilers, debuggers, profilers etc), de taal moet conceptueel werken op alle drie de nogal divergente hardware opties en je moet developers zover krijgen dat ze willen werken in deze nogal van voor hun bekende API afwijkende nieuwe API.

AMD is slimmer bezig met HIP, dat is een bijna 1 op 1 kopie van CUDA (ze leveren zelfs tooling om HIP code direct om te zetten in CUDA compileerbare code voor NVIDIA hardware). Dus geen "one size fits all" oplossing, maar een op GPU gebruik toegespitste oplossing.

OpenCL is door iedereen afgeschreven, dus daar zit ook geen heil in.

[dmantione]

al hun devices hier onder te brengen: GPU, CPU en FPGA

En dat is dus precies waar het misgaat: GPU, CPU en FPGA is fundamenteel andere hardware. Net zoals dat een GPU nooit efficiënt een gecompileerde stukje C-code zal uitvoeren, zal een FPGA nooit efficiënt CUDA uitvoeren en zo verder.

CUDA is zo dominant geworden omdat Nvidia videokaarten kado gaf aan programmeurs die wetenschappelijke software schreven en ook mannetjes langs stuurden die mee gingen helpen de code te porteren.

Intel kan de GPU-markt niet winnen door een one-size-fits-all API te maken. Dat hebben ze eerder geprobeerd met Knights Landing en toen zeiden "hier is de API en het is x86 dus eh... supermakkelijk voor jullie". Maar het was niet makkelijk want rekenkracht uit Knights Landing halen vereiste een serieuze herschrijving van software. Iets waar programmeurs niet op zaten te wachten en gezien ze voor hoge prijzen kaarten moesten kopen (de CUDA GPU's hadden ze gratis of voor een vriendenprijsje gekregen), hadden ze daar ook weinig trek in.

Code omschrijven naar GPU vereist talen die gemaakt zijn om de architectuur van de GPU te benutten. Het geschikt maken van software voor GPU's vereist denken in de architectuur van GPU's en een one-size-fits-all API zal daar niet toe leiden. Hoe dan ook is het veel werk, en Intel kan er niet vanuit dat iedereen zit te springen om al de investering die men in CUDA heeft gestopt nog een keer over te doen.

[Novermars_]

Je kan in SYCL (wat jullie bedoelen met oneAPI) ook een kernel specialiseren voor een specifieke device (dus CPU/GPU/FPGA/...), als je de maximale performance wilt halen. Verder is het idee natuurlijk dat de device compiler je algemene code omzet naar device code die goede performance heeft.

Maar vector machines zijn sowieso de toekomst en CPUs zullen meer een meer gebruikt worden om alleen accelerators aan te sturen. Niet voor alle taken, maar NVIDIA bewijst elk jaar maar weer hoe nuttig GPUs in heel veel branches zijn. Intel en AMD (en nog wat meer partijen tegenwoordig) willen graag een stukje van die taart stelen...

Net zoals dat een GPU nooit efficiënt een gecompileerde stukje C-code zal uitvoeren

OpenCL - hold my beer

en Intel kan er niet vanuit dat iedereen zit te springen om al de investering die men in CUDA heeft gestopt nog een keer over te doen.

Hangt er vanaf of NVIDIA door gaat met het verhogen van hun prijzen. Alleen NVIDIA heeft baat bij hun monopolie in de data center markt.

[dmantione]

Klopt allemaal, maar behalve voor FPGA's: Een FPGA is beslist geen vectormachine, om een FPGA optimaal te benutten, bouw je het beste een pijplijn, zodat niet één CPU- of GPU-machinetaalinstructie per klokpuls berekend wordt, maar één stap van het algoritme.En om een pijplijn te bouwen heb je weer hele andere talen nodig, het is dan VHDL of Verlog waar dat in gebeurt.

[CrazyJoe]

SyCL is slechts 1 stukje van de OneAPI puzzel. SyCL is de basis van DPC++, samen met wat constructies die overgenomen zijn uit C++, OpenCL en mogelijk nog wat andere bronnen (is alweer even geleden dat ik naar OneAPI gekeken heb). DPC++ is de programmeertaal voor OneAPI en samen met allerlei libraries vormt dit OneAPI.

Als je kijkt naar de structuur die DPC++ afdwingt om accelerated code te maken, damn lijkt het sterk op die van OpenCL, wat vergeleken met CUDA nogal veel setup werk vereist. CUDA heeft een prettig abstractie niveau die het voor C en C++ programmeurs vrij makkelijk maakt om zich in te werken. Natuurlijk vereist het bekend worden met de specifieke eigenschappen van een massief parallel systeem en hoe je er het beste gebruik van kunt maken een serieuze hoeveelheid training, maar vanuit een taal en API oogpunt gezien heeft NVIDIA het heel makkelijk gemaakt om daar je tijd in te steken.

Daarnaast is de tooling die NVIDIA heeft voor CUDA extreem goed, wat het werken in en debuggen van CUDA code en het optimalizeren van CUDA code zeer prettig maakt.

Zowel OneAPI als ROCm (het ecosysteem rond HIP van AMD) zijn op dit gebied niet zo sterk.

[Novermars_]

DPC++ is SYCL plus wat Intel extensies, die vaak later ook in de SYCL standaard terecht komen. Intel (ook via Codeplay) heeft enorm veel invloed op de SYCL standaard.

DPC++ is de programmeertaal voor OneAPI

SYCL/DPC++ is gewoon C++17. SYCL is met opzet zo opgezet dat je het ook als pure library kan implementeren. Je kan ook oneAPI gebruiken zonder SYCL, je hebt bijvoorbeeld ook Thread Building Blocks binnen oneAPI.

Als je kijkt naar de structuur die DPC++ afdwingt om accelerated code te maken, damn lijkt het sterk op die van OpenCL,

Dat is niet zonder toeval. Beiden komen van Khronos en met de initiële standaard was alleen OpenCL als back-end mogelijk. Met SYCL2020 heb je nu veel meer vrijheid. Intel gebruikt bijvoorbeeld Level0 (dat ook zeer sterk geïnspireerd is door OpenCL), er zijn ook PTX en HIP/ROCm back-ends voor NV en AMD.

wat vergeleken met CUDA nogal veel setup werk vereist.

Klopt, maar wat je daar voor terug krijgt is dat het loopt op alle devices waarvoor een backend is

Daarnaast is de tooling die NVIDIA heeft voor CUDA extreem goed, wat het werken in en debuggen van CUDA code en het optimalizeren van CUDA code zeer prettig maakt.

Preach. VTune voor GPUs is een gedrocht. gdb-oneapi is wel weer beter. Geen idee wat AMD heeft tegenwoordig, zal ook niet veel soeps zijn.

[SuperDre]

Nouja, de A750 en A770 zijn al behoorlijk goede alternatieven. Helaas voor VR zijn de drivers nog niet zo goed maar hopelijk fixen ze dat toch nog snel. Ben beniewd naar de refresh versies die schijnbaar nog dit jaar komen.

[whersmy]

Ze hebben het niet makkelijk zeg als nieuwe speler, hoop dat ze gewoon door kunnen gaan.

[Ladiesman777]

Dat hebben ze aan hun zelf te danken met het niet overnemen van ATI.

[vanaalten]

Waarom wordt dit nog een videokaart genoemd in het Tweakers.net artikel?

Supercomputers, datacentra - ik kan mij niet voorstellen dat er een monitor aan komt te hangen en denk ook niet dat het primair gebruikt wordt voor het berekenen van videobeelden; lijkt mij eerder dat zo'n ding gebruikt wordt voor specifieke taken die veel parallelle bewerkingen vereisen, maar niets met video te maken hebben.

Of mis ik hier iets en wordt zo'n ding wel degelijk vooral voor grafische toepassingen gebruikt?

[Pietjeball]

In bovenstaande slide noemt Intel het een 'Data Centre 'GPU' dus je kunt je kritiek beter tot Intel richten gezien ze het nog steeds een Graphics Processing Unit noemen. Goed vertaald zou Tweakers dan de term 'grafische kaart' kunnen gebruiken. Maar dat klopt ook al niet meer