Preview features van volgende versie DirectX

Op Beyond3D is een uitgebreid artikel geplaatst over de features die mogelijk in 'DirectX Next' zullen verschijnen, en dan natuurlijk met name over Direct3D. Hoewel deze API van huis uit een Microsoft-product is, wordt de koers al jaren in goed overleg met fabrikanten van 3d-hardware en -software uitgestippeld. Een indicatie van wat Direct3D in de toekomst gaat doen, is dus tevens goede wegwijzer voor het pad waar de hele industrie de komende jaren in zal slaan. DirectX Next zal het in DirectX 8 onstane idee van de programmeerbare GPU maximaal uitbuiten. Er zal geen expliciet onderscheid meer worden gemaakt tussen pixel- en vertexshaders, en alle limieten die nu nog gelden voor het aantal instructies of textures dat een shader mag gebruiken gaan overboord.

De manier waarop videogeheugen werkt moet daarvoor veranderd worden, het is de bedoeling dat toekomstige videokaarten net als de huidige processors met virtueel geheugen gaan werken. Deze ontwikkeling wordt aangevuld met een geheel nieuw I/O-model waarin geen onderscheid meer wordt gemaakt tussen verschillende soorten data zoals pixels en vertices. Verder kan de videochip tijdens iedere stap in de pipeline data wegschrijven die volgende instructies weer op kunnen pikken. Bepaalde algoritmes kunnen door deze minder lineare opzet vele malen efficiënter worden uitgevoerd. Een andere verbetering in shader 4.0 is het toevoegen van integer-instructies. Op dit moment kan er alleen gewerkt worden met floating point getallen, wat prima is voor kleuren, maar voor de programmeur niet handig wanneer hij een lijst wil nummeren of naar een geheugenadres wil wijzen.

Ook nieuw is de toevoeging van de topology processor, een onderdeel van de pipeline die point sprites, schaduwen en 'fur'-effecten (zie onderstaand plaatje) kan laten zien zonder de CPU te belasten met de benodigde berekeningen. Daarnaast wordt het gebruik van high order surfaces (het beschrijven van vormen met behulp van wiskundige formules in plaats van met driehoekjes) wederom makkelijker gemaakt. Iets anders wat men probeert te doen is het reduceren van de overhead die het gebruik van de DirectX-API veroorzaakt, voornamelijk door een strakke integratie met Windows Longhorn, maar ook door meer flexibiliteit van de functies in het algemeen. In de conclusie merkt te schrijver op dat veel features die op het verlanglijstje voor DirectX Next staan makkelijker te implementeren lijken in tile-based architecturen dan in standaard videochips, en hij ziet dan ook een interessante kans liggen voor PowerVR. Er is echter nog een lange weg te gaan, en in hoeverre de genoemde features (verplicht) aanwezig zullen zijn op DirectX Next-videokaarten is dus nog maar de vraag:

The new memory management model, which allows virtually unlimited resources, also allows the implementation of virtually unlimited geometry storage, which has always been a concern for the deferred rendering implementations. Access to current frame buffer values from the pixel shader is also very easy to do on a tile-based deferred renderer since all the data is already in the on-chip tile buffer. So there are no costly external memory accesses required or expensive pipeline and back-end cache flushes. The front-end changes to the vertex/geometry shader side are independent of the tile-based deferred rendering principle and are thus not as big of a problem to support on tile-based deferred renderers as they are for immediate mode renderers. It will indeed be very interesting to see whether PowerVR, who has been laying pretty low lately, will take this opportunity to put out a really awesome DirectX Next implementation.

It will also be fairly interesting to see exactly how the proposed features develop - it's unclear, for example, where exactly in the pipeline the topology processor will reside. It has also yet to have been determined whether or not the new tessellator will be programmable, highly configurable, or simply purely fixed function.

Since the API is still in an extremely infantile state, much of this probably will not be known for some time, and much of what was discussed in this article will probably undergo several changes or be completely scrapped; but all in all the next few years of real-time computer graphics should prove to be quite interesting.

Reacties (62)

Als dit zo doorgaat ziet de toekomst voor games onder Linux er zeer somber uit. DirectX wordt gewoon met de dag dominanter.
En games zijn toch de belangrijkste(en enige) reden waarom ik nog steeds Windows draai.

Ehm, heb je al van OpenGL 2.0 gehoord?

Dat is multiplatform, ondersteunt ongeveer dezelfde dingen die hier genoemd zijn.
http://www.3dlabs.com/support/developer/ogl2/index.htm

Dat is voor professionele 3D renderers (en zal daarvoor ook de standaard worden vermoed ik) dus ook "goed genoeg" voor gamers.

Het is niet alsof Microsoft met iets origineels komt.

Het gaat er ook niet om dat Microsoft met echt iets NIEUWS komt..

Het probleem wat ik de laatste tijd merk is dat je niet meer weet (lees:de keuze hebt) wat voor rederer er gebruikt wordt, tenzij je in .ini files gaat zitten vroeten..
voorbeeld:
Unreal2003. Draait standaard in D3D.. Maar heeft nergens een menu met een keuze voor de renderer.. Maar als je d'r iets meer vanaf weet en in de configuratie bestanden gaat kijken, kun je eenvoudig een stukje regel verwisselen en je draait in OpenGL.
Dungeon Siege: uberhaupt geen keuze.. waar draait'ie in? Ik zou't zo niet weten.. Waarschijnlijk D3d, aangezien het door Ms uitgebracht is. KAN het wel in OpenGL draaien?
Volgens mij heb je bij bijna alle spellen van microsoft's game studio's absoluut geen keuze waar je in kunt draaien, behalve de resolutie, en met wat geluk, 16 of 32 bit kleur.
Vertel mij eens welk spel van de laatste tijd 'standaard' in OpenGL draait? Ik weet het zo snel niet... Maar WEL d3d..

Overigens merkte ik wel dat m'n performance in UT2003 achteruit ging in dezelfde resolutie/bit kleur in OpenGL dan wat ik had in D3D.. Maar het zag er (imo) wel weer mooier uit..

Geef me EEN reden waarom het interessant is welke 3D api een game gebruikt... Ik zou er geen weten. Een consument start het spel op en het enige dat die consument wil is het spelen van het spel. Of de beelden nu door D3D, OpenGL, FooBar3D of whatever worden gerendered zal die consument worst zijn, in 99% van de gevallen weet die consument niet eens het verschil tussen convex en concave polies.

Het is alleen interessant voor die ene procent van de computergebruikers die dat wel weet en het is nog interessanter voor een NOG kleinere groep die ook 3D software bakt, hobby of professioneel.

Gekrakeel over OpenGL is voor de buhne. Voor windows, waar de meeste PC games voor worden uitgebracht, is D3D het platform, dat is een gegeven. Dat er een ander platform is, is fijn voor de statistieken, maar een gamedeveloper interesseert zich daar alleen voor als hij iets wil dat D3D niet kan (en dat is op dit moment niets) en de consument, dus de doelgroep waar die developer zn spullen voor maakt, interesseert het uberhaupt niets, dus het is totaal IRRELEVANT, dat OpenGL.

Ik heb zelf veel OpenGL geprogrammeerd, en mijn ervaring is is dat Microsoft een deel schuld heeft aan het kleine marktaandeel van OpenGL, maar de kaartfabrikanten OOK, en wellicht een nog groter aandeel. De ARB is vleugellam (hoelang babbelt men nu al over 2.0? 2 jaar? ) en de kaartenmakers verzinnen de ene proprietry extensie na de andere, en ik kan je verzekeren, voor een developer is dat ronduit klote. Ik heb op een gegeven moment de brui eraan gegeven, simpelweg omdat ik het zat was om voor iedere kaart een andere extensie te gebruiken voor dezelfde functionaliteit.

Als laatste, en dat zal uiteraard als flamebait worden opgevat, is de OpenGL community zelf mede-schuldig aan het feit dat weinig mensen op windows nog OpenGL programmeren: de community is zo anti-microsoft/windows, mede gevoed door SGI (!), dat je als Windows developer je je buitengesloten gaat voelen op een gegeven moment. En dat terwijl het een API is, een stukje software...

Dat die performance achteruit ging had vast wel te maken met je videokaart, immers is bekend dat een ATI radeon kaart beter onder DirectX werkt dan onder OpenGL, de Nvidia kaarten werken beter onder OpenGL dan onder DirectX. Nvidia's kaarten hebben daardoor een hogere kans van slagen als het gaat om linux games.

Een van de andere spellen die standaard in OpenGL draait is van Electronic Arts de Medal Of Honor Alliied Assault serie. Deze is ook zeker speelbaar via wine (transgaming editie) onder Linux!

Electronic Arts levert ook Battle Field 1942. Lijkt veel op MOHAA, maar draait weer in D3D. Doet het ook wel via wine onder Linux, in combinatie met 1GB geheugen. MOHAA heeft genoeg aan 512MB.

dat zit toch gewoon onder zo'n video menuutje?
kan ik me dachtik ergens herinneren...

Doom 3 als ik het niet verkeerd heb...
Alle Quake 3 gebaseerde games

UT2003 in Linux
Alle andere 3D Linux spellen

En Savage natuurlijk!
- For the Leogion
- Jarizajah is my leader

Wat had je gedacht van het neigste online spel dat er bestaat?

Wolfenstein - Enemy Territory

Met opengl 2.0 loopt het anders niet zo'n vaart (helaas). Op de opengl website www.opengl.org is er nagenoeg niets over te vinden. Tegenwoordig moet de OpenGL programmeur het doen met OpenGL 1.4 plus een aantal vendor afhankelijke extensies (nvidia,ati,sgi,etc) en (vendor onafhankelijke) ARB extensies, niet echt elegant dus.

ARB is niet vendor afhankelijk (staat voor Architecture Review Board), maar juist een 'prelude' op OpenGL 2.0.

Verder is dit verhaal over DirectX nog net zo goed toekomstmuziek als OpenGL 2.0 dat is.

Since the API is still in an extremely infantile state, much of this probably will not be known for some time

De API van OpenGL 2.0 is juist al vrij goed gedocumenteerd, vooral implementatie ervan wordt nog hevig aan gewerkt.

(reactie op wumpus)
Allemaal leuk, maar MS heeft OpenGL al buiten de deur gezet: de opengl32.dll die wordt meegeleverd bij windows is OpenGL 1.1, en zal ook geen hogere versie meer krijgen, ondanks het feit dat SGI 2 jaar geleden Microsoft al de source heeft gestuurd voor OpenGL 1.2.

Dit houdt in dat alle OpenGL 1.2 en 2.0 acties middels extensions moeten worden uitgevoerd. Dit houdt in dat iedere kaartfabrikant zn eigen draai er aan kan geven en het voor de ontwikkelaar minder abstract wordt allemaal: hij moet voor iedere kaart en driver een stuk code schrijven om alle extensies te ondersteunen, overeenkomstige extensions uit te zoeken etc.

SGI kan geen opengl32.dll uitbrengen want Microsoft heeft de copyrights op de technologie die ervoor zorgt dat een OpenGL canvas kan worden geplakt op een Device Context (DC). Dit is absoluut noodzakelijk om uberhaupt OpenGL te kunnen gebruiken in bv windows.

Bottom line: OpenGL is leuk, heb het zelf jarenlang gebruikt, maar voor windows ten dode opgeschreven en daarmee voor de gamewereld idem dito. Neem maar van mij aan, ook Carmack gaat over naar Direct X ooit

Met opengl 2.0 loopt het anders niet zo'n vaart (helaas). Op de opengl website www.opengl.org is er nagenoeg niets over te vinden.

Welles, klik maar eens op "OpenGL 2x suggestions".

Dat is idd wel waar. Het is gewoon een feit dat veel meer games uitkomen op windows gewoonweg omdat veel meer mensen het hebben. het houdt zichzelf dus groot.
Dat is dus ook het feit met het hele directx gebeuren. In principe een prachtig mooi iets, wat imho ook steeds beter wordt uitgewerkt. Aangezien directx toch wel zorgt voor betere ontwikkelingen tussen hard- en software is het toch wel een makkelijk iets. alleen niet linux compatible

/edit: verhaaltje was nog niet af

En terecht,
Linux is ook niet voor spelletjes bedoelt. Niet zoals windows dat is in ieder geval.
Het is volgens mij verder wel een positieve ontwikkeling dat directx steeds geavanceerder wordt. Ik denk dat je er uiteindelijk wel naartoegroeid dat alles rondom de GPU ook een soort mini-computerwordt. Zeker nu ze ook al virtueel geheugen gaan gebruiken.

Ik zou het zelf helemaal mooi vinden als je geen videokaart maar een videomainboard zou krijgen waar je de GPU instopt met een zif-socket, met eigen sockets voor geheugen, enz....

EDit: Typo's

Volgens mij moet je het meer andersom zien
De spelletjes op de pc begonnen als oefening/gijntje/test. Pong was niet zozeer een commercieel product maar eerder een expiriment of je ook iets "leuks" kon programmeren. De commerciele spelletjes kwamen pas toen er genoeg pc's in omloop waren en de potentiele markt groot genoeg was. Dat is eigenlijk met elk product zo.

Alleen de linux gebruikers vinden dat het voor linux andersom hoort te zijn. Zij willen dat er eerst vanalles gemaakt wordt voor linux, met als argument dat het dan pas door kan breken. Als dit communischtisch rusland was met een planneneconomie zou dat werken, maar als een ontwikkelaar die wat wil verkopen gewoon een te kleine markt ziet, dan houdt het op.

Linux zit wel in de lift bij mensen die veel online quake en wolvenstein spelen. Dit zijn allebei spellen die ook met publieke servers werken, en linux is beter als server dan als desktop, dus die keuze ligt voor de hand.

Maar het gemiddelde flightsimulator publiek is toch nogsteeds meer van de PC. FS is meer iets voor niet-diehard gamers, en diehard computer gebruikers, en die gebruiken ook geen linux. Op T.net hoor je wel eens stemmen dat linux voor iedereen beter in alles is, tot de embedded software van de viberator van mijn vriendin aan toe, maar als desktop voor niet ervaren gebruikers/experts blijf ik toch bij windows.

De commerciele spelletjes kwamen pas toen er genoeg pc's in omloop waren en de potentiele markt groot genoeg was. Dat is eigenlijk met elk product zo.

Há nu weet ik zeker dat de playstation 2 als dvd speler bedoeld was.

Heb jij poep in je ogen ofzo?

Linux is weldegelijk bezig met zich te richten op de desktopmarkt en daar horen spelletjes ook bij. Het probleem ligt niet bij Linux, maar bij de spelletjesbouwers en GPU-bakkers die geen drivers / games schrijven voor Linux.

nvidia en ATI hebben biede linux drivers.
nvidia heeft al heel lang uitstekend linux drivers, en ATI heeft recentelijk veel vooruitgang geboekt met hun linux drivers (al hebben ze nog wel te doe, vooral op 3d gebied)

spellen blijven nog wat achter ja, maar epic (die van unreal) hebben al lang linux versies van hun spellen.
en nu de mac met os-X is overgestap op iets dat compatible is met linux zullen we meer spellen in linux gaan zien.

daarnaast kan je met winme een hoop spellen al spelen onder linux. (nee de emulatie is nog niet prefect, maar snelheids verlies is meestal minimaal en het word steeds beter)

daarnaast kan je met winme een hoop spellen al spelen onder linux.

Volgens mij bedoel je Wine..

Linux probeert al jaren en faalt al jaren om interessant te worden voor de thuisgebruiker..

Microsoft heeft niet voor nix 'monopolie' ze bieden gewoon het beste/compleetste wat er is..

Moeten ze bij Linux hun best maar beter doen

Je onderschat denk ik een beetje hoe moeilijk het is om een monopolie te doorbreken dat zo groot is als dat van Microsoft.... Ik denk dat Linux hard op weg is qua populariteit, en dat merk je zeker al in de servermarkt. Gewoon afwachten, over een paar jaar is de situatie wel anders

Linux is ook niet voor spelletjes bedoelt. Niet zoals windows dat is in ieder geval.
Dat is toch onzin !
Linux draait toch ook al jaren games en met opengl draaien die net zo goed als degene op windows of soms wel beter. Ik haalde op men oude linux bak meer fps tijdens quake dan op men windows bak.
Dus ik denk eerder dat het een kwestie van tijd is.
Kijk naar wolfenstein ET dat draait op beiden en de linux versie moet niet onderdoen.

Linux is ook niet voor spelletjes bedoelt. Niet zoals windows dat is in ieder geval.

Linux is ook nooit bedoeld als desktop-OS. Toch gebruik ik het als zodanig. Waarom? Omdat het me beter bevalt dan Windows. Windows is precies het omgekeerde: een desktop-OS dat wordt gebruikt als server-OS. De gevolgen zijn bekend.

Terug on topic: je krijgt natuurlijk wel een soort achterkamertjespolitiek tussen Microsoft en de hardwarefabrikanten, waar andere softwareboeren niet meer tussenin komen. Leuk voor MickeySoft, maar de niet-Windows-gebruiker is de dupe.
Een ander punt is dat het de spelontwikkelaar nog moeilijker wordt gemaakt om een spel naar Linux te porten. De directX-functies zijn er wel, maar daar bestaan in SDL/GL2/... geen goede alternatieven voor.
Toch maar overwegen om Transgaming te gaan steunen...

Als dit zo doorgaat ziet de toekomst voor games onder Linux er zeer somber uit. DirectX wordt gewoon met de dag dominanter.

Wat houdt de Linux community tegen de DX API ook onder Linux te implementeren?

Is die er niet dan

WineX

Ik geef je 1000% gelijk!!!!, ik kan het neit uitstaan om windows te gebruiken maar aangezien ik aardig wat game wordt ik ertot gedwongen...

jammer dat er meteen weer een flame tussen DirectX- en OpenGL liefhebbers uitbarst.

Wat veel interessanter is (voor ons tweakers) is dat nu resultaten van berekeningen, op hoge snelheid, teruggelezen kunen worden.

Dit betekend dat de grafische processor meer een coprocessor wordt. Eentje die ongelofelijk snel wiskundige berekeningen parallel uit kan voeren --> goed nieuws voor DPC en iedereen die met smart terugdenkt aan het 386 tijdperk...

Dit betekend dat de grafische processor meer een coprocessor wordt. Eentje die ongelofelijk snel wiskundige berekeningen parallel uit kan voeren.
Heel interessant academisch gezien, maar noem es een reden dat dit in de praktijk interessant kan zijn?

Oke, misschien als je PCI kaartjes hebt dat je er 6 van in je PC kan zetten en zo parallel rekenen. Maar zou dit goedkoper zijn dan gewoon een Multi CPU bak? (zeker als je dingen als geheugen capaciteit en latency in acht neemt)

Grafische kaarten zijn intern parallel, 8 pijplijnen ... hij bedoelt geen verschillende kaarten.

Het idee van de coprocessor is correct. De cpu is te algemeen en heeft een te diepe pijplijn. Grafiek en geluid worden best door gespeciale processor uitgevoerd. Je kunt geen CPU maken die alles (grafiek, geluid, AI, besturingssyteem, drivers,...)tergelijkertijd (realtime) aankan zelfs niet in 8x configuratie, dat kost hopeloos meer. De meeste cpus zouden gebrekkig gebruikt omdat ze voor algemenere taken zijn gebouwd.

Een 3dkaar doet veel meer dan je denkt, aniso, fsaa, trilineair filteren, mip-map generatie, ... een cpu doet dat in 10 stappen (40% pijplijngebruik, schatting) terwijl een 3dkaart dat in 1 stap (100% pijplijngebruik) kan.

Als het aan mij ligt verdwijnt de pc in zijn huidige staat en word ie vervangen door een krachtige multi-media box met alles erop en eraan. Zo zul je meer markt splitsing krijgen voor de doelgroepen en kunnen de console's straks ook gaan bepalen met welke OS ze nu verder moeten gaan. Persoonlijk zie ik Linux op game console's wel zitten met dvd brander ondersteuning met daarbij een toetsenbord en een muis.

Laat de PC verder ontwikkelen voor bedrijfsgebruik en de prosfessionele gebruiker. Ik koop liever eens in de 3-5 jaar een krachtige game console inplaats van om het 1 1/2 jaar een videokaart van 500 Euro + snellere cpu's en ram wat heel kostbaar is. Ik betaal dan liever goedkoper voor een console en wat duurder voor de games als andersom, zo betaal ik tenminste voor datgene wat ik leuk vind en niet voor dure hardware. Ook Barebone pc's zie ik niet blijven bestaan op de lange termijn, is een kleine doelgroep voor en ook veel te duur.

Dus deze meneer bezoekt tweakers.net met de computer die nog voor de nintendo 8bit op de markt was..

Ok, misschien 'verdwijnt' de pc in een andere versie.
Maar ik denk dan nog eerder dat ie 'opsplitst' in een weer alsoude versie die duurder was en voor een bepaalde markt aan pro's is besteed. (Werkstations en zware systeemeisen, specifiek) En next to that, jou idee van een thuisgebruikers syst...eh...multimedia-doos.

Klinkt allemaal zeer cewl...

en dat gamedevelopers geen games voor linux maken?? duh, dat is een markt net zo groot als 0.1% van de windows markt... Er zit voor game developers gewoon geen geld in die tak.

En natuurlijk zijn er developer die spellen voor linux maken, maar niet als "core" business.. Unreal, Quake e.t.c. zijn allemaal ports omdat het relatief eenvoudig was, aangezien de "engine" toch al onder linux functioneert...

Veel interessanter is echter voor de game developer of deze "DirectX Next" ook voor de XBox2 wordt ontworpen. De consoles, die zijn namelijk WEL gemaakt om games op te spelen... Het idee alleen al dat ik een machine moet kopen met een videokaart van 600 E om een spelletje te kunnen spelen... doe mij dan maar zo'n GameCube van 99 pops.

Die kun je wel maken hoor, dit duurt nog wel een jaartje of 1,5 2 schat ik zo

Maak daar maar 3 jaar van... volgens Beyond3D kunnen we deze versie van DirectX pas verwachten rond de release van Longhorn... dia iirc pas in 2006 uitkomt.

Jammer genoeg kan ik niets over geluid vinden.

Het zou echt superinteressant zijn als je de GPU ook voor geluidszaken zou kunnen belasten. Als je toch FPS over hebt dan kun je ook wel wat SoundFX's verbeteren. (de verschrikelijke galmen bijv)

Een gpu geluidseffecten laten doen? Lijkt me niet erg interessant. Lijkt me meer de taak van de chipset op een geluidskaart. (Voorzichtige 'duh', no flame intended.)

Er is een fabrikant die speciaal een geluidsbewerking kaart heeft gemaakt met (naar schijnt) een GPU als DSP gebruikt. Dat is dan de UAD-1 van Mackie.
Die kost rond de 600€ en voor de helft van het geld heb je een redelijke grafische kaart die dan hetzelfde zou kunnen.

De nVidia NV1 had zowel geluid als video aan boord, dus wie weet .

Maakt het uit of het dezelfde feartures bevat als Open GL 2.0 Wij profiteren toch van de technologiesche voorderingen en daar gaat het om

Linux is weldegelijk bezig met zich te richten op de desktopmarkt en daar horen spelletjes ook bij. Het probleem ligt niet bij Linux, maar bij de spelletjesbouwers en GPU-bakkers die geen drivers / games schrijven voor Linux.

Ja maar jij als manager van een game producent gaat geen geld in ontwikkelkosten stoppen als de opbrengst van een linux markt kleiner is dan de ontwikkelkosten

dat klopt wel maar ergens is dat ook een straatje zonder einde.
Stel dat alle game producenten zo zouden gereageerd hebben in de begin jaren van de PC dan waren alle games enkel op MAC geweest of op game consoles

PowerVR is toch van de Kyro kaarten?

Het is jammer dat ze bij PowerVR alleen veel kennis hebben over tile-based rendering en op andere vlakken zo ver achterlopen.
Ik zie een mooie overname door Nvidia of ATI in het vooruitzicht als de beweringen over de potenties van PowerVR waar zijn

In het DX Next concept zitten 'nieuwe' mogelijkheden die met de kyrokaarten al heel gemakkelijk realiseerbar waren maar door gebrek aan ondersteuning niet gebruikt werden. Het hele DX Next lijkt btw zeer goed te stroken met het tile based rendering principe terwijl het lastig te realiseren is op conventionele VPUs (btw nvidia heeft tile base rendering patenten).
De PowerVR5 waarop we allemaal hopen is een tile based renderer die ook tile based rendering op shaders zal introduceren en zeker over nog veel onbekende gaven beschikt. De PowerVR4 heeft het daglicht nooit gezien terwijl het een dx8 GPU was. Kortom PowerVR heeft nog heel veel toekomst en potentieel.

Lachuh .. goede drivers voor je videokaart, goede Directx .. wordt het allemaal weer een beetje sneller .... kan ik de wissel van mijn 128Mb 4200Ti voor een FX5900 of 9x00pro nog ff uitstellen

Sja, komt DX10 strax uit, best lullig hoor, maar je GF4 ( DX8 ) snapt helemaal nix van die nieuwe mogelijkheden, en uiteindelijk staat je CPU zich nog steeds groen te rekenen op instructies, die de dan up-to-date GPU's natuurlijk wel zelf kunnen uitvoeren. Gevolg zal zijn, dat je performance juist nog schriller gaat afsteken bij het geweld van de dan nieuwe GPU's.

Waarom denk je dat je GF4 zo matig scoort in 3D Mark2003 ? Daar waar ik een ATi 6900 Pro nog in het stof laat bijten in DX8 ( uitgaande van 3D Mark2001SE en Aquamark3 ), kom ik in DX9 niet veel verder dan een 60-70% score van een 9600 Pro. Domweg om dat alle specifieke DX9 zaken door je CPU worden gedaan ipv van door je GPU ..............

"Daarnaast wordt het gebruik van high order surfaces (het beschrijven van vormen met behulp van wiskundige formules in plaats van met driehoekjes)"

Hmmmzz high order surfaces??
Bedoelt men daar NURBS mee? patches? subdivs?

Want bijv NURBS worden dan wel beschreven door wiskundige formules, op het moment van renderen zal die surface toch omgezet (tesselation) worden naar poly's en dan gerenderd worden.

Of snap ik iets niet, en bedoelt men iets anders met "high order surfaces" ??

EDIT --> *** lezen is ook een vak ***

Het BESCHRIJVEN van vormen. zegt niks over het uiteindelijke renderen. ok laat maar...