Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 326 reacties
Submitter: stresskiller

AMD heeft een bŤtaversie van Catalyst 14.1 uitgebracht waarin voor de eerste maal ondersteuning is opgenomen voor zijn Mantle-api. Het alternatief voor Direct3D en OpenGL moet betere prestaties bieden in 3d-games.

AMD MantleMantle is beschikbaar voor AMD-gpu's op basis van de Graphics Core Next-architectuur. In ondersteunde games vervangt Mantle het minder efficiënte DirectX of OpenGL. Mantle zorgt volgens AMD voor minder overhead op de cpu en zal zo minder snel een bottleneck vormen voor de gpu. Doordat ontwikkelaars volledige toegang tot de mogelijkheden van de gpu krijgen wordt het eveneens gemakkelijker om op een recente Radeon-videokaart het onderste uit de kan te halen.

Met de bèta van Catalyst 14.1 heeft AMD met de nodige vertraging de eerste driverversie uitgebracht die Mantle voor de pc-gamer toegankelijk maakt. Desondanks zijn er nog weinig games die Mantle benutten, al heeft EA vorige week een Mantle-patch voor Battlefield 4 uitgebracht. Ook de benchmark Star Swarm is aangepast voor AMD's nieuwe api.

De snelheidswinst die Mantle volgens AMD mogelijk maakt, lijken in de praktijk gehaald te kunnen worden. Zo zijn in benchmarks van Legitreviews met een Sapphire Radeon R7 260X significant betere prestaties te zien in Battefield 4 en Star Swarm. Zodra meer games Mantle gaan ondersteunen wordt het duidelijker welke snelheidswinst gemiddeld verwacht mag worden.

Moderatie-faq Wijzig weergave

Reacties (326)

Wat ik niet zo snap is dat Mantle effectiever is dan bijv. DirectX of OpenGL. Zijn die technieken dan zo bloated? Die zijn toch ook geoptimaliseerd voor performance? En moeten developers nu niet al de hogere abstractielagen van bijv. DirectX zelf nog eens gaan implementeren in hun engine om zo Mantle te kunnen gebruiken? T lijkt me dan voornamelijk interessant voor grote enginebouwers, en niet voor de gemiddelde dev.

[Reactie gewijzigd door - peter - op 2 februari 2014 15:21]

Er zijn een aantal redenen dat we zo blij zijn met Mantle en daarom moet je eigenlijk iets meer weten over hoe DirectX werkt. Under the hood bouwt DirectX een platform agnostische command-buffer op. Dat is een buffer met alle render commandos "clear depth buffer. set pixel shader" etc. Die cmdbuf word periodiek gesubmit naar de driver - en die driver vertaalt het dan weer naar een platform specifieke cmd buffer.

Dit zorgt voor een aantal restricties, zoals het gebrek aan parallelle submits zijn met DirectX niet mogelijk. Er zijn in die richting wel ontwikkelingen gedaan, bijvoorbeeld met Deferred Contexts. Maar door verschillende redenen is dat een enorme flop gebreken. Zo kunnen we op 4 threads tegelijk commandos submitten ipv op 1 thread. En mantle heeft geen dure driver thread nodig om de vertaalslag te doen.

Verder heeft Mantle een aantal andere concepten om het aantal commandos wat in de cmdbuffer word gesubmit te verkleinen door bijvoorbeeld Pipeline Objects te hebben. Dat zijn objecten die alle shading stages (waar normaal aparte vertex, pixel en andere shaders voor gebruikt worden) als een object te behandelen. Er zijn 0 legacy concepten in de API dus niets hoeft "sub optimaal" en alles kan netje met descriptor sets gebind worden.

Daar naast hebben we nog memory management, op het moment bieden beide APIs daar vrij weinig ondersteuning voor. Dus moet alles in de driver gepooled en gerenamed worden om zo het geheugengebruik acceptabel en efficient te houden. In Mantle kunnen we gewoon geheugen in blokken alloceren en zo zelf bepalen wat er in welk type geheugen komt te staan (en met welke prioriteit - voor WDDM).

Verder zitten er wel meer leuke dingen in, zo kunnen we resources aliassen, hebben we zelf controle over de shader compiler, etc etc.

Mantle is inderdaad vooralsnog een tool voor "de grote jongens", engines die de performance enorm nodig hebben. De gemiddelde dev zal er niet zo veel aan hebben en kan waarschijnlijk net zo goed wachtten tot de gangbare APIs dergelijke concepten ondersteunen.
Toch zie ik nog een groot nadeel: compatibiliteit. Je hebt een recente AMD/ATI kaart nodig om dit te kunnen gebruiken. Dus een developer moet dan ook hiervoor ondersteuning inbouwen waardoor het project gewoon ingewikkelder wordt. En dat alleen voor andere FPS-waarden.
in PrisonerOfPain's profiel staat dat hij aan de frostbite engine werkt en zou dus moeten weten waar hij het over heeft. elders zegt hij al dat de mantle APU heel generiek is gehouden.
dat zou betekenen dat nvidia zijn eigen mantle drivers zou moeten kunnen schrijven voor hun eigen kaarten.
Implementeren van Mantle is niet veel moeilijker dan directX. De extra kosten voor ondersteuning van mantle kun je veelal terugverdienen door de kortere doorlooptijd van je optimalisatie en het bereik dat je game heeft op de markt door de lagere eisen die je kunt stellen.

Het probleem met DX en openGL is dat ze een framework hebben dat je altijd door moet voor alles wat je wil doen. Een deel is soms gewoon overbodig, vooral als je reeds gebruikte resources hergebruikt.

Het gaat er vaak niet om dat DX of OpenGL niet performancegericht zijn, ze zijn niet flexibel wanneer je meer van hetzelfde wil doen. In dat geval wordt nodeloos de CPU belast terwijl het ook gewoon direct op de GPUt opgelost had kunnen worden.
Nou het is iets waar je als non software engineer gepecialiseerd in realtime rendering gewoon de vak kennis mist. In dat geval kan je gissen.

Mantle is gericht op GCN.
DirectX en OpenGL op veel oudere hardware.

Mijn 5870 werkt fijn met DX. Mantle doet daar niks mee.

Kijk dat is de kracht van openGL en Direct3D.

De kracht van mantle lijkt mij meer dat ze alle legacy support overboard gooien. En nu een API technische implementatie specifiek vanaf de latere generatie architectuur richten.

Dat scheeld nogal wat performance beperkingen. En je krijgt een meer efficentere API die geen last heeft van beperkingen voor support voor oude architectuur en bijbehorende beperking.

Maar er kleeft ook nadeel aan. Legacy hardware wordt niet ondersteund. Maar gelukkig dat er DX en opengl is om op terug te vallen.
Mijn 5870 werkt fijn met DX. Mantle doet daar niks mee.

Kijk dat is de kracht van openGL en Direct3D.
backwards compatability is natuurlijk heel fijn maar openGL en directX zijn 2 decennia geleden gemaakt en toen gemaakt in een hele andere hardware markt.

ze gaan veel te ver in het behoudt van backward compatability.

direct X doet dingen die toen belangrijk waren maar die er nu helemaal niet meer toe doen. heel veel van de hardware werkt nu op de zelfde manier als die van de concurrenten. ze gebruiken allemaal de zelfde data structuren (bijvoorbeeld een floating point ziet er bitsgewijs op alle gpu's het zelfde uit nu) maar direct X checkt dat nog steeds elke keer ect.

veel van die dingen hadden ze 10 jaar geleden al kunnen laten vallen eigenlijk maar dat is nooit gebeurt.

mantle gaat wat ver in het breken met de backward compatability misschien, een extra generatie ondersteuning had ik graag gezien... (en zou ook best kunnen met de juiste drivers heb ik het idee aangezien ze ook zeggen dan kaarten van andere fabrikanten tot de mogelijkheden behoren) maar het is in ieder geval een mooie schop onder de kont van MS om met iets nieuws te komen en weer eens echt aan het werkt te gaan met directX (net als FF dat deed met IE, dat nu weer bruikbaar is geworden mocht je het willen gebruiken)

[Reactie gewijzigd door Countess op 2 februari 2014 18:31]

backwards compatability is natuurlijk heel fijn maar openGL en directX zijn 2 decennia geleden gemaakt en toen gemaakt in een hele andere hardware markt.

ze gaan veel te ver in het behoudt van backward compatability.
Klok-en-klepel.
D3D is een aantal keren compleet op de schop gegaan, inclusief het onderliggende drivermodel.
D3D11 heeft op geen enkele manier te maken met de vroege D3D-versies uit midden jaren 90. Zowel de API zelf als de driver lijken er in de verste verte niet meer op.

D3D is strikt gezien ook helemaal niet backwards-compatible. Iedere major update van D3D is een compleet nieuwe set objecten, die naast de oudere APIs draaien.

De rest van je verhaal is dus compleet gebaseerd op foute aannamen en gebrek aan kennis van jouw kant, en raakt kant noch wal.
Er zijn zat dingen die anders onder DirectX nog geemuleerd worden waar de hardware al geen specifieke code-paths meer voor heeft. Een hoop van de fixed function meuk word tegenwoordig gewoon behind the scenes met compute gedaan.
Er zijn zat dingen die anders onder DirectX nog geemuleerd worden waar de hardware al geen specifieke code-paths meer voor heeft. Een hoop van de fixed function meuk word tegenwoordig gewoon behind the scenes met compute gedaan.
DX is dan ook een graphics API. Het beschrijft niet hoe de functionaliteit geimplementeerd dient te worden.
Al in het DX9-tijdperk was oa Intel al bezig om dingen als polygon clipping via shaders te doen.
Mijn punt is: de APIs lopen achter op de hardware die er op de markt is (wat raar is aangezien die hardware al 4+ jaar in ontwikkeling is voor het uberhaupt op de markt komt).

Vervolgens zitten de API makers op nieuwe hardware dus oude dingen te emuleren terwijl er veel betere manieren voor zouden kunnen zijn. Het punt van mantle is om die emulatie weg te halen omdat in die gevallen de driver aan het gokken is wat de bedoeling van bepaalde acties moet zijn.

Door die controle terug te geven aan de applicatie schrijver is het mogelijk om bepaalde dingen efficienter te doen.
Nou een 5870 non GCN loopt nog niet zo ver achter. Maar valt wel buiten de mantle support.

Een ouwe 3DFX kaart waar de CPU nog de T&L moet doen. Ja dat is verleden tijd. of de i740

DX10 kan je zien als grote revisie. Dus alles vanaf G80 en R600 is ook wel oud, maar nog vanniet al te ver verleden. De high-end van toen valt nu onder budged.

GCN is DX11.x architektuur en heeft nu dus zijn Eigen specifieke API. Dat is leuk maar de breede zin in mainstream gamers met AMD gpu heeft nog geen GCN type.

Dus de API lopen niet achter maar mantle loopt vooruit. Als over enkele Jaren elke 3 jaar oude AMD GPU powerd PC the van het soort GCN is. Dan zullen dev's het ook veel gretiger supporten.

Ik heb er dus nu total niks aan. Mijn Game PC trekken nog steed elke game redelijk. Maar ja 5870
een mantle implementatie voor oudere kaarten is niet onmogelijk. AMD heeft er echter niet de drivers voor gemaakt. dat is dus niet rechtstreeks de schuld van de API.
Vervolgens zitten de API makers op nieuwe hardware dus oude dingen te emuleren terwijl er veel betere manieren voor zouden kunnen zijn. Het punt van mantle is om die emulatie weg te halen omdat in die gevallen de driver aan het gokken is wat de bedoeling van bepaalde acties moet zijn.
Vind ik overdreven simplistisch geredeneerd, sorry hoor.
Bij zoiets als polygon clipping maakt het helemaal niks uit of het met fixed hardware gedaan wordt, of met een shader.

Net als de hele fixedfunction pipeline. Die wordt al vele jaren compleet door shaders geimplementeerd in de drivers, en dat werkt prima.
Er valt voor een developer weinig eer aan te behalen om dat zelf te gaan implementeren.

Pas als je iets anders wil doen, wordt het interessant. Maar daar staat Mantle ook niet echt voor open. Het is nog steeds voornamelijk een graphics-API, en niet een compleet 'shader framework', dat meer de GPGPU-kant op gaat, waar je een complete 'software'-renderer mee kunt implementeren (wat via CUDA, OpenCL of DirectCompute ook zou kunnen, evt gecombineerd met D3D/OGL code).
Ok. Hoe bepaalt een API of 'ie een slow-clear moet doen, of z'n fast-path moet gebruiken? Of hoe bepaal je nu als application developer welke state transitions je textures moeten ondergaan (is het een render target of een shader resource of is het iets anders)?

Nu gaat er redelijk wat CPU tijd in zitten om de commandbuffer die een applicatie genereert te analyseren om die op te patchen en er iets efficienters van te maken (in D3D). In Mantle hoeft dat dus niet meer.

Verder is het mogelijk om resources te aliassen en dat is iets wat je driver zo 1, 2, 3 niet voor je gaat doen. Als applicatie developer kun je zeggen "deze render targets heb ik niet nodig tijdens een loading screen dus alias die maar met de video rendertarget" of "deze textures wil ik als RGBA8 samplen in de ene shader en als L8 in de andere", of "nu wil ik bij de hierarchical depth buffer kunnen".

Dat zijn allemaal dingen die nu door driver developers worden bepaald (als ze er tijd en zin in hebben). Terwijl application developers dat soort trade-offs veel beter zelf kunnen maken.
Ok. Hoe bepaalt een API of 'ie een slow-clear moet doen, of z'n fast-path moet gebruiken?
Heb je het nu over het clearen van een buffer? Is dat nou echt heel relevant?
De performance van een moderne game hangt af van hoe snel je een buffer kunt clearen?
Of hoe bepaal je nu als application developer welke state transitions je textures moeten ondergaan (is het een render target of een shader resource of is het iets anders)?
...
Verder is het mogelijk om resources te aliassen en dat is iets wat je driver zo 1, 2, 3 niet voor je gaat doen. Als applicatie developer kun je zeggen "deze render targets heb ik niet nodig tijdens een loading screen dus alias die maar met de video rendertarget" of "deze textures wil ik als RGBA8 samplen in de ene shader en als L8 in de andere", of "nu wil ik bij de hierarchical depth buffer kunnen".
Wel eens gehoord van views? Uberhaupt al eens een modernere versie van D3D dan 9 van dichtbij gezien?
Heb je het nu over het clearen van een buffer? Is dat nou echt heel relevant?
De performance van een moderne game hangt af van hoe snel je een buffer kunt clearen?
Ja, een slow-clear kan tussen de 0.1 en 0.3ms kosten op een fullscreen rendertarget - dat wil je niet als je maar 16ms hebt.
Wel eens gehoord van views? Uberhaupt al eens een modernere versie van D3D dan 9 van dichtbij gezien?
Resource view hebben hun voor en nadelen - maar er zijn nog genoeg dingen die ze niet kunnen. En kijk voor de grap eens naar m'n profiel ;)
Kun je mij uitleggen waarom mantle maar 4 job threads maximaal
heeft op een 6 core of meer cpu?
johan wil hier geen antwoord op geven en roy van amd reageert ook
niet op die vraag.
"Kun je mij uitleggen waarom mantle maar 4 job threads maximaal
heeft op een 6 core of meer cpu?"

Mischien omdat die API nog volop in ontwikkeling is?
De api is klaar, de ontwikkeling die amd nu nog doet is de driver
optimaliseren.
Als mantle niet meer dan 4 job threads kan gebruiken heb je niets aan mantle op high end systemen.
Als die 4 threads de GPU bij kunnen benen dan lijkt me niks aan de hand.
Hoezo kan je de andere cores niet vullen met non-mantle threads?
Wat ik heb begrepen was dat mantle zelf maar heel weinig cpu tijd opslokt en dat je daarbij nog andere taken kunt doen.
Ja, want dat is wel 0.6-1.9% van de totale frametijd! Wat een drama!
En dat maal X voor alle gebruikte temporary buffers (MRT's, shadowmaps, etc.). Het is een serieus probleem in menig game wat je niet kunt bagetelliseren, ook op de consoles.

[Reactie gewijzigd door .oisyn op 3 februari 2014 15:13]

Blijkbaar levert alles bij elkaar zo'n 8% op in BF4. Dus die buffers zijn <= 8% van de totale frametijd.
Ik vind dat jullie het allemaal veel belangrijker maken dan het is.
Bedankt voor de hint. Veel objectiviteit kan ik van jou niet verwachten!
wow....

serieus? deze gast werkt rechtstreeks met frostbite en mantle maar omdat hij het niet met jouw eens is moet hij wel bevooroordeeld zijn? want jouw mening moet de juiste zijn ondanks dat je in vergelijking met hem niks van mantle af weet?

ja, zijn objectiviteit is het probleem....
Ik persoonlijk denk dat we het nog allemaal moeten afwachten, Mantle heeft veel potentie en zal zeker nog geoptimaliseerd moeten worden voor diverse hardware. We kunnen pas over een jaar of 2 zeggen dat nu beter of efficiŽnter. Momenteel heeft nog niemand de ware kracht/efficiŽntie van mantle kunnen zien/ervaren
valt op he, dat hij nu ineens heel actief op tweakers zit te posten... Johan Andersson is ook al op verschillende fora gesignaleerd...)
Wat een onzin, PrisonerOfPain post al jaren op tweakers.net, ik kende 'm al via de forums nog voordat hij bij Nixxes stage kwam lopen (jaja je verzint 't niet). Ik stel voor dat jij een keer die conspiracy-theory attitude dropt en gewoon leest wat er staat ipv er meteen vanalles achter te zoeken. Op het moment dat het te heet onder je voeten wordt ga je dingen verdraaien en speel je de WC-eend kaart.

[Reactie gewijzigd door .oisyn op 3 februari 2014 15:08]

Wat er staat is een aantal foute claims over D3D
Ik zie ze niet. Wat ik vooral zie, en dat is vrijwel identiek aan onze discussie van laatst, is dat iemand beweert dat je met Mantle iets kan doen dat niet met D3D kan maar wat wel lijkt op een feature van D3D, waardoor jij er vervolgens keikhard op ingaat door te stellen dat het allemaal maar onzin is en dat D3D het ook kan. Maar punt blijft dat jij niet exact weet wat Mantle wel kan en dat zowel PrisonerOfPain als ik dmv NDA's daar niet heel erg veel dieper over uit kunnen wijden (die fout heb ik al eens eerder gemaakt en ben niet van plan dat nog een keer te doen). Je wil blijkbaar niet van ons aannemen dat het anders is, en dat is je goed recht, maar dan stopt de discussie daar dan ook. En dat ziet er dan van buitenaf wellicht uit als zwaktebod maar I couldn't care less eerlijk gezegd. Ik zit hier niet om mensen eruit te lullen.

[Reactie gewijzigd door .oisyn op 3 februari 2014 15:43]

Je kan er anders niet omheen dat je wel erg hard in de verdediging schiet, en mijns inziens lijken veel reacties zelfs op dat je in je persoon aangevallen voelt.
En om eerlijk te zijn is het ook een typisch geval van 'de pot verwijt de ketel'; je claimt dat DX zwart gemaakt wordt, maar Mantle geef je niet eens een kans om zich te bewijzen ;) Het is pas een beta.
Gezien je aan de 6e generatie van een engine werkt neem ik aan dat je weet wat een beta is. Behandel het dan ook zo, en niet als een volwassen product.

Verder blijft het een kwestie van afwachten welke resultaten er in de final zullen worden geboekt. Persoonlijk ben ik er erg benieuwd naar, ook al kan ik er niks mee omdat al mijn devices (desktop, gaming laptop) nVidia kaarten bevatten. Het is gewoon interessant om te zien dat er gewerkt wordt aan een API waar de hardware 'echt' tot zijn recht komt, zonder allerlei legacy problemen en onnodige compatibiliteit. Daar zijn al API's voor.

@.oisyn, PrisonerOfPain
Helaas dat jullie er niet meer over kwijt kunnen, lijkt me erg interessant en zou waarschijnlijk ook een heleboel onnodige discussies etc. schelen!
Lijkt me overigens wel tof als er ook support zou komen voor nVidia kaarten, dan heb ik mijn GTX 770 niet voor niks gekocht :D
Gezien je aan de 6e generatie van een engine werkt neem ik aan dat je weet wat een beta is.
Beta is de status waarin de software vrijwel in de uiteindelijke staat is qua functionaliteit, maar waarbij er nog getest wordt op dingen als de stabiliteit en correctheid: http://en.wikipedia.org/w...e_release_life_cycle#Beta
Behandel het dan ook zo, en niet als een volwassen product.
Dat doe ik dus.
In dit geval is de 'feature' van Mantle dus dat het de performance verhoogt, dus is het nogal onlogisch dat men het als beta zou bestempelen als het niet goed zit met de performance. En het is al helemaal vreemd als ze het dan een open beta maken, en aan de pers beschikbaar stellen.
Dat doen ze natuurlijk pas als het goed zit met de performance, dus ik verwacht niet heel veel verbetering meer.
Het is gewoon interessant om te zien dat er gewerkt wordt aan een API waar de hardware 'echt' tot zijn recht komt, zonder allerlei legacy problemen en onnodige compatibiliteit.
Daar zijn al consoles voor.

[Reactie gewijzigd door Scalibq op 10 februari 2014 00:36]

Hoe vaak kom je software tegen waar er, ondanks dat het een feature is, de performance nog niet optimaal is? ;)
In dit geval hebben ze geoptimaliseerd voor de 260X en 290, waar ik persoonlijk het verschil in FPS in een aantal situaties best behoorlijk vind. De increase van 45% die ze hebben behaald in de demo met BF4 zal lang niet overal gehaald worden, maar is toch best indrukwekkend.

Voor de 260X en 290 zal er misschien niet veel meer geoptimaliseerd (kunnen) worden, maar ik ben toch benieuws naar de prestaties bij de overige series die genoemd worden.
Daar zijn al consoles voor.
Waar je ook gelijk 6 jaar lang vast zit aan beperkte hardware en aan de grillen van een bepaalde leverancier, wat er tevens voor zorgt dat de gehele gaming branche met oude meuk blijft zitten. DX9 had al lang uitgefaseerd kunnen zijn, maar de XDoos 360 kan geen DX10 aan.
Zo'n Xbox of PS is leuk, maar hoe je het ook wendt of keert, de PC blijft veruit superieur op gafisch gebied. Juist daarom vind ik het interessant dat er ook hiervoor eens een nieuwe API geschreven wordt waar DX zich weer aan op kan trekken.
Het sterke punt aan DX blijft toch dat het met alle kaarten compatible is.

Het is een beetje IE6 all over again, alleen dan met DirectX.
In dit geval hebben ze geoptimaliseerd voor de 260X en 290, waar ik persoonlijk het verschil in FPS in een aantal situaties best behoorlijk vind. De increase van 45% die ze hebben behaald in de demo met BF4 zal lang niet overal gehaald worden, maar is toch best indrukwekkend.
Maar dat zegt dus meer over de slechte kwaliteit van AMD's D3D-implementatie dan over D3D zelf: http://techreport.com/rev...rmance-in-battlefield-4/2
Op de A10-7850K ga je met de R290X van 69 fps naar 110 fps -> 59%
Diezelfde A10-7850K haalt met een 780Ti 93 fps, en de stap naar 110 fps is dan maar 18%.
En dan hebben we het dus over extreme CPU-limited situaties. Met een iets snellere CPU en/of iets tragere GPU is het verschil verwaarloosbaar.
Juist daarom vind ik het interessant dat er ook hiervoor eens een nieuwe API geschreven wordt waar DX zich weer aan op kan trekken.
Behalve dan dat dat dus niet zo is.
Het sterke punt aan DX blijft toch dat het met alle kaarten compatible is.
En dat is dus de reden dat het iets zwaarder voor de CPU is... En dus een directe vergelijking met Mantle sowieso nutteloos is. Appels en peren.
Het is een beetje IE6 all over again, alleen dan met DirectX.
Niet bepaald.

[Reactie gewijzigd door Scalibq op 11 februari 2014 15:11]

Op de A10-7850K ga je met de R290X van 69 fps naar 110 fps -> 59%
Diezelfde A10-7850K haalt met een 780Ti 93 fps, en de stap naar 110 fps is dan maar 18%.
Alleen is de concurrent (nVidia) in deze vergelijking totaal niet relevant. Mantle draait immers niet om een performance gain tegenover nVidia kaarten, maar tegenover de performance van exact dezelfde kaart zůnder Mantle.
Behalve dan dat dat dus niet zo is.
Want DX is de 'Heilige Graal' voor game engines en kan niet verbeterd worden? En DX draait al zo efficiŽnt mogelijk?
Ik weet niet hoe Mantle er van binnen uit ziet, maar er zullen concepten zijn die daar nu worden toegepast waar ook DX bij gebaat is en ik hoop dat Microsoft dat inziet en die toe gaat passen om ook DirectX efficiŽnter te maken.
Niet bepaald.
De technologie wordt standaard met Windows meegeleverd, is marktleider, bevat veel backward compatibility waardoor de efficiŽntie er onder lijdt, er wordt gevraagd om functionaliteit die niet geboden wordt en er is zeer weinig echte concurrentie.
Situatie die bekend voorkomt? :)
En ik zeg ook niet dat het exact is zoals met IE6, maar wel een beetje ;)
Alleen is de concurrent (nVidia) in deze vergelijking totaal niet relevant. Mantle draait immers niet om een performance gain tegenover nVidia kaarten, maar tegenover de performance van exact dezelfde kaart zůnder Mantle.
Nee, dat vind ik dus niet. nVidia is HEEL relevant. Mantle zou een meerwaarde moeten zijn voor AMD. Als je nVidia erbuiten laat, kun je dus niet goed bepalen wat de meerwaarde van Mantle precies is.
Deze tests geven aan dat nVidia's kaarten onder D3D een stuk minder CPU-overhead lijken te hebben dan AMD. Dat is iets dat ik graag nader onderzocht zou zien.
Want dan slaat de balans ineens compleet om: Dan is AMD dus een slechtere keuze bij een low-end CPU voor alle games die geen Mantle ondersteunen.
Want DX is de 'Heilige Graal' voor game engines en kan niet verbeterd worden? En DX draait al zo efficiŽnt mogelijk?
Dat zeg ik niet, maar Mantle is niet bepaald een revolutie tov D3D. Zowel qua functionaliteit als qua performance vind ik het allemaal niet bijster spannend.
Ik weet niet hoe Mantle er van binnen uit ziet, maar er zullen concepten zijn die daar nu worden toegepast waar ook DX bij gebaat is en ik hoop dat Microsoft dat inziet en die toe gaat passen om ook DirectX efficiŽnter te maken.
Voor een deel is het ook zo dat D3D al lang nieuwe concepten ondersteunt om efficienter te zijn, die AMD niet, of niet goed geimplementeerd heeft. Zoek voor de grap eens op Driver Command Lists (http://www.anandtech.com/...-radeon-hd-7970-review/24)
Daarom geeft D3D vs Mantle dus een vertekend beeld op AMD hardware, en zie je dus dat nVidia sneller is met D3D.

Kortom, als je je eens ECHT zou verdiepen in wat D3D is, en wat het kan, en niet alleen naar AMD zou luisteren, zou je inzien dat Mantle echt niet zo spectaculair is als dat AMD beweert. D3D11 kan echt een hoop, maar je moet natuurlijk wel goede drivers schrijven. Met een eigen API komen is een beetje onzin.

Sowieso, waarom moest het per se een eigen API worden? Hadden ze erop gegokt dat Sony en MS zouden aanhaken? Wat nVidia doet, lijkt me veel logischer: OpenGL ondersteunt extensies, dus nVidia voegt gewoon allerlei extensies toe om de CPU-overhead te verlagen, op een manier vergelijkbaar met Mantle: http://www.slideshare.net/CassEveritt/beyond-porting
De technologie wordt standaard met Windows meegeleverd, is marktleider, bevat veel backward compatibility waardoor de efficiŽntie er onder lijdt, er wordt gevraagd om functionaliteit die niet geboden wordt en er is zeer weinig echte concurrentie.
Dat is het sterk gekleurde beeld dat AMD je voorspiegelt. Heeft weinig met de realiteit te maken.

[Reactie gewijzigd door Scalibq op 11 februari 2014 17:36]

Dat je met nieuwe toy speelt zegt nog niks over de high-end-heid, dacht ik zo.
Ik heb op alle platformen high end en low end engines gezien.

Anyway, je suggereert dat je dus op een console aan het developen bent, waarschijnlijk (gezien je religieuze houding tegenover DX) de xbone.
Mantle is vooral bedacht om een aantal problemen op PC's aan te pakken. Andere wereld.
"Jullie AMD fanboys denken zo krom, "

Ik ben geen AMD fanboy, ik ben agnostisch.
Maar ik ben erg voor nog slankere API's en vind het dus ook jammer dat Microsoft zich hier nioet meer op focust.

Ja, religieuze houding omdat je erg hard aan het verdedigen bent met veel emotionele argumenten. Dat ken ik vooral van mensen die hun religie aan het verdedigen zijn.
"anders zou je mij niet zo krampachtig in het niet-AMD-hokje zitten duwen."

Dat doe je toch echt zelf.
Het voornaamste dat je in dit topic te zeggen hebt is dat Mantle geen enkel voordeel heeft en dat DX alles al kan.

Verder had je het over gen 6 en dat is typisch een console term.

Lijkt me dan niet zo gek om te denken dat je xbox programmeert.

Ja, heb zelf wel geprutst met D3D en GL. Qua shaders alleen GLSL gedaan. Niks baanbrekends ofzo.
D3D is een aantal keren compleet op de schop gegaan, inclusief het onderliggende drivermodel.
D3D11 heeft op geen enkele manier te maken met de vroege D3D-versies uit midden jaren 90. Zowel de API zelf als de driver lijken er in de verste verte niet meer op.
je gaat er VEEL te gemakkelijk overheen wat directX nog allemaal te veel doet. je kan hoog en laag springen maar wat ik noemde is gewoon direct gezegd door bijvoorbeeld de oxide games developes. de mensen van oxide gaan al een tijdje mee en zullen vast beter weten waar ze het over hebben als jij. (even als PrisonerOfPain die dus werkt aan de frostbite engine en het ook niet met je eens is)

en zelfs als wat je zegt waar zou zijn dan bewijst dan alleen maar meer dat ze bij microsoft een enorme shop onder hun kont nodig hebben! want ze hebben dus voor geen METER geluisterd naar wat developers willen ondanks dat ze toch al 2 keer met een schone lei konden beginnen volgens jouw.

bewijst alleen maar meer hoe hard mantle nodig is, al is het maar om te laten zien dat het beter kan.

[Reactie gewijzigd door Countess op 2 februari 2014 22:09]

wat ik noemde is gewoon direct gezegd door bijvoorbeeld de oxide games developes
En dat slik jij allemaal voor zoete koek, terwijl het allemaal zwaar aangedikte marketing-leuter is. Oxide is natuurlijk verre van objectief.
de mensen van oxide gaan al een tijdje mee en zullen vast beter weten waar ze het over hebben als jij.
Als ik ze moet beoordelen op de kwaliteit van hun D3D-code, dan nee, dan kunnen ze van mij nog het een en ander leren.
en zelfs als wat je zegt waar zou zijn dan bewijst dan alleen maar meer dat ze bij microsoft een enorme shop onder hun kont nodig hebben want ze hebben dus voor geen METER geluisterd naar wat developers willen ondanks dat ze toch al 2 keer met een schone lei konden beginnen volgens jouw.
Het is eerder andersom: ondanks de verbeteringen die MS heeft toegevoegd, is de performance niet zo veel verbeterd, vooral omdat de CPUs veel sneller zijn geworden, en het problem dus minder belangrijk is. Dat zie je nu ook met Mantle: op papier is het veel beter, maar op een high-end systeem heb je in de praktijk 8% winst. Niet echt om over naar huis te schrijven.
Wel om over naar huis te schrijven, als je tegelijkertijd minder cpu belasting hebt! Snap niet dat iedereen hier maar steeds aan voorbij gaat en enkel en alleen naar de FPS kijkt (of iig over praat).

-Minder cpu-belasting == meer cpu power voor multitasking
-Of: gewoon een zuiniger systeem
-OF: gamedevs hebben meer cpu-power tot hun beschiking en kunnen daar weer andere leuke dingen mee doen.
Dat zie je nu ook met Mantle: op papier is het veel beter, maar op een high-end systeem heb je in de praktijk 8% winst. Niet echt om over naar huis te schrijven.
en op midrange system heb je dikke winsten. dan is het toch OVERDUIDELIJK dat directX VEEL TE VEEL WERK aan het doen is dat NIET noodzakelijk is om goed beeld op het scherm te zetten.

dat een high end systeem dat VERBERGT doet toch niks af aan het feit dat dat zo is!
Als ik ze moet beoordelen op de kwaliteit van hun D3D-code, dan nee, dan kunnen ze van mij nog het een en ander leren.
ooow natuurlijk. jij weet het beter als deze mensen,

net als dat je beter weet wat mantle is als de frostbite developer die er mee heeft gewerkt, waar je eerder mee in discussie was?
En dat slik jij allemaal voor zoete koek, terwijl het allemaal zwaar aangedikte marketing-leuter is. Oxide is natuurlijk verre van objectief.
serieus? jij gaat hier complot theorieŽn opgooien? hoe paranoia anti-amd ben jij inmiddels?

waar ben je zo bang voor precies?

[Reactie gewijzigd door Countess op 2 februari 2014 22:33]

en op midrange system heb je dikke winsten.
Juist niet. Alleen met high-end GPUs, en dan liefst een zo traag mogelijke CPU.
We weten allemaal dat de gemiddelde computer juist het omgekeerde is: relatief snelle CPU, en iGPU of low-end GPU.
lol werk jij in een hardware winkel? Nee dus .... kan je wel vertellen als iemand die WEL in een hardware winkel werkt dat het eerste dat mensen verbeteren hun GPU is en niet hun CPU ... je ziet dus eerder FX 6350 en een R9-290 of een I5-Ivy met een R9 280X dan een I7 met een GTX 640 of GTX 760 .... seriously ga je weer met je onzin .... Mensen doen VEEL eerder een GPU upgrade dan een CPU upgrade omdat de meeste mensen niets hebben aan een quad, hexa of een 8 core. Dus draaien ze op 2 (core duo's nog genoeg gezien incombo met nieuwere kaarten) - max 6 (in geval van een FX6350). Dus helaas weer pech voor je gemiddelde PC is dus budget-midrange CPU met over het algemeen midrange- highrange GPU -_-
kan je wel vertellen als iemand die WEL in een hardware winkel werkt dat het eerste dat mensen verbeteren hun GPU is en niet hun CPU
Uhhh... Mensen die uberhaupt naar dat soort winkels gaan, zijn al enorm in de minderheid. De meesten kopen gewoon kant-en-klare PCs bij de Media Markt, of bestellen ze ergens online (HP/Compaq/Dell/Lenovo etc).
Mensen die dan nog eens hun PC upgraden ipv een compleet nieuwe te kopen, zijn nog VEEL MEER in de minderheid.

Wat jij vertelt is dus onzin. Het is wel degelijk een feit dat de gemiddelde PC een relatief zwakke GPU heeft. Zo bouwen die merken (HP/Compaq/Dell/Lenovo etc) hun PCs nou eenmaal, omdat, zoals ik al zei, op de GPU meer te besparen valt (en een snelle CPU is makkelijker te verkopen: 4 cores! 3 GHz! Dat snappen mensen veel beter dan GPU specs).
ergo: met je midrange systeem en een goede videokaart kan je met Mantle WEL goed gamen.

AMD heeft net nieuwe game systemen 100 tot 200 euro goedkoper gemaakt als mantle aan slaat of mantle er voor zorgt dat mircosoft een keer wel gaat luisteren naar developers.

maar je accepteert nu dus dat directX nodeloos inefficient is? mooi.
Absoluut niet. Zoals ik al eerder zei... DirectX is minder efficient dan iets als Mantle, maar dat is een 'noodzakelijk kwaad', en zeker niet nodeloos.
enkel en alleen als jouw ongefundeerde en al meerdere malen tegengesproken mening over mantle's compatability met andere GPU's waar zou zijn EN dat alle game ontwikkelaars onnodig en onterecht zouden klagen over de inefficiŽntie van DirectX.

neem je het me kwalijk als ik die kans niet al te groot acht?
Ja, maar wie bouwt zo'n systeem?
iedere gamer die een GPU upgrade doet? en dat nu zeg 3 keer ipv maar 2 keer kan doen?
Er is maar 1 Mantle-game op het moment.
juist ja, op het moment.

[Reactie gewijzigd door Countess op 3 februari 2014 00:44]

Die zelfs zeggen dat ze Mantle onnodig vinden.
noem er maar 1. ik heb ze nog niet gezien namelijk. ik heb er gehoord die het liever in directX of openGL hadden gezien, en niet graag een nieuwe API, maar geen een die de voordelen er niet van in ziet.
noem er maar 1
Andrew Copland.
ik heb er gehoord die het liever in directX of openGL hadden gezien, en niet graag een nieuwe API, maar geen een die de voordelen er niet van in ziet.
Dat komt dus op hetzelfde neer.
Iedereen zal de voordelen van Mantle zien, dat lijkt me duidelijk: minder CPU-overhead.
Maar de meeste developers vinden de nadelen van Mantle niet opwegen tegen die voordelen.
"Iedereen zal de voordelen van Mantle zien, dat lijkt me duidelijk: minder CPU-overhead."

Jij zag anders de voordelen van mantle niet.
Op je blog was je al bijna 2 jaar geleden mensen die meer performance wouden aan het uitlachen.
Ondertussen heeft mantle bewezen dat je EN een dunnere API kan bakken EN dat dat zin heeft.
Niemand gaat de HAl weggooien en direct tegen het ijzer aan programmeren, zoals jij dat uitgebreid in je blog beschrijft.
Mantle is op zich een HAL die dus ook aan andere architecturen kan worden aangepast. Dus helemaal niet wat jij in je blog hebt gefantaseerd.
In die fantasie hebt je het ook over Soundblaster. Maar in die tijd had je veel meer vendors die game sound hardware uitbrachten. Je kon geluid produceren op: pc speaker, Speech thing, MIDI MT32, MIDI GS, AdLib, Game Blaster, Sound Blaster, Gravis ultasound. Het werdt dus automatisch een zooitje.

De situatie met GPU's op de pc is heel anders. Je hebt 2 vendors (waarvan er 1 ook de 3 consoles voorziet) en dan heb je nog intel die maar een beetje meedoet in het low-end segment.
Die situatie uit de tijd van soundblaster gaat dus gewoon niet meer op.
Jij zag anders de voordelen van mantle niet.
Hoezo? Ik heb gezegd dat ik op een high-end systeem zo'n 10-15% betere performance verwachtte. En dat bleek vrij nauwkeurig geschat. In dat blog dat je aanhaalt staat ook:
Although XBox360 and PS3 may be more efficient than a PC, their hardware cannot be updated.
Daarin zeg ik dus al impliciet dat hun APIs efficienter zijn, en dat er dus ruimte is voor zoiets op de PC... Ik geef alleen aan dat het probleem van D3D niet zo heel groot is (en 8% is dat ook niet), en dat de nadelen niet opwegen tegen de voordelen.

Verder was mijn kritiek op Huddy volkomen terecht. Mantle is een API, en hij riep dat we geen APIs meer moesten gebruiken.
Een ding waar je met Mantle veel beter af bent dan DX is het aantal objecten welk je tegelijkertijd mee kan werken op het scherm.

Als dat de enige verbetering was, dan was Mantle al een goede verbetering; bedenk je een stads-scene met duizenden voorbijgangers (Mantle) vs 500 (DX).
Als dat de enige verbetering was, dan was Mantle al een goede verbetering; bedenk je een stads-scene met duizenden voorbijgangers (Mantle) vs 500 (DX).
Daarvoor bestaat in DX al jaren geometry instancing. Dat heeft ATi destijds nog zitten promoten ook: http://www.youtube.com/watch?v=PRloZehGnTw

Als er iets is dat aangeeft hoe krom dat Mantle is, dan is dit het wel.
Dit is een tech-demo, nota bene van ATi zelf, van de Radeon X800. Dat was in 2004 (het tijdperk van single-core Athlons en Pentium 4s). Toen konden we dus al 1400 soldaatjes animeren in realtime. En 10 jaar later kan dat ineens niet meer, en moeten we Mantle hebben?

[Reactie gewijzigd door Scalibq op 3 februari 2014 00:41]

leuk, maar geen 500. en zeker geen duizenden. en maar 1 lichtbron en weinig verdere effecten. nogal slapjes ivm wat oxide laat zien.
Het waren er 1400 (dus bijna 3 keer zo veel als de geclaimde 500), en dat op hardware van 10 jaar geleden(!). Met de hardware van nu kunnen dat er makkelijk duizenden zijn, met meerdere lichtbronnen en extra effecten.
"Toen konden we dus al 1400 soldaatjes animeren in realtime"

Nee, geometry instancing betekent 1400 van DEZELFDE soldaat. wil je unieke geometry hebben, dan kan dat niet en zit je met DX met lage limieten. Mantle helpt daar boven uit te komen.
Nee, geometry instancing betekent 1400 van DEZELFDE soldaat. wil je unieke geometry hebben, dan kan dat niet en zit je met DX met lage limieten. Mantle helpt daar boven uit te komen.
Ten eerste kun je met creatief gebruik van geometry instancing echt wel meer dan 1 objectje doen.
Ten tweede, je gaat nooit 1400 unieke objecten gebruiken (veel te veel werk om dat allemaal te modelen en animeren, vreet ook teveel geheugen etc).
Realistischer is bv iets van 10 a 20 unieke objecten, en van ieder dan een paar honderd instances of zo. En dat is prima haalbaar met D3D.
Het 'probleem' dat Mantle probeert op te lossen, bestaat dus gewoon niet.
"Toen konden we dus al 1400 soldaatjes animeren in realtime. "

Ja, allemaal dezelfde modellen zeker.
En hoeveel parameters kreeg je dan per instance gebatched?
Is dus eigenlijk een gebrekkige oplossing voor het traag batchen op de CPU...
En hiermee geef je ook aan dat een probleem dat zich meer dan 10 jaar geleden al voordeed en waar mensen toen al over aan het zeuren waren nu nog steeds niet is opgelost.
" Dat zie je nu ook met Mantle: op papier is het veel beter, maar op een high-end systeem heb je in de praktijk 8% winst. Niet echt om over naar huis te schrijven. "

Je bedoelt dus dat je met een goedkope/zuinige CPU dezelfde performance kan krijgen? En waarom is dat slecht?
Je bedoelt dus dat je met een goedkope/zuinige CPU dezelfde performance kan krijgen?
Dat kon al, als je de benches van Anandtech ziet: ook met maar 2 cores ingeschakeld, en teruggeklokt naar 3 GHz, halen ze maar 8% winst uit Mantle met Ultra settings.
En dat komt dus overeen met een Core i3 van nog geen 100 euro.
"D3D is een aantal keren compleet op de schop gegaan, inclusief het onderliggende drivermodel."

En toch krijgen ze het voor elkaar om een API te maken die ergens in de verwerking volledig single-threaded het hele frame loopt op te houden.
Deze latency wordt opgelost met Mantle.

Dit, en meer, komt uitgebreid aan de beurt in dit filmpje.
De argumenten van deze WC Eend kunnen wel degelijk hout snijden. Maar je reageert er niet inhoudelijk op.
Lees ook bv ExtremeTech eens: http://www.extremetech.co...in-gaming-since-directx-9
The Star Swarm demo looks like a great engine for a latter-day Homeworld title, but it’s important to remember that it’s only a tech demo — not a beta or even an alpha version of a shipping product. It’s an excellent demonstration of Mantle’s capabilities, but its low frame rate intrinsically limits real-world applicability. No company could ship a game that can’t break 30 fps on DX11 on top-end hardware.

Because Star Swarm clearly isn’t designed to demonstrate a playable level of D3D performance, it’s also a limited window on Mantle performance.
Dat lijkt me de enige logische, objectieve manier om er naar te kijken.
Ik snap niet dat zoveel mensen zo makkelijk over dat punt heen stappen.
Daarom is het ook een demo... :/

Natuurlijk gaat niemand een game shippen die brak loopt op DX.
Maar er zijn natuurlijk meer opties om een game op 30fps te laten lopen.
Deze demo probeert gewoon op beide API's dezelfde dingen te tekenen en dan zie je inderdaad verschil.

Ik begrijp echt niet waarom je zo agerssief DX aan het verdedigen bent zonder echt met technische argumenten te komen. Je klinkt ondertussen een beetje als een kapotte langspeelplaat.
Daarom is het ook een demo... :/
Vooral een demo van hoe slecht en onrealistisch hun D3D-code is.
Ik begrijp echt niet waarom je zo agerssief DX aan het verdedigen bent zonder echt met technische argumenten te komen
Ik heb in de afgelopen topics (en ook hier) al vaak genoeg alle technische argumenten opgesomd. Die waren echter aan dovemansoren gericht.

Verder ben ik niet specifiek DX aan het verdedigen. Voor OGL geldt hetzelfde.

[Reactie gewijzigd door Scalibq op 3 februari 2014 19:40]

Ook jij mist je vakkennis en praat gewoon over iets waar je geen verstand van hebt. Er is geen enkele technische reden waarom Mantle GCN only is. AMD zou het prima kunnen implementeren voor oudere kaarten, maar het is gewoon dat ze de driverondersteuning niet uitbrengen want dan verkopen ze geen nieuwe kaarten meer natuurlijk. Zelfs NVIDIA zou prima de Mantle API kunnen implementeren voor hun hardware als ze dat echt zouden willen.

[Reactie gewijzigd door Shadow op 2 februari 2014 19:50]

True ik gis er ook op los, maar geld ook voor jouw. Je zit ook maar wat te gissen. Wat is GCN eigenlijk. Die gpu cores komen met bepaalde feature set. Niet GCN zijn uiteraard anders maar ook beperkt. Een API voor beide moet rekening houden met beperking. Maar API op GCN kan de volledige minimale featureset van GCN als basis nemen. En dan kan het zijn dat je iets veel efficenter kan doen. gezien nieuwere generaties GPU shader cores steed flexibeler worden.

Gezien deze featureset sterk gerelateerd zijn aan DX feature set en NV generaties dit ook volgen. Kan bepaalde familie van NV ook mantle methode geschikt zijn.
En de mantle implementatie method keuze ook geschik is voor dat deel van NV gpu's. Ik gis ook maar wat. Aannames net als jij. Maar ja NV zal dan eerder voor hun nVAPI gaan, dan mantle. Als tegen hanger. Zullen nu wel hard bezig zijn.
Wat ik niet zo snap is dat Mantle effectiever is dan bijv. DirectX of OpenGL. Zijn die technieken dan zo bloated?
DirectX en OpenGL hebben een extra laag er tussen zitten; het OS. Met Mantle (= een API) kun je direct de GPU aanspreken en hoeft de OS laag er dus niet tussen te zitten.
Mantle is een API net als DX en OpenGL, alleen moeten DX en OpenGL redelijk generiek geschreven worden om met drivers van verschillende fabrikanten te werken terwijl AMD zijn Mantle API kan optimaliseren voor zijn eigen architectuur. IPV de GPU en drivers op te bouwen rond de API kan men nu de API opbouwen rond de GPU.
mantle brengt nauwelijks verbetering op puur GPU gebied, het is dus geen GPU versneller an sich. Het probleem is ook niet dat OpenGL en directX generieker zijn.

Het "probleem" dat mantle voornamelijk aanspreekt is dat directx en opengl op de CPU draaien. Dit, terwijl moderne videokaarten eigenlijk volledig programmeerbaar zijn en belangrijke taken dus niet aangestuurd meer hoeven te worden vanuit de CPU. Mantle haalt eigenlijk een omweg via de CPU eruit voor een grote groep taken.

Het is ook niet AMD specifiek. In principe werkt dit op elke videokaart met volledig programmeerbare shaders, inclusief NVIDIA en moderne intel chips.
Het "probleem" dat mantle voornamelijk aanspreekt is dat directx en opengl op de CPU draaien. Dit, terwijl moderne videokaarten eigenlijk volledig programmeerbaar zijn en belangrijke taken dus niet aangestuurd meer hoeven te worden vanuit de CPU. Mantle haalt eigenlijk een omweg via de CPU eruit voor een grote groep taken.
Dit is niet helemaal correct.
Mantle stuurt de GPU nog steeds op dezelfde manier aan als D3D.
Het verschil is dat Mantle direct via de 'native' taal van de GPU praat. Bij D3D zit er een abstracte laag tussen API en driver, en moet de driver dat vertalen naar GPU-specifieke instructies.
Bij Mantle kun je deze instructies (in de 'command buffer') ook direct manipuleren, waardoor je meer controle hebt, en bepaalde dingen efficienter kunt doen.
Het is ook niet AMD specifiek.
Dat is het dus wel.

De D3D-variant op de Xbox is ongeveer hetzelfde verhaal als Mantle: omdat er maar 1 GPU is, hoeft daar geen abstracte laag tussen. Maar de 'gewone' D3D zou niet op deze manier kunnen werken.

[Reactie gewijzigd door Scalibq op 2 februari 2014 18:32]

Het is niet AMD specifiek. AMD heeft de API gedefinieerd en nu dus een implementatie in in hun driver opgenomen. BF4 en binnenkort Thief hebben ondersteuning voor deze API en praten er dus tegen aan.
Het is niet AMD specifiek. AMD heeft de API gedefinieerd en nu dus een implementatie in in hun driver opgenomen.
Waarom niet? In Mantle zitten een hoop zeer hardware-specifieke dingen, waar je toch echt een AMD GCN-GPU voor nodig hebt, omdat de GPUs van de concurrentie op een net wat andere manier kunnen werken.
Dingen als de verschillende memory pools, of de manier van swizzling van textures... en dan het direct manipuleren van command buffers... om maar wat te noemen.
Als je dat wil implementeren op andere GPUs, dan moet je daar dus een vertaal-laag op de CPU voor maken, en ben je weer net zo ver van huis als je was met D3D of OGL.

De claim dat het dus niet AMD-specifiek is, is een wassen neus.
Er hoeft helemaal geen vertaallaag gemaakt te worden - een andere vendor kan gewoon de C API implementeren, en dan zou het moeten werken. Echt veel GPU specifieke dingen zitten er niet in de API behalve wat er in de extensions gesupport word trouwens.
Er hoeft helemaal geen vertaallaag gemaakt te worden - een andere vendor kan gewoon de C API implementeren, en dan zou het moeten werken.
Dat spreekt niet tegen wat ik al eerder zei, ook al probeer je het zo te brengen.
Hoe moet ik dit dan interpreteren?
Als je dat wil implementeren op andere GPUs, dan moet je daar dus een vertaal-laag op de CPU voor maken, en ben je weer net zo ver van huis als je was met D3D of OGL.
Kijk bijvoorbeeld hier naar een lijst gedumpte functies uit de mantle dlls http://pastie.org/8682650 enkel de functies in MANTLEAXL64.DLL zijn echt AMD specifiek, de rest is allemaal redelijk cross platform gehouden.
Baseer je al je claims hier op een dump van wat symbols? Daar kun je nog niet eens aan afleiden wat voor parameters die functies hebben.
Dit zegt niks.
Ik baseer de claims met de ervaring die ik met de API heb - ik kan niet meer delen dan dat lijstje met symbols ;)
Uh ... ja, dat kan hij wel.
Bij zowel Mantle, DirectX als OpenGL praat je tegen de GPU driver aan, die vervolgens tegen de hardware aan praat. Het OS heeft er niet zoveel mee te maken.

Ik vermoed dat de betere snelheid van de Mantle API vooral te danken is aan dat deze nauw aansluit bij de (AMD) hardware.
Wel "handig" als straks elke video kaart of merk weer zijn eigen drivers gaat krijgen. Dat was vroeger ook altijd zo leuk, dan moest je de games of zelfs applicaties die je kocht matchen aan de video hardware die je had,

Gouwe tijden!
Een stukje uit het verleden. Er was eens 3DFX en 3DFX bouwde de glide API en uit cholere en de "enemy of my enemy is my friend" mentaliteit scharrelen de andere bouwers zich achter OpenGL en het opkomende Direct3D. Is Mantle een poging tot het vernietigen van OpenGL/Direct3D ?

[Reactie gewijzigd door goarilla op 2 februari 2014 22:19]

Ik denk dat je API of SDK bedoeld. Zoiets als Glide.
Ja, duh! Drivers die hun eigen API hebben om tegen aan te praten als software zijnde ;)
"Wel "handig" als straks elke video kaart of merk weer zijn eigen drivers gaat krijgen."

Wat?? Alle 3? De wereld zal vergaan!
Wat ik niet zo snap is dat Mantle effectiever is dan bijv. DirectX of OpenGL. Zijn die technieken dan zo bloated? Die zijn toch ook geoptimaliseerd voor performance?
Mantle heeft een iets ander doel dan Direct3D en OpenGL.
Bij DirectX en OpenGL wordt een brede selectie aan hardware ondersteund. Mantle werkt op een lager niveau, en is veel directer verbonden met de hardware.
D3D en OpenGL zijn wel geoptimaliseerd voor wat ze doen, maar dat is iets anders dan wat Mantle doet, en de extra abstractie-overhead is dus een 'noodzakelijk kwaad'.

Zo kan bv D3D11-code ook gewoon op een telefoon of tablet gebruikt worden, met een veel minder geavanceerde GPU (D3D9-achtige hardware). Voor OpenGL ES geldt ongeveer hetzelfde. Dat kan Mantle niet.
de abstractie laag van directX en openGL is echter veel dikker als hij zou kunnen en zou moeten zijn.

je kan vinden dat die van mantle te dun is (maar dat is enkel jouw gok aangezien je er nog niks mee hebt gedaan) maar dat wil niet zeggen dat hij hardware specifiek is.
de mantle drivers staat duidelijk beschreven, er is dus duidelijk abstractie aanwezig.
de abstractie laag van directX en openGL is echter veel dikker als hij zou kunnen en zou moeten zijn.
Waar baseer je dat op? Eigen ervaring? Kun je technische argumenten noemen?
Of ga je puur af op AMD-marketing?
Nou, wellicht op wat alle developers zeggen (yup, including mr Carmack). Jij vervalt in "het is allemaal maar marketing praat!", terwijl anderen met directe quotes van developers komen.

Put up or shut up; kom met direct technisch onderbouwde tegenargumenten of quotes of houd je koest.
Technisch onderbouwde argumenten genoeg, zoek maar even in m'n posts over de Mantle topics onlangs.
oxide games, wat AMD zegt, en wat bijvoorbeeld prisonerOfPain (frostbite developer) hier op tweakers zegt.

en jij gaat af op je anti-AMD mening.

dus tenzij er een groot complot gaande is is de kans dat de waarheid dichter bij mij ligt vrij groot.
oxide games, wat AMD zegt, en wat bijvoorbeeld prisonerOfPain (frostbite developer) hier op tweakers zegt.
Da's allemaal pro-AMD, en dus verre van objectief.
dus tenzij er een groot complot gaande is is de kans dat de waarheid dichter bij mij ligt vrij groot.
Ja, je zou het een 'complot' kunnen noemen ja,
Net als bv bij Bulldozer met John Fruehe. Iedereen geloofde hem. Toch bleek er weinig van waar.

[Reactie gewijzigd door Scalibq op 2 februari 2014 23:23]

Da's allemaal pro-AMD, en dus verre van objectief.
ja want oxide is natuurlijk enkel en alleen gestart met oude civ-5 developers om AMD te promoten enzo.

en wat heeft bijvoorbeeld prisonerofpain er mee te winnen?

[Reactie gewijzigd door Countess op 2 februari 2014 23:59]

Ze hebben voorlopig alleen dat Starswarm geproduceerd, wat niet meer is dan een tech-demo voor AMD. Dus ja.
ze zijn de Nitrous engine aan het maken. jij bent nu aan het klagen dat daar nog geen games voor zijn terwijl die engine nog in ontwikkeling is...
Hij werkt aan een product dat valt onder het Gaming Evolved-programma. Hij zal dus contractueel verbonden zijn om alleen positieve dingen te melden over AMD-gerelateerde zaken. Zo gaan die dingen.
zo gaan die dingen niet. hij is contractueel gebonden om niks te zeggen over heel veel dingen.

daarbij is hij hier nog steeds vrijwillig, en ik betwijfel ten zeerste of hij hier vrijwillig zou komen om dingen te vertellen waarvan hij weet dat ze niet waar zijn. daar heeft hij zelf helemaal niks aan.
de installatie van de 14.1 duurde bijna 30 minuten , alleen al de installatie van MS .Net framework 4.5 duurde een kwartier , maar ja heb dan ook niet de nieuwste hardware :D

== Hardware Configuration =================================
GPU: AMD Radeon R9 200 Series
CPU: AuthenticAMD
AMD Phenom(tm) II X4 920 Processor
Physical Cores: 4
Logical Cores: 4
Physical Memory: 8589004800
Allocatable Memory: 8796092891136
===========================================================
Extreme Follow
direct x average FPS 17.23
Mantle average FPS 29.53

Medium Follow
Direct X average FPS 23.01
Mantle average FPS 41.96

ik gebruik dan wel een R9 270x waar de drivers nog niet voor geoptimaliseerd zou zijn , kan dus alleen maar beter worden.

ter info mijn moederbord heeft geen pci express 3.0 ondersteuning en werkt nog met ddr2 geheugen.

[Reactie gewijzigd door stresskiller op 2 februari 2014 16:51]

Wel een verschil Ik weet nog dat ik nvan mijn amd 955 met een 6870 naar een intel i7 3770k ging en toen haalde ik al 40% meer uit mn gpu :)
Ben benieuwd of ondanks dat je cpu nu bijna aan het idlen zou zijn een snellere cpu toch nog voordelen heeft voor je fps of dat je gpu+mantle gewoon zorgd dat he cpu niks meer te doen heeft.
In mijn ogen is het namelijk slecht als je cpu niks te doen heeft omdat je dan rekenkracht verliest.
Misschien moeten in toekomstige games de taken iets beter verdeeld worden zodat cpus dan beter benut wordennu de gpu bijna alle opdrachten direct verwerkt.
In mijn ogen is het namelijk slecht als je cpu niks te doen heeft omdat je dan rekenkracht verliest.
Beetje kromme redenering. Als de CPU de bottleneck is en je omzeilt deze dan is het logisch dat vervolgens de GPU de bottleneck wordt. Er is immers altijd een zwakste schakel. Hoe dan ook is het een verbetering die waarschijnlijk anders met een heel prijzige CPU- upgrade behaald kan worden. De hardware wordt hoe dan ook veel beter benut.
Het probleem is alleen dat als je CPU niks aan het doen is het zou betekenen dat ik voor jan piep een supersnelle cpu gekocht heb.
Er zijn vast wel taken die de cpu even goed kan doen als de gpu waardoor de gpu ontlast word en dus meer andere taken tot zuch kan nemen.

In een ideale werled zijn bijde devices belast en aan het werk.
Een idle cpu is niet goed en een 100% belastte gpu dordat het teveel andere taken tot zich neemd geeft weer andere limitaties qua prestatie.
Vergeet niet dat AMD er het grootste belang bij heeft om de CPU-load naar beneden te krijgen. Op het gebied van CPU's laat AMD het namelijk gruwelijk afweten tegen Intel, zeker wat betreft games (andere taken zijn vaker multi-threaded, waar de multi-cores van AMD nog wel mee kunnen komen).
In plaats van te concurreren op brute kracht, iets dat ze al jaren verliezen van Intel, kan Mantle ervoor zorgen dat die CPU-kracht minder nodig is. Dan worden AMD CPU's opeens een stuk aantrekkelijker voor gamers, aangezien ze een stuk goedkoper zijn dan die van Intel.

IMO is Mantle dan ook meer een aanval richting Intel dan richting Nvidia; vandaar dat het ook waarschijnlijk is dat Mantle opengesteld gaat worden voor de concurrentie. Hoe meer game(r)s Mantle gebruiken, hoe meer CPU's AMD potentieel kan verkopen.
Bij games kan je de gfx tweaken naar je hardware. Soms heel uitgebreid. Maar dat geld niet voor AI of physics. Deze is meestal al sterk verbonden aan de gameplay en dus meestal fixed. En dan is de load gekozen met bepaalde mainstream in gedachte. Was dat erg low dan dual core. Beetje veel eisenderer een instap quadcore.

Die iNtel high-end is al snel overkill. Wil men de CPU meer belasten dan shift men al snel van mainstream naar high-end gamers.

En configureerbare AI is vaak niet gewenst. enige voorbeeld die ik ken. In BF2 kon je aantal bot aanpassen en hun AI.
Physics tja effect physics kan je aan passen. Maar meestal doen dat alleen enkele PhysX game voor Cuda effect physics. Zijn er een paar.

Dus ja voor gamen is een dure CPU beetje overkill.
Ehhm, ideaal zal het nooit worden. Maar niets let je om je ongebruikte cpu-power te benutten en bijv een video gaat renderen (doe ik zelf al jaren). Moet je eens kijken man, hoeveel cpu-load je krijgt ? Codec niet multithreaded genoeg ? Ook geen probleen, doe gewoon 2,3,4 of meer films tegelijk (doe ik ook al jaren met VirtualDub) , Cpu load? Gegarandeerd 100% ! (core i7-920 @3.66Ghz)

Eigenlijk wil je helemaal niet dat je cpu constant 100% cpu belast is, met welk spel dan ook. Omdat je simpelweg nog reserve wil hebben voor rand-taken en taken op de achtergrond.

Als cpu-belasting geen issue meer is, kan je je gpu belasting zefl aanpakken. Niemand verplicht je nml. om op Ultra te spelen met 16x AA ! En ja, zo kan het maximale uit je systeem halen. Door te tweaken!
Mijn pc heeft helemaal geen rand taken op de achtergrond als ik aan het gamen ben.

Je mist dan ook het hele punt.
als mijn cpu nu maar 20% benut word in een game is er 80% onbenut doordat je gpu op 100% aan het draaien is.
Van alle taken die de GPU aan het doen is zijn er best wel taken die de CPU kan doen ipc alles naar de GPU te sturen.
En doordat je GPU 100% aan het draaien is betekend dat dat hij niet meer FPS kan renderen.
Als de je dus nog 70% extra van de CPU belast en Daarmee 5 a 10% van de GPU untlast betekend dat dat in theorie je FPS met 5 a 10% omhoog kunnen wat een behorlijk verschil is.

Nou is duidelijk je CPU niet voor alle taken meer geschikt maar daarom zij ik ook dat dat opnieuw geoptimaliseerd moet worden en dus Alleen nuttig is voor de toekomstige games.
Alleen in een ideale wereld zijn gpu en CPU 100% benut. De gpu levert veruit de meeste rekenkracht voor graphics. Het feit dat we meer fps halen met minder cpu-belasting is hoe dan ook winst. Zeker voor de mensen die niet zo'n dure CPU hebben als jij.

In feite word je nu geconfronteerd met het gegeven dat een dure CPU straks niet meer nodig is en dat een snelle gpu volstaat. Precies hetzelfde als dat Windows geen quad core 3 GHz nodig heeft om soepel te draaien. Cpu's zijn voor de meesten van ons al jaren overkill, zeker in desktop systemen.

Bekijk het eens andersom. Al die jaren is de gemiddelde CPU belast met taken die veel beter door de gpu afgehandeld kunnen worden. Al die mensen met een redelijke videokaart kunnen straks dus eindelijk gewoon lekker gamen.
Ah, nou snap ik waar je heen wilt en nee, je zit er compleet naast. De taken die de GPU doet kunnen niet zomaar even door de CPU overgenomen worden. Het zijn twee heel verschillende beestjes.

En zelfs dan; hoeveel moet de cpu dan voor zijn kiezen krijgen? 100% load op een i5 3570K is teveel werk voor allles wat trager is bijv. En nee, ff load balancing doen bestaat niet. Maw: Waarop stem je die 100% cpu load dan af ?

Bij de desktop pc loop je hier altijd tegenaan, omdat de hardware steeds beter/sneller word en er zoveel keus is.

Update
http://pclab.pl/art55953-3.html
Zoals je kan zien ik deze Multiplayer test, pak je zelfs winst met dikke Intel quadcores! Maw; ook met de gangbare quadcores van Intel kan je een leuke winst boeken, vooral als je online speelt.

[Reactie gewijzigd door Madrox op 3 februari 2014 12:33]

niet zomaar nee maar somes kan het wel.
kijk maar naar borderlands physx. dat draaide prima op een cpu maar je had er een supersnelle cpu voor nodig omdat 40% can de cpu al door de game zelf in gebruik was.
nu kan je dus bijna de volle 100% gebruiken voor een taak als dat aangezien de gpu een hoop andere cpu taken tot zih genomen heeft.

het vergt alleen wat anders conden bij de game makers en dat zal dan ook alleen bij pc only games echt gebruikt gaan worden.
we weten immers allemaal hoe lui ze zijn bij console ports.
Daar veranderen ze vaak niet eens de input iconenen van abxy naar je tb intelling als je dat al in kan stellen.
Klopt, ik heb ook een flinke vooruitgang gezien toen ik van mijn Phenom II X4 955 naar een i7 2600k ging. In sommige gevallen steeg mijn minimum fps van 30 naar 60, dus da's een behoorlijk verschil.
Heb op mijn systeem ook nog maar ff deze test gedraait en heb een paar dingen gezien die wat mij betreft dr score van deze bench nutteloos maken.

RIG:
GPU: AMD Radeon HD 7900 Series (7970 3G OC editie)
CPU: GenuineIntel
Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz
Physical Cores: 4
Logical Cores: 8
Physical Memory: 8532865024
Allocatable Memory: 8796092891136


DX :
Test Duration: 360 Seconds
Total Frames: 17556

Average FPS: 48.76
Average Unit Count: 4461
Maximum Unit Count: 5685
Average Batches/MS: 1011.82
Maximum Batches/MS: 2652.40
Average Batch Count: 23946
Maximum Batch Count: 113070

Mantle:
Test Duration: 360 Seconds
Total Frames: 17556

Average FPS: 48.76
Average Unit Count: 4461
Maximum Unit Count: 5685
Average Batches/MS: 1011.82
Maximum Batches/MS: 2652.40
Average Batch Count: 23946
Maximum Batch Count: 113070


Zoals je kan zien haal ik er bijna niets extras uit als het neerkomt op FPS MIjn top FPS was namelijk nooit hoger dan 72.9 FPS
Maar het meest opmerkelijke was dat deze 2 tests compleet verschillen van elkaar en dus NIET met elkaar te vergelijken zijn.
Ik denk dat je ergens een kopieer foutje gemaakt hebt 2x exact dezelfde score lijkt me erg sterk.
Ik kan de hele text doc wel posten maar dat word dan een behoorlijke post ;)
Ik heb het meerdere keren getest en deze hele benchmark is gewoonweg waardeloos doordat de D3D en Mantle runs bijde compleet verschillende tests zijn.
Als de tests zo verschillen hoe kunnen de uitkomsten dan identiek zijn? Zoals stresskiller al schrijft, heb je ergens een foutje gemaakt. Lees je post maar eens goed na.
Star Swarm benchmark (Extreme preset) met een i7 2600K (stock) en een HD 7950 (1000Mhz core en 1400Mhz geheugen) 12GB RAM @ 1333Mhz

Scenario: RTS

Direct X:

Average FPS: 7.75
Average Unit Count: 3860
Maximum Unit Count: 5658
Average Batches/MS: 810.80
Maximum Batches/MS: 1062.29
Average Batch Count: 102465
Maximum Batch Count: 170415

AMD Mantle:
Average FPS: 21.59
Average Unit Count: 3976
Maximum Unit Count: 5601
Average Batches/MS: 1801.27
Maximum Batches/MS: 2344.66
Average Batch Count: 84935
Maximum Batch Count: 177307

Edit: ook nog follow scenario gedraaid met Mantle en dan komen deze resultaten tevoorschijn (Extreme):
Average FPS: 50.70
Average Unit Count: 4312
Maximum Unit Count: 5517
Average Batches/MS: 787.30
Maximum Batches/MS: 2131.98
Average Batch Count: 17514
Maximum Batch Count: 103980

[Reactie gewijzigd door David Regeling op 2 februari 2014 16:47]

Star Swarm bench op standard settings (zie hieronder) @ 1920x1080, running on i5 3450, 8GB 1600mhz, xfx HD7950

Bloom Quality: High
PointLight Quality: High
ToneCurve Quality: High
Glare Overdraw: 16
Shading Samples: 64
Shade Quality: Mid
Deferred Contexts: Disabled
Temporal AA Duration: 16
Temporal AA Time Slice: 2

Scenario: Follow

DX:

Average FPS: 29.37
Average Unit Count: 4143
Maximum Unit Count: 5602
Average Batches/MS: 516.45
Maximum Batches/MS: 1331.81
Average Batch Count: 20526
Maximum Batch Count: 110751


Mantle:

Average FPS: 42.71
Average Unit Count: 4248
Maximum Unit Count: 5533
Average Batches/MS: 825.79
Maximum Batches/MS: 2431.57
Average Batch Count: 21120
Maximum Batch Count: 98178

[Reactie gewijzigd door Kapoon op 2 februari 2014 16:42]

Een grote stap in grafische technieken. Kan me niet voorstellen dat nvidia en/of microsoft lang zullen wachten met een opvolger van directx.
nV zou met een eigen alternatief kunnen komen, maar hoe lang gaan developers het slikken dat ze ineens weer van 1 API te moeten ondersteunen ineens weer meerdere APIs moeten gaan ondersteunen? DX is net ontstaan omdat er nood was aan 1 enkele API zodat developers konden gaan ontwikkelen zonder naar de drivers te moeten kijken. Met initiatieven zoals Mantle haal je dit weer onderuit.
Aan de andere kant is het weer net IE6. Microsoft heeft de defacto standaard en weigert al 5 jaar naar ontwikkelaars te luisteren.

Mantle doet niets wat DX ook al niet in 10.1 had kunnen stoppen. Iedereen is aan het nvidia/ati bashen en flamen, maar daar heeft het feitelijk heel weinig mee te maken.

De ironie is een beetje dat de DX specificatie heeft geleid naar kaarten met volledig programmeerbare shaders en compute units en diezelfde DX nu directe toegang daartoe blokkeert.

Meerdere standaarden is misschien niet wenselijk, maar hopelijk schudt het de bestaande standaarden eens wakker.
Microsoft heeft de defacto standaard en weigert al 5 jaar naar ontwikkelaars te luisteren.
Helemaal niet. Microsoft heeft voor D3D11 toch duidelijk stappen gemaakt, en ook in nieuwe revisies van D3D11 nog verbeteringen meegenomen die samen met DICE zijn ontwikkeld.
De ironie is een beetje dat de DX specificatie heeft geleid naar kaarten met volledig programmeerbare shaders en compute units en diezelfde DX nu directe toegang daartoe blokkeert.
Klok en klepel.... D3D11 is ook nog backward-compatible met D3D9-hardware (oa voor smartphones/tablets), en die hebben nog niet per se compute units of unified shaders.
Het is dus sowieso nog niet de tijd om die stap te maken. Sterker nog... Met D3D10 had MS wel een strikte minimum hardware-eis, maar heeft deze in D3D11 weer versoepeld, om D3D9-hardware weer op te nemen.
Ik zie het punt niet? Ja directX is nog wat verbeterd? Zitten daar de veranderingen in die al in 2007 zijn gevraagd door de dev community? Nee. Hebben we direct access op de shaders? nee.

Als je zegt: "we willen een vliegtuig" en je krijgt als antwoord, "we hebben wel een snellere helikopter" dan heb je toch nog steeds geen vliegtuig?

Ik noem toch ook specifiek DX 10.1? Dat DX11 backward compatible is en mindere hardware requirements heeft veranderd toch niets aan het feit dat de huidige AMD en NVIDIA architectures wel ontwikkeld zijn voor 10. DX9 heeft geen invloed en is ook niet interessant want DX9 only hardware kan dus ook nooit mantle draaien. Daar mist namelijk de architectuur.
Ik zie het punt niet? Ja directX is nog wat verbeterd? Zitten daar de veranderingen in die al in 2007 zijn gevraagd door de dev community?
Kun je die veranderingen concreet maken? Dan kan ik beoordelen of die er al dan niet in zitten.
Hebben we direct access op de shaders? nee.
Wat bedoel je daarmee? Mantle werkt net als D3D via HLSL, dus er is geen verschil in hoe shaders geprogrammeerd worden.
Ik noem toch ook specifiek DX 10.1? Dat DX11 backward compatible is en mindere hardware requirements heeft veranderd toch niets aan het feit dat de huidige AMD en NVIDIA architectures wel ontwikkeld zijn voor 10.
DX11 is een superset van DX10. En toch nog steeds mogelijk om te draaien op DX9-architecturen, omdat de markt hier nog om vraagt.
Het was toch Dice die naar AMD zijn gestapt met hun 'frustraties' dat ze niet meer uit hun hardware konden halen met DX.
En het is idd beter als de concurrentie elkaar scherp houdt want als er een hele grote is dan stagneert de boel teveel.
DX komt to stand tussen 3 hoofd groepen.

De API beheerders MS,
de hardware vendors AMD( ATI ) NVidia intel,
de developers zoals de famous devs John Carmack etc.

Het duurt Jaren om de nextgen GPU te ontwikkelen. Dat zou dus beteken dat als er nieuwe API kwam de hardware vele jaren later op duikt. Maar zo werkt het niet.

DX is tot stand gekomen elke iteratie door samen werking tussen die drie groepen.
DX12 zullen ze waarschijnlijk al mee bezig zijn ook al is het nog ver weg.
Had gedacht dat ze de Mantle API zouden vrijgeven voor alle developers, maar het is alleen voor AAA developers. Ik denk dat heel weinig games dit zullen gaan gebruiken.
Mantle is nog enorm in ontwikkeling. Ik verwacht dat men er wat vrijer mee om zal gaan naar mate het verder in de ontwikkel fase is. Op het moment is men bezig een tweede ronde developers te vinden om de API verder te kunnen polishen.

https://twitter.com/NThibieroz/status/429897769445097472
Op het moment is men bezig een tweede ronde developers te vinden om de API verder te kunnen polishen.
Misschien iets voor Scalibq ? O-)
Tja inderdaad als je hem zo moet geloven dan is hij Heer en Meester op het gebied. Maar wacht hij is anti-Mantle dus nee gaat hem niet worden. |:(
Prisoner,

Vraagje. Hebben jullie bij het ontwikkelen van support voor Mantle ook contact gehad met de heren van Oxide?
Ik kan me voorstellen dat het nuttig is om ervaringen uit te wisselen. Of loopt alle communicatie via Amd?
Zijn er andere developers die in de eerste ronde zaten voor Mantle support bij AMD?
Oxide games is niet bepaald een AAA studio, maar toch maakt hun engine gebruik van de Mantle API, en dus al hun toekomstige games. Natuurlijk moet blijken hoe dit in de toekomst zich ontwikkeld en hoe andere studio's Mantle gaan toepassen of niet.

[Reactie gewijzigd door David Regeling op 2 februari 2014 16:00]

Maakt niet uit, het framework zou gewoon openbaar beschikbaar moeten zijn.
Waarom?

Directere toegang tot de mogelijkheden van de grafische kaart heeft niet alleen voordelen. Het legt ook veel grotere verantwoordelijkheden bij de gebruikers. AMD heeft ervoor gekozen om tijdens de beta alleen te werken met een beperkt aantal studios. Dat is hun goed recht. Als de beta klaar is is er een grote kans dat het framework voor groter publiek beschikbaar zal komen
Niet als nvidia er ook gebruik van gaat maken maar dat is aan nvidia zelf. Ik hoop wel dat nvidia het toe wil passen op de duur zo niet dan heb je weer meer dat AAA game1 het wel heeft en AAA game 2 weer niet.
Hier een HD7750 + i7 effe snel in BF4 getest op 1920x1080 alles op normal:
DX: 44 fps
Mantle: 29 fps

Voor niet R9 kaarten met zware cpu dus een preformance degradatie.

[Reactie gewijzigd door Deem op 2 februari 2014 18:39]

Dat kan kloppen in sommige uitzonderlijke situaties kan de framerate inderdaad lager zijn dan met DirectX, zoals Anandtech ook al laat zien in deze statistieken.

http://www.anandtech.com/...tlefield-4-mantle-preview
Using Low quality settings on the other hand significantly widens the gap in both directions, with the minimum gain being -14%, and the maximum gain being 28%. In the case of our 6C/12T CPU configuration, Mantle actually has a detrimental impact on performance, bringing down our framerate from a positively absurd 216fps to a slightly less absurd 181fps. This was unexpected to say the least, and while we’re not particularly concerned about it given the fact that we have little reason to use this setting in day-to-day gaming, but it does point to a weakness in the current builds of BF4 and the Mantle drivers.

Maw; de drivers zijn nog voor verbetering vatbaar. Niet zo gek, het is een Beta en Mantle is nogal vers. Deem: er is ook voor jou nog hoop dat het goed komt ;)

[Reactie gewijzigd door Madrox op 3 februari 2014 12:11]

Nou vraag ik me af is Mantle AMD's reactie op Nvidia's physx geetter en werkt dit alleen op AMD kaarten of gaat dit ook op nvidia kaarten werken?
nee dit heeft niks met physX te maken.

AMD heeft aangekondigd dat mantle (net als bijna alles wat AMD doet) een open standaard gaat worden, en dan is het straks dus helemaal aan nvidia zelf op ze mee willen doen of niet.
NV had voor PhysX ipv Cuda ook openCL kunnen gaan. Ik denk dat ze eerder een Eigen API met diezelfde insteek gaan doen. Ze hebben al nVAPI die zal dan mogelijk naar mantle like niveau uitgewerkt worden.

Ze doen dat niet want tech van je grootste concurrent is imago verlagend. Tech van de ander gebruiken is zeer ongewenst.
Nvidia kan dan 2 dingen doen, hun architectuur aanpassen aan mantle api of een layer maken zodat mantle met bv maxwell kan communiceren dus hoe open is mantle dan?

Misschien krijgen we straks wel een directx die ook direct met nvidia gpu's kan communiceren
omdat amd support voor directx niet meer nodig is?
Tressfx is AMD's reactie op Nvidia's physx, ik moet wel zeggen dat ik die niet echt als prettig heb ervaren, erg efficient werkt het ook niet.

Significante drop in performance wat het het niet waard maakte voor mij, tevens zag het er vaak (bijv bij Lara Croft's wapperende lokken) best raar uit.
Het gaat alleen op nVidia-kaarten werken als nVidia zelf Mantle-drivers ontwikkelt. De kans dat nVidia dat gaat doen is niet heel groot.
Nou ja het is dus nog altijd een optie.
AMD had nooit de keuze om physx te laten werken op een amd kaart.


En als nvidia een beedje slim is maken ze juist wel mantle drivers.
Als er eenmaal meer games uitkomen die dit ondersteunen kunnen ze moeilijk verkopen dat door laksheid hij duurdere kaarten nu 50% minder fps leveren.
En waarom is dat iet slim?

Denk je dat het slim is om 40 a 50% prestatiewinst links te laten liggen op populaire titels?
Dat zou nvidia de kop kosten omdat iedere gamer dan AMD kaarten gaat kopen omdat het en goedkoper is en 40 a 50% sneller...
Feit blijft dat als nvidia het niet gaat ondersteunen en het dus echt veel effectiever met hogere fps draait op een mantle api ze zwaar marktaandeel gaan inleveren.

Linksom of rechtsom amd heeft nvidia bij de ballen.

En wel D3D en opengl bijn voor bijde amd en nvida hetzelfde qua prestatie dus waarom zou mantle anders zijn.
Het is immers gewoon een api.

We gaan het zien maar ik denk dat NVIDIA geen keuze heeft en wel zal moeten om bij de blijven.
Er is geen excuus om bijde trager en duurder te zijn.
Niemand zal dat slikken.

Het licht dus volledig in handen van game makers als die het massaal gaan ondersteunen heeft amd een flinke voorsprong als nvidia geen aangepaste drivers maakt.
We gaan het zien de bal is in handen van game makers.
gaan zij het ondersteunen dan zijn de laatste jaren voor D3D en OpenGL aangebriken zo niet zal er niet veel veranderen.

Voor gamers is het beter als we eindelijk eens vooruitgang boeken na 8 jaar lang op consoles leunen met nouwelijks vooruitgang.
Voor gamers is het beter als we eindelijk eens vooruitgang boeken na 8 jaar lang op consoles leunen met nouwelijks vooruitgang.
Dat ligt meer aan de developers dan aan de API.
BF4 met Mantle is leuk, maar wat schiet je er eigenlijk mee op? Het is gewoon hetzelfde spel als in D3D, alleen op sommige configuraties iets sneller. Maar als de game toch al snel genoeg draaide in D3D, wat voor vooruitgang heb je dan eigenlijk?
zucht.
Misschien krijgen we ipv FPS nu meer eyecandy omdat er gpu capaciteit overblijft.
Iets wat we al bijna 6 jaar niet echt superveel op vooruit gegaan zijn doordat de rekenkracht niet toerijkend was.
Misschien krijgen we ipv FPS nu meer eyecandy omdat er gpu capaciteit overblijft.
Nee, want Mantle verandert weinig tot niets aan het GPU-verhaal (daarom zie je ook bij snelle CPUs vrijwel geen verbetering).
Er blijft meer CPU-capaciteit over, maar of je daar nu zo veel mee kunt... Consoles hebben die CPU-capaciteit niet, dus je hebt nog steeds het probleem van de 'slechte console-port'. Je hebt nu alleen een iets minder snelle CPU nodig om die console-port goed te kunnen draaien.
Dus nogmaals: het is vooral aan de developers, niet aan de API.
Ook zonder Mantle hadden high-end systemen al lang CPU-capaciteit over.
Meer cpu power kan ik zeker wat mee in mijn multitask omgeving. Zit vaak te spelen en een video te recoden bijv. waarbij er dus meer cpu-resources vrij zijn om de video sneller te recoden.
tja maar of dat nou zo goed is voor je videokwaliteit.
Je ziet vaak zat videos online met hiccups en artifacts door hiccups en gebrek aan cpu krsacht op een bepaald moment.

Als je echt om je videokwaliteit geeft gebruik je dus ook een dedicated pc en doe je er tijdens encoden/decoden niks anders.
Als een nVidia ben je dan veroordeeld tot de willekeur van AMD, waar het gaat om API-updates etc.
OPEN STANDAARD!

nvidia kan dus bij het consortium aanschuiven (als AMD het patroon volgt dat ze hebben gedaan met hun andere standaarden) en meebeslissen over hoe mantle er in te toekomst uit moet gaan zien.
uit je link:

"freely available SDK for game developers" is NIET het zelfde als vrij beschikbaar voor AMD.

en ondanks dat het gratis was zie je weinig games meer iets doen met physX. waarom? het heeft weinig voordelen. je kan er mooien dingen mee doen kwa physics maar dan heb je niet genoeg gpu over om het weer te geven of je beperkt je... maar dan kan je net zo goed een andere physics engine pakken die wel fatsoenlijk op de CPU draait.

[Reactie gewijzigd door Countess op 2 februari 2014 21:49]

maar dus niet gratis.

en AMD gaat niet betalen voor iets dat niks oplevert.
als dat niet het geval is dan zou dat een flinke verandering van MO zijn voor AMD vergeleken met hun voorgaande open standaarden.

ik bedoel het kan, maar AMD heeft er alle voordeel bij om mantle aan te laten slaan binnen de PC game markt.
Staat er bij AMD Mantle ook!! maar tja dat was vast niet waar toch? lol gaat ie weer met z'n twee maten meten. AMD zegt het:Het is vast niet waar of teveel geld! Nvidia zegt het: Halleluja!!!! LOLOLOL zo biased man zo biased
lol Ja hoor daarom haalde je dat aan :P Echt niet om te laten "zien" dat Nvidia zeiden dat ze PhysX open wilden maken volgens hun PR team :P Wie zei er ook alweer dat we door een marketing team ons niets aan moesten laten praten? Oh dat was natuurlijk alleen over het AMD Marketing team lol.
LOL waar dan? Doe me maar je directe quote waar je dat dan PRECIES zegt :P Maar baseline: We weten het nou wel, je haat AMD, jij persoonlijk vind Mantle niks, Je verafgood DirectX, Nvidia en Intel. Goed leuk voor je dat jij dat vindt. Hoeven we geen 20.000 versies in thread van te horen. Doe dat maar op je *coughBScough* blogje van "hoogste kwaliteit".

Fact is tot nu toe genoeg positieve reacties. Kan nog beter worden. Zijn wel downsides maar het is nog niet helemaal geoptimised. Je bent niet verplicht om het te willen, het te liken of te supporten en zijn er genoeg mensen die er anders over denken en echt je hoeft ze echt niet allemaal persoonlijk op te reageren waarom het allemaal zo slecht is in JOUW mening. Klaar.

Je had ook 1 reactie kunnen doen: Ik vind het niks (niet dat je het uberhaupt gebruikt of getest hebt but meh) en ik zie er niks in, Klaar. Was genoeg geweest
Op zich verbaast het me niet dat AMD degene is die met dit initiatief komt. Ik kan me nog herinneren dat AMD heel ontevreden was met DX10 en dat ze veel verder wilden gaan dan MS.
Aan de ene kant juich ik dit toe, aan de andere kant vraag ik me af of we straks 2 belangrijke API's krijgen met alle nadelen van dien.
Het doet mij inderdaad een beetje denken aan de Glide API van 3DFX, deze werd ook naast OpenGL en DirectX gebruikt en was in veel gevallen dus ook een stuk sneller wanneer het op de framerate aankwam.

Alhoewel Glide wel redelijk geadopteerd werd door redelijk wat game studio's toentertijd.
Alhoewel Glide wel redelijk geadopteerd werd door redelijk wat game studio's toentertijd.
Glide was dan ook de eerste 3D-API voor consumenten. 3dfx bracht de eerste 3d-accelerators voor consumenten op de markt, en Glide was de API om die aan te spreken. Direct3D werd pas later ontwikkeld, en hoewel OpenGL al bestond, werden er nog geen drivers voor OpenGL meegeleverd. De consumenten-hardware was te beperkt om OpenGL te ondersteunen.
Dus Glide was de enige keus. Zodra D3D en OGL volwassen warden, werd Glide overbodig.

Mantle is nu eigenlijk vanaf het begin al vrij overbodig.
Dat is niet helemaal correct want er waren zo ver ik mij kan herinneren al producten die werkte met OpenGL acceleratie, alleen waren de Voodoo kaartjes de eerste die echt succesvol werden vanwege hun prestaties en beeldkwaliteit (die te wensen over liet bij de andere fabrikanten vanwege andere soms vage rendering technieken).

Wel is het inderdaad zo dat 3DFX 3D-acceleratoren populair heeft gemaakt bij de grote massa.

[Reactie gewijzigd door David Regeling op 2 februari 2014 19:14]

http://www.techspot.com/article/650-history-of-the-gpu/

Maar goed dat komt inderdaad uiteindelijk op hetzelfde neer als wat jij hierboven beschrijft dat het geen volwaardige implementatie was van OpenGL, maar feit blijft wel dat Glide wel enigszins te vergelijken is met Mantle gezien Glide ook closer to metal werkte en sommige kernelcalls terugbracht in vergelijk met OpenGL, dat was eigenlijk ook mijn punt.

//off-topic
goede oude tijd :)

[Reactie gewijzigd door David Regeling op 2 februari 2014 19:20]

Mantle performance for the AMD Radeon™ HD 7000/HD 8000 Series GPUs and AMD Radeon™ R9 280X and R9 270X GPUs will be optimized for BattleField 4™ in future AMD Catalyst™ releases. These products will see limited gains in BattleField 4™ and AMD is currently investigating optimizations for them.

Ok wat betekend dit?
Gewoon wat er staat: De snelheidsverbetering is nu nog groter voor de 260 en 290's dan voor andere moderne kaarten.

Die verbeteringen komen later

[Reactie gewijzigd door Belgar op 2 februari 2014 15:46]

Dat is een assumptie die je maakt. Wat er letterlijk staat is dat er geoptimaliseerd gaat worden voor de 270X en 280X, verder niets.

Het kan ook zijn dat verwacht wordt dat deze kaarten het grootste percentage van de markt gaan hebben, waardoor het voor de andere kaarten nog niet noodzakelijk of interessant is om te optimaliseren.
Je kan gelijk hebben, maar dat is niet uit het stukje dat b0art aanhaalt op te maken. :)
Ik maak helemaal geen assumptie, dat is gewoon een statement die AMD ook heeft gemaakt:
AMD Catalyst 14.1 Beta will support ALL desktop GCN products, though we are working with EA to further optimize performance on 280X, 270X, HD 7000 and HD 8000.
De verbeteringen voor kaarten gebaseerd op de oude architectuur is dus nog niet af.
Dat zegt alleen niks over de performance als Mantle wordt gebruikt met de 260X en 290X ;) Dus dat de performance bij die kaarten hoger ligt is, naar wat ik uit b0art zijn stuk opmaak, een assumptie. Ook in de quote die je zelf aanhaalt staat niks over de performance op de 260X en 290X, weer alleen dat er gekeken wordt naar optimalisaties voor de genoemde series.

Optimaliseren is iets anders dan ondersteuning toevoegen of afmaken. Bij optimaliseren wordt er eigenlijk geen functionaliteit meer toegevoegd, maar alleen herschreven zodat het met minder resources (CPU-cycles, geheugen e.d.) hetzelfde doet.

Dat wil dus zeggen dat wat er staat betekent dat de ondersteuning voor de HD 7000, HD 8000, 270X en 280X series al klaar is, maar dat er wordt gekeken of de implementatie van de ondersteuning beter, sneller en zuiniger kan werken.
That's it. Er wordt geen woord gerept over de 260X en 290X in de gegeven statements, waardoor daar, strikt genomen, ook geen oordeel over geveld kan worden. Daar is meer, en andere, informatie voor nodig om het te onderbouwen.

In dit artikel op wccftech staat een vergelijking tussen de 260X, 270X en 280X. Op basis van die informatie kan je wťl zeggen dat de performance gain met de 260X aanzienlijk groter is dan met de 270X en 280X.
AMD zou zich in de gehaaste driverrelease nu hebben beperkt tot voornamelijk de Radeon R9 290, R9 260X en de Kaveri APU's. Andere videokaarten en APU's zouden wel werken, maar moeten nog worden geoptimaliseerd in toekomstige driverversies. De Radeon R9 280X en R9 270X zouden hierdoor nauwelijks prestatieverbeteringen laten zien in Battlefield 4 vooralsnog.
Bron: HardwareInfo
Ook dit onderbouwd je punt, maar geeft wťl de 'juiste' informatie waarmee je het punt kan onderbouwen. :)
De focus heeft voor deze driver op de 260X, 290 en Kaveri APU's gelegen, waardoor de 270X en 280X nog weinig winst laten zien al worden ze al wel ondersteund. Ook hiervoor geldt weer dat er geoptimaliseerd moet worden, niet ondersteuning ingebouwd, maar ik neem aan dat het verschil wel duidelijk is. ;)
Die verwarring komt waarschijnlijk alleen omdat dat B0art selectief quote uit de release notes.

In de release notes staat namelijk duidelijk waar de mantle drivers op werken en vervolgens welke nog niet geoptimaliseerd zijn. Het was misschien handiger geweest van AMD om het om te draaien, maar dat kan ook met marketing te maken hebben.
mijn hd7970(stock) gaat op de testrange van 114 naar 160 FPS met mantel. (ik spawn op A en kijk naar het hoofd gebouw)

(phenom II x4 @3.8ghz )

CPU load gaat van 95-99 naar 90-95%

v-sync aan is strak 60 en een CPU load van 70-75% waar dat met dx11 ook 95-99% was

kan ik eindelijk die map op mijn 2de scherm gebruiken zonder framedrops.

als dit de verbeteringen zijn voor dat ze vergaand geoptimaliseerd hebben dan lijkt het me wel duidelijk: mantle is in iedergeval niet 'zeer' afhankelijk van de GPU-architectuur.

de hd7970 en de nieuwe r9 290's lijken wel veel op elkaar natuurlijk dus het zegt nog niet zo veel over wat het zou doen op een niet GCN GPU maar jij hebt dat al lang afgeschreven als onmogelijk terwijl iedereen die er mee gewerkt heeft zegt van niet. jij gaat toch geloven wat je wil tot nvidia of intel een mantle driver heeft gemaakt.
Dat AMD aan het uitzoeken is of er door middel van (kleine) aanpassingen in de driver of API nog meer performance te behalen is voor BF4 als er gebruik gemaakt wordt van de Mantle API.

Is ongeveer hetzelfde als wat NVIDIA al een tijdje doet voor zijn GeForce drivers, waarbij er op basis van profielen binnen de driver optimalisaties worden doorgevoerd en spellen 'nog meer' uit de grafische kaart kunnen trekken.
Komt bij mij over dat mantle nog niet helemaal lekker werkt op de bovenstaande kaarten. Ben benieuwd!
het optimalisatie process is er eentje die continue gaande is in GPU land. dat die extra optimalisaties nog niet zijn gedaan voor die wat oudere kaarten wil niet zeggen dat het verder niet goed functioneert.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True