AMD vs. Nvidia drivers: waar blijft de prestatiewinst van DirectX 12?

58 reacties
Inhoudsopgave
  1. 1. Inleiding
  2. 2. DirectX 11
  3. 3. Nvidia's (wonder)driver versus AMD's aanpak
  4. 4. DirectX 12 en Vulkan
  5. 5. Test
  6. 6. Resultaten API Overhead test
  7. 7. Resultaten games
  8. 8. Analyse
  9. 9. Conclusie
  10. 58 reacties

Nvidia's (wonder)driver versus AMD's aanpak

In de opkomst van DX11 voorzag Nvidia al dat de complexiteit van multithreading voor het afhandelen van draw calls veel ontwikkelaars zou ontmoedigen het te gaan gebruiken. Het bedrijf had de middelen om flink te investeren in een driver die voorgoed een voordeel in de DX11-race zou garanderen. Met driver v.270 werd in 2011 een briljant stuk zeer complexe software toegevoegd, dat het werk van het multithreaden van command lists uit de handen van de developers neemt en door middel van een software scheduler zelf verdeelt over meerdere threads.

De software scheduler van Nvidia’s driver zorgt er dus voor dat elk spel dat gebruik maakt van de DX11-api draw calls feitelijk multithreaded afhandelt als de ontwikkelaars daar zelf geen ondersteuning voor hebben ingebouwd. De primaire processorthread van DX11 wordt daarbij ontlast, omdat de draw calls over meerdere threads worden verdeeld. Omdat de software scheduler deze verdelingen moet regelen en hiervoor de processor gebruikt, is de driveroverhead van Nvidia strikt genomen dus wel wat hoger dan bij AMD, al wordt vaak het tegendeel beweerd. Door de software scheduler is de totale processorbelasting hoger dan zonder deze scheduler. Bij een groot aantal draw calls is dit echter geen enkel probleem, omdat er niet meer een enkele core geheel verzadigd (volledig belast) is, en zo de videokaart met Nvidia’s oplossing nog steeds van voldoende instructies kan worden voorzien.

AMD's aanpak

Bij AMD daarentegen kan de primaire processorthread van DX11 veel sneller verzadigd raken. Dit komt ten eerste omdat de draw calls allemaal op dezelfde, enkele thread worden afgehandeld en naar de hardware scheduler op de GCN-gpu wordt verstuurd. Dit betekent dat het maximum aantal draw calls dat de AMD-driver kan verwerken geheel afhankelijk is van de ipc (instructions per cycle) van een processor en de maximale kloksnelheid van een enkele core. Het wordt problematischer als de ontwikkelaar van een spel niet specifiek programmeert dat zaken als audio, input, physics en AI op een andere thread dan de primaire thread worden afgehandeld. In dat geval is de primaire thread al tijd kwijt om tevens deze zaken te berekenen, en blijft er minder tijd over om de AMD-gpu van instructies te voorzien.


AMD's GCN-gpu's hebben een hardwarematige scheduler aan boord die in de ideale situatie instructies van 64 threads tegelijkertijd kan verwerken, maar onder DX11 is dat slechts één thread.

Voor DX11 heeft AMD überhaupt nooit een driver met ondersteuning voor multithreading uitgebracht. Hiervoor zijn twee redenen. Ten eerste de GCN-architectuur, waarbij de hardware scheduler afhankelijk is van een constante stroom van draw calls en niet een al te grote buffer aan command lists kan bewaren. Ten tweede is de keuze van AMD destijds geweest om een nieuwe api (Mantle, wat uiteindelijk omgedoopt werd tot Vulkan) te ontwikkelen in plaats van de beperkingen van DX11 verder op te schuiven, zoals Nvidia heeft gedaan. De schaarse voorbeelden van DX11-games waarin ontwikkelaars hebben geprogrammeerd om draw calls te verdelen over meerdere threads draaien dus op Radeons nog altijd op een enkele thread.

Het voordeel van AMD’s aanpak is dat de DX11-driver vrij simpel blijft en er minder fout kan gaan in het renderen. Tegelijkertijd is dat ook het struikelblok: omdat er geen heftige ingrepen worden gedaan in het renderpad kan er beperkter worden geoptimaliseerd dan bij Nvidia het geval is. Het grotere aantal rekenkernen op een AMD-kaart (shader processors) biedt op papier meer rekenkracht, maar een Nvidia-kaart met minder rekenkernen (CUDA cores) weet in de praktijk op conventionele api’s (DX11 en OpenGL) vergelijkbare prestaties te bieden.

Advertentie
0

Hardware Info maakt gebruik van cookies

Hardware Info plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Hardware Info relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie.

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Hardware Info contextuele advertenties te tonen op basis van pagina's die je hebt bezocht.

    janee

    Hardware Info genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Hardware Info gevolgd worden. Deze data wordt maximaal 2 weken bewaard. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden.

    janee