Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 55 reacties

Intel heeft processors in de Xeon E3-1200v3-lijn aangekondigd die van een Iris Pro-gpu voorzien is. Tot nu toe werden Xeons met aanzienlijk minder krachtige videochips uitgerust; de toevoeging zorgt onder andere voor 3-renderingfunctionaliteit op afstand.

De krachtigste gpu die in een Xeon E3-1200v3 aangetroffen kon worden was tot nu toe de HD Graphics P4600, die ook wel GT2 genoemd wordt en in enkele Haswell-processors zit. Intel meldt echter de komst van een Xeon E3-1200v3-serie met codenaam Crystal Well, die van Intel Iris Pro- ofwel GT3-gpu's voorzien gaan worden. De videochips hebben met 40 execution units dubbel zoveel eu's als de GT2 en presteren daarmee aanzienlijk beter.

Volgens Intel helpt de extra grafische rekenkracht bij beeldtaken op afstand, zoals het draaien van cad-toepassingen, videobewerking en andere complexe rekentaken. Daarbij moet Intel GVT helpen. Dit is een set technieken die in samenwerking met Citrix is ontworpen en het inzetten van grafische rekenkracht op afstand moet bewerkstelligen, zoals Workstation Remoting, vdi, daas en het streamen van games en andere media. GVT zal voorlopig uit een -d-, -s- en -g-variant bestaan.

Intel gaat met de Xeon E3-1200v3 de concurrentie aan met AMD en Nvidia. De trend is dat bedrijven niet voor iedere gebruiker een individueel workstations aanschaft, maar een klein aantal krachtige serversystemen inzet die meerdere gebruikers op afstand kunnen bedienen.

Intel GVT

Moderatie-faq Wijzig weergave

Reacties (55)

Dit snap ik dus even niet. Als je een klus hebt die gebruik kan maken van GPUs dan zet je er een losse kaart in. Die zijn rustig 20x sneller met hun 2k-3k execution units, waarmee het voordeel hiervan meteen nihil is. Het vreet ondertussen wel stroom, en je betaalt er (flink) voor.

Het grote nut van deze dingen komt pas in beeld als je een kleine server ook wat simpele beeldtaken laat doen, beeldmanipulatie die toevallig niet op de gewone CPU-cores kan, en waar je liever geen grafische kaart voor implementeert (omdat die niet genoeg geheugen heeft wellicht, of omdat die niet remote werken).

Bij virtualisatie van je workstations (wat ik heel onverstandig vind, single point of failure voor heel veel personen) moet je overigens heel veel data rondpompen, zeg 1920x1200 (toch wel het absolute minimum voor grafisch werk) * 30 frames per seconde = 1 Gbit-lijn compleet vol. Compressie, natuurlijk, maar dan moet je weer meer (grafische) power in je client hebben.
(wat ik heel onverstandig vind, single point of failure voor heel veel personen)
Vergelijking:
50 man iedere een eigen werkstation. 1 werkstation valt uit, 1 persoon kan niet werken. Kans hierop is groot en neemt toe naarmate je meer mensen aan het werk hebt.
Alternatief:
50 man, allemaal een VM in de cloud. 1 server valt uit, niemand merkt er iets van want er wordt dynamisch naar andere hardware over geschakeld. De kosten hiervan nemen af naarmate je meer mensen aan het werk hebt.

Hoezo SPoF? en hoezo onverstandig?
1 op 50 mensen kan dan niet werken? oh nee? iedereen mag naar huis?
En wat als de ultra magische dynamische overschakeling niet (direct?) werkt? Dan zit je met een werkloos bedrijf?

Je verkoopt het toch echt niet man :|
1 op 50 mensen kan dan niet werken? oh nee? iedereen mag naar huis?
En wat als de ultra magische dynamische overschakeling niet (direct?) werkt? Dan zit je met een werkloos bedrijf?
Die "ultra magische overschakeling" waar jij het over hebt heet bij een professionele omgeving een cluster. Daar is niets magisch aan, dat is gewoon business as usual. 5 of 10 servers die met z'n allen een pool vormen waar alles op draait.

Welcome in the real world. Waar private clouds de standaard zijn en failover zo ingericht is dat een gebruiker helemaal niets merkt van uitvallende systemen.
De exchange, sharepoint en CRM waar die 50 werknemers op werken draait al op een VM in de cloud. Waarom de werkplekken er niet bij?


Overigens is de dynamische overschakeling niet ultra magisch, maar gewoon netjes gedocumenteerd bij VMWare.
ooit al eens met een cad pakket gewerkt?
van zodra het wat ingewikkeld wordt (zo goed als altijd dus) kan een workstation het nog niet eens vlot aan, laat staan als er 50 man op een paar servers aan de slag moeten
als je bang bent dat er 1 van je 50 workstations gaat uitvallen: zet gewoon een reserve workstation klaar
Wij werken virtueel in een private Citrix cloud met Nvidia Grid K2 kaarten met verschillende CAD pakketten zoals SolidWorks, SolidEdge en Inventor.
Door vGPU kan je 8 mensen op 1 server hosten. De performance is nagenoeg gelijk aan lokaal, maar 10x flexibeler.

Dus het kan wel ;)

alleen zijn deze Intel dingen echt niet geschikt voor CAD

[Reactie gewijzigd door Motion2 op 8 mei 2014 18:34]

CAD-pakketten lopen vrijwel geheel op de CPU, pas als je gaat renderen gaat er misschien eens een GPU echt over nadenken. Deze Intel dingen zijn dus weldegelijk geschikt voor CAD, maar absoluut ontoereikend wanneer je gaat renderen of gaat spelen met videobewerking.
Ik weet niet met welke CAD jij werkt maar SolidWorks etc gooien toch flinke belasting op de video kaart. Tevens zijn die Intel gpu's vaak niet ondersteund, enkel Nvidia Quadro/Grid of AMD Firepro.
Autodesk, bijna volledige suite (alleen van 3DMax begrijp ik de ballen). De Quadro wordt echt pas opgestookt als ik ga renderen, zolang het bij lijntjes trekken of modelleren blijft, mag de i7 het mooi alleen opknappen. En ja, hardware acceleratie staat aan.
kan je ook dynamisch power allocaten? zeg 2 gebruikers die flink aan het lighten zijn meer power geven zeg 2 gpu's pp terwijl de rest een klein stapje achteruit doet?

bijv:
2 personen 2 gpu's pp (totaal dus 4 gpu's)
de andere 8 krijgen een halve. (totaal dus ook vier)

dan zie ik er wel wat in, als dat niet kan dan zie ik het punt niet echt.
Het kan helaas nog niet zonder rebooten van die specifieke virtuele machine maar het is mogelijk.
Het dynamische is de volgende stap.

Je kan de Grid wel zelf indelen kwa gpu types
dank! zodra dat kan ben ik zeker geinteresseerd, tot dat punt zie ik het punt nog niet echt. hopelijk komt het snel :)
Ja, met zo'n beetje het hele EDA portfolio van Cadence.

Een werkstation is leuk, maar 90% van de jobs draai je toch in het datacenter. Er is al lang een beweging bezig om ook de EDA in het DC te draaien en naar de desktop te streamen. Waarom denk je dat HP 3D mezzanines verkoopt voor hun blades? Niet voor serverbeheerders die graat Farcry willen spelen...
En ook bij de concurenten zoals Xen (waar ze het gewoon HighAvailability genoemd word) en bij Hyper-V (microsoft) is dit een (betaalde) optie.
Die overschakeling heb je alleen bij hardware failure. Als het OS crasht ofzo, dan gebeurt er gewoon niets.
Hangt er vanaf, ik werk in de industrie en hier draaien een aantal virtuele server draaien voor de centrale automatisering. Bij een fail van een co server loopt alles gewoon naadloos door hoor. Dit is algemeen geaccepteerd, en werkt prima...
50 man op 1 VM, switch valt dood, of de server ploft, en met een VM zul je dus een stuk overcapaciteit nodig hebben. Als iemand z'n bak laat crashen is dat nu geen punt. Bij een VM is het ietsje lastiger troubleshooten, en heb je al snel systeembeheer nodig.
50 man op 1 VM, switch valt dood, of de server ploft, en met een VM zul je dus een stuk overcapaciteit nodig hebben. Als iemand z'n bak laat crashen is dat nu geen punt. Bij een VM is het ietsje lastiger troubleshooten, en heb je al snel systeembeheer nodig.
Switch valt dood of server ploft merk je niet eens. Dit soort dingen draaien namelijk helemaal niet meer op een server of een switch. Troubleshooten stelt overigens ook niets voor; je ziet in je control console wat er mis is, vervangt dat onderdeel en that's it, het geheel draait gewoon rustig weer door.
Dat is; als je een local cloud gebruikt. Gebruik je een private cloud dan merk je er helemaal niets van omdat de gespecialiseerde leverancier dit al voor je geregeld heeft.
Komaan zeg. Ik snap niet dat je tegenwoordig nog kunt geloven in het concept van losse PC's. Dat is compleet achterhaald en kost teveel manuren om te onderhouden en te servicen.

Virtualisatie is zoveel meer dan enkel wat PC's vervangen en in het datacenter plaatsen. De voordelen zijn legio en werken gebeurt al lang niet meer enkel en alleen op een vaste werkplek voor een PC. Tegenwoordig moet alles van overal toegankelijk zijn en dan kom je er niet meer met je vast PC.

Alles draait bij ons in het datacenter en ik kan het alleen maar aanraden. Het is goedkoper, minder fall-out (echt wel), alles is gebackupped en alles is op een veilige manier toegankelijk vanop afstand vanop verschillende devices.
Als je meer dan een man of 30 hebt wel, wellicht, maar ik ben (samen met best wat collegas) gehecht aan m'n eigen bakkie die ik in de soep kan draaien zonder er anderen mee te storen.
Volledig redundante ketens kost klauwen vol geld, een simpel burgerbakkie heb je voor een prikkie (500 euro ofzo?), een server die 10 van die dingen (die actief belast worden) kan vervangen kost je ruim meer dan het 10voudige. Ons serverpark drukt ietsje zwaarder op de kosten dan onze normale bakjes, en heeft minder power.
Juist niet.

We zitten hier ook nog steeds met gegevens op lokale pc's, maar nu we stapsgewijs meer naar een (lokale) cloud gaan gebruik je dat ook steeds meer.
Een stukje schijf dat bereikbaar is met pc, laptop en tablet.

Hier hebben we altijd servers gehad, en 10 jaar geleden was dat een kostenpost, vandaag de dag nog steeds met het grote voordeel dat ze meer kunnen.
Als jij een VM in de soep draait, heeft niemand anders er last van. Je krijgt echt niet de onderliggende virtualisatie-laag kapot. En meestal is een koude start van jouw VM voldoende om je weer aan het werk te helpen, anders trekken ze hem opnieuw vanaf de juiste template. Veel, veel sneller dan het opnieuw inspoelen van een fysieke bak.

Gehecht aan je eigen bakkie is zo van het vorige millenium.
VM is leuk als je je op een vaste locatie bevind of in elk geval over een gegarandeerde, snelle internetverbinding kunt beschikken. Zit je (net als ik momenteel) op een locatie waar dit niet het geval is, dan ben je blij met je eigen snelle bakkie. Rekenintensieve taken die je realtime moet doen zijn gewoon niet leuk als je midden in een weiland staat en VM moet laten lopen over 3G
Je snapt het inderdaad niet.
Mensen die een Xeon E3 1200v3 gebruiken, doen (hopelijk) meer dan wat kantoortaken. Als er dan 50 werknemers met een dergelijk profiel op een VM aan de slag moeten spreken we eerder over meerdere E5's of E7's.
Dan moet je wel weten dat een E5 een pak duurder is dan een E3 en uiteindelijk minder snel is (wanneer bv 2 medewerkers voluit aan de slag gaan op 1 E5).
Die fall-out wordt volgens mij zwaar overdreven, de data staat uiteraard wel op een server.
Voor kantoortaken kan ik het volgen, voor het echte werk niet echt. Tenzij je weer begint over een renderen.
Een normale bedrijfs-situatie is tegenwoordig toch echt wel :
- redundante switches;
- cluster van meerdere servers, bij voorkeur verdeeld over 2 (of meer) fysieke locaties).
Allemaal goed, maar ik denk niet dat op zo'n schaal men nog moeite gaat doen met deze E3 CPU's.

Dat is voor workstations of KMO's, en daar mag je al blij zijn dat ze een backup willen bekostigen, laat staan volledige redundantie.
Haha, bij een goed datacenter, zit een Host niet op 1 switch man.. Alles is redundant
Dat is dan ook het punt wat Intel hier maakt:
Je pompt niet gewoon frames rond, maar je stuurt grafische commando's door via de Hypervisor. Dat zou je als een vorm van compressie kunnen zien.
Neehoor, de frames worden nog steeds gemaakt echter kan de computation ge-offload worden naar de GPU, de 1Gbit lijn waar FreezeXJ het over heeft blijft net zo vol
Sorry, maar als je een VM in de cloud hebt dan heeft FreezeXJ gewoon gelijk, die frames moeten nog steeds overgepompt worden naar je thin client. Dat de VM in de cloud nu gebruik kan maken van de hypervisor's GPU zonder tussen lagen is een optimalisatie, en heeft niks te maken met compressie.

Het artikel zegt dit dan ook duidelijk:
Dit is een set technieken die in samenwerking met Citrix is ontworpen en het inzetten van grafische rekenkracht op afstand moet bewerkstelligen
Met nadruk op "op afstand"

Als je werkelijk het GPU gedeelte wil offloaden naar je client om commando's over te sturen ipv bitmaps, dan zijn er technieken zoals RemoteFX van microsoft.

Misschien kan je beter uitleggen waar FreezeXJ het verkeerd hebben ipv doorverwijzen middels een linkje

[Reactie gewijzigd door DLGandalf op 9 mei 2014 11:39]

Sorry, maar als je een VM in de cloud hebt dan heeft FreezeXJ gewoon gelijk, die frames moeten nog steeds overgepompt worden naar je thin client.
Hoezo? Ook met bv Xorg of Windows Remote Desktop worden er geen hele frames overgepompt. Er worden grafische commando's doorgestuurd, die door de thin client worden uitgevoerd.
Dit idee is enigszins vergelijkbaar: de VM heeft een virtuele GPU-driver. De VM denkt dus dat ie tegen een GPU praat, maar de commando's worden via het net naar de client verstuurd. Het verschil is dat dit dus op een iets lager niveau gedaan wordt (en daarmee waarschijnlijk minder OS-afhankelijk is).
Dit is een set technieken die in samenwerking met Citrix is ontworpen en het inzetten van grafische rekenkracht op afstand moet bewerkstelligen
Met nadruk op "op afstand"
Ja, alleen snap je het zelf niet, volgens mij. De thin client is namelijk het ding dat 'op afstand' werkt. De VM is namelijk 'lokaal' vanuit het OS/de apps gezien.
Als je werkelijk het GPU gedeelte wil offloaden naar je client om commando's over te sturen ipv bitmaps, dan zijn er technieken zoals RemoteFX van microsoft.
Ja, maar dit is dus op een lager abstractieniveau.
Misschien kan je beter uitleggen waar FreezeXJ het verkeerd hebben ipv doorverwijzen middels een linkje
Hoezo? Dat linkje legt het veel duidelijker uit dan dat ik hier in een post op de frontpage kan doen.
Daarnaast, moet er uberhaupt uitgelegd worden dat 'frames overpompen' wel de meest simplistische manier van remote graphics is, en dat er duidelijk slimmere manieren bestaan om dat te doen? Dat zou toch sowieso al pijnlijk duidelijk moeten zijn?
Als Intel alleen maar frames overpompt, was het geen nieuws.

Zoals het linkje zegt: "From user experience view point, there is practically no difference between having a local desktop machine with a dedicated GPU, versus, having a Virtual Desktop with Intel GVT-d direct assigned Intel processor-graphics somewhere in the enterprise server or in the cloud."
Die user experience haal je natuurlijk nooit als je alleen maar frames overpompt.

[Reactie gewijzigd door Scalibq op 9 mei 2014 12:49]

Ok, volledige frames overzenden is wat overdreven in geval van klassieke desktop apps, hier bestaan inderdaad allang betere technieken voor, daar gaat het bij mij in principe niet om, echter de nieuwe technieken beschreven in het artikel en waar jij naar linkt gaan hier ook geen enkele verbetering in brengen.

De nieuwe intel technieken zorgen eigenlijk voor een gemultiplexte toegang naar de GPU vanaf een VM. Wil je de resultaten vanaf de VM naar een client op afstand krijgen moet je nog steeds via een netwerk.

Nu zorgen de nieuwe technieken er dus voor dat de communicatie mbt GPUsop de VM zelf efficienter is, toch zullen deze gegenereerde OpenGL frames over het netwerk naar de client gestuurd worden. In het geval van gegenereerde OpenGL frames zijn er geen slimmigheden die je kan gebruiken om van VM/Hypervisor naar client te gaan, tenzij je dus een fatclient gebruikt in de trend van RemoteFX wat in RDP8 gebruikt kan worden.

Het artikel/technieken zeggen niks over het gedeelte van VM naar client, de bottleneck waar FreezeXJ het over heeft blijft.

/edit
Ik zie nu de crux waar we van mening verschillen:
Dit idee is enigszins vergelijkbaar: de VM heeft een virtuele GPU-driver. De VM denkt dus dat ie tegen een GPU praat, maar de commando's worden via het net naar de client verstuurd. Het verschil is dat dit dus op een iets lager niveau gedaan wordt (en daarmee waarschijnlijk minder OS-afhankelijk is).

Naar mijn idee gebeurt dit dus niet, de "commando's" gaan niet via het net, die worden naar de hypervisor gestuurd, ofwel de fysieke server en niet naar de client.

[Reactie gewijzigd door DLGandalf op 9 mei 2014 14:29]

Wil je de resultaten vanaf de VM naar een client op afstand krijgen moet je nog steeds via een netwerk.
Dat lijkt me nogal een open deur.
Het punt is vooral: wat voor protocol gebruik je over dat netwerk. En dat is dus wat Intel hier uitlegt.
/edit
Ik zie nu de crux waar we van mening verschillen:
Dit idee is enigszins vergelijkbaar: de VM heeft een virtuele GPU-driver. De VM denkt dus dat ie tegen een GPU praat, maar de commando's worden via het net naar de client verstuurd. Het verschil is dat dit dus op een iets lager niveau gedaan wordt (en daarmee waarschijnlijk minder OS-afhankelijk is).

Naar mijn idee gebeurt dit dus niet, de "commando's" gaan niet via het net, die worden naar de hypervisor gestuurd, ofwel de fysieke server en niet naar de client.
Dan had je ook het andere linkje uit het artikel even moeten lezen: https://software.intel.co...ics-virtualization-update
Hier wordt bij de GVT-s variant al naar Remote FX gerefereerd, die je zelf ook al noemde.

[Reactie gewijzigd door Scalibq op 9 mei 2014 14:36]

En we gaan weer door: bij nader inzien werkt RemoteFX niet door commando's door te sturen naar een fatclient . GVT-s is gewoon de abstractielaag tussen VM en host waarbij een generieke VM-driver gebruikt kan worden.

Verder
[...]


Dat lijkt me nogal een open deur.
Het punt is vooral: wat voor protocol gebruik je over dat netwerk. En dat is dus wat Intel hier uitlegt.


[...]
Intel legt dus niks uit over een protocol over het netwerk. Het gaat hier om communicatie in een hypervisor. RemoteFX bestond al, en dat is het protocol over netwerk. Dat een mogelijke implementatie,zoals het RemoteFX protocol toevallig leunt op functionaliteit van GVT-s voor bepaalde onderdelen, zegt nog niet dat GVT-s zelf een netwerk protocol is
Intel legt dus niks uit over een protocol over het netwerk.
Niet veel inderdaad, maar wel wat, zoals ik al eerder quotte:
From user experience view point, there is practically no difference between having a local desktop machine with a dedicated GPU, versus, having a Virtual Desktop with Intel GVT-d direct assigned Intel processor-graphics somewhere in the enterprise server or in the cloud.
Hier maken ze dus wel degelijk een opmerking over remote desktops.

Sowieso, ze hebben het samen met Citrix ontwikkeld. Zoals je zou moeten weten, is Citrix een specialist op het gebied van remote desktops: http://www.citrix.com/
RemoteFX bestond al, en dat is het protocol over netwerk.
Dat is ook niet helemaal waar. RemoteFX is een API forwarding techniek, de daadwerkelijke implementatie wordt overgelaten aan de driver-fabrikant. Dat staat dus ook al in het artikel:
Specific sharing algorithms remain proprietary to the virtual graphics driver.
In het geval van Intel wordt dat dus met GVT-s geimplementeerd.
Ik zeg niet dat GVT-s een netwerkprotocol is, maar wel dat het onderdeel is van de RemoteFX-implementatie van Intel.
Als ik even vergelijk zie ik dat een Iris top-end ding in 3D11 zo'n 2k punten scoort. Een high-end GPU haalt 14k punten of meer, en dat is in 3Dmark, mogelijk gelimiteerd door de CPU. Mid-end kaarten halen het niet, maar high end? Zeker wel.
Compressie wacht ik nog af, maar so far heb ik er geen hoge pet van op, zeker niet als m'n data van de andere kant van de planeet moet komen. Zelfs commandline kan dan al best traag zijn...
Das ook niet zo gek, een cpu + high end gpu combinatie verbruikt dan ook al snel 250+W, terwijl een Iris Pro Haswell een 47W chip is.

[Reactie gewijzigd door Dreamvoid op 8 mei 2014 17:54]

Ik had ff over dat mobile gedeelte gelezen, maar dan nog vind ik het een aardig indrukwekkende score (http://www.futuremark.com/hardware/gpu/):
  • Nvidia 780 14020
  • Nvidia 780m 7530
  • AMD HD7970 10680
  • AMD HD7870 8090
De Iris Pro 5200 zou dan op 2191 zitten. Gek genoeg staat er ook een Intel HD Graphics 4600 op de Futuremark site die een score van 4430 heeft terwijl hij volgens de wiki minder zou moeten zijn. Wie het weet mag het zeggen.

[Reactie gewijzigd door gast128 op 8 mei 2014 20:07]

Ze testen daar laptop gpus, die zijn beduidend trager dan hun desktop varianten.
Je ziet ook bij die test dat bij hoge settings en resolutie de framerate gigantisch inkakt omdat er gewoon te weinig bandbreedte beschikbaar is.
Je throughput/grafische kracht op de client-verhaal gaat niet op, Compressie kan er voor zorgen dat er prima op een 5 tot 10 mbit lijntje gewerkt kan worden en compressie wordt doorgaans op de CPU uitgevoerd. deze zijn daar doorgaans krachtig genoeg voor.

Ik verwacht dat deze technologie bedoeld is voor de mid-range grafische gebruikers waarvan desktop upgrades (veel) duurder zijn dan een betere server CPU met dezelfde uitwerking voor de eindgebruiker.
Het gaat ook om de behuizing ;)
Bij virtualisatie van workstations gebruik dus (geografische gespreide) clusters met meerdere hosts, zodat als er een van de hosts uitvalt de rest vrolijk doordraait, en de VM's keurig worden overgenomen. Feitelijk robuuster dan een eigen PC op het bureau, want als die het begeeft kost het bij de meeste bedrijven uren, zo niet dagen voordat er een nieuwe staat.

En de drivers die de grafische informatie doorgeven werken niet alleen met efficiente compressie, maar ook met het principe dat ze alleen de wijzigingen in de grafische informatie over de lijn sturen, dus dat scheelt heel wat bandbreedte.
Volgens mij is dit echt wel een bewijs dat de iris GPU zn productiekost gewoonweg niet rendabel is voor intel, of dat ze het niet kunnen op grote schaal. Waarom lukt/mag het dan niet in hun reguliere processors?
Omdat daar maar hele kleine gpu's in zitten, dat houdt de chips kleiner en dus voor Intel goedkoper - ze maken hun chips niet groter dan noodzakelijk, tenzij er een markt is die er genoeg meerprijs voor betaalt. Blijkbaar ziet Intel nu een commercieel lucratief genoeg gat tussen de groep mensen die genoeg hebben aan de GT2 Haswells en de groep die per se een dikke discrete kaart nodig heeft.

[Reactie gewijzigd door Dreamvoid op 8 mei 2014 17:23]

Designwerk op een Integrated GPU, ja je kan crysis ook met een pentium 4 spelen maar verwacht er minder dan niets van.
Had liever een paar extra cpu cores voor dat geld/op die ruimte gehad :/
Die zijn er ook, dat is de Xeon E5-xxxx v2 serie met 6-15 cores, zonder GPU.

[Reactie gewijzigd door Dreamvoid op 8 mei 2014 17:01]

Dat lijkt me nog steeds het allermooiste! Gewoon 2 of 3 thin clients thuis en één server met 2-3 videokaarten die het zware werk doet. Voornamelijk gamen moet dan mogelijk zijn, zonder direct aangesloten te zijn op een dikke PC met dito grafische kaart.

De server kun je op die manier veel efficiënter gebruiken en heb je maar één systeem waar je af en toe een videokaart vervangt of bij prikt. Leuker is het dan als je met de warmte die het systeem genereert ook nog wat kunt doen; zoals het bijverwarmen van CV of gewoon warme lucht de woonkamer in blazen. Uiteraard zomers naar buiten blazen, maar dat moet te doen zijn!
Nu nog meer laptops met Iris Pro! Ik zit hier echt om te springen, en een Macbook kopen gaat me véél te ver.
In het geval van ESXi zie ik niet waarom je een snelle igp nodig zou hebben?

ik dacht dat je bij esxi/xen toch echt 2 gpu's nodig hebt. eentje voor de hypervisor en een voor sgx/passthrough?
Van HP had je ook al 2d cad systemen met een xeon met gpu er in, dit zal daar ook prima voor zijn.
Vroeger, de eerste servers waren mainframes waar iedereen met een terminal op werkte. Toen werden de PCs goedkoper en krachtiger, dus kreeg iedere werknemer zijn eigen PC. En vandaag gaan ze terug naar een mainframe, al dan niet virtueel (Hyper-V, VM-Ware, ...) met kleine bakjes die terug als terminal gaan dienen.

Geweldig toch hoe het verleden terugkomt in de PC-wereld :P
Nu kan Apache zeker nog mooiere graphics leveren. jk :D Inplaats van die grafische chips in te bouwen geef mij dan maar wat extra CPU kracht. Dit zijn toch server processors? Als ik CAD wil doen zet ik er wel een i7 in.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True