Intels laboratoria: Wolfenstein en memorycubes
Hybrid Cube-geheugen
Op het IDF demonstreerde Intel ook de Hybrid Memory Cube of HMC, een geheugenmodule die het bedrijf samen met Micron ontwikkeld heeft. Volgens de makers is dit het 'snelste en efficiëntste dram ter wereld'. De truc ervan is om meerdere lagen geheugenchips direct op elkaar te plaatsen, met de i/o-circuits daaronder. Het prototype zou veel sneller werken en bovendien veel efficiënter zijn dan de modernste ddr3-modules van dit moment.
Vorig jaar demonstreerde Intel al een prototype dat 1,4 milliwatt per gigabit per seconde verbruikte. Dit jaar gaf het bedrijf ook details over de 'geheugenkubus' zelf vrij. We vroegen de aanwezige onderzoekers onder andere hoe snel de module nu werkelijk is, en wanneer we de Hybrid Memory Cubes in onze pc's mogen verwachten.
Inhoudsopgave
Reacties (35)
De gezichtsherkenning ziet er erg netjes uit 
1,4 milliwatt per gigabit per seconde
en dat in normaal game verbruik?
en dat in normaal game verbruik?
Zoals gezegd wordt in the filmpje, is dit geheugen niet bedoeld voor pc's of laptops maar voor supercomputers e.d. Dus je zal hier in de nabije toekomst geen game op spelen. 
Waarom dat zo is weet ik niet, misschien wordt het geheugen buitengewoon duur?
Het werd ook niet helemaal duidelijk wanneer dit soort geheugen dan in supercomputers beschikbaar zou komen, daar ben ik ook wel benieuwd naar.
Waarom dat zo is weet ik niet, misschien wordt het geheugen buitengewoon duur?
Het werd ook niet helemaal duidelijk wanneer dit soort geheugen dan in supercomputers beschikbaar zou komen, daar ben ik ook wel benieuwd naar.
Het is in ieder geval zo dat we op dit moment gewoon niet echt sneller geheugen nodig hebben dan het huidige DDR3 geheugen in PC's en Laptops. Natuurlijk zal het systeem misschien iets sneller reageren, maar het limiet zal al snel bij de drive en processor liggen.
Daarbij denk ik ook dat het misschien efficiënt is per bandbreedte, maar dat de bandbreedte zo excessief veel is dat het alsnog veel meer energie gaat gebruiken (hoewel ik niet echt grote koelers op dat prototype zag, maar het zichtbare prototype stond dan ook niet aangesloten).
En ja, ik denk daarbovenop ook nog dat het buitengewoon duur gaat worden. Al met al dus niet echt iets voor de doorsnee consument
Daarbij denk ik ook dat het misschien efficiënt is per bandbreedte, maar dat de bandbreedte zo excessief veel is dat het alsnog veel meer energie gaat gebruiken (hoewel ik niet echt grote koelers op dat prototype zag, maar het zichtbare prototype stond dan ook niet aangesloten).
En ja, ik denk daarbovenop ook nog dat het buitengewoon duur gaat worden. Al met al dus niet echt iets voor de doorsnee consument
Je kan natuurlijk je drive bottleneck oplossen door data gewoon in dit geheugen te plaatsen.. dan heeft sneller wel degelijk zin. Het is alleen zaak dat transport van en naar dit geheugen ook mee gaat; dat is de huidige bottleneck.
Dat is gewoon pertinent onwaar. De bandwidth is dan wellicht wel voldoende, maar de latency is absoluut niet om over naar huis te schrijven. Als een stuk geheugen niet in de cache staat, dan gaan er al gauw 200 CPU cycles overheen voordat het geheugen op z'n plek is, en als er verder geen berekeningen te doen zijn (bijv. omdat die data nou eenmaal nodig is) dan staat de CPU dus doodleuk uit z'n neus te eten. Met andere woorden, als je een app hebt die niets anders dan random access naar uncached geheugen doet, dan gedraagt je 2GHz CPU al gauw alsof het eigenlijk een 10MHz CPU is. Welkom in 1985Het is in ieder geval zo dat we op dit moment gewoon niet echt sneller geheugen nodig hebben dan het huidige DDR3 geheugen in PC's en Laptops
Maar helaas, dat probleem gaat HMC ook niet oplossen, die levert vooral bandwidth. Uit een reactie op een comment in de HMC blog:
The short of it is that no, memory latency is not reduced. Other technology from Micron such as RL-DRAM (reduced latency DRAM) trades off die-area for a reduction in latency. In short, they chop the bitlines up into shorter pieces, reducing RC delay, and getting your data out faster. The HMC is all about low-power and bandwidth. In many video applications, getting larger bandwidth is actually more important than reduced latency, especially as density increases. I imagine that with a logic chip built in a logic-specific process would contribute very little in terms of latency to the system. Remember that transistors in a DRAM are incredibly slow due to the high-temperature steps in capacitor formation. A high-speed logic device will be capable of running at incredible frequencies - implying very minimal gate delays (and thus, an insignificant increase in latency relative to the RC delay of a large bitline).
[Reactie gewijzigd door .oisyn op vrijdag 30 september 2011 11:32]
Mwa, zoals CMG ook aangeeft, als ze geheugen sneller, goedkoper en van grotere capaciteit kunnen voorzien dan kunnen applicaties meer in het geheugen cachen en wordt er minder van de opslagmedia gebruik gemaakt.
Ook zouden ze meer geheugen (ram-achtig) in opslagmedia kunnen bouwen, zodat dat gebruikt wordt voor het cachen van regelmatig opgevraagde gegevens.
Ontwikkeling moet (mijns insziens) altijd op alle fronten doorgaan.
Ook zouden ze meer geheugen (ram-achtig) in opslagmedia kunnen bouwen, zodat dat gebruikt wordt voor het cachen van regelmatig opgevraagde gegevens.
Ontwikkeling moet (mijns insziens) altijd op alle fronten doorgaan.
Dit is dus exact hoe het niet zit...Het is in ieder geval zo dat we op dit moment gewoon niet echt sneller geheugen nodig hebben dan het huidige DDR3 geheugen in PC's en Laptops. Natuurlijk zal het systeem misschien iets sneller reageren, maar het limiet zal al snel bij de drive en processor liggen.
(emphasis added)From 1986 to 2000, CPU speed improved at an annual rate of 55% while memory speed only improved at 10%. Given these trends, it was expected that memory latency would become an overwhelming bottleneck in computer performance.
Ik kan er iig de eerste al bedenken, waar het praktisch altijd (in het begin) door komt: geld. De kosten van nieuwe technologie is in het begin altijd duur, naar mate het meer en meer gebruikt wordt, wordt de kennis over de technologie beter, het proces om het te maken verbeterd en wordt daardoor ook goedkoper, zuiniger en sneller. Uiteindelijk zal dit denk ik heus wel in de desktop verschijnen, maar zal nog even duren eer het populair en betaalbaar genoeg is.Waarom dat zo is weet ik niet, misschien wordt het geheugen buitengewoon duur?
Het werd ook niet helemaal duidelijk wanneer dit soort geheugen dan in supercomputers beschikbaar zou komen, daar ben ik ook wel benieuwd naar.
"1,4 milliwatt per gigabit per seconde"
Gezien 'watt' al Joules per seconde betekent lijkt me die tweede 'per seconde' een beetje overbodig... wel heel interessant though
Gezien 'watt' al Joules per seconde betekent lijkt me die tweede 'per seconde' een beetje overbodig... wel heel interessant though
Lees het als 1,4 miliwatt per Gb/s
Dus stel het geheugen gaat 10 Gb/s, dan verbruikt het geheugen dus 14 miliwatt per seconde.
Tweede 'per seconde' is dus zeker niet overbodig.
Dus stel het geheugen gaat 10 Gb/s, dan verbruikt het geheugen dus 14 miliwatt per seconde.
Tweede 'per seconde' is dus zeker niet overbodig.
Raytracing, back to the old days...
Op zichzelf vind ik het nog wel een goede ontwikkeling. Stel dat alle GPU-kracht toegankelijk zou worden binnen de CPU, dan zou je de dikke hardwareversnelling in de GPU kunnen dumpen.
Raytracing is een relatief eenvoudige techniek om hele goede 3d-plaatjes door te rekenen. Het is buitengewoon rekenintensief, maar het basisproces is verrassend eenvoudig. http://en.wikipedia.org/wiki/Ray_tracing_(graphics)
Het proces is daarnaast goed parallel uit te voeren, dus geschikt voor de huidige trent van veel cores/threads per CPU.
Als laatste voordeel vind ik dat de techniek door zijn eenvoudig makkelijk is uit te breiden in de richting die je zelf wil. Stel dat je iets intelligents wilt maken voor het omgevingslicht of met spiegels, het kan allemaal.
Bij D3D ben je toch sterk afhankelijk van de API en wat de hardware kan aan trucjes. Bij raytracing is de grens de fantasie van de programmeur. Hierdoor zou je ook wat meer diversiteit kunnen gaan zien bij 3d-games. Op dit moment is het wel een eenheidsworst van "skybox", terrain, buildings, trees, monsters/characters en jezelf met een wapen in het beeld.
Op zichzelf vind ik het nog wel een goede ontwikkeling. Stel dat alle GPU-kracht toegankelijk zou worden binnen de CPU, dan zou je de dikke hardwareversnelling in de GPU kunnen dumpen.
Raytracing is een relatief eenvoudige techniek om hele goede 3d-plaatjes door te rekenen. Het is buitengewoon rekenintensief, maar het basisproces is verrassend eenvoudig. http://en.wikipedia.org/wiki/Ray_tracing_(graphics)
Het proces is daarnaast goed parallel uit te voeren, dus geschikt voor de huidige trent van veel cores/threads per CPU.
Als laatste voordeel vind ik dat de techniek door zijn eenvoudig makkelijk is uit te breiden in de richting die je zelf wil. Stel dat je iets intelligents wilt maken voor het omgevingslicht of met spiegels, het kan allemaal.
Bij D3D ben je toch sterk afhankelijk van de API en wat de hardware kan aan trucjes. Bij raytracing is de grens de fantasie van de programmeur. Hierdoor zou je ook wat meer diversiteit kunnen gaan zien bij 3d-games. Op dit moment is het wel een eenheidsworst van "skybox", terrain, buildings, trees, monsters/characters en jezelf met een wapen in het beeld.
Eventjes naar dat cloudgaming: voor RayTracing met een hoog aantal FPS moet er dus 1 of meerdere stevige processoren aan de gang. Ik zie persoonlijk niet in waarom deze machines bij een internet-bedrijf beter zouden draaien laat staan goedkoper dan bij mij thuis. Het nadeel van dergelijke cloudgaming is bovendien dat er een behoorlijke netwerkverbinding moet zijn en dat betekend een nog grotere investering van het aanbiedende bedrijf. En die investering vertaald zich weer terug in hogere kosten voor de eind-gebruiker. Ik kan dan ook niet anders concluderen dan dat cloudgaming stuiptrekkingen zijn van een PR afdeling die ergens 'cloud' heeft gelezen en denkt met cloud-gaming het gouden ei gevonden te hebben.
Het principe RayTracing is natuurlijk wel geweldig en zeker als dit real-time mogelijk is.
Het principe RayTracing is natuurlijk wel geweldig en zeker als dit real-time mogelijk is.
Naja, wat betreft de cloudgaming, daar zijn zeker wat goeie argumenten voor te geven;
- Meerdere werelddelen spelen op verschillende tijdstippen, dus relatief minder hardware nodig
- Er kan worden gekozen voor hardware die mogelijk duurder is, maar efficienter
- Massa inkoop is sowieso goedkoper an sich
- Thuis heb je dan alleen een boxje nodig van 100-150 euro + maandelijk, laat ik zeggen 10 euro (bij onlive heb je voor dat geld een abbo met redelijk veel games erin), dat komt uit op zo'n 250 euro per jaar, dus realistisch gesproke is het momenteel niet echt veel goedkoper (meeste mensen kopen een nieuwe laptop eens in de 5 jaar ofzo van 600 euro mss + wat games misschien komt op zo'n 800 euro terwijl met onlive kom je op 600 euro + (100 tot 150 als je een settopbox er bij koopt))
Ik weet niet hoe jij dan een FPS wilt gaan spelen als je een soort videostream bedient.. Lijkt me dat dat al een hoge latency oplevert als de server bij je om de hoek staat. Laat staan als een server in de VS staat.. Je ping is al 50ms.. dan is het maar hopen dat je verbinding super stabiel is..Meerdere werelddelen spelen op verschillende tijdstippen, dus relatief minder hardware nodig
Het zal vast wel beter zijn voor het milieu en ik denk voor de makers van spellen.. garantie dat er licentiegelden worden gevangen.
Natuurlijk heb je helemaal gelijk, maar je denkt niet creatief genoeg.
Als de GPU's in de Europese vestigingen geen Europese gamers hoeven te bedienen, dan moet je ze niet voor Amerikaanse gamers inzetten, dat werkt waarschijnlijk niet nee. Maar je kunt ze dan wel inzetten voor de industrie! Commercials renderen, of de volgende Pixar-film, misschien wat gegevens van medische scanners omtoveren tot extreem gedetailleerde 3D-beelden; alles wat veel cycles kost, niet al te gevoelig is voor latency en geld oplevert.
Om een lang verhaal kort te maken: wat Amazon doet met CPUs, maar dan met GPUs!
Als de GPU's in de Europese vestigingen geen Europese gamers hoeven te bedienen, dan moet je ze niet voor Amerikaanse gamers inzetten, dat werkt waarschijnlijk niet nee. Maar je kunt ze dan wel inzetten voor de industrie! Commercials renderen, of de volgende Pixar-film, misschien wat gegevens van medische scanners omtoveren tot extreem gedetailleerde 3D-beelden; alles wat veel cycles kost, niet al te gevoelig is voor latency en geld oplevert.
Om een lang verhaal kort te maken: wat Amazon doet met CPUs, maar dan met GPUs!
Ik denk dat we in de toekomst vooral een combinatie van ray tracing en de gangbare manier van renderen gaan zien omdat niet alle oppervlakken in een scene veel mooier worden van raytracing. Auto's , ramen van gebouwen etcetera worden er natuurlijk een stuk mooier van maar niet alle details van een 3d scene hoeven zoveel detail als bij raytracing gebruikelijk is te hebben. Rekenkracht hoef je niet te verspillen aan onbelangrijke details. Wil je op een zandkorrel in kunnen zoomen in een 3d shooter? Leuk idee maar weinig nuttig.
Toch zul je, op een zeker moment, een API/interface aan willen bieden die de abstractie voor de programmeur aanbied op een niveau á la: "hey, dit is makkelijk en productief", maar toch, door middel van een driver, net zoals D3D onafhankelijk is van de hardware. En daar wil ik dus eigenlijk mee zeggen dat RayTracing, hoewel een typische "OpenCL" taak op dit moment, nog helemaal niet volwassen is.
Er ís geen OpenRT of DirectRT, je hebt wel DX11 DirectCompute, OpenCL, CUDA en Stream, maar dat zijn allemaal in feite "reken" modules. Pure, raytrace graphics zijn nog onontgonnen gebied. Laat er eerst maar eens een standaard opgelegd worden. Helaas, als het op graphics aankomt, is het de praktijk dat de Khronos group (van OpenGL) net iets té veel stokpaardjes-poetsers in de gelederen heeft, waardoor bijvoorbeeld de CAD wereld het ene prioriteit geeft, en nVidia/AMD allemaal hun eigen extensies aan het toevoegen zijn (Carmack is haast zo ver dat hij, tenminste, las ik ooit ergens, helemaal aan het begin van z'n engines een mooie: IF (nvidia) THEN (engine1), ELSEIF (amd) THEN (engine2) ELSE (engine3) neerzet (of gewoon 3 binaries aanbieden). Dat is de praktijk van OpenGL.
Microsoft is wat meer dictatoriaal, en zegt: dit is een graphics bibliotheek voor de massa. OpenGL zitten de hardware makers en de CAD makers in, daar kunnen we toch niet tegen op. En hoewel het een Windows-only dingetje is (ik geef ze daar de schuld niet van), is DirectX in feite de oorzaak geweest van een booming game-industrie op de PC, die snel innoveren kan en waardoor hardware fabrikanten duidelijk konden afbakenen (DXversiezoveel ondersteund door deze kaart!) wat hun speeltjes ondersteunen.
Wat dat betreft zie ik Raytracing nog wel opgepikt worden op net zo'n manier, en waarschijnlijk zal het een onderdeel worden ván D3D. Transparant voor de programmeur, onafhankelijk van hardware. Zeker nu ARM ook steeds meer een factor wordt náást X86 (en X86-64), en het tijdperk van de "app" op de desktop ook aanbreekt: XNA kan daar handig op inspringen door een nóg transparantere Raytracer aan te bieden. Nadeel echter van zo'n API, en dat is iets wat DirectX dus ook heeft met de hardware truukjes, is dat er altijd iets nieuws komt. Kijk bijvoorbeeld maar eens goed naar het eerste filmpje... mij valt het volgende op:
* Niet heel veel particles
* Tearing in het filmpje. Not done voor demo's
Nou zou tearing iets zijn wat met VSync op te lossen is, een techniek die je eigenlijk alleen uit hoort te zetten als je e-peen wilt vergelijken met je FPS, maar is dat iets wat in een raytrace engine/API zit? (Persoonlijk vind ik: dat moet de API oplossen) Een framerate-limiter en een scan-syncer is in feite wat je moet hebben dus. Dat wil zeggen: monitor-refresh uitlezen, timing vaststellen, en zorgen dat er per signal-refresh er maximaal één beeldje uitkomt. Dus niet 5 verschillende beelden naar een monitor pompen die er maar 2 in die tijd kan weergeven en dus wat vreemd knutselwerk gaat doen. Maar particles? Tsja, dan kom je weer bij physics. En er moeten dus IETS van model-parameters worden aangemaakt. Anders kun je niet raytracen
. Allemaal van die dingetjes... tsja... daar kan op geinnoveerd worden.
Dus ik denk dat het geven van vrijheid aan de programmeur goed is, maar je maakt het jezelf moeilijk als je jezelf vastlegt. Er moet ALTIJD een API zijn, anders krijg je het resultaat dat een game in feite een stuk OS gaat schrijven, en dat WIL je niet hebben. Laat het OS, Windows bijvoorbeeld, een uniforme bibliotheek aanbieden waar games op kunnen zitten, en zorg dat die bibliotheek ALTIJD hetzelfde is, of tenminste kan. Zoals D3D misschien wel soms geoptimaliseerd is omdat NV soms net wat sneller X doet dan dat AMD dat doet (en andersom), maar in essentie is het DX11 "keurmerk" iets wat goed is, en dat WIL je juist met raytracing. Geen grens van verbeelding van de programmeur, want dan heb je een marketing man die zegt: 80% van de klanten kan dit niet weergeven met hun IGP
Er ís geen OpenRT of DirectRT, je hebt wel DX11 DirectCompute, OpenCL, CUDA en Stream, maar dat zijn allemaal in feite "reken" modules. Pure, raytrace graphics zijn nog onontgonnen gebied. Laat er eerst maar eens een standaard opgelegd worden. Helaas, als het op graphics aankomt, is het de praktijk dat de Khronos group (van OpenGL) net iets té veel stokpaardjes-poetsers in de gelederen heeft, waardoor bijvoorbeeld de CAD wereld het ene prioriteit geeft, en nVidia/AMD allemaal hun eigen extensies aan het toevoegen zijn (Carmack is haast zo ver dat hij, tenminste, las ik ooit ergens, helemaal aan het begin van z'n engines een mooie: IF (nvidia) THEN (engine1), ELSEIF (amd) THEN (engine2) ELSE (engine3) neerzet (of gewoon 3 binaries aanbieden). Dat is de praktijk van OpenGL.
Microsoft is wat meer dictatoriaal, en zegt: dit is een graphics bibliotheek voor de massa. OpenGL zitten de hardware makers en de CAD makers in, daar kunnen we toch niet tegen op. En hoewel het een Windows-only dingetje is (ik geef ze daar de schuld niet van), is DirectX in feite de oorzaak geweest van een booming game-industrie op de PC, die snel innoveren kan en waardoor hardware fabrikanten duidelijk konden afbakenen (DXversiezoveel ondersteund door deze kaart!) wat hun speeltjes ondersteunen.
Wat dat betreft zie ik Raytracing nog wel opgepikt worden op net zo'n manier, en waarschijnlijk zal het een onderdeel worden ván D3D. Transparant voor de programmeur, onafhankelijk van hardware. Zeker nu ARM ook steeds meer een factor wordt náást X86 (en X86-64), en het tijdperk van de "app" op de desktop ook aanbreekt: XNA kan daar handig op inspringen door een nóg transparantere Raytracer aan te bieden. Nadeel echter van zo'n API, en dat is iets wat DirectX dus ook heeft met de hardware truukjes, is dat er altijd iets nieuws komt. Kijk bijvoorbeeld maar eens goed naar het eerste filmpje... mij valt het volgende op:
* Niet heel veel particles
* Tearing in het filmpje. Not done voor demo's
Nou zou tearing iets zijn wat met VSync op te lossen is, een techniek die je eigenlijk alleen uit hoort te zetten als je e-peen wilt vergelijken met je FPS, maar is dat iets wat in een raytrace engine/API zit? (Persoonlijk vind ik: dat moet de API oplossen) Een framerate-limiter en een scan-syncer is in feite wat je moet hebben dus. Dat wil zeggen: monitor-refresh uitlezen, timing vaststellen, en zorgen dat er per signal-refresh er maximaal één beeldje uitkomt. Dus niet 5 verschillende beelden naar een monitor pompen die er maar 2 in die tijd kan weergeven en dus wat vreemd knutselwerk gaat doen. Maar particles? Tsja, dan kom je weer bij physics. En er moeten dus IETS van model-parameters worden aangemaakt. Anders kun je niet raytracen
. Allemaal van die dingetjes... tsja... daar kan op geinnoveerd worden.Dus ik denk dat het geven van vrijheid aan de programmeur goed is, maar je maakt het jezelf moeilijk als je jezelf vastlegt. Er moet ALTIJD een API zijn, anders krijg je het resultaat dat een game in feite een stuk OS gaat schrijven, en dat WIL je niet hebben. Laat het OS, Windows bijvoorbeeld, een uniforme bibliotheek aanbieden waar games op kunnen zitten, en zorg dat die bibliotheek ALTIJD hetzelfde is, of tenminste kan. Zoals D3D misschien wel soms geoptimaliseerd is omdat NV soms net wat sneller X doet dan dat AMD dat doet (en andersom), maar in essentie is het DX11 "keurmerk" iets wat goed is, en dat WIL je juist met raytracing. Geen grens van verbeelding van de programmeur, want dan heb je een marketing man die zegt: 80% van de klanten kan dit niet weergeven met hun IGP
Nee, dat is gewoon de praktijk van verschillende hardware. Met Direct3D heb je precies hetzelfde (al is bovenstaand stuk code wel overdreven). Problemen kennen meerdere oplossingen, en niet elke oplossing werkt even goed op elk stuk hardware.Carmack is haast zo ver dat hij, tenminste, las ik ooit ergens, helemaal aan het begin van z'n engines een mooie: IF (nvidia) THEN (engine1), ELSEIF (amd) THEN (engine2) ELSE (engine3) neerzet (of gewoon 3 binaries aanbieden). Dat is de praktijk van OpenGL.
[Reactie gewijzigd door .oisyn op vrijdag 30 september 2011 11:19]
Lijkt me evident; het bevindt zich nog in de laboratorium fase, getuige deze demo van Intel labs.En daar wil ik dus eigenlijk mee zeggen dat RayTracing, hoewel een typische "OpenCL" taak op dit moment, nog helemaal niet volwassen is....Pure, raytrace graphics zijn nog onontgonnen gebied.
Laat er eerst maar eens voldoende snelle en betaalbare hardware ontwikkeld worden om hoge kwaliteit raytracing real time te doen. Zolang raytracing zich nog in de laboratorium fase bevindt, is het wat vroeg voor een standaard. Als de techniek rijp is, komt er die standaard er wel.Laat er eerst maar eens een standaard opgelegd worden.
Hangt er vanaf wat voor demo het is; product demo, game demo, of demo van een render techniek.* Tearing in het filmpje. Not done voor demo's
VSync is triviaal om te implementeren en dus m.i. wel begrijpelijk dat het niet een punt van aandacht is bij onderzoek naar implementatie van raytracing. Het doel is hier niet om de mooist mogelijke video te produceren.
Zelden zo'n warrig verhaal gelezen die genomen wordt voor zoete koek.
Bij OpenGL en Direct3D maak je gebruik van de hardwareversnelling van je videokaart om bepaalde grafische berekingen snel en parallel uit te kunnen voeren. Dat is OP je videokaart en bepaalde algoritmes worden op OP je videokaart uitgevoerd.
Er is een API nodig om de hardware van je videokaart te kunnen benaderen om die methodes die je aan je videokaart kun overlaten aan te kunnen spreken.
Bij Raytracing heb je een methode/algoritme die op je CPU zelf plaats vind. Een softwarefabrikant kan dit wel verpakken in een API, zodat je een gereedschapskistje krijgt waardoor je sneller kunt ontwikkelen, maar je kunt zelf ook het raytracen toepassen.
Voorbeeldje: http://www.codeproject.co...e_Ray_Tracing_in_C_4.aspx
Geen OS, geen spectaculaire hardware aanroepen. Geen rocketscience. Je geeft gewoon een pixel een bepaalde kleur op het scherm.
@.oisyn
Raytracing-drivers? Om wat voor stuk hardware aan te spreken? Volgens mij zit je nog steeds in het idee dat je de GPU de raytracing laat uitvoeren. Daar gaat het artikel niet over en in de praktijk wordt raytracing vrijwel alleen toegepast met behulp van de CPU. In het geval van het artikel een Xeon E7-cluster.
Bij OpenGL en Direct3D maak je gebruik van de hardwareversnelling van je videokaart om bepaalde grafische berekingen snel en parallel uit te kunnen voeren. Dat is OP je videokaart en bepaalde algoritmes worden op OP je videokaart uitgevoerd.
Er is een API nodig om de hardware van je videokaart te kunnen benaderen om die methodes die je aan je videokaart kun overlaten aan te kunnen spreken.
Bij Raytracing heb je een methode/algoritme die op je CPU zelf plaats vind. Een softwarefabrikant kan dit wel verpakken in een API, zodat je een gereedschapskistje krijgt waardoor je sneller kunt ontwikkelen, maar je kunt zelf ook het raytracen toepassen.
Voorbeeldje: http://www.codeproject.co...e_Ray_Tracing_in_C_4.aspx
Geen OS, geen spectaculaire hardware aanroepen. Geen rocketscience. Je geeft gewoon een pixel een bepaalde kleur op het scherm.
@.oisyn
Raytracing-drivers? Om wat voor stuk hardware aan te spreken? Volgens mij zit je nog steeds in het idee dat je de GPU de raytracing laat uitvoeren. Daar gaat het artikel niet over en in de praktijk wordt raytracing vrijwel alleen toegepast met behulp van de CPU. In het geval van het artikel een Xeon E7-cluster.
[Reactie gewijzigd door Kaw op vrijdag 30 september 2011 12:02]
Er is technisch gezien helemaal geen API nodig. Je kunt ook gewoon zelf commando's in een commandbuffer schrijven, wat op de consoles niet eens zo heel vreemd is.Er is een API nodig om de hardware van je videokaart te kunnen benaderen om die methodes die je aan je videokaart kun overlaten aan te kunnen spreken.
Natuurlijk kun je dat zelf. Maar het daadwerkelijk ook zo efficient mogelijk doen is niet voor heel veel mensen weggelegd. Beter praat je gewoon tegen een API die het zo goed mogelijk implementeert op de aanwezige hardware. En omdat hardware nogal verschilt, zou je dus ook raytracing-drivers kunnen hebben. En op het moment dat je drivers hebt, is een API wel zo handig.maar je kunt zelf ook het raytracen toepassen.
Ik heb het over welk stuk hardware dan ook. Uiteindelijk gaan we een kant op waarin dingen steeds meer geïntegreerd worden in de CPU. Zo is er Intel's Larrabee, en AMD's Fusion. Dingen als OpenCL zijn leuk, maar hoewel je het daarmee kunt implementeren blijft een extra laag van abstractie die niet nodig is als je een library wilt maken met 1 bepaald doel.Raytracing-drivers? Om wat voor stuk hardware aan te spreken? Volgens mij zit je nog steeds in het idee dat je de GPU de raytracing laat uitvoeren
[Reactie gewijzigd door .oisyn op vrijdag 30 september 2011 15:10]
Als je de video kijkt, op 0:50 zegt de engineer dat ze draaien op "eight Knight Ferry cards". Dat is een ander research-project van Intel: Many Integrated Cores (MIC). Hoewel die kaarten er inderdaad uit zien als grafische kaarten bevatten ze in feite x86 (of x86-achtige??) cores. Of de CPU een Xeon is maakt niet uit, de Knights Ferry kaarten doen het eigenlijke werk.Raytracing-drivers? Om wat voor stuk hardware aan te spreken? Volgens mij zit je nog steeds in het idee dat je de GPU de raytracing laat uitvoeren. Daar gaat het artikel niet over en in de praktijk wordt raytracing vrijwel alleen toegepast met behulp van de CPU. In het geval van het artikel een Xeon E7-cluster.
Yep, dat doe ik ook.(Carmack is haast zo ver dat hij, tenminste, las ik ooit ergens, helemaal aan het begin van z'n engines een mooie: IF (nvidia) THEN (engine1), ELSEIF (amd) THEN (engine2) ELSE (engine3) neerzet (of gewoon 3 binaries aanbieden). Dat is de praktijk van OpenGL.
Mooie rapportage, thanks dudes!
Dat is geen wolfenstein3d... wolf3d is de eerste 3d game uit de wolf serie (1992). dit is wolfenstein 2009 
, ook wel gewoon 'wolfenstein' genoemd.
, ook wel gewoon 'wolfenstein' genoemd.Uhm, ik kan me vergissen, maar is 1,4 milliwatt per gigabit per seconde wel correct?
Volgens mij is watt al een eenheid die energie per seconde aangeeft (Joule/seconde).
Op deze manier zou het dus energieverbruik per seconde kwadraat zijn.
EDIT: .oisyn, dankjewel voor de reactie. Stom dat ik het zo niet bekeek.
Volgens mij is watt al een eenheid die energie per seconde aangeeft (Joule/seconde).
Op deze manier zou het dus energieverbruik per seconde kwadraat zijn.
EDIT: .oisyn, dankjewel voor de reactie. Stom dat ik het zo niet bekeek.
[Reactie gewijzigd door Mythx op vrijdag 30 september 2011 13:51]
Ja, dat is correct, alleen missen er haakjes waardoor het op verschillende manieren te interpreteren is, en jij pakt net de verkeerde . De bedoelde grootheid is namelijk de hoeveelheid energie per seconde (in milliWatt), per bandbreedte (in GB/s). Dus in dit geval mW / (GB/s). Wil je een hogere bandbreedte, dan kost dat meer energie.
Je kan natuurlijk ook zeggen: mW∙s/GB, oftewel milliwattseconde per gigabyte, ookwel millijoule per gigabyte, maar dat is niet bepaald intuitief
. De bedoelde grootheid is namelijk de hoeveelheid energie per seconde (in milliWatt), per bandbreedte (in GB/s). Dus in dit geval mW / (GB/s). Wil je een hogere bandbreedte, dan kost dat meer energie.Je kan natuurlijk ook zeggen: mW∙s/GB, oftewel milliwattseconde per gigabyte, ookwel millijoule per gigabyte, maar dat is niet bepaald intuitief
[Reactie gewijzigd door .oisyn op vrijdag 30 september 2011 12:02]
Je bedoelt natuurlijk gigabit
Moet je eens voorstellen wat dit geheugen gaat doen met SSD later als dit een beetje doorkomt richting de "thuispc"
En niet te vergeten de cache in processoren
En niet te vergeten de cache in processoren
[Reactie gewijzigd door Maximilian op vrijdag 30 september 2011 11:39]
@Mythx; Het is onhandig op geschreven, maar natuurkundig wel correct -->
Per staat voor verhouding, dus gedeeld door, dus [mJ/s]/[Gb/s]=[mJ/Gb]
Seconde valt dan weg, gaat dus niet in het kwadraat
Per staat voor verhouding, dus gedeeld door, dus [mJ/s]/[Gb/s]=[mJ/Gb]
Seconde valt dan weg, gaat dus niet in het kwadraat
Duh, het punt is dat je mW per GB per s ook kunt lezen als mW/GB/s (en dat is doorgaans ook gebruikelijker), wat wat anders is dan het bedoelde mW / (GB/s). Het is maar net hoe je de haakjes zet. Dat "per" voor een deling staat snapt iedereen denk ik wel.Per staat voor verhouding, dus gedeeld door, dus [mJ/s]/[Gb/s]=[mJ/Gb]
mW / GB / s => (mJ / s) / GB / s => mJ / GB / s2
mW / (GB / s) => (mJ / s) / (GB / s) => mJ / GB.
[Reactie gewijzigd door .oisyn op vrijdag 30 september 2011 22:40]
Valt mee. Ze leggen gewoon niet echt wat ze gedaan hebben, maar vertellen alleen wat het concept is (wat betreft die memorycubes).
Ben zeer geïnteresseerd in raytracing, maar ik denk niet dat we voorlopig al teruggaan naar software rendering. Een bedrijf gaat niet eerst terug in graphics omdat we daarmee de technologie verder pushen.
Het mooie is, dat wanneer we het echt real-time voor elkaar krijgen, dan maken poly-counts niet meer zoveel uit.
Maar goed, Intel is hier al jaren mee bezig, en zelfs al lukt het ze dan duurt het nog lang voordat we er financiële winst mee kunnen behalen.
Ik zie ook geen heil in NVidia's methodes. Niet omdat ze het niet goed doen, maar omdat ze niet de enige fabrikant op de markt zijn.
Misschien Intel's raytracing engine met OpenCL erbij.
Het mooie is, dat wanneer we het echt real-time voor elkaar krijgen, dan maken poly-counts niet meer zoveel uit.
Maar goed, Intel is hier al jaren mee bezig, en zelfs al lukt het ze dan duurt het nog lang voordat we er financiële winst mee kunnen behalen.
Ik zie ook geen heil in NVidia's methodes. Niet omdat ze het niet goed doen, maar omdat ze niet de enige fabrikant op de markt zijn.
Misschien Intel's raytracing engine met OpenCL erbij.
[Reactie gewijzigd door Wolfos op zaterdag 1 oktober 2011 01:16]
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Asus Samsung Mobiele telefoons Laptops Apple Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
