Ontwikkelaar draait Doom-level op enkel een fpga

De van oorsprong Franse ontwikkelaar Sylvain Lefebvre heeft een, zoals hij het zelf noemt, 'Doom-chip' ontwikkeld. Een fpga draait het E1M1: Hangar-level van het spel uit 1993 volledig hardwarematig en zonder dat een cpu of gpu is vereist.

Lefebvre toont de weergave van E1M1: Hangar op zijn scherm met de toelichting dat het Doom-level draait op een CycloneV van Intel-dochteronderneming Altera in combinatie met sdram. "Het algoritme is gebrand in de bedrading, lut's en flip-flops op een fpga", meldt de ontwikkelaar, die onder andere de ontwikkelaar van de IceSL-modeler/slicer voor 3d-printing is. De hardwarematige implementatie van het level maakt geen gebruik van een cpu, opcodes of instruction counter.

Het level wordt op een resolutie van 320x200 pixels op 60Hz weergegeven. De ontwikkelaar meldt nog tal van problemen met glitches en latency te moeten verhelpen, en ook wil hij dat het spel op 70Hz gaat draaien. Doom draaide oorspronkelijk op 35fps en is ontworpen voor een verversingssnelheid van 70Hz. Het goed krijgen van de textures voor aan de ene kant de vloer en het plafond, en aan de andere kant de wanden, was lastig volgens Lefebvre omdat de berekeningen hiervoor verschillen. Hij toont een debugview met verschillende kleurvlakken waarmee hij controleert of de berekeningen kloppen.

Doom fpga

De maker heeft nog de nodige speelruimte bij de verbetering en uitbreiding van het Doom-level; hij heeft nog slechts dertig procent van de capaciteit van de fpga gebruikt. Voor zijn werk maakte hij gebruik van documentatie van het Game Engine Black Book van Doom, het boek Unofficial Doom Specs en de originele broncode van het spel. Zelf gaat hij de broncode te zijner tijd ook op Github vrijgeven.

Doom fpga

Reacties (63)

Amanoo 12 mei 2020 12:17

Ik dacht eerst dat hij gewoon een CPU en een GPU geïmplementeerd had. Dat is niet spannend. Er is een standaard CPU die je in een Altera chip kan gooien. Andere merken hebben ook hun eigen CPU design.

Maar hij zegt dus expliciet dat hij dat niet deed. Er zijn geen opcodes, geen instruction counter, niets daarvan. Het is een bare metal FPGA implementatie. Dat is wel bijzonder. Het spel is echt naar een HDL geport. Waarschijnlijk in Verilog, maar dat kan ik zo gauw niet zien.

.oisyn Moderator Devschuur® @Amanoo • 12 mei 2020 14:41

En ook niet zomaar "geport", het is eigenlijk from scratch geschreven. Wel met de broncode als leidraad om specifiek gedrag te kunnen achterhalen.

Zo is de originele DOOM geen raycasting engine, maar deze implementatie juist wel. Hij gebruikt direct de BSP-tree om rays te casten voor elke kolom pixels. De datastructuur leent zich daar natuurlijk uitermate goed voor, want je komt precies op volgorde alle vloeren, plafonds en stukken muur tegen totdat je in het midden een muur raakt die verbonden is met zowel een vloer als plafond. En met een FPGA kun je alle pixelkolommen makkelijk parallel afhandelen.

robvanwijk @Amanoo • 12 mei 2020 15:09

Er is een standaard CPU die je in een Altera chip kan gooien. Andere merken hebben ook hun eigen CPU design.

Voor de mensen die hier meer over willen weten is het misschien handig om te linken naar meer informatie: https://en.wikipedia.org/wiki/Soft_microprocessor Tip: het woord "softcore" in zijn eentje in Google gooien is niet handig (want: Internet :-s ), met een tweede zoekterm erbij ("altera softcore" of "microblaze softcore" om maar iets te noemen) werkt het natuurlijk wel. Softcores zijn een mooie manier om een reguliere CPU (ook al is die dan op een speciale manier geïmplementeerd) en de speciale mogelijkheden van een FPGA met elkaar te laten samenwerken.

mg794613 12 mei 2020 12:15

"Om de berekeningen voor aan de ene kant de vloer en het plafond, en aan de andere kant de wanden correct te laten verlopen, paste hij onder andere kleurcoderingen toe."
Die kleuren zijn enkel kunstmatig aangebracht om te visualiseren of the draw order goed gaat en hoe de vlakken ingevuld worden, heeft verder NIKS met "berekeningen correct te laten lopen" te maken en puur en enkel alleen voor tijdens devprocess/presentatie. *artikel updatet*

Ok zou het leuk zijn als er uitgelicht werd hoe er GEEN code draait en geen OPCODES zijn, en dit compleet in hardware zit.

[Reactie gewijzigd door mg794613 op 22 juli 2024 21:52]

paoper @mg794613 • 12 mei 2020 13:14

Inderdaad. Hier mag misschien wel even een '.achtergrond' artikeltje aan vast. Goede kans om te leren hoe het werkt!

WienerBlut @paoper • 12 mei 2020 14:06

JA! Want FGPAs zijn "terug van weggeweest". Ze maken meer en meer deel uit van hardware in datacentres en high-performance netwerken. Intel heeft niet voor niets Altera gekocht en AWS en Azure bieden beide FPGA instances aan.

Exirion 12 mei 2020 12:43

Het idee van een FPGA is nu juist dat je er van alles mee kunt bouwen, veelal voor prototyping. Processoren en zelfs GPU cores worden op FPGA’s gevalideerd en soms in prototypevorm verkocht in development kits. Wat hij nou precies gebouwd heeft is niet direct duidelijk. Je kunt bij wijze van spreken een PC platform met x86-compatible CPU en VGA-compatible video interface op een FPGA draaien.

.oisyn Moderator Devschuur® @Exirion • 12 mei 2020 13:02

Wat hij nou precies gebouwd heeft is niet direct duidelijk

Op zich is dat wel duidelijk, DOOM is direct in hardware geïmplementeerd. Dus geen CPU die instructies uitleest en een bijbehorende gecompileerde versie van de DOOM source code, maar schakelingen in hardware die direct doen wat ze moeten doen.

theseboetz @.oisyn • 12 mei 2020 14:27

Alhoewel dat voor jou misschien heel duidelijk is, is het voor de meer casual Tweaker, zoals ikzelf heel moeilijk om voor te stellen hoe zoiets in zijn werk gaat, en wat de bijbehorende implicaties zijn. Ik denk op dit moment dat ik het begrijp, maar zeker weten doe ik dat niet.

Menesis @.oisyn • 12 mei 2020 17:14

Dus een bug betekent: nieuwe chip bakken?

likewise @Menesis • 12 mei 2020 20:07

Nee, want de FP in FPGA staat voor field-programmable.

mae-t.net @Exirion • 12 mei 2020 21:47

Philips had er vroeger ook wel een handje van. In TV's even snel wat nieuwe functies bouwen kon ook met een FPGA. Ambilight geloof ik, en 100Hz.

gunghir 12 mei 2020 12:05

Ik lees DOOM in een titel en ik klik er op. Sommige dingen zijn eenvoudig in het leven.
Is dit dezelfde FPGA als in de MiSTer (DE-10 nano) Heb echt onwijs veel plezier van dat ding gehad,

FrankHe

@gunghir • 12 mei 2020 12:15

Het programmeren van FPGA's lijkt mij bijzonder 'hardcore'. Ik heb mij laten vertellen dat er per model FPGA slechts een handje vol mensen zijn die dit echt onder de knie hebben. Knap staaltje werk.

kdeboois

@FrankHe • 12 mei 2020 12:41

Dankzij High Level Synthese kan het tegenwoordig ook in C/C++ hoor. Met de Xilinx Vitis Libraries zelfs in Python.

[Reactie gewijzigd door kdeboois op 22 juli 2024 21:52]

gold_dust @kdeboois • 12 mei 2020 13:22

Ik heb dit een keer geprobeerd met de Lite versie van Quartus Prime, het werkte alleen met een hele oude versie van gcc of met Visual Studio 2015. Uiteindelijk kreeg ik een compilatie error onder Linux omdat er bepaalde headers misten.

Ergens wel te verwachten gezien de tools die fpga fabrikanten leveren altijd problemen hebben. Ik zat vorige week nog naar Vitis/Vitis AI te kijken maar de fpga die ik wil aanschaffen bij AVnet: de Ultra 96 V2 is niet meer leverbaar en wordt op dit moment ook niet ondersteund door Vitis.

kdeboois

@gold_dust • 12 mei 2020 13:42

De Ultra96V2 hebben we gewoon op voorraad/ in bruikleen te krijgen bij ons (EBV) en Vitis is ondersteund. Vitis AI is een ander verhaal en daar gebruiken we voorlopig nog DNNDK V3.1

gold_dust @kdeboois • 12 mei 2020 14:15

Die EBV website ben ik laatst een keer geweest en die verwijzen je weer door naar AVNet om de Ultra 96 V2 te kopen. Alleen is die daar niet meer leverbaar ...

DNNDK heb ik ook naar gekeken maar dat schijnt vervangen te zijn door Vitis AI. De benchmarks voor inferentie van grotere fpga's zoals de ZCU 102 zijn wel veelbelovend maar anderzijds is het int8 wat niet echt een eerlijke vergelijking met fp16 van Volta is. Onze voorkeur gaat uit naar fp16, de nauwkeurigheid is voor onze toepassing veel hoger.

Intel/Altera met OpenVINO zijn niet echt overtuigend qua prestaties. Ik blijf fpga's interessant vinden maar denk dat ze het heel moeilijk zullen krijgen, helemaal als je prijs/prestatie en ontwikkeltijd er ook nog in betrekt.

kdeboois

@gold_dust • 12 mei 2020 15:35

Farnell, Avnet of bij ons kan je terecht. Door het Chinese Nieuwjaar en COVID is de voorraad wat beperkt, maar niet meer verkrijgbaar is niet juist. Midden juni en eind juli zijn er weer grote aantallen beschikbaar.

Mocht je er een willen lenen dan kan dat.

fp16 zal nog wel even duren op een 'betaalbare' FPGA vrees ik.

Mocht je een keer een discussie willen hebben met onze ML specialist dan weet je me te vinden.

jopiek @gold_dust • 12 mei 2020 15:16

Drama dat Quartus en VHDL hebben studenten het ook vaak zwaar mee. Misschien goede incentive nu er een 'nuttige' toepassing gevonden is (die iig past bij de belevingswereld van veel studenten

, hoewel Doom natuurlijk ook wel oldskool is)

[Reactie gewijzigd door jopiek op 22 juli 2024 21:52]

DigitaldumpKing @jopiek • 12 mei 2020 16:42

Ik heb nog een opdracht liggen voor school om een softcore te schrijven op een DE10-lite. Ik hou zo veel van quartus en VHDL dat ik er nog niet aan begonnen ben

jopiek @DigitaldumpKing • 12 mei 2020 21:58

Haha, misschien kun je Ewout vragen of dit mag als vervangende opdracht

DigitaldumpKing @jopiek • 13 mei 2020 00:10

Hahaha. Denk niet dat ik zo goed ben in VHDL

Aardedraadje

@jopiek • 12 mei 2020 23:18

Oud ESE'er hier. Toch is Quartus een veel betere omgeving dan het alternatief dat er eerder op de opleiding gebruikt werd, dat draak van een pakket van Xilinx. De softcore-opdracht was één van de toffere opdrachten die ik gedaan heb.

Dichter op je hardware kom je bijna niet, en ik houd zelf wel van dat low-level gestoei.

[Reactie gewijzigd door Aardedraadje op 22 juli 2024 21:52]

jopiek @Aardedraadje • 13 mei 2020 10:16

Thanks voor je input, jammer dat Xilink dus ook niet veel beter is, het low-level deel is zeker ook leuk op eens mee te stoeien, maar jammer dat die tools allemaal zo gebruiksonvriendelijk zijn. Red Pitaya had ik gezien op Embedded World, idee is leuk, maar hoorde ook al weer dat daar ook allerlei haken en ogen aan zaten. Heb dus echt wel hoop dat zodra we met iets modernere talen die hardware kunnen programmeren (uiteraard met extensies voor signals etc) eea ook qua tools een stukje beter zal worden. Dedicated machine learning of zo lijkt mij ook voor bedrijven een hele interessante, zou als het allemaal net even wat makkelijker wordt mooi onderdeel van de vision minor kunnen worden.

robvanwijk @FrankHe • 12 mei 2020 14:54

Het programmeren van FPGA's lijkt mij bijzonder 'hardcore'.

Je bedoelt "hardware"

Ik heb mij laten vertellen dat er per model FPGA slechts een handje vol mensen zijn die dit echt onder de knie hebben.

Als je bedoelt dat ze alle details "achter de schermen" kennen (enigszins vergelijkbaar met een CPU programmeren in assembler), dan wil ik dat nog best geloven... maar goed, dat geldt voor CPUs ook. Maar ik zou het ook "onder de knie hebben" noemen als mensen met gebruik van de (tegenwoordig behoorlijk high level) tools hun werk doen. Met die definitie zijn er talloze mensen die FPGAs uitstekend beheersen.

Een reden waarom FPGAs programmeren zo lastig is, is omdat ze fundamenteel anders werken dan andere vormen van programmeren. Bij "gewone" talen vertel je stap voor stap wat er moet gebeuren; de ene regel wordt uitgevoerd na de andere. Dat is waarom je de waardes van twee variabelen niet om kunt wisselen met "a := b ; b := a"; na de eerste regel bevatten ze allebei dezelfde waarde. In VHDL vertel je echter "draadje voor draadje" wat er moet gebeuren, waarna dat allemaal tegelijk gebeurt; in VHDL zal "a <= b ; b <= a" dus wel degelijk (bij de volgende kloktik) die signalen omwisselen.
Dit lijkt een klein verschil, maar het vereist een compleet andere manier van denken. Er zullen flink wat mensen rondlopen die op zich prima programmeurs zijn, maar er niet in geslaagd zijn die omschakeling te maken; zij zullen je vertellen hoe verschrikkelijk moeilijk VHDL is. Iemand die eerst VHDL leert en pas daarna C, Pascal, Python of wat dan ook zal diezelfde omschakeling moeten maken, maar dan de andere kant op. Dikke kans dat "gewoon" programmeren, zeker in het begin, compleet tegen hun intuïtie in gaat en dus heel moeilijk lijkt. Maar die mensen hoor je nooit klagen, want voor zover ik weet is er bijna niemand die als eerste programmeertaal VHDL (of, wat dat betreft, Verilog) geleerd heeft.

Kliko @robvanwijk • 12 mei 2020 15:26

Goede beschrijving!

In mijn opleiding beide soort programmeertalen (C en VHDL)als vakken tegelijk gehad. Man wat heb ik zitten stoeien! Het omschakelen zoals jij beschijft is echt verdraait lastig!

[Reactie gewijzigd door Kliko op 22 juli 2024 21:52]

goarilla @robvanwijk • 13 mei 2020 02:13

Is de overgang naar functioneel programmeren niet vergelijkbaar ?

robvanwijk @goarilla • 13 mei 2020 10:58

Ja, ik heb zelfs ooit nog een vak gehad waarbij de prof uitlegde waarom het specificeren van hardware meer lijkt op functioneel programmeren dan op imperatief ("gewoon") programmeren. Bij functionele talen gebeurt precies hetzelfde als bij VHDL en co: veel mensen vinden de leercurve erg stijl en lastig.

MeMoRy @robvanwijk • 13 mei 2020 14:15

in VHDL zal "a <= b ; b <= a" dus wel degelijk (bij de volgende kloktik) die signalen omwisselen.

Alleen als je het in een sequential statement gooit (if rising_edge(clk) zeg maar). Dan wordt er door de synthesis software namelijk een register per assignment gegenereerd.
Doe je het concurrent, dan krijg je problemen. Dan triggert elke assignment namelijk een update van de andere assignment, dus krijg je een oneindige loop.

Ik heb overigens C(++) en VHDL ongeveer tegelijk geleerd (aan de TUDelft). Dus dus welke de 'eerste taal' is draait om het even.

[Reactie gewijzigd door MeMoRy op 22 juli 2024 21:52]

Cilph @FrankHe • 12 mei 2020 13:18

Oh valt best mee hoor. Tis een andere manier van denken, en de apparatuur is wat irritant om aan te komen. Maar op onze technische universiteiten is er genoeg aanraking met dit en Verilog of VHDL.

g4wx3 @FrankHe • 12 mei 2020 15:17

Het was leuk om wat mee te hobby's. Eerst maak je een simpele adder met wat logische poorten, vervolgens breid je uit naar meer bits, maak je een multiplier. Dan stuur je een VGA signaal, speel je wat met kleuren en vormen, rechthoek, circle.
Dan grote stap, importeer je een softcpu. Dan wordt het leuk, je leert de bus, adreslijnen en datalijnen, je begint met Pong, en als je kan maak je breakout.

Aardedraadje

@FrankHe • 12 mei 2020 23:22

Het valt wel mee. VHDL is een apart taaltje. Je moet onthouden dat je niet programmeert, maar hardware "beschrijft". Als je dat gedachtegoed onder de knie hebt, kun je al snel veel leuke dingen doen. Voor programmeurs is het even omschakelen, maar toch tegelijkertijd lijkt het er sterk op.

Jeroenzer @gunghir • 12 mei 2020 12:12

Lol, dat heb ik dus ook, maakt niet uit of ik het interessant vind of niet, als ik een bericht zie met DOOM, zeker op tweakers, klik ik er op.

Ik heb datzelfde ook met Duke Nukem

12_0_13 12 mei 2020 12:13

Wow dit is wel veel vetter dan de tetris-on-a-chip (ook fpga) die ik 15 jaar geleden maakte samen met een collega

PageFault @12_0_13 • 12 mei 2020 12:42

Maar deze heeft geen gebaren besturing

12_0_13 @PageFault • 12 mei 2020 13:15

Dit is inside info

Maar dat klopt! (alhoewel de gebarenbesturen door een extern systeem werd gedaan)

PageFault @12_0_13 • 12 mei 2020 13:20

Een kleinigheid hou je altijd

Ik denk dat die FPGA overigens verloren is gegaan (ben ik bang).

jaapstobbe 12 mei 2020 13:10

Ik zie een screenshot van Doom en ik hoor meteen het muziekje afspelen in mn hoofd. Toch moet dat 25 jaar geleden geweest zijn...

4play @jaapstobbe • 12 mei 2020 13:19

Ik ben bij doom overgegaan van PC speaker naar SoundBlaster 2.0 (een mono ISA kaart).

Mond openvallend materiaal was dat het verschil tussen een PC speaker en een geluidskaart was ongekend. Zowel Doom als Dune 2 bleven me bij als meest indrukwekkende spellen die ik toen speelde.

Doom door de knallen, de muziek en natuurlijk de kettingzaag, Dune 2 vanwege het gesproken dialoog bij de openings intro en de "yes"en "affirmative" van de mannetjes.

ravw

Games

@4play • 12 mei 2020 13:29

Lol ... soundblaster installeren en dan er achter komen dat de helft van de games te weinig ruimte was om nog te kunnen draaien met geluid .......... mompelt iets met hoog en laag laden van drivers autoexe.bat / configsys

.... ik word oud

Marctraider @ravw • 12 mei 2020 13:45

HIMEM.SYS !

ravw

Games

@Marctraider • 12 mei 2020 14:00

zo iets ja :-) ach het is voor mij zo lang geleden dat ik dat heb gedaan ... iets met een 286 voor het laatst ....

mvrhrln @Marctraider • 12 mei 2020 15:31

384KB extra !

gimbal @ravw • 12 mei 2020 14:01

Dune 2 met volledige ondersteuning voor digitaal geluid kunnen draaien (stemmen + explosies)... minimaal 600kb conventioneel geheugen had je vrij nodig voordat het ging werken als ik me goed kan herinneren. Het was een redelijke uitdaging om boven de 600kb vrij te hebben op sommige systemen.

ravw

Games

@gimbal • 12 mei 2020 14:07

Ja ik weer dat ik vaak dan maar zonder geluid speelde , of de muis moest er maar een geloven ... had een Philips 286 staan 16mhz 1 mb ram ? ( dit weet ik niet zeker ) 20 MB HD

toen was dat een bakbeest van een pc Maar leuk om hier weer eens dingen terug te zien , nu ik die kleurtjes hier zo ziet doet me denken aan Vectors $_/-\o_$ als waren ze toen allemaal Gold door de monitor :-)

[Reactie gewijzigd door ravw op 22 juli 2024 21:52]

4play @ravw • 12 mei 2020 14:48

Ik heb toen ook Qemm geïnstalleerd en nooit meer teruggekeken..

Alles in één blok en geen gezeik meer met EMS en XMS geheugen, bootdisks en config.sys files.

Ik mis die tijd toch wel dat het gewoon niet altijd werkte en je echt nog het gevoel had controle over je systeem te hebben. Maar daar gebruik ik tegenwoordig Linux en een raspberry Pi voor

Skyrunner @ravw • 12 mei 2020 16:37

Haha, ja inderdaad. Die 640Kb limiet managen, QEMM, EMM386 schiet zomaar even te binnen...

"640Kb ought to be enough for everyone".

_Pussycat_ @Skyrunner • 13 mei 2020 08:34

Heeft 'ie niet gezegd......

MazeWing

12 mei 2020 12:15

Het is mooi om te zien hoe ze doom op zoveel soorten apparaten draaiende weten te krijgen.
Dit laat tevens de enorme sprongen qua rekenkracht die we sinds ‘93 gemaakt hebben...

Ajunne @MazeWing • 12 mei 2020 12:43

Alleen is het dat hier niet. Ze hebben niet Doom op een hardware aan de praat gekregen, ze hebben letterlijk hardware gemaakt die E1M1 van Doom draait. Hier is geen code die uiteindelijk instructies op de CPU uitvoert om Doom te draaien, dit is hardware die Doom draait en ook niks anders, omdat hij niks anders kan.

Vergelijk dit met de ROM die in de Apollo Guidance Computer zat, die was letterlijk hard met ijzerdraad en magneten in de hardware gewoven (letterlijk: door dames met naald en draad). Alleen is dit nog een stapje erger, de AGC had wel degelijk een CPU en voerde de instructies uit die in de ROM zaten. Dit heeft zelfs dat niet.

KRASH @Ajunne • 12 mei 2020 13:11

En als je benieuwd bent hoe dat er dan uitziet kan ik de youtube serie van CuriousMarc aanraden. Die hebben een AGC gerestaureerd en weer werkend gekregen. https://www.youtube.com/w...pb59FWrLZfdlisi_x7-Ut_-w7

Dograver 12 mei 2020 12:23

Is het raar om nu te eisen dat elke leverancier van moederborden deze DOOM-Chip standaard op het moederbord plaatst?

Press F6 to play Doom

Dit moet gewoon standaard functionaliteit van elke PC/Laptop zijn.

.oisyn Moderator Devschuur® @Dograver • 12 mei 2020 13:06

Ik ga even serieus reageren op iets wat duidelijk een grapje was

Is het raar om nu te eisen dat elke leverancier van moederborden deze DOOM-Chip standaard op het moederbord plaatst?

Ja. Waarom zouden ze een dergelijke chip toevoegen als er al een CPU aanwezig is die de game prima kan draaien? Er bestaan al UEFI ports voor Doom zodat je niet eens eerst een OS hoeft te booten

[Reactie gewijzigd door .oisyn op 22 juli 2024 21:52]

Luukfit @Dograver • 12 mei 2020 12:34

eens

Verwijderd @Dograver • 12 mei 2020 13:03

Yes, om af en toe lekker hersenloos te kunnen knallen!

The Zep Man @Dograver • 12 mei 2020 13:24

Is het raar om nu te eisen dat elke leverancier van moederborden deze DOOM-Chip standaard op het moederbord plaatst?

Don't let your dreams be dreams! Dat zou relatief makkelijk in een UEFI image geïntegreerd kunnen worden. Wel heb je waarschijnlijk een grotere flash chip nodig.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 21:52]

0vestel0 12 mei 2020 12:19

Het hele concept van "Will it Run Doom" is toch wel geniaal. Met nu de FPGA als nieuwe toevoeging. Zo gaaf om de creativiteit van de mens in werking te zien

Jorgen 12 mei 2020 12:32

'But can it run Crysis?'

Dat en 'but can it run Doom?' zijn toch wel de meest essentiële IT-vragen gebleken.

Op dit item kan niet meer gereageerd worden.

Ontwikkelaar draait Doom-level op enkel een fpga

Lees meer

Programmeren op transistorniveau

Reacties (63)

Sorteer op:

Weergave: