Ik zou inderdaad niet weten wat DX10 _precies_ allemaal meer kan dan DX9, volgens mij is het niet iets waarvan iedereen achterover slaat.
Maaaar... DX10 schijnt toch wel zo anders te coden dat je als programmeur je engine moet aanpassen om op dx9 te werken. Spellen krijgen dan een DX10 mode en een DX9 mode. Quake2 had ook verschillende renderers als iemand dat nog weet. Je kon kiezen uit software, opengl, 3dfx opengl, etc. Zoiets zal dit weer worden met DX10 en DX9.
De vraag is dan: Hoeveel spellen gaan er uitkomen die de moeite niet hebben genomen om een Dx9 compatible renderer erbij te doen. Of andersom natuurlijk.
Maar je hebt wel gelijk in een goed punt (en waarom ik een heleboel van de DX9/DX20/WinXP heisa niet snap): Als je een DX10 compatible kaart hebt, lijkt het mij niet meer dan normaal dat ie het ook gewoon doet onder WinXP met DX9 hoor! Alleen spellen die persee DX10 nodig hebben doen het dan niet. En als Vista / DX10 inderdaad een lange tijd nodig heeft om 'in te burgeren' zullen er nog meer dan genoeg DX9 spellen uitkomen, of spellen die zowel DX9 als DX10 ondersteunen.
Ik kan me nog herinneren dat Prince Of Persia: Sands of Time uit kwam, en dat het spel pixelshaders (geen idee welke versie) _nodig had_. Dus m'n oude Geforce2'tje is toen eindelijk de deur uit gegaan.
Nog een punt om over te denken: Er werden een paar DX10 spellen geshowed op de E3 dit jaar. Crysis bijvoorbeeld. Ze draaide dat op een bijzonder high-end systeem wat gewoon DX9 en WinXP draaide... alleen DX10 werd gewoon 'geemuleerd' of 'brute-force berekend' (weet niet meer hoe Gamespot.com het noemde, geen goed woord in ieder geval
).
Dus er zullen altijd wel mogelijkheden zijn om DX10 spellen te draaien op oude DX9 hardware. Maar het zal natuurlijk nooit zo soepeltjes lopen of mooi eruit zien als echte DX10 hardware..
DX10 heeft een radicaal andere driver structuur. Het grote probleem met DX9 is dat je zelfs op de snelste PC's maar een beperkt aantal API calls kan doen (ergens rond de 500 of zo.) Als je veel objecten wil renderen moet je in 1 API call meerdere objecten tegelijkertijd renderen.
DX9 laat dit toe, maar enkel als die objecten er nagenoeg identiek uit zien (zelfs texture, zelfs polygon's etc.)
De reden hiervoor is dat je voor elke API call van user mode naar kernel mode moet switchen: dat duurt serieus lang.
DX10 lost dat op 2 manieren op. Ten eerste verblijft een groot deel van de driver nu in User mode. Ten tweede heeft de GPU zelf veel meer flexilibiliteit om totaal verschillende objecten in dezelfde operatie te renderen.
Microsoft heeft besloten om die nieuwe driver structuur niet over te zetten naar XP. Dat valt wel enigszins te begrijpen: in tegenstelling tot de overstap van DX7 naar DX8 naar DX9, zijn er nu dus niet gewoon een aantal API calls toegevoegd: de driver structuur is totaal anders en de API is ook niet meer backward compatible.
Dat sluit niet uit dat de nieuwe GPU's ook nog met een DX9 geleverd zullen worden.
DX10 heeft nog een aantal andere verbeteringen, zoals de unified shader instruction set (daarom niet noodzakelijk: unified shader chip architecture!) en geometry shaders. De laatste kan voor meer spectaculaire effecten zorgen. Het eerste maakt eigenlijk niet zoveel uit.
Het eerste maakt eigenlijk niet zoveel uit.
Toch wel, met een unified architecture kun je als programmeur (of als driver, ik heb nog geen idee op wat voor manier het geexposed gaat worden naar de user toe in DX10, maar op de Xbox360 kan het iig wel) zelf kiezen hoeveel units je in wilt zetten voor resp. vertex- en pixelbewerkingen. Dit betekent dat als je een applicatie hebt dat behoorlijk vertex limited is (zoals bijvoorbeeld 3d modeling applicaties) je meer energie in het transformeren van vertices kunt steken, en het daadwerkelijke renderen op een laag pitje kunt laten draaien. Of juist het omgekeerde. Hierdoor kun je het dus perfect uitbalanceren, terwijl bij echt fysiek aparte vertex- en pixelpipelines het vaak zo zal zijn dat de ene partij uit z'n neus staat te vreten terwijl de andere partij resources tekort komt.
Dat sluit niet uit dat de nieuwe GPU's ook nog met een DX9 geleverd zullen worden
Klopt, het is relatief simpel om een oudere API te layeren op nieuwe hardware. Dit gebeurt al veel langer met bijvoorbeeld de fixed function pipeline en oudere shader models, die worden gewoon vertaald naar de nieuwe microcode door de driver.
Andersom zal met DX10 echter niet gaan, een van de radicale veranderingen in het ontwerp is het verwijderen van de mogelijkheid om de capabilities van je videokaart op te vragen. Voor DX10 moest je nog controleren of de hardware wel die ene feature ondesteunt, met DX10 kun je er gewoon glashard van uitgaan dat alle door DX10 blootgestelde features gewoon beschikbaar zijn. En aangezien de oudere hardware die nieuwe features niet hebben en het onmogelijk is om die te emuleren op de CPU, zul je dus geen DX10 API werkend kunnen krijgen op pre-DX10 hardware.
![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.gif){kind=icon}
De RS600-chipsets die ATi in de komende maanden wil uitbrengen, ondersteunen geen DirectX 9.0c of Shader Model 3.0. Volgens een roadmap waar DailyTech de hand op wist te leggen, zal het bedrijf een dergelijk product zelfs helemaal overslaan en in de RS700-serie meteen DirectX 10 en Shader Model 4.0 implementeren. De nieuwe chipsets zouden verder pin-compatibel met de RS600 worden gemaakt, zodat moederbordfabrikanten eenvoudig kunnen upgraden. Uiteraard komen we ook weer Avivo, voor Blu-ray en HD-DVD geschikte decoders en dergelijke in de specs tegen. Volgens Xbit Labs zou de RS700 overigens pas tegen de zomer van 2007 in de winkels opduiken, al zouden werkende prototypes mogelijk tegelijk met de R700 gedemonstreerd kunnen worden.
17:56
15:54
Door 
![[show]](http://tweakimg.net/g/if/comments/button_down.gif "Reactie uitklappen")
Kan iemand me dit uitleggen? Ze komen de volgende maanden met een nieuwe chipset die geen SM 3.0 support? En dan willen ze dat wellicht overslaan en direct SM 4.0 (DX10) gaan ondersteunen met de RS700?
