Voor DX10 games is het moeilijker om multi-GPU drivers te schrijven. Ondanks dat Vista (en dus DX10) de pre-renderlimiet weg haalt van 3 frames, is men nu op andere zaken gebotst die de boel bottlenecken. Het wegvallen van de pre-renderlimiet is voornamelijk zeer voordelig voor DX9 games onder Vista. Dit zie je dan ook in de scaling. Maar wanneer het aankomt op DX10 games, is AMD (en ongetwijfeld ook nV) tegen andere problemen aangebotst.
** WARNING: WALL OF TEXT INCOMING **
DX10 is zeer efficient met resources, wat ideaal is voor Multi-GPU in de meeste gevallen... maar niet wanneer je die resources persistent wilt houden... als elke keer de command buffers leeg gemaakt worden (om immers efficient met de resources om te gaan) kan dit juist voor een averechts effect zorgen op Multi-GPU scaling, terwijl dit op single-GPUs juist geen enkel effect heeft.
Verder zijn er een aantal nieuwe functies binnen DX10, zoals streamout naar de geometry shader, die voor nieuwe problemen hebben gezorgd. Resources worden vaak geschreven binnen 1 frame om gebruikt te worden door andere frames. Gebruik je meerdere GPUs dan is het dus taak om die resources te behouden en ze naar de juiste GPU toe te wijzen. Dat vergt enorm veel van het driverteam om die balancing goed te doen.
Daarnaast is de CPU vaak ook de beperkende factor. Als de CPU niet snel genoeg is om data aan 4 GPUs te leveren, dan heb je vaak weinig aan CrossFireX4. Loadbalancing is dus ook hier weer enorm belangrijk.
Onder DX9 zijn de drivers van AMD trouwens multi-threaded. Dit zijn ze echter niet onder DX10! De reden is dat Microsoft had verwacht dat er steeds meer applicaties zouden komen die van huis uit multi-threaded waren... AMD is er echter achter gekomen dat veel applicaties helemaal niet zo multi-threaded zijn als MS had verwacht. De graphicsdriver multi-threaded maken onder DX10 is niet mogelijk, omdat de driver callbacks moet maken via de DX10 runtime naar de OS kernel. En deze callbacks gaan via de hoofd-thread. MS vond het namelijk niet nodig om een extra thread hiervoor aan te maken.
Omdat deze beperking dus niet via multi-threading op te lossen is, moet AMD hard werken om de CPU limitations weg te werken. Een van de manieren hoe ze dit hebben opgelost is een wachtrij via de drivers creeeren waarin commandbuffers onthouden worden als ook welke frames er gerendered moeten worden.
De driver zorgt er normaal gesproken dat in deze buffer tot 3 frames van te voren worden onthouden. Het operatingsystem (dus Vista) kan er voor zorgen dat applicaties (dus niet de drivers van AMD!) deze limiet ophogen naar maximaal 10. De graphicsdriver heeft hier dus weinig over te zeggen... dit is helemaal afhankelijk van het OS!
Microsoft heeft deze beperking ingebouwd omdat een bepaalde fabrikant van GPUs (niet AMD!) vaak meer frames in de wachtrij zette dan de applicaties aan konden, wat resulteerde in gigantische mouse-lag. Gamedevelopers hebben hierover geklaagd, dus bouwde MS de limiet in.
AMD maakt dus nu voornamelijk gebruik van AFR als loadbalancingsysteem. De drivers blijven dus de pre-renderlimiet van 3 frames houden, waardoor in sommige applicaties de vierde GPU weinig nut heeft... tenzij de applicatie toestemming heeft gegeven om meer dan 3 frames te renderen. Dit zie je bij sommige games want die schalen vrij goed mee met 4 GPUs (zie bv Call of Duty4 (DX9) en CoJ (DX10)). Voor de games die tegen de limiet aanlopen van maximaal 3 frames, bouwt ook AMD een alternatief in om toch gebruik te maken van de 4de GPU net zoals NV dat deed met hun Quad SLI. AMD is ook bezig met een combinatie van SFR met AFR voor deze gevallen. En... AMD is zelfs bezig met een nieuwe techniek... maar die is nog in ontwikkeling en zal misschien later dit jaar gebruikt worden.
Oh en voor de mensen die vinden dat AMD te weinig doet aan performanceboosts... Check deze slide eens:

Omdat de Catalyst drivers elke maand gereleased worden valt een boost minder snel op... vaak gaat het maandelijks een klein beetje omhoog (of omlaag). Neem je een paar maanden, dan tikt het soms toch nog best leuk aan.
** WARNING: WALL OF TEXT INCOMING **
DX10 is zeer efficient met resources, wat ideaal is voor Multi-GPU in de meeste gevallen... maar niet wanneer je die resources persistent wilt houden... als elke keer de command buffers leeg gemaakt worden (om immers efficient met de resources om te gaan) kan dit juist voor een averechts effect zorgen op Multi-GPU scaling, terwijl dit op single-GPUs juist geen enkel effect heeft.
Verder zijn er een aantal nieuwe functies binnen DX10, zoals streamout naar de geometry shader, die voor nieuwe problemen hebben gezorgd. Resources worden vaak geschreven binnen 1 frame om gebruikt te worden door andere frames. Gebruik je meerdere GPUs dan is het dus taak om die resources te behouden en ze naar de juiste GPU toe te wijzen. Dat vergt enorm veel van het driverteam om die balancing goed te doen.
Daarnaast is de CPU vaak ook de beperkende factor. Als de CPU niet snel genoeg is om data aan 4 GPUs te leveren, dan heb je vaak weinig aan CrossFireX4. Loadbalancing is dus ook hier weer enorm belangrijk.
Onder DX9 zijn de drivers van AMD trouwens multi-threaded. Dit zijn ze echter niet onder DX10! De reden is dat Microsoft had verwacht dat er steeds meer applicaties zouden komen die van huis uit multi-threaded waren... AMD is er echter achter gekomen dat veel applicaties helemaal niet zo multi-threaded zijn als MS had verwacht. De graphicsdriver multi-threaded maken onder DX10 is niet mogelijk, omdat de driver callbacks moet maken via de DX10 runtime naar de OS kernel. En deze callbacks gaan via de hoofd-thread. MS vond het namelijk niet nodig om een extra thread hiervoor aan te maken.
Omdat deze beperking dus niet via multi-threading op te lossen is, moet AMD hard werken om de CPU limitations weg te werken. Een van de manieren hoe ze dit hebben opgelost is een wachtrij via de drivers creeeren waarin commandbuffers onthouden worden als ook welke frames er gerendered moeten worden.
De driver zorgt er normaal gesproken dat in deze buffer tot 3 frames van te voren worden onthouden. Het operatingsystem (dus Vista) kan er voor zorgen dat applicaties (dus niet de drivers van AMD!) deze limiet ophogen naar maximaal 10. De graphicsdriver heeft hier dus weinig over te zeggen... dit is helemaal afhankelijk van het OS!
Microsoft heeft deze beperking ingebouwd omdat een bepaalde fabrikant van GPUs (niet AMD!) vaak meer frames in de wachtrij zette dan de applicaties aan konden, wat resulteerde in gigantische mouse-lag. Gamedevelopers hebben hierover geklaagd, dus bouwde MS de limiet in.
AMD maakt dus nu voornamelijk gebruik van AFR als loadbalancingsysteem. De drivers blijven dus de pre-renderlimiet van 3 frames houden, waardoor in sommige applicaties de vierde GPU weinig nut heeft... tenzij de applicatie toestemming heeft gegeven om meer dan 3 frames te renderen. Dit zie je bij sommige games want die schalen vrij goed mee met 4 GPUs (zie bv Call of Duty4 (DX9) en CoJ (DX10)). Voor de games die tegen de limiet aanlopen van maximaal 3 frames, bouwt ook AMD een alternatief in om toch gebruik te maken van de 4de GPU net zoals NV dat deed met hun Quad SLI. AMD is ook bezig met een combinatie van SFR met AFR voor deze gevallen. En... AMD is zelfs bezig met een nieuwe techniek... maar die is nog in ontwikkeling en zal misschien later dit jaar gebruikt worden.
Oh en voor de mensen die vinden dat AMD te weinig doet aan performanceboosts... Check deze slide eens:

Omdat de Catalyst drivers elke maand gereleased worden valt een boost minder snel op... vaak gaat het maandelijks een klein beetje omhoog (of omlaag). Neem je een paar maanden, dan tikt het soms toch nog best leuk aan.
Technical PR Officer @ MSI Europe. My thoughts and opinions may not reflect the ones of my employer.