John Carmack over videokaart API's

John Carmack heeft op Slashdot een interessante posting geplaatst omtrent de status van videokaart API’s nu en in de toekomst. Probleem nu is dat videokaart fabrikanten allemaal hard bezig zijn met het ontwerpen van nieuwe features en deze dan toegankelijk maken aan de programmeur via OpenGL extenties, of een nieuwe DirectX release. Dit systeem werkt, maar het zorgt er ook voor dat de moderne API’s en videokaarten een complexe zooi zijn. Carmack verwacht dat dit binnen enkele jaren zal veranderen, en een nieuw soort API het licht zal zien :

We are rapidly approaching a real golden age for graphics programming. Currently, cards and API's are a complex mess of hundreds of states and function calls, but the next two years will see the addition of the final primitive functionality needed to allow arbitrarily complex operations with graceful performance degradation.

At that point, a higher level graphics API will finally make good sense. There is debate over exactly what it is going to look like, but the model will be like C. Just like any CPU can compile any C program (with various levels of efficiency), any graphics card past this point will be able to run any shader. Some hardware vendors are a bit concerned about this, because bullet point features that you have that the other guy doesn't are a major marketing feature, but the direction is a technical inevitability. They will just have to compete on price and performance. Oh, darn.

It's a Turing machine point. Even if OpenGL 2.0 and DX10 don't adopt the same shader description language, they will be functionally equivalent, and could be automatically translated.

There is lots of other goop like texture specification and context management that will still be different between API, but the core day-to-day work of a graphics programmer will be basically above the disputes.

Reacties (33)

[Verwijderd]

Nou ja zeg, die spelontwikkelaars willen zelf de nieuwste hardware technieken gebruiken binnen een zo kort mogelijke tijd en dan gaan ze nog zeuren dat het een beetje rommelig gebeurt. Lijkt me logisch dat ze dan zelf helemaal gek worden van alweer een nieuwe extensie. Zo kun je natuurlijk nooit de meest optimale code schrijven omdat je dan bijna per videokaart de meest optimale instructies moet gaan kiezen.
Volgens mij moeten de ontwikkelaars hun koppen (nog vaker) bij elkaar steken om zelf standaarden te bedenken waar iedereen blij mee is en ze daar eisen aan de hardware bouwers kunnen stellen. Maar ja om zoiets voor elkaar te krijgen moet je wel veel (meestal eigewijze) koppen bij elkaar krijgen.
En eigenlijk ben je dan bijna aangewezen op de hardware die op dat moment leider is (of gaat worden) op de markt en daar mee werken, dan komen die andere merken vanzelf wel ook al zijn die veruit minder optimaal.

[RetepV]

De ontwikkelaars hebben geen problemen met het koppen bij elkaar steken en standaards afspreken. Het grote probleem is om de twee grote spelers in de graphics markt zo ver te krijgen dat ze die standaard adopteren.

Die twee grote spelers zijn Microsoft met DirectX en Sun met OpenGL.

Bij deze spelers heeft het geen zin om te vragen of ze 'alsjeblieft' de door gamesontwikkelaars bedachte standaard te implementeren. Die twee spelers kunnen al niet eens met elkaar overweg, laat staan met hun ontwikkelaars. Of dacht jij dat Microsoft met Direct3d was gekomen omdat de ontwikkelaars dat zo graag wilden? Pas sinds DX 7 begint het iets te worden, daarvoor hoorde ik ontwikkelaar alleen maar vloeken en schelden op DX.

OpenGL heeft altijd de voorkeur gehad omdat je daarmee veel sneller iets kunt maken dan met DX. Mischien haal je niet het onderste uit de kan, zoals dat met DX wel lukt, maar dat maakt niet zo uit, gameplay is nog altijd belangrijker dan snelheid en details. En voor gameplay moet je gamestests uitvoeren en hoe eerder je die kunt uitvoeren hoe beter, en hoe sneller je het 3D gebeuren hebt geprogrammeerd, hoe meer tijd je voor gamestesting overhoudt.

Je ziet nu al dat de meeste nieuwe games allemaal uitgesteld worden. Ik zal niet zomaar 100% DirectX de schuld geven, maar feit is dat het een hele hoge leercurve heeft en OpenGL niet.

Helaas heeft Microsoft de ontwikkelingen in OpenGL op het Windows platform stopgezet. En Microsoft's relatie met Sun kennende geven ze de broncode niet vrij aan Sun om met de ontwikkelingen door te gaan.

Eigenlijk is dit het zoveelste voorbeeld van hoe Microsoft zijn Windows platform inzet om zijn eigen 'verbeterde' technologieen in te zetten. Ik zet 'verbeterde' tussen aanhalingstekens omdat het meer lijkt op het 'bevrijden' wat Duitsland in de jaren '40 deed, dan op het maken van wat de markt vraagt.

Maar goed, sinds DirectX 7 zit er een derde mode in die, hoe toevallig, ongeveer hetzelfde abstractieniveau heeft als OpenGL. Alleen zit er nu een Microsoft stempel op.

[mr_a]

SUN != SGI

[Consequator]

hm, dit is hetzelfde idee als die programeerbare infinity gpu van de gf3 ?
want dat idee is natuurlijk leuk dat men hun eigen grafische instructies naar de chip kan 'uploaden'

[Martin Sturm]

hm, dit is hetzelfde idee als die programeerbare infinity gpu van de gf3 ?
want dat idee is natuurlijk leuk dat men hun eigen grafische instructies naar de chip kan 'uploaden'

Volgens mij is dit niet hetzelfde idee..
Wat hij probeert te zeggen is dat er een API moet komen, die op alle videokaarten werkt. Het mogelijke gevolg hiervan is dat videochipmakers niet meer kunnen concurreren op speciale features die de concurrent niet heeft, maar dat ze dus puur op prijs/prestatie moeten gaan concurreren. Hij trekt derhalve ook een vergelijking met de huidige CPU markt. Hier kan ook alle software op AMD en Intel lopen, en concurreren ze vrijwel uitsluitend op prijs/prestatie en niet of nauwelijks op features.

edit:
dit is dus als reactie op Consequator... is ff fout gegaan ofzo

[Verwijderd]

[Miereneuker Mode]
Het gaat er hier om dat het om een EENVOUDIGER API gaat. Een API werkt al voor alle videokaarten.
Het heet niet voor niets een Applications Programmer Interface. Zo algemeen mogelijk. Het is alleen nog te lastig om op dit moment die API te programmeren.
De instructies dienen eenvoudiger te worden, dat waar het verhaal over gaat.
[/Miereneuker Mode]

[Florimon]

[double mierenneukmode]API == Application Program(ming) Interface (volgens http://www.acronymfinder.com/af-query.asp?acr onym=AP I&string=exact )[/double mierenneukmde]

Het gaat er hier om dat het om een EENVOUDIGER API gaat [...] De instructies dienen eenvoudiger te worden, dat waar het verhaal over gaat.

Nee, dat staat er dus niet volgens mij. Het gaat erom dat het eenvoudiger moet worden om de API te gebruiken. Carmack wil dat bereikt zien door de API zo volledig mogelijk te maken, zodat alle voorkomende 3D operaties & features gedefinieerd zijn, en voor elke videokaart op dezelfde consequente manier gebruikt kunnen worden. Dus zonder er rekening mee te hoeven houden dat voor de ene kaart de feature A bereikt moet worden door een reeks X aan API-calls uit te voeren, terwijl op een andere kaart diezelfde feature bereikt moet worden door reeks Y aan API-calls uit te voeren.
Tenminste, dat proef ik uit zijn quote :

the next two years will see the addition of the final primitive functionality needed to allow arbitrarily complex operations with graceful performance degradation.

En die 'graceful performance degradation' slaat er dus op dat bij kaarten die bepaalde operaties niet in hardware uit kunnen voeren, dit dan maar door de driver of de API gedaan moet worden. Dit principe van software emulation is niets nieuws natuurlijk, Carmack wil het alleen tot het uiterste doorvoeren en elk onderscheid in functionaliteit tussen de kaarten wegnemen.
Lijkt mij alleen de vraag of dat gaat lukken - zijn statement over "

[...]the final primitive functionality[...]

" doet een beetje erg optimistisch aan. Wie ben ik om de goede man naief te noemen, maar hij weet zelf natuurlijk als geen ander wat voor een stormachtige ontwikkeling de 3D industrie tot nu toe heeft doorgemaakt, niet alleen qua hardware en algoritmen maar ook qua speciale effecten die ontwikkeld zijn om de realiteit zo dicht mogelijk te benaderen.
Dus om er dan vanuit te gaan dat er binnen 2 jaar, of zelfs maar ooit, een 'final' primitive functionality zal zijn die het niet mogelijk maakt voor kaartenbouwers om met verrassende nieuwe en zinvolle extensies te komen ... Het is dus zaak om dat soort extensies zo snel mogelijk te omarmen en als nieuwe primitive in je API op te nemen. Die API blijft dus een werk in ontwikkeling.

/edit:typo

[Verwijderd]

Quote van Florimon:

Carmack wil dat bereikt zien door de API zo volledig mogelijk te maken, zodat alle voorkomende 3D operaties & features gedefinieerd zijn

Euhh, dat is dus exact NIET wat hij wil.
Vergelijk het met de huidige risc/cisc structuur van de processoren.
Hij wil zo weinig mogelijk functie calls, waardoor het allemaal te begrijpen is voor de programmeur.
En doordat je wat minder instructies hebt, moet je wel eens om een probleempje heen programmeren, dat is dan wat hij bedoelt met:

with graceful performance degradation

Tenminste, dat pluk ik uit het artikel.

[Florimon]

Tenminste, dat pluk ik uit het artikel.

Verkeerd geplukt, denk ik

Quote van intruder :

En doordat je wat minder instructies hebt, moet je wel eens om een probleempje heen programmeren, dat is dan wat hij bedoelt met: with graceful performance degradation

Volgens mij niet dus; Carmack zegt niet voor niets :

At that point, a higher level graphics API will finally make good sense.

Higher level dus, waarbij de API is afgestemd op de behoeften van de graphics programmer, in plaats van op kaart-specifieke features.

Om bij jouw risc/cisc vergelijking te blijven: zolang jij niet in assembler gaat programmeren, maar in een 'hogere' programmeertaal als bijvoorbeeld C of Java, dan merk jij verder niks van dat verschil - nou vooruit, misschien in grootte of performance van de compiled code, maar in ieder geval niet t.a.v. het programmeren zelf. Cisc instructies die de risc-architectuur 'mist' worden immers door de compiler wel 'ingevuld' (door inline code of function calls).

[Ralph Smeets]

Ik weet niet hoe het zit met nVidia, maar de PowerVR (Kyro) is gebouwd rondom 'n soort van CPU die z'n functionaliteit uit 'n ROM haalt.

Tenminste dat is de reden waarom m'n de Linux community niet kan voorzien van specifieke informatie over hoe je 'n driver kunt maken voor de Kyro.

* 786562 Ralph
Ik kan me voorstellen dat deze ROM misschiens gewoon 'n geheugen is waarin de driver de instructies schrijft om bepaalde dingen te doen. In dat geval kun je dus makkelijk bugs uit de hardware halen....

[Verwijderd]

offtopic:
Alle CPU's en waarschijnlijk ook alle GPU's hebben hun instructie's in Rom opgeslagen en in de nieuwere generaties is dat nog EEPROM. Dus kun je door die te flashen de hardware upgraden. (is geen firmware btw)

[TheEagle]

Om het eerlijk te zeggen klinkt dat niet eenvoudig. En was het niet de bedoeling dat het dat werdt

[BurningSheep]

Voor de eindgebruiker van die API (de programmeur dus) is dit natuurlijk juist heel makkelijk, op dit moment heeft iedere kaart z'n eigen extra features.

Volgens mij word de GPU hierdoor wel steeds generieker en meer en meer een 2e CPU. Maar we zullen wel zien, in die paar jaar kan een hele hoop gebeuren

[Furrball]

De Meester heeft gesproken!
Laten we hopen dat ie gelijk heeft.

[Horus]

Hehe, idd, maar dat had een ventje op slashdot nog niet helemaal door, die begon carmack uit te schelden voor het zo autoritair doen, en dat ie waarschijnlijk een of andere newbie was die nog nooit ook maar iets van een game had geprogrammeerd.
Best grappig als je dat zegt tegen de god van 3d gameing. (en dat werd hem dan ook wel even duidelijk gemaakt )

[PuzzleSolver]

Of dat ventje had het wel door en heeft een hoop lol gehad van alle reacties

[Verwijderd]

Hij heeft er echt verstand van hoor

Een GPU wordt steeds meer een volledige CPU.

Troll: die snap ik niet? Ik geef een compliment en dat is een troll?

[Verwijderd]

Een GPU wordt steeds meer een volledige CPU

Sterker nog, een GPU is momenteel 2x zo complex als een CPU. De GeForce 3 is complexer als een Pentium 4.

[Vastloper]

complexiteit heeft niet altijd wat met het aantal transistoren te maken wat jij nu zit te vergelijken. Neem bijvoorbeeld een geheugen chipje deze kan erg veel transistors bevatten maar is vrij eenvoudig en heel eenduidig in structuur in dit geval is een gpu meestal wel complexer dan veel cpu's maar dit is niet in cijfers uit te drukken.

[SG]

Een GPU wordt steeds meer een volledige CPU.

als dat zo is kan je ook de CPU weg laten. Ehuu??? hij doet niks!!!

De CPU Centrale Processing Unit is zoiets dat hij alles in het systeem kan regelen regeld

Dan heb je specifike processing units FPU GPU I2O dat zijn specialistische units die doen maar een ding en horen daar zeer goed in te zijn maar blijven afhankelijk van de CPU die delegeerd hun specifieke werk.

dus 'n CPU kan GPU werk doen maar 'n GPU géén CPU taken. Zo ver ik weet

[PuzzleSolver]

Het wordt steed meer een CPU voor de videokaart.

En sinds de Geforce 3 kunnen eigen (assembly) programma's gedraait worden. Maar het zijn nog wel allemaal hele specialistische en meerdere CPU tjes. Ze kunnen nog niet rechtstreeks bij het geheugen maar benaderen meer een pixel of een vertex wat in principe op het zelfde neerkomt.

Mischien ook een leuk ID voor de PC een apparte processor voor geheugen besturing een apparte voor berekeningen en een apparte voor IO. Het zou wel handig kunnen zijn om b.v. een cache programma te kunnen draaien die "inteligent" cached. Het zou alles wel weer een slag complexer maken en dat maakt het weer een stuk moeilijker om stabiel te houden.

[Acidfire]

Vanaf wanneer kan je je GPU een laten grazen???

[sharkzor]

kan me nog herrineren dat er al eens is geprobeerd een niewe api in te voeren. nvidia werkte hier ook aan mee. fahrenheit f zo moest dat gaan heten, maar ze waren er mee gestopt...

[-=unicron=-]

nvidia heeft daar niet mee te maaken. dat is het silicon graphics and microsoft project om DirectX mooi en vlugger tu maaken. en zo als weet is silicon graphics de uitvinder van opengl. meer info http://www.sgi.com.au/news/42dcmic2.html

[machiel]

Een samensmelting van OpenGL en DirectX. Volgens mij was het niet de bedoeling om een hoger abstractieniveau te implementeren met Fahrenheit. Over een hogere abstractie wordt wel al lang gespeculeerd (zoals ook vandaag weer).

[sab]

nVidia is al aardig op weg met hun nFinite whatsitcalled (tis nog vroeg), maar zo wordt het idd straks een stuk makkelijker bij het aanschaffen van een nieuwe videokaart.
Kan me trouwens voorstellen dat spelontwikkelaars ook wel vrolijk worden van deze ontwikkelingen.

[RvdH]

OpenX? DirectGL?

[Erhnam]

Dit is volgens mij het probleem van Carmack:

Als er een leuke feature wordt meegeleverd met een nieuwe videokaart is het zo dat de leverancier van het bepaalde stukje hardware bij MS moet aankloppen of zij deze feature in de eerst volgende generatie van Directx willen stoppen. Dit is natuurlijk jammer want zo komen er leuke features uit waar nauwlijks gebruik van gemaakt wordt

Met OpenGL werkt het, volgens mij ( correct me if i'm wrong ) iets anders. Deze 'software' wordt meegeleverd met de drivers van de fabrikant en zo is de fabrikant in staat nieuwe features al meteen te ondersteunen, mits ! Spellen gebruik maken van deze features.

Op dit moment is iedere fabrikant allemaal eigen leuke features aan het maken en weten de game-creators niet meer welke ze nou moeten inplementeren in hun games.. Gaan zij voor Opengl en ondersteunen zij een aantal features van bepaalde fabrikanten, met als gevolg dat bepaalde kaarten niet lekker lopen. Of kiezen zij voor de API Directx.. Wat welliswaar wat achterloopt en niet iedere leuke feature ondersteund..

Al met al een choas ! Waar volgens Carmack ( en ook aan mij ) snel een einde aan moet komen.

/edit: typo

[joho]

Ik lees een hoop verschillende interpretaties van John Carmac's opmerkingen, hier volgt de mijne.

Voor het benutten van de nieuwe pixel/vertex/lighting features van GPU's is het (nu nog) noodzakelijk dat de applicatie programmeur de GPU voorziet van GPU specifieke instructie code. Om meerdere GPUs te ondersteunen moeten er tal van (assembly achtige) GPU routines geschreven worden.

John Carmack zou het liefst zien dat er een programmeertaal (zoals C) word gespecificeerd waaruit compilers dan GPU specifieke code kunnen genereren. Hierbij ontstaat ook de mogelijkheid om een truuk die niet in hardware mogelijk is in software af te vangen.

Door de compilatie slag pas in de DirectX (of andere) API te laten uitvoeren kunnen toekomstige kaarten, waar nu dus nog geen compilers voor zijn, ondersteund worden. Het word dus in principe mogelijk dat de software weer voor gaat lopen op de hardware. De grafische bewerkingen die je nu zou willen hebben kunnen in de taal opgenomen worden en nu in software, en pas later in hardware geimplementeerd worden. (Dan worden oude spellen mooier en sneller naar mate de hardware beter word.)

[Verwijderd]

Ik vind het vreemd dat dit op tweakers terecht komt. Dit is eigenlijk alleen interessant voor spelontwikkelaars toch?

[TheGhostInc]

Het werpt een nieuwe blik op de toekomst van de GPU's waar elke tweaker bij gebaat is.
De verschillen die de huidige tweaker doen beslissen welke kaart ze willen, kunnen in de toekomst minder worden.

* 786562 TheGhostInc

[rjeggens]

Komt bij dat, gezien het aantal reacties, er toch zeker wel interesse in dit soort nieuws is. Ik vind het in ieder geval wel interessant.

Wat ik wel hoop is dat die API niet alleen het windowsplatform gaat bevolken, maar dat er ook varianten komen voor Linux, BeOS, BSD en OS/2. Worden spellen makkelijker porteerbaar en dat lijkt me geen verkeerd plan.

[Verwijderd]

Het moet wel een open standaard worden zonder dat er license fees betaald moeten worden. Dan komt multi platform gamen een heel stuk dichter bij. Dan hoef je alleen maar te recompilen voor dat betreffende platform en je bent klaar.