Jeroenneman schreef op donderdag 14 april 2016 @ 10:49:
U vraagt, wij draaien:
You'll see from the minimum frame-rates that the GTX 750 Ti holds more of its performance than the R7 360, and that's because AMD's driver actually consumes quite a lot more CPU power than its Nvidia equivalent - something to be aware of at the budget end of the market.
http://www.eurogamer.net/...card-upgrade-guide?page=2
As we saw in Star Swarm and continue to see here, AMD’s DirectX 11 throughput is relatively poor, topping out at 1.1 draw calls for both DX11ST and DX11MT. AMD simply isn’t able to push much more than that many calls through their drivers, and without real support for DX11 multi-threading (e.g. DX11 Dirver Command Lists), they gain nothing from the DX11MT test.
But on the opposite side of the coin, this means they have the most to gain from DirectX 12.
http://www.anandtech.com/...i-overhead-feature-test/3
Uitleg over het specifieke gebruik van Command List en multi-threading in DX11.
http://forums.anandtech.c...p?p=31520674&postcount=28
Aangezien iedereen altijd loopt af te geven op Nvidia voor het niet supporten van Async Compute: AMD doet precies hetzelfde door nog steeds geen Command Lists te gebruiken binnen DX11. Maar in plaats van dat te fixen, heeft AMD gegokt op DX12.
Dat is prima te verdedigen, maar het is gewoon een feit dat Nvidia bij DX11 titels gewoon een efficientere methode gebruikt. Zodra DX12 mainstream is geworden, dan zal AMD pas echt voordeel hebben van een strategie die ze waarschijnlijk al meerdere jaren gepland hebben.
Jeroenneman schreef op donderdag 14 april 2016 @ 11:03:
Zie verhaal hierboven. Multi-threading had Nvidia al redelijk voor elkaar op DX11. Als je je load al hebt verspreid, dan is het enige wat nog uitmaakt, hoe snel de cores zijn. AMD had multi-threading onder DX11 minder onder de knie (zij het door keuzes, zij het door architectuur, zij het door drivers), en zien dus een boost zowel in threading, als in kloksnelheidincrease.
Het verhaal over MT klopt, maar dat is slechts 1 kant van het verhaal. Je gooit overhead en MT hier door elkaar; en begrijpt MT dan ook nog verkeerd. Kijk nog eens naar de charts van Anandtech. Let op hoe Nvidia dezelfde aantallen draw calls haalt op een 750 Ti, een 680 en een 980. Hier zouden bij jou gigantische alarmbellen moeten gaan rinkelen. D3D11MT kan inderdaad helpen en in het geval van Civ V is dat ook zo. Echter gebruikt vrijwel geen enkele game dit en heeft dit verder dus ook geen reet met Nvidia's betere performance in D3D11 in z'n algemeen te maken.
Laat ik even twee dingen voorop stellen:
- Nvidia heeft een veel betere D3D11 driver, dat ga ik niet ontkennen of weerleggen. Dat heeft echter niets, nada, niente, noppes, nichts, rien met D3D11MT te maken.
- Het maximaal mogelijke aantal drawcalls staat niet noodzakelijkerwijs gelijk aan performance
D3D11MT zit niet aan Nvidia's kant. Ja, Nvidia biedt een implementatie aan, maar als een game het niet implementeert, krijg je er dus ook geen performance winst uit. Waarom implementeren games het dan niet? Omdat het in de praktijk vreselijk irritant is om te gebruiken. Ondanks het feit dat het een gigantische managed API is met een overhead waar je U tegen zegt, is D3D11MT niet inherent thread safe. Dat vergt dus extra werk, tenzij je engine meteen al voor D3D11MT is gebouwd. Vervolgens heb je inderdaad leuk meerdere contexts, maar uiteindelijk gaat het alsnog door slechts een enkele core heen omdat D3D11 simpelweg niet daadwerkelijk multithreaded is. Het schaalt niet zoals het zou moeten. Vandaar ook dat je bij Nvidia slechts 15% meer draw calls ziet met MT. Je hebt nog steeds een CPU bottleneck die niet door een driver of een developer opgelost kan worden.
Civ V had veel baat bij D3D11MT omdat ze veel compute werk hadden. Dusdanig veel dat ze tegen een CPU limit aanliepen waardoor hun render werk niet eens op tijd bij de GPU kon komen, met als eind resultaat een lagere framerate. Civ V is echter ook één van heel weinig games die écht iets met compute shaders doen.
Op het gebied van MT is het grote verschil tussen D3D11 en D3D12 (en Mantle, en Vulkan) dat de laatste je niet alleen meerdere contexts (queues) laat bijhouden, maar dat deze die ook nog eens daadwerkelijk parallel verstuurt. Waar alle lists in 11 alsnog door slechts 1 thread verwerkt worden, is dat in 12 niet meer het geval. Dus zelfs op dit gebied doet 12 het beter dan 11 en zou je dus weldegelijk winst moeten zien met meerdere cores als de driver ze ook parallel verwerkt. En daarvan weten we dat Nvidia dat niet 100% doet; daar zit HyperQ eerst nog tussen.
En dit is ook meteen waarom Nvidia minder profijt heeft van meerdere cores: het gaat uiteindelijk allemaal door een enkele core heen in HyperQ. Waar AMD daadwerkelijk in principe tot wel 64 cores zou moeten kunnen gebruiken (ik vraag me nu dus af of dit ook daadwerkelijk zo is...iemand toevallig een E5-2699v4 om eens te zien of ze tot 22 kunnen komen?

) omdat hun queues in hardware zitten, is dat bij Nvidia niet het geval. HyperQ is daar de bottleneck.
Gebrek aan een MT implementatie is niet waardoor AMD het zo veel slechter doet in D3D11. Dat is de overhead. De overhead van D3D11 heeft ook met MT de grootste impact op het aantal draw calls dat je naar de GPU verstuurt krijgt. Deze overhead wil zeggen dat waar jij slechts 1 ding wil doen, D3D11 intern eerst 20 andere dingen doet en controleert voordat het bij de driver aan komt. Met andere woorden, alles wat je doet hangt eerst even een paar cycles in limbo. Je kunt alles ook op 10 verschillende manieren doen, waarbij het telkens net even iets anders bij de driver aan komt. De driver moet zich vervolgens ook conformeren aan D3D11, wat als gevolg heeft dat de drivers belachelijk groot zijn en deze ook zelf moeten uitvogelen wat D3D nou precies wil bereiken.
En dit is waar Nvidia het slim heeft aangepakt. Dit is waar Nvidia kortere wegen heeft gecreëerd. Hoe ze het precies doen durf ik je niet met zekerheid te zeggen, maar dit zit hoogstwaarschijnlijk in preemption. Het pad dat eender welke opdracht door de driver volgt is simpelweg een stuk korter bij Nvidia. AMD heeft meer een 1:1 aanpak gehanteerd; dat is de eenvoudigste (en dus goedkoopste) manier om conform met de specs te zijn.
Waarom heeft AMD hier dan niets aan gedaan? Kan van alles zijn. Het zal deels te maken hebben met een gebrek aan geld. Ze moeten ergens investeren en de software is dat lange tijd simpelweg niet geweest. Er is echter ook nog het verhaal van GCN. Tegen het eind van 2011 had AMD die win van Sony en MS al binnen aan de hand van hun GCN ontwerpen. En het zal niet lang (althans, in deze industrie

) hierna geweest zijn dat ze hebben gezien hoe belachelijk de overhead van D3D11 is en ze gestart zijn met het ontwikkelen van Mantle. Zeker niet de beste keuze als het op D3D11 performance aan komt, maar uiteindelijk heeft het wel goed uitgepakt.
En waarom zien we dan niet ook 10x meer performance, aangezien de draw call limieten zo veel hoger liggen? Omdat die benchmarks de simpelste drawcalls maken die mogelijk zijn. Het is nog veel synthethischer dan de grafische benchmarks van 3DMark. In de praktijk zul je die 15, 20, 30 miljoen nooit halen omdat je veel complexere constructies hebt. Daar zitten onder andere roundtrips tussen en drawcalls komen ook zelden in hun eentje voor. Dat zijn hele bendes. Vandaar dat AoS dus ook niet meteen 10x beter presteert.