Nvidia kondigt pci-e-versie van Tesla P100 aan

Nvidia heeft pci-e-versies van de Tesla P100-accelerator aangekondigd. Nvidia onthulde de hpc-kaart met Pascal-gpu al in april, maar die versie beschikte over een door de fabrikant zelf ontwikkelde Mezzanine-connector.

Nvidia maakt eind dit jaar twee versies van de pci-e-variant van de P100 beschikbaar: een met 16GB hbm2 en een met 12GB. De kaarten beschikken niet over de nvlink-interconnect: voor die interface waarmee P100-kaarten onderling kunnen communiceren heeft Nvidia zijn eigen Mezzanine-connector ontwikkeld.

De kaarten beschikken over iets lagere boost-kloksnelheden dan de Mezzanine-versie en ook de tdp is lager: 250W in plaats van 300W. De 12GB-versie van de pci-e-P100 beschikt bovendien over een 3072 bits brede geheugenbus, tegenover de 4096bit-interface van de overige twee kaarten. Net als de P100-kaart die Nvidia in april aankondigde, gaat het om accelerators voor high performance computing zoals supercomputers met een Pascal-gpu en high bandwidth memory van de tweede generatie.

Nvidia kondigde de P100-kaarten aan tijdens de International Supercomputing Conference in Frankfurt.

Nvidia Tesla-familie
	Tesla P100 (Mezzanine)	Tesla P100 (16GB)	Tesla P100 (12GB)	Tesla M40
Streamprocessors	3584	3584	3584	3072
Core-kloksnelh.	1328MHz	?	?	948MHz
Boost-kloksn.	1480MHz	1300MHz	1300MHz	1114MHz
Geheugen kloksn.	1,4Gbit/s HBM2	1,4Gbit/s HBM2	1,4Gbit/s HBM2	6Gbit/s gddr5
Geheugenbus	4096-bit	4096-bit	3072-bit	384-bit
Geheugenbandbreedte	720GB/sec	720GB/sec	540GB/sec	288GB/sec
Geheugenhoeveelheid	16GB	16GB	12GB	12GB
Half Precision	21,2 tflops	18,7 tflops	18,7 tflops	6,8 tflops
Single Precision	10,6 tflops	9,3 tflops	9,3 tflops	6,8 tflops
Double Precision	5,3 tflops (1/2 rate)	4,7 tflops (1/2 rate)	4,7 tflops (1/2 rate)	213 gflops (1/32 rate)
Gpu	GP100 (610mm2)	GP100 (610mm2)	GP100 (610mm2)	GM200
Transistors	15,3 miljard	15,3 miljard	15,3 miljard	8 miljard
Tdp	300W	250W	250W	250W
Formfactor	Mezzanine	pci-e	pci-e	pci-e
Koeling	N/A	passief	passief	passief
Procede	tsmc 16nm finfet	tsmc 16nm finfet	tsmc 16nm finfet	tsmc 28nm
Architectuur	Pascal	Pascal	Pascal	Maxwell 2

Tabel afkomstig van Anandtech

Reacties (74)

[SomerenV]

Kan zoiets nou ook ingezet worden om zaken als video/3d te renderen? Of waar is dit kaartje nou precies voor bedoeld?

[Error323]

Deze kaart is met name bedoel voor deeplearning, een subveld in Artficial Intelligence die nogal in opmars is. De half precision (16 bit float) dragen genoeg precisie als gewichten in een neuraal netwerk en geven dus 21.2 terraflops. De meeste wetenschappelijke/industriele doeleinden hebben veel hogere precisie nodig.

[kiang]

Even ter duiding: 16 bits floating point (oftewel half precission) hebben 10 bit precisie wat overeenkomt met ongeveer 4 cijfers precisie in het decimale stelsel(*). Niet erg veel dus, maar zoals Error323 al zegt is dat voldoende voor deep learning, ook al is het onvoldoende voor vele andere toepassingen.


(*): berekening: je hebt 10 bits in je mantisse van je floating point getal, maar die heeft altijd een niet-opgeslagen voorloop-1, dus in totaal kan je getallen met 11 bits precisie opslaan (ongeveer: subnormale getallen hebben minder precisie).

2¹¹ = 2048, een getal van 4 cijfers, in decimale vorm heb je dus ongeveer 4 significante cijfers. In zeg ongeveer: het laatste getal bevat al vaak een afrondingsfout, maar het is altijd een correcte benadering, dus het is, ook al is het fout, alsnog een significant cijfer.

Even op een rijtje, voor de programmeurs die tid nog niet wisten, welke floating point getallen je wanneer kan gebruiken:

16 bit: mantisse van 10 bits (half precission)-> +- 4 significante decimale cijfers
32 bit: mantisse van 24 bits (single precission, in java een float) -> +- 8 significante decimale cijfers
64 bit: mantisse van 52 bits (double precission, in de meeste talen een double) -> +- 16 significante decimale cijfers

Alle cijfers na die significante decimalen zijn pure 'ruis' (nutteloze informatie door de conversie van base 2 naar base 10). Wanneer je er wel nood aan hebt, moet je een andere datastructuur gebruiken, in Java bvb een BigDecimal. Let er wel op dat je daarmee serieus wat performance zal inleveren (weliswaar niet merkbaar bij een klein aantal berekeningen) omdat de programmalogica dan voor elke bewerking moet worden doorlopen, ipv gewoon de fixed functions van je CPU te gebruiken voor een optelling of deling.

Ook is het voordelig om, wanneer het niet nodig is, geen doubles maar floats te gebruiken: je bespaart geheugenruimte, en je processor kan ook meer gebruik maken van parallellisme: als je 10 vermenigvuldigingen moet doen met 20 onafhankelijke getallen, dan verdubbel je je snelheid wanneer je floats ipv doubles gebruikt: je compiler kan namelijk die parallelle vermenigvuldigingen als 1 bewerking schrijven met één SSE-instructie.

Kijk dus steeds naar je toepassing en kies het datatype dat er het beste bij past

[Reactie gewijzigd door kiang op 26 juli 2024 06:50]

[kdekker]

Hoe en wat er met floating point precisie omgegaan wordt is niet alleen afhankelijk van de taal, maar ook van de onderliggende processor. Voor precisie is er al lang een standaard, IEEE 754, zie ook bijv. https://en.wikipedia.org/wiki/Floating_point en https://en.wikipedia.org/...ion_floating-point_format.

Ik heb geen ervaring met een Tesla kaart, wel met allerlei andere platformen. Voor Linux/x86 hebben zelfs compiler vlaggen invloed op de floating point precisie. Al gebruik je in de taal C/C++ een float of een double, de onderliggende precisie kan gestuurd worden door wel/niet gebruik te maken van de SSE instructieset. Oorspronkelijk was de precisie van de SSE instructieset (code die gebruik maakt van aparte registers) minder precies dan de 'standaard' implementatie. Er is volgens mij geen 1:1 relatie tussen 'bij type x in taal y is de precisie zus-of-zo'. Gelukkig is de ondersteuning van IEEE 754 inmiddels wel gemeengoed, zodat je in de meeste gevallen voor alle platformen een minimale precisie beschikbaar is. Zie ook: https://gcc.gnu.org/wiki/FloatingPointMath.

Na al die jaren programmeren hebben eindgebruikers, die onze software gebruiken, nog steeds moeite om te begrijpen dat een processor een eindige precisie heeft. D.w.z. berekeningen op 14 decimalen nauwkeurig gaat lang niet altijd. Voor boekhouders is het soms vervelend dat er bij complexe berekeningen van grote bedragen met een relatief hoge precisie achter de komma toch verschillen uit kunnen komen rollen.

Er zijn wel technische oplossingen voor het berekenen met een gewenste precisie, maar de performance prijs daarvan is vaak hoog + de portabiliteit tussen platformen lang niet altijd goed. Extended precisie kan gebruik maken van 80-bit: https://en.wikipedia.org/wiki/Extended_precision.

In de meeste gevallen is de precisie die Java heeft voor floating point types gelijk aan die van C/C++. Tenslotte is de Java VM veelal in die taal geschreven.

En ter completering, een stukje van de man page van gcc (-mfpmath mbt SSE):

Use scalar floating point instructions present in the SSE instruction set. This instruction set is supported by Pentium3 and newer chips, in
the AMD line by Athlon-4, Athlon-xp and Athlon-mp chips. The earlier version of SSE instruction set supports only single precision
arithmetics, thus the double and extended precision arithmetics is still done using 387. Later version, present only in Pentium4 and the
future AMD x86-64 chips supports double precision arithmetics too.

For the i386 compiler, you need to use -march=cpu-type, -msse or -msse2 switches to enable SSE extensions and make this option effective.
For the x86-64 compiler, these extensions are enabled by default.

The resulting code should be considerably faster in the majority of cases and avoid the numerical instability problems of 387 code, but may
break some existing code that expects temporaries to be 80bit.

This is the default choice for the x86-64 compiler.

[Reactie gewijzigd door kdekker op 26 juli 2024 06:50]

[kaas-schaaf]

Is het niet gewenster om voor klanten die hoge precisies willen een bigint representatie te gebruiken en daarbij een vorm van scaling toe te passen als de precisie niet genoeg is (e.g. * 1000 bij drie extra kommas)? De performance penalty is bij non-HP toepassingen minimaal.

Je hebt ovrigens genoeg talen en libs die een vorm van bigint met kommagetallen combineren en een een cutoff limiet aan preciesie achter de komma hebben (e.g. bigdecimal in java waarbij de 'out-of-memory' de cutoff is).

[kdekker]

Dat is een prima methode. Maar 64-bit ints waar je met veel decimalen en met hele grote getallen wilt werken kan dat nog te kort schieten.

[Anoniem: 714420]

Sloerie had het dan ook over een bigint, niet over een 64 bits datatype. Een bigint is de gebruikelijke benaming voor een arbitraire precisie datatype. Zie bijvoorbeeld de java documentatie: https://docs.oracle.com/j...java/math/BigInteger.html

[kdekker]

Ik had het over een 64-bit int, wat toevallig ook hetzelfde lijkt te zijn als een java big-int: http://docs.oracle.com/ja...dbc/getstart/mapping.html. Dit is wel een oude java versie. Bij de door jou genoemde URL staat geen grootte meer. Ik weet niet of dat betekent dat de grootte arbitrair is, of dat er onder de motorkap toch nog naar een 64-bit integer getal gemapped wordt.

[Anoniem: 714420]

Jouw link gaat specifiek over de link tussen SQL en java datatypes. Het gaat er hier dus om dat er een SQL type genaamd BIGINT is. Hiervoor is in de JDBC library een corresponderend type aangemaakt, en dit wordt vertaald naar simpelweg een 64 bits int. Dit is niet wat mensen normaal gesproken bedoelen als ze het hebben over een BigInt in de context van java.

De eerste zin in de documentatie die ik je gaf is "Immutable arbitrary-precision integers.". Dus ja, het gaat hier over arbitraire precisie. De enige limiet op hoe grote getallen je op kan slaan en mee kan rekenen is je RAM (en je geduld).

[Anoniem: 714420]

Bij bijvoorbeeld financiële toepassingen is het dan ook absoluut niet aan te raden om met floating point arithmetic te werken. In zo'n geval moet je altijd voor fixed point arithmetic kiezen. Op die manier weet je altijd exact wat je precisie is. Je kan bijvoorbeeld gewoon een (64 bits) integer gebruiken om het aantal cents op te slaan. (Of, als dit voor de toepassing relevant is, nog kleinere onderverdelingen van een cent).

In bijvoorbeeld C# heb je een specifiek datatype hiervoor: de decimal. Dit is weliswaar wel een floating point type, maar het werkt met 10 als grondgetal (wat dus mooi overeenkomt met financiële berekeningen), en het heeft een extreem hoge precisie (96 bits mantissa).

[DukeBox]

Maar om terug te komen op de originele vraag, gebruik makend van zo'n accelerator bij hoge compressie kan dus voor issues zorgen omdat voor loss-less compressie er weer meer ingewikkelde algoritmes nodig zijn om de data precisie te compenseren. De vraag is of de snelheid hoog genoeg is om het efficient te houden.

Wij gebruiken dergelijke accelerators voornamelijk voor interpolatie berekeningen in analytische statistieken, hierbij is de uitkomst hoe dan ook geen 100% gegeven dus enige afwijking (al is deze niet eens te bepalen) is geen enkel probleem.

[Reactie gewijzigd door DukeBox op 26 juli 2024 06:50]

[koelpasta]

Waar heb je het over?
Hoezo compressie en hoezo lossless compressie?
En hoezo is lossless compressie ingewikkelder dan lossy compressie? Bij lossy compressie moet je van te voren gaan bedenken wat later belangrijk is, bijvoorbeeld met een psychovisueel model, lijk me veel ingewikkelder dan lossless.
En waarom zou de snelheid te laag zijn? Welke toepassing heb je het over en wat is dan genoeg/te laag?

[Tuxwielder]

Tijd voor Unum's :

https://www.crcpress.com/...fson/p/book/9781482239867

[MSalters]

Voor de acceptatie van unum's is een 1 bit nummer genoeg

Serieus, variable representaties zijn eerder bedacht (Burroughs bijvoorbeeld), en nooit aangeslagen.

[M3!]

Video waarschijnlijk wel, 3D is al wat lastiger met 'maar' 16GB aan memory. Alles wat je graag zou wil renderen op deze kaarten vreet veel meer memory door de gigantische texture sizes die we tegenwoordig hebben om het op 4K er ook nog een beetje fatsoenlijk er uit te laten zien.

[koelpasta]

Huh? Waarom denk jij dat textures groter worden als ze op deze kaart in het geheugen staan?

[M3!]

Met 'vreet veel meer memory' bedoelde ik 'dan de beschikbare 16GB'.

[koelpasta]

Ja, maar dan is het toch gewoon een keuze?
Ik bedoel, de texturesizes die we tegenwoordig hebben passen (als dan niet gestreamed) in 4GB van een normale videokaart. Waarom zou 16GB te weinig zijn?

[M3!]

Ah, vandaar de verwarring. Ik heb het over textures bij het renderen van films. Die zijn vele male groter dan de gecomprimeerde textures van games. Een textureset van een voorgrondpersonage kan zo maar een aantal gb zijn.

[EraYaN]

Maar die hoeven dan toch ook niet allemaal (tegelijk) in het VRAM te zijn? De meeste renderers/encoders gaan nog steeds gewoon per chunk van een bepaalde lengte of aantal (source) frames.

[M3!]

Nog een keer verwarring Renderen van 3d scenes in films.

Met global illumination weet je van te voren niet welke materialen een ray tegen gaat komen in raytracing.
Omdat de kleur van een pixel dan dus afkomstig is van alle materialen waarop de ray een bounce heeft gehad, moet je een shitload aan geometry en textures in-memory hebben om de lookups een beetje snel te houden.

[Quas]

In theorie zou het kunnen. Maar de drivers voor dit apparaat zijn er niet voor gemaakt.
Deze kaarten zijn monsters in parallelle berekeningen uitzoeken. Daarom zijn ze uitermate geschikt voor super computers die vaak veel berekeningen tegelijk uitvoeren.

[Cave_Boy]

Wel mooi dat het zo ook voor meer mensen bruikbaar gaat worden.

Er staat trouwens bij dat de koeling passief is maar er wordt naar mijn weten wel een minimale airflow langs de kaart verwacht. Is dit dan nog steeds echt passief? 250W koel je namelijk niet met een kleine fan. Er moet een behoorlijke airflow aanwezig zijn (ook goed gericht).

[WienerBlut]

Ik denk dat de gebruikersgroep toch bij datacenters zal liggen... Die hebben meestal wel een koude --> warme straat inrichting.. De meeste servers hebben ook al een gelijke airflow ingebouwd.

[Cave_Boy]

Ik snap dat deze in een serverruimte bedoeld zijn maar de term passief kan dan beter veranderd worden naar bijvoorbeeld "passief met ondersteuning" / "Semi passief".

De servers zijn allemaal met fans en vaak ook in speciaal gekoelde ruimtes en daar wordt vanuit gegaan maar dan heeft de kaart dus actieve koeling nodig.

[WienerBlut]

Je hebt een puntje; als je de kaart zo zou toepassen, zonder koeling, en daarmee een rookmachine zou bouwen, dan heb je natuurlijk gelijk.

Maar in de praktijk zal niemand (nu is er altijd wel iemand ) de kaart in een niet industriële/geschikte omgeving inbouwen.

Het is een taalkundig vraagstuk in dit geval, maar weinig impact in de praktijk.

[Cave_Boy]

Mede doordat Nvidia een veelgebruikte aansluitmogelijkheid heeft gekozen wordt de brug om dit soort apparatuur thuis te gebruiken als nerd natuurlijker steeds makkelijker. Ja de prijs is hoog en of je er echt wat aan hebt...? Je kunt er als nerd natuurlijk wel veel van leren.

Het is idd een taalkundig stuk. Misschien iets voor Tweakers om hier ook over na te denken? Een sterretje erbij.

Ben benieuwd hoe grote testbedrijven dit soort kaarten gaan testen. Vaak zie je op Youtube juist open kasten en soms een enkele keer een "simpele" 12cm fan een beetje erop gericht.

Ergens vanuit gaan is gevaarlijk.

[MSalters]

Deze kaarten hebben een prijs waarbij NVidia zich niet druk maakt over thuisgebruik. "Veel van leren" is geen argument; je kunt voor een fractie van het geld een GTX970 kopen.

[EraYaN]

Als iemand zijn kaart van vele duizenden euro's opblaast omdat "hij is toch passief" dan is diegene gewoon dom en verdient het bijna dat zijn kaart nu stuk is...

[DukeBox]

Ik snap dat deze in een serverruimte bedoeld zijn maar de term passief kan dan beter veranderd worden naar bijvoorbeeld "passief met ondersteuning" / "Semi passief".

De doelgroep voor deze kaarten weet echt wel wat er in dit geval met passief bedoeld wordt.

[EdDeNtEr]

Voor mijn idee is de bedoeling dat deze kaarten voornamelijk in renderfarms en of servers gebruikt gaan worden. Bij dit soort opstellingen zie je vaak dat een batterij aan ventilatoren zorgt dat er een hoop horizontale luchtstroom is.

[Jeroen_Galjaard]

Deze kaart is naar mijn weten gemaakt voor data centers, welke over het algemeen een goede airflow beschikken. De kaart zal dus door de airflow van de kast/server gekoeld worden. Passief gekoeld dus, gezien hij zelf niet over een koeler beschikt, slechts over heat spreaders.

Mensen waren al eerder.

[Reactie gewijzigd door Jeroen_Galjaard op 26 juli 2024 06:50]

[Deadsy]

In een server waarin dat ding terecht komt maakt geluidsproductie toch niet zo veel uit.

[Cave_Boy]

Ik snap niet helemaal deze opmerking omdat het niet over het geluid gaat. Maar ook hierbij er zijn steeds meer servers die geluidsarm worden gemaakt omdat er steeds vaker kleinere servers op de kleinere kantoren worden neergezet en de grote kantoren houden daar het beheer vaak van. Deze server staat dan niet altijd in een gekoelde aparte ruimte.

[Deadsy]

Het gaat eigenlijk wel over geluid.
Deze kaart heeft geen actieve koeling, omdat de koeling van het rak deze kaart mee koelt. De fans draaien dan op een dusdanig hoge snelheid dat ze veel lawaai maken.

Daarnaast is deze kaart niet bedoeld voor het type servers dat jij bedoeld.

[Cave_Boy]

Discussie die gestart was ging over de luchtstroom en koeling.

Het woord geluid is niet eerder volgens mij gevallen tot jij erover begon.

De opmerkingen dat deze kaart daar niet voor bedoeld is snap ik maar het is wel mogelijk. Vroeger was SCSI ook niet voor thuisgebruik bedoeld. Ik heb menig vrienden die vroeger wel dat soort schijven hadden. Waren lekker snel. Je kon ook makkelijk omdat je toch een big tower had veel schijven erop koppelen (tegen 2 per kanaal van IDE).

Deze schijven vooral de eerdere series werden ook een stuk warmer. Hier werd niks over vermeld. (nooit gezien/ opgevallen of tegen me verteld). Van deze types werd ook vanuit gegaan dat de eigenaar actieve koeling had in de pc. Pas wat later kwamen er ook koellichamen / fans voor deze schijven.

Ik verwacht dat er ook voor dit model later een aangepaste koeling komt voor degene die hem toch thuis of in een niet server behuizing willen gebruiken..

[Deadsy]

Inderdaad, de oorspronkelijke discussie ging over luchtstroom en koeling.
En die 2 dingen zijn beide geen probleem, tenzij geluidsproductie een probleem is.
In racks/behuizingen waar dit ding terecht komt hebben een vrij goede airflow en de koel capaciteit van de fans in dat soort racks is sterk genoeg om alles erin te koelen. Ze maken derhalve ook vrij veel lawaai (dat is waarom ik het daarover had).

En deze kaart zul je denk ik niet zo snel bij iemand thuis vinden of ergens op een klein kantoor.
Aan de ene kant vanwege de markt waarvoor de kaart bedoeld is, er is al een discussie gaande hoe ongeschikt deze kaart voor diverse andere dingen is.
En het prijskaartje wat eraan hangt.

Mocht het ooit zover komen dat dit soort kaarten bij mensen thuis liggen dan zijn we al een paar generaties verder.

[spNk]

De enige reden waarom deze op lagere clocks werkt lijkt me om de Mezzanine connector/hardware te verkopen.

[Ramoonus]

zou ook een technische limitatie van PCI Express kunnen zijn?

[djdaan]

Dat lijkt me wel heel sterk. De originele Titan had al geen bottleneck op PCI-e 2.0 x8, dus bandbreedte genoeg op PCI-E.https://www.pugetsystems....5612&width=800&height=800

[gjmi]

Of het is het een maximale standaard wattage voor een server? Niet alleen wat voeding betreft, maar ook afvoer van warmte?

[djdaan]

De kaarten met die speciale interface zitten ook in servers en gebruiken ook 300w dus dat maakt geen verschil lijkt mij.

[MSalters]

Een serieuze server kan 4000Watt leveren, en dus ook 4000W aan hitte afvoeren. Dan moet je dus denken aan een quad-Xeon server met elk 2 van dit soort kaarten, plus nog RAM en disks. (500W aan CPU's en 2000W GPU's).

Ik vermoed dat het probleem meer is hoe je 300Watt naar een PCI-e kaart krijgt. NVIdia's eigen connector zal wel ontworpen zijn voor 300W, PCI-e is dat zeker niet.

[gjmi]

Snap ik, maar per slot zal er een maximum zijn, 2000watt afvoeren op 1 slot zal niet werken.

[koelpasta]

Moah, je weet et niet.
Mischien hebben ze wel een VRAM interface in hun aansluiting gebouwt (dus dat de ene kaart op hoge snelheid bij het geheugen van een andere kaart kan) .
Wil je dat op een knappe snelheid doen dan zal PCI-e denk ik wat tegenvallen, zelfs PCI-e 4.0 x16.

[DukeBox]

Nee, dit is omdat de meeste server fabrikanten een maximale heat dissipation hebben voor de add-in cards. Door het vermogen te lagen blijf deze nog binnen de grenzen.

[spNk]

Waarom heeft de K80 dan wel gewoon een TDP van 300watt?

[DukeBox]

En in hoeveel servers denk je dat die geplaatst kon worden ?

[spNk]

Uhm minimaal zoveel als dat er servers zijn met Mezzanine aansluiting...

[albatross]

Zou hier de OpenCL benchmarks wel eens van willen zien!

[gjmi]

Dat zou best nog eens kunnen tegenvallen, aangezien deze voor andere taken is ontworpen.

[NESFreak]

Afgezien van nvidia's brakke openCL support (correct me als ze inmiddels up to date zijn), zijn deze kaarten JUIST gemaakt om gpgpu via CUDA te draaien.

Als ik dan vervolgens die performance voor doubles zie, dan wordt ik in het geval van PDE/matrix solvers heel blij

Helaas worden deze registers op de gp104 (GTX 1080) (mogelijk met software) uitgeschakeld, wat dus op die gebieden de meerprijs van deze kaarten rechtvaardigt.

[Collen]

Zouden deze kaarten ook te gebruiken zijn als virtuele videokaarten op systemen die virtual machines draaien ? Dus als offload voor de vCPU.

Lijkt me heerlijk als KVM/QEMU of VMware dit kan gebruiken..

[NESFreak]

Lijkt me dat het met PCIE forwarding gewoon gaat werken als je cpu+mobo vt-d ondersteuning hebben. Dit betekend wel dat één vm instance dan volledig beheer van het device krijgt (hoewel dit wel eventueel te hotswappen valt). Je kunt dus niet bijv. je gpu delen tussen meerdere guests (of tussen je guest en host).

[Collen]

Nee niet forwarding of pass-thrue, dan heb je er nog niks aan..
kan je net zo goed een normale GPU gebruiken..

bedoel meer als ondersteuning voor video ed.
dus dat de Tesla het renderen en en/decode voor zijn rekening neemt voor alle virtual pc's
dat over de lijn gooit en de clients niets extra's hoeven te doen.

virtuele video reken kracht (?!)

[Manke]

Is dit goed voor bitcoin mining?

[Theo]

Met een prijs van rond de 10.000 tot 15.000 dollar per stuk voor iets meer dan 10Tflops lijkt mij dit niet rendabel om in te zetten voor mining.

Ter vergelijking, de GTX1080 levert ongeveer 6 Tflops voor 600 euro,

[Iblies]

Ik twijfel dat ze rond de 10K per stuk gaan kosten maar eerder rond de 2 tot 3k.

Ze zijn niet alleen sneller dan de 1080,
maar je krijgt ook meer ondersteuning. En dan nog zal er over de prijs kunnen worden onderhandeld als je ze in grote getallen afneemt.

Het doel van deze range is overigens oa automotive om auto's zelf te laten rijden,
als de kaarten te duur worden is de kas klein dat ze daadwerkelijk structureel worden gebruikt.

Edit;idiote spelfouten

[Reactie gewijzigd door Iblies op 26 juli 2024 06:50]

[Theo]

IN het vorige nieuwsbericht over de P100 staat dat een systeem met 8 van deze kaarten ongeveer 129.000 dollar gaat kosten. Dit kan enkel indien de P100 per stuk tussen de 10K en 15K gaan kosten.
nieuws: Nvidia kondigt Tesla P100-accelerator met Pascal-gpu en 16GB hbm2-geh...

Zelf brengt Nvidia de DGX-1 uit, naar eigen zeggen een 'supercomputer', die is voorzien van acht Tesla P100-accellerators. [....]. In de Nvidia DGX-1, die 129.000 dollar kost, zitten twee Intel Xeon E5-2698 v3-processors, 512GB ddr4-ram en vier 1,92TB-ssd's in raid 0-opstelling

[gjmi]

Enige manier om nog een beetje rendabel te bitminen is met behulp van ASIC's

http://bitcoinmining.nl/hardware

[Sir_Hendro]

Hallo undercover Titan Xtreme

[-The_Mask-]

Je denkt dat er een GTX 1080 Ti of Titan versie van deze GPU komt? Dan denk je dat verkeerd, aangezien een GeForce kaart gebaseerd op deze GPU niet sneller gaat zijn als een GTX 1080 bij een verbruik van 250W. Deze GPU is gewoon niet geschikt als GeForce GPU. De prestaties zullen dan namelijk niks beter zijn als de huidige GTX 1080, maar het verbruik zal wel hoger liggen en de kaart zou ook een stuk duurder zijn om te maken.

Of te wel, geen één persoon die zich in leest gaat zo'n kaart kopen. Hoger verbruik, niks sneller, maar wel stukken duurder als een GTX 1080. Daarom gaat nVidia ook geen GPU maken gebaseerd op deze GPU. Het zou niet verkocht worden, zou een grap worden zo'n videokaart.

[Interlace84]

Ik begrijp je standpunt maar kan je toon denk ik weerlegggen; op papier heeft deze kaart namelijk wel:

• 3840 vs 2560 CUDA Cores
• 16GB HBM2 vs 8GB GDDR5x RAM
• Met 720GB/s vs 320GB/s doorvoer
• Op een 4096 vs 256-bit bus

Mijn bescheiden mening; Niet de techniek van de kaarten, maar het feit dat nVidia ze vooral via hun drivers feature-beperkt houdt tot gebruik binnen een doelgroep, voorkomt dat we dit soort dingen serieus kunnen inzetten voor gaming. Floating-point precision is leuk, maar de driver bepaalt hoe de kaart met de berekeningen omgaat, qua architectuur zijn quadro vs geforce chips hetzelfde opgebouwd. Ja de foutcontrole richting geheugen kost wat performance maar dan nog zou een kaart als deze interessant klinken om te benchen, toch?

Ervaring uit het verleden: er was eens een tijd waarin je met een custom driver op je tnt2 of geforce-kaart alle $1000 features van de quadro's kon activeren

[Reactie gewijzigd door Interlace84 op 26 juli 2024 06:50]

[SkiFan]

Kon het even niet laten; nu nog een AGP versie

[Cave_Boy]

Kon het even niet laten; nu nog een AGP versie

Waarom niet PCI of ISA? VESA?

Voor VESA is de kaart groot genoeg

[SkiFan]

Gut, dat hebben we inderdaad ook nog gehad ja, VLB...

[GeeBee]

Als we toch bezig zijn: en dan voor de fancy graphics nog even doorlussen naar een 3dfx Voodoo...

[OverSoft]

Lekker verwarrende naam. Komt er ook een P100D?

[mcDavid]

Dacht ik ook gelijk. Doen ze dit nou bewust in de hoop geld te kunnen verdienen aan dit trademark of zo?

[Gamebuster]

Ha, en dan met 2 GPUs ook echt

[onok]

Dit. Wat een eikels

[Tadream]

Kan je er een beetje een spelletje mee spelen?
Zou dit wat zijn voor b.v. 2D/3D CAD toepassingen onder VMware/hyper-v en RDP/Citrix omgevingen of ga je dan toch meer naar de Quadro/FirePro kaarten?
Even zo snel uit m'n hoofd passen er geen pci-e kaarten in onze HP blade servers, maar wel die Mezzanine kaarten.