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.

Reacties (35)

[Kaw]

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.

[Umbrah]

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

[Kaw]

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.

[Reactie gewijzigd door Kaw op 23 juli 2024 14:57]

[.oisyn]

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.

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.

maar je kunt zelf ook het raytracen toepassen.

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.

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

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.

[Reactie gewijzigd door .oisyn op 23 juli 2024 14:57]

[robvanwijk]

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.

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.

[.oisyn]

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.

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.

[Reactie gewijzigd door .oisyn op 23 juli 2024 14:57]

[BadRespawn]

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.

Lijkt me evident; het bevindt zich nog in de laboratorium fase, getuige deze demo van Intel labs.

Laat er eerst maar eens een standaard opgelegd worden.

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.

* Tearing in het filmpje. Not done voor demo's

Hangt er vanaf wat voor demo het is; product demo, game demo, of demo van een render techniek.
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.

[Wolfos]

(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.

Yep, dat doe ik ook.

[Anoniem: 64607]

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.

[David Mulder]

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))

[Anoniem: 314471]

Meerdere werelddelen spelen op verschillende tijdstippen, dus relatief minder hardware nodig

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..

Het zal vast wel beter zijn voor het milieu en ik denk voor de makers van spellen.. garantie dat er licentiegelden worden gevangen.

[robvanwijk]

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!

[Anoniem: 231832]

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.

[Themperror]

1,4 milliwatt per gigabit per seconde

en dat in normaal game verbruik?

[Left]

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.

[Niet Henk]

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

[.oisyn]

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

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 1985

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 23 juli 2024 14:57]

[CMG]

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.

[YopY]

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.

[robvanwijk]

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.

Dit is dus exact hoe het niet zit...

quote: http://en.wikipedia.org/w...access_memory#Memory_wall

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.

(emphasis added)

[CH4OS]

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.

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.

[Ayporos]

"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

[Lennard1]

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.

[Mythx]

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.

[Reactie gewijzigd door Mythx op 23 juli 2024 14:57]

[.oisyn]

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

[Reactie gewijzigd door .oisyn op 23 juli 2024 14:57]

[Eli3l]

Je bedoelt natuurlijk gigabit

[wavegroveler]

@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

[.oisyn]

Per staat voor verhouding, dus gedeeld door, dus [mJ/s]/[Gb/s]=[mJ/Gb]

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.

mW / GB / s => (mJ / s) / GB / s => mJ / GB / s²
mW / (GB / s) => (mJ / s) / (GB / s) => mJ / GB.

[Reactie gewijzigd door .oisyn op 23 juli 2024 14:57]

[kamerplant]

Mooie rapportage, thanks dudes!

[Maximilian]

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

[Reactie gewijzigd door Maximilian op 23 juli 2024 14:57]

[Wolfos]

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.

[Reactie gewijzigd door Wolfos op 23 juli 2024 14:57]

[Ashy]

De gezichtsherkenning ziet er erg netjes uit

[BoozeWooz]

Dat is geen wolfenstein3d... wolf3d is de eerste 3d game uit de wolf serie (1992). dit is wolfenstein 2009 , ook wel gewoon 'wolfenstein' genoemd.

[Aham brahmasmi]

Valt mee. Ze leggen gewoon niet echt wat ze gedaan hebben, maar vertellen alleen wat het concept is (wat betreft die memorycubes).